[
https://issues.apache.org/jira/browse/IMAGING-251?focusedWorklogId=425524&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-425524
]
ASF GitHub Bot logged work on IMAGING-251:
------------------------------------------
Author: ASF GitHub Bot
Created on: 21/Apr/20 02:28
Start Date: 21/Apr/20 02:28
Worklog Time Spent: 10m
Work Description: gwlucastrig commented on issue #72:
URL: https://github.com/apache/commons-imaging/pull/72#issuecomment-616913125
I thought I should point out one aspect of the new API elements that I think
is not optimal. When I added the getFloatingPointRasterData() method to the
TiffDirectory class, I had it take ByteOrder as an argument. I took this
approach because the existing "getTiffImage" methods did the same thing. But as
I look at the unit tests and example applications that use it, it seems awkward
to make the code handle a data element that is extraneous to the task that it
is trying to accomplish. It's just one extra thing for a developer to have to
keep track of and doesn't give him any added capability.
I've done some research and studied the TIFF specification, and it's clear
that byte order is only specified one place in a TIFF file and doesn't change
once the header section of the file is read. So I think a better approach to
the new functionality would be to make the TiffDirectory class have byte-order
as a member element that was populated by the constructors. Then the
getFloatingPointRasterData() would not need it as an argument.
Since I've already said that I've "finished" this Pull Request (pending your
review), I won't burden you with more changes... But I may submit the change
as a future PR, if you think it a good idea.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
Issue Time Tracking
-------------------
Worklog Id: (was: 425524)
Time Spent: 6h 40m (was: 6.5h)
> 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
>
> Attachments: Imaging252_USGS_n38w077.jpg
>
> Time Spent: 6h 40m
> Remaining Estimate: 0h
>
> 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)
