[jira] [Commented] (IMAGING-266) Read integer data from GeoTIFFS

["Bruno P. Kinoshita (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/IMAGING-266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17413428#comment-17413428 ] 

Bruno P. Kinoshita commented on IMAGING-266:
--------------------------------------------

>Does anyone know if the 32-bit version is worth supporting? My criteria for determining that would be based on whether there is a significant number of projects using that format (life is too short to chase rarely used data formats).

Sorry, wasn't even aware of the 16-bit :)

>Currently, one of the code-analysis operations conducted by the Commons Imaging build process is coverage by JUnit tests. Lacking any test data for the 32-bit case, I am reluctant to include it in the code base because it would mean putting uncovered code into the distribution.

Agreed, sensible decision.

>Also, I am wondering about the best design for the access API. The current TiffImageParser class has a method called getFloatingPointRasterData() that returns an instance of TiffRasterData. TiffRasterData is pretty much hard-wired to floating point data. I am thinking of creating a new method called getIntegerRasterData() that would return an instance of a new class called TiffIntegerRasterData. Does this seem reasonable? I considered trying to combine both kinds of results into a unified class and method, but it seems more unwieldy than useful. 

I think there might be pros and cons to both. Let's try to release with the approach you thought would work better and see if we get any feedback. IMO either would be fine, from the POV of a developer that could use the API to process some tiff/geotiff.

>I researched this feature request and what I've found is basically a mix of good news and bad news. The good news is that the ImageBuilder API can be used as a way of storing the integer data. I looked into the idea of just storing the integer data in the BufferedImage output from the file, but it had too much of an improvisational flavor for my liking. It would also mean performing an extra transcription of the data. During processing, the ImageBuilder is used as a temporary container for pixel information while it is being extracted from the TIFF file and collected for output. 

(y) using the BufferedImage could generate other problems if someone serialized it I think. Not sure if it wouldn't cause image editors to fail to parse it. Safer to use the ImageBuilder IMO.

>So my plan is to just provide an API element that exposes the ImageBuilder instance to the application. This addition can be accomplished with minimal changes to the existing code base.

+1

>Even though it is common to think of RGB values as consisting of three bytes (three "samples", one for each color), there is nothing fundamental about the specification of 8 bits per sample. For example, the current GOES-R generation of weather satellites use 12-bit imaging channels to give better discrimination of cloud and ground radiance values. Older satellite images frequently used 10 bits.

#TodayILearned.

>I propose the following: The Commons Imaging API permits an application to pass in a custom photometric interpreter. The new feature will implement a special processing rule so that, when the application passes in a customer photometric interpreter, the data readers will retain the full precision for the samples. Eight bit samples will stay 8 bits. Four bit samples will stay 4. And the 16 bit samples in the elevation products will stay 16. Presumably, an application that takes the trouble to supply a custom photometric interpreter will want to handle the data exactly as it appears in its source TIFF files. And, since the ability to specify custom photometric interpreters is a relatively new feature (only a few months old), it is unlikely that this change will interfere with any existing code.

Sounds sensible to me too. Unfortunately for this level of detail when discussing an API like our TIFF image reader/parser, the only way to provide good feedback is by using the API in real life projects (which I don't have one).

>Please let me know if you have any suggestions or insights that I may have missed.

Will finish the code review now that I have read the issue, and see if I can provide any feedback. Thanks a lot for the code contribution (with tests!)  and for the documentation (in the code, and here in the issue!).

Bruno

> Read integer data  from GeoTIFFS
> --------------------------------
>
>                 Key: IMAGING-266
>                 URL: https://issues.apache.org/jira/browse/IMAGING-266
>             Project: Commons Imaging
>          Issue Type: New Feature
>          Components: Format: TIFF
>    Affects Versions: 1.0-alpha3
>            Reporter: Gary Lucas
>            Priority: Major
>          Time Spent: 2h 10m
>  Remaining Estimate: 0h
>
> I recently discovered that there is a large amount of digital elevation data available in the form of 16-bit integer coded data in GeoTIFF files (TIFF files with geographic tags).  I propose to enhance the Commons Imaging API to read these files.  This work will be similar to the work I did for reading floating-point raster data under ISSUE-251.
> Available data include the nearly-global coverage of one-second of arc elevation data produced from the Shuttle Radar Topography Mission (SRTM) and other sources. These products give grids of elevation data with a 30 meter cell spacing for most of the world's land masses. They are available at NASA Earthdata and Japan Space Systems websites, see [https://asterweb.jpl.nasa.gov/gdem.asp|https://asterweb.jpl.nasa.gov/gdem.asp] There is also a ocean bathymetry data set available in this format at [http://www.shadedrelief.com/blue-earth/]
> This new feature will continue to expand the usefulness of the Commons Imaging API in accessing GeoTIFF products.
> Request for Feedback
> So far, the data products I've found (ASTER and Blue Earth Bathymetry) give elevation and ocean depth data in meters recorded as a short integer.  I haven't found an example of where the 32-bit integer format is used.  For now, I am planning on only coding the 16-bit integer variation.  Does anyone know if the 32-bit version is worth supporting?  My criteria for determining that would be based on whether there is a significant number of projects using that format (life is too short to chase rarely used data formats).
> Currently, one of the code-analysis operations conducted by the Commons Imaging build process is coverage by JUnit tests.  Lacking any test data for the 32-bit case, I am reluctant to include it in the code base because it would mean putting uncovered code into the distribution.
> Also, I am wondering about the best design for the access API.  The current TiffImageParser class has a method called getFloatingPointRasterData() that returns an instance of TiffRasterData.  TiffRasterData is pretty much hard-wired to floating point data.  I am thinking of creating a new method called getIntegerRasterData() that would return an instance of a new class called TiffIntegerRasterData. Does this seem reasonable?  I considered trying to combine both kinds of results into a unified class and method, but it seems more unwieldy than useful. 
>  
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)