[
https://issues.apache.org/jira/browse/IMAGING-251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17056931#comment-17056931
]
Gary Lucas commented on IMAGING-251:
------------------------------------
Thanks for the comments. I use Commons Imaging in a weather application at
work myself. We wrote our own rendering and mapping logic, and we depend on
Commons Imaging to bring up GeoTIFF images of orthorectified aerial
photographs, FAA sectional charts, and a few other products. I used to have a
source of weather radar images in GeoTIFF, but we don't have one right now.
I contributed some TIFF-performance enhancements to Commons Imaging some years
back, so I am familiar with the general organization of the project... Though
changed a bit since the last time I took code. I'll brush up on the
contribution guidelines and make sure I follow the project coding style.
*Implementation Approach*
I think that the access for floating-point data is really specific to TIFF
formats and won't propagate to other imaging formats or other Java packages in
the Commons Imaging code base. That should save a lot of complications and
avoid changing any code outside the TIFF package. So everything will be done
inside org.apache.commons.imaging.formats.tiff.
I will focus on the reading operations and save writing operations for a
future effort.
Applications would access the data by using the TiffReader class directly to
pull out TiffDirectory instances. I would add access methods for pulling out
floating point rasters from the TiffDirectory. Under the hood, I would add
code to DataReaderStrips and DataReaderTiles. Some TIFF raster files are
huge. The test data I am using reads a 10800-by-10800 pixel data source, but
I've seen larger. So my implementation would support the sub-image feature
that is currently built into the TIFF readers.
Since the output floating-point raster data is not really suitable for
representation using a BufferedImage, I may end up writing a simple "raster
data result class" for the output. The class would probably give width,
height, and a one-dimensional array of Java floats. I don't know whether this
would be better put into the TIFF format package or into the
commons.imaging.common package. Suggestions are welcome.
I've got lots of data for 32 bit floats, but TIFF also permits the
specification of weird formats like 24-bit floats and 16-bit floats. The 16-bit
format features so few digits of precision that I would be surprised if anyone
actually uses it. So I will give that a low priority.
*Request for Data Samples*
If anyone has data samples for floating-point data given in GeoTIFF format,
please let me know. I will do some digging myself (especially with regard to
the 24-bit format), and am sure I can find example products.... But I'd prefer
to focus my efforts on data that is actively being used in current
applications.
> 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)
