[jira] [Comment Edited] (IMAGING-251) Support TIFF standard floating point data

["Gary Lucas (Jira)" <ji...@apache.org>]

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

Gary Lucas edited comment on IMAGING-251 at 3/29/20, 10:55 PM:
---------------------------------------------------------------

Fortunately, it should be possible to fit this change into the TIFF packages without changing the existing APIs. The original authors of the TIFF modules did a pretty thorough job (I wish I knew the story behind the original Sanselan code), and there is a precedent for this kind of thing.

The trick is to read the TIFF image using some of the low-level classes in the package org.apache.commons.imaging.formats.tiff package.  The API is specific to TIFF, so the changes will not overlap into other data formats (JPEG, GIF, PNG, etc.).  A TIFF file consists of entities called "Directories" which are essentially bundles of information, including images.  A TIFF file may contain multiple images. The TiffReader class allows you to read the directories.  The Directory class has a method called getTiffImage() which gets a Java BufferedImage from the source.

The key is that the getTiffImage() method takes a Java Map<String, Object> as an input parameter.  The code uses the parameters to allow the calling module to specify options for reading the data.  For example, some TIFF images are HUGE, but if you have limited memory you can use the parameters map to specify a sub-image.  

In my new code, I have specified a new option that allows an application to populate the parameter map with an object of type PhotometricInterpreter that extends the base class to support interpretation of floating-point data.    This setting would override the interpreter specified by the TIFF input. Other than that, it wouldn't change a thing that the existing code does.

One area where I would *_really_* welcome some help is in how to specify a palette.  To render floating-point values, we need some range-based specification to map numerical values to colors.  For example, if we have a TIFF file that gives elevation (positive values) and water depth (negative values) as floating-point numbers, I'd want a palette that could map positive values to greenish/brownish color and negative values to blueish colors.  Now, coming up with a way to do this is easy.  I can think of three or four just off the top of my head. But what I'm really looking for is a way to do it that could provide some compatibility with existing API's already in use "out there".  Of course, I wouldn't want to give commons-imaging a dependency on another package.  But I want to at least use an approach that other developers would understand pretty quickly.

So I've been doing some web searches looking for existing palette implementations to see how other API's have done it.  So far, nothing really seems better than anything else, but I am still looking.

Finally, I note that it took me a lot of time to figure out the API used for TIFF files by commons-imaging.  I'd like to spare others going through that effort. So one of the things I plan on doing in the near future is to put together some example applications for the Commons-Imaging's "examples" folder (which is under the "test" folder).




was (Author: gwlucas):
Fortunately, it should be possible to fit this change into the TIFF packages without changing the existing APIs. The original authors of the TIFF modules did a pretty thorough job (I wish I knew the story behind the original Sanselan code), and there is a precedent for this kind of thing.

The trick is to read the TIFF image using some of the low-level classes in the package org.apache.commons.imaging.formats.tiff package.  The API is specific to TIFF, so the changes will not overlap into other data formats (JPEG, GIF, PNG, etc.).  A TIFF file consists of entities called "Directories" which are essentially bundles of information, including images.  A TIFF file may contain multiple images. The TiffReader class allows you to read the directories.  The Directory class has a method called getTiffImage() which gets a Java BufferedImage from the source.

The key is that the getTiffImage() method takes a Java Map<String, Object> as an input parameter.  The code uses the parameters to allow the calling module to specify options for reading the data.  For example, some TIFF images are HUGE, but if you have limited memory you can use the parameters map to specify a sub-image.  

In my new code, I have specified a new option that allows an application to populate the parameter map with an object of type PhotometricInterpreter that extends the base class to support interpretation of floating-point data.    This setting would override the interpreter specified by the TIFF input. Other than that, it wouldn't change a thing that the existing code does.

One area where I would *_really_* welcome some help is in how to specify a palette.  To render floating-point values, we need some range-based specification to map numerical values to colors.  For example, if we have a TIFF file that gives elevation (positive values) and water depth (negative values) as floating-point numbers, I'd want a palette that could map positive values to greenish/brownish color and negative values to blueish colors.  Now, coming up with a way to do this is easy.  I can think of three or four just off the top of my head. But what I'm really looking for is a way to do it that could provide some compatibility with existing API's already in use "out there".  Of course, I wouldn't want to give commons-imaging a dependency on another package.  But I want to at least use an approach that other developers would understand pretty quickly.

Finally, I note that it took me a _lot_ of effort to figure out the API used for TIFF files by commons-imaging.  So one of the things I plan on doing in the near future is to put together some example applications for the Commons-Imaging's "examples" folder



> Support TIFF standard floating point data
> -----------------------------------------
>
>                 Key: IMAGING-251
>                 URL: https://issues.apache.org/jira/browse/IMAGING-251
>             Project: Commons Imaging
>          Issue Type: New Feature
>          Components: Format: TIFF
>    Affects Versions: 1.x
>            Reporter: Gary Lucas
>            Priority: Major
>             Fix For: 1.x
>
>
> Commons Imaging does not support the floating-point format included in the TIFF specification. There are prominent data sources that issue products in this format. The ability to support this information would open up new application areas for Commons Imaging.
> TIFF is often used as a mechanism for distributing data from geophysical applications in the form of GeoTIFF files.  Some of this is not imagery, but data. For example, the US Geological Survey is currently releasing high-resolution elevation data grids for the 3DEP program under the name Cloud-Optimized GeoTIFF (COG). It is a substantial data set with significant potential commercial and academic applications.
> To access this data means modifying the TIFF DataReaderStrips and DataReaderTile classes to recognize floating point data (which is typically indicated using TIFF tag #339, SampleFormat). Also, returning the data in the form of a BufferedImage makes no sense at all, so the API on the TiffImageParser and supporting classes would need additional methods to return arrays of floats.  The good news here is that that requirement would mean adding new methods to the classes rather than making significant changes to existing classes. So the probability of unintended consequences or new bugs in existing code would be minimized.
> Specification details for floating-point are given in the main TIFF-6 documentations and Adobe Photoshop TIFF Technical Note 3.
>  
> I am willing to volunteer to make these changes provided that there is interest and a high probability that my contributions would be evaluated and, if suitable, integrated into the Commons Imaging code base. 
> Thank you for your attention in this matter.
>  



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