I am all for fixing a regression in functionality, do you have a specific bug report in mind here?
It sounds like you have a fix in mind, if this is just a regression I do not think a change request will be required. If you need an API change then we can go through the usual channels (make a wiki page proposal describing the API change and so forth). Jody -- Jody Garnett On 14 October 2015 at 02:29, Ville Karppinen <[email protected]> wrote: > 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] > > > > ------------------------------------------------------------------------------ > _______________________________________________ > GeoTools-Devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/geotools-devel >
------------------------------------------------------------------------------
_______________________________________________ GeoTools-Devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
