[
https://issues.apache.org/jira/browse/IMAGING-251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17070560#comment-17070560
]
Gary Lucas commented on IMAGING-251:
------------------------------------
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)
