Ciao Simone,

This change would give 16-bit target images only for GS queries that use GS style similar to &style=raster and &format=image/tiff or geotiff or png. So, this should only have an effect on tiff/geotiff/png image formats and only if GS style uses RasterSymbolizer without ColorMap. Then, the decision between 8-bit and 16-bit is defined by &format-parameter with values tiff8 vs. tiff, geotiff8 vs. geotiff or png8 vs png. I am not sure if this change will cover all use cases. But, hopefully it is adequate for now.

I have build GT (mvn clean install -Dall) and all tests pass. Notice, I have made some changes also to test cases.

But, it seems that I have made newbie mistake related to testing with GS. I only build GT and run test cases there. Then, tested prebuild GS only with my own test URLs after copying GT jar-file to lib-folder. Now, that I built the GS master branch and used my own version of GT, there seems to be at least one GS test case that fails.
-- clip -->
Tests in error:
  testInterpolations(org.geoserver.wms.map.GIFMapResponseTest)
testInterpolations(org.geoserver.wms.map.RenderedImageMapOutputFormatTest)
..
[INFO] Web Map Service Module ............................ FAILURE
<-- clip --

So, it seems that I need to study also GS source related to the GT change before making the GT pull request. And, most likely some GS pull request is also needed to make tests pass. I let you know when I know more about this. So, let's see about the pull request after that.

Best regards,

Ville Karppinen
[email protected]

On 10/18/2015 01:49 PM, Simone Giannecchini wrote:

Ciao Ville,
I have recently reviewed work on the rastersymbolizer to enhance contrast stretch capabilities (more should come shortly) and I also tried to hack in again the support for 16 bits in a comprehensive way.

You change is ok but of my memory serves me right is not enough.

Couple of questions:
- have you run a full build of GT?
- have you run a full byld of GS?

If I remember correctly, this change would not cover all use cases. At least we would need some code GS wise to decide the bit depth prior to rendering.

If all test passes, move ahead with a PR and I will make sure we look into it next with Daniele or Andrea.

Simone.

Il 14/Ott/2015 12:56, "Ville Karppinen" <[email protected] <mailto:[email protected]>> ha scritto:

    Hi,

    I have a change proposal for you on how GeoTools should handle 16-bit
    raster content.

    At the moment, geotools rescales 16-bit (ushort) source raster content
    to 8-bit. In case of 16-bit source raster data, this may result to
    target image that has lost valuable information, which in some use
    cases
    may not be acceptable. Therefore, I propose that geotools would pass
    16-bit source raster content as 16-bit target image unless 8-bit
    target
    image is explicitly requested. The change required to the source
    code is
    really simple and can be viewed here:
    https://github.com/TheKarppinen/geotools/tree/fix_16bit_raster
    I have included in the commit also necessary changes to test cases.

    I think 16-bit target image would be good feature also from the
    GeoServer use case points of view. At the moment, GeoServer
    queries may
    define image format in URL. 8-bit images can be explicitly
    queried, for
    example geotiff8, tiff8, or png8 (FORMAT=image/geotiff8 vs
    FORMAT=image/geotiff). But, if FORMAT=image/geotiff is used with
    raster
    style, the target image bit-accuracy should correspond the source
    data,
    instead of always being 8-bit.

    Also, GeoServer and GeoTools have provided 16-bit target content when
    16-bit raster data was queried in previous versions. This behavior has
    changed at some point after GeoServer 2.5 that included GeoTools
    version
    11.0. So, in that sense the change to provide 16-bit target images
    would
    actually provide same behavior that has already been there before.

    I was thinking to make a pull request for this change. But, wanted to
    ask about additional comments here first. So, do you think that I may
    make the pull request and this change will be included to GeoTools
    master branch at some point?

    The change is quite small and I am not sure if contribution license is
    required for this. Anyway, I am working for Finnish Meteorological
    Institute and our team has already signed the license. Personally
    for me
    this pull request would be the first one. So, I am newbie with the
    process.


    Here are still some example results when 16-bit raster content has
    been
    queried from GeoServer and target image content is checked by using
    identify-program:

    GeoServer query for 16-bit source content by using
    format=image/geotiff
    current GeoTools implementation gives:
      TIFF 485x768 485x768+0+0 8-bit Grayscale DirectClass 373KB
    vs. fixed implementation gives:
      TIFF 485x768 485x768+0+0 16-bit Grayscale DirectClass 746KB

    GeoServer query for 16-bit source content by using format=image/tiff
    current  GeoTools implementation gives:
      TIFF 485x768 485x768+0+0 8-bit Grayscale DirectClass 373KB
    vs. fixed implementation gives:
      TIFF 485x768 485x768+0+0 16-bit Grayscale DirectClass 746KB

    GeoServer query for 16-bit source content by using format=image/png
    current  GeoTools implementation gives:
      PNG 485x768 485x768+0+0 8-bit PseudoClass 256c 9.67KB
    vs. fixed implementation gives:
      PNG 485x768 485x768+0+0 16-bit PseudoClass 65536c 66.4KB


    Best regards,

    --
    Ville Karppinen
    [email protected] <mailto:[email protected]>


    
------------------------------------------------------------------------------
    _______________________________________________
    GeoTools-Devel mailing list
    [email protected]
    <mailto:[email protected]>
    https://lists.sourceforge.net/lists/listinfo/geotools-devel


------------------------------------------------------------------------------
_______________________________________________
GeoTools-Devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Reply via email to