Hi Jody,
I am not aware of any JIRA ticket related to this issue and I have not
created one. I was thinking that I just ask green light here before
sending the pull request in GitHub. I would say this is just a small
regression fix in the implementation point of view and there is no need
for any API changes. So, I do not see any need for wiki updates about
API change or change request ticket in JIRA. Of course, I may create a
JIRA ticket if one is requested.
I will still give couple of days for others to think about this change
if necessary. And, maybe I could make the pull request at some point
next week, for example on Thursday, if nobody disagrees about this
change before that.
Best regards,
Ville Karppinen
[email protected]
On 10/15/2015 07:16 PM, Jody Garnett wrote:
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]
<mailto:[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] <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
