[
https://issues.apache.org/jira/browse/IMAGING-102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13581245#comment-13581245
]
Gary Lucas commented on IMAGING-102:
------------------------------------
I have obtained permission to contribute a sample satellite image in the 64bit
floating point format from the data supplier. This 451x337 image stores data
using IEEE 754 formatted floating point values in the range 0 to 1.0 which is
ultimately scaled to a 16 bit grayscale. I am assuming that the gray scale is
a non-gamma-corrected, linear intensity scale. The data also includes values
of -9999 which are interpreted as no-data values. As far as I can gather, this
appears to be a convention that is used for scientific data, though the TIFF
6.0 spec only gives partial details.
In the implementation I am working on, I treat the -9999 values as transparent
pixels. Conventionally, the TIFF format does not support transparent pixels,
but this appears to be the appropriate choice. I haven't made up my mind about
what to do with regard to gamma correction. I will probably look at some
C-language open-source implementations for guidance.
> TIFF parser does not support floating-point images
> --------------------------------------------------
>
> Key: IMAGING-102
> URL: https://issues.apache.org/jira/browse/IMAGING-102
> Project: Commons Imaging
> Issue Type: Bug
> Reporter: Gary Lucas
>
> The TIFF specification defines a data form for storing pixels as either
> 32-bit or 64-bit floating point values given in the IEEE 754 format. The
> TIFF-6 specification is actually incomplete in this regard, but typically
> such values are stored as data in the range [0,1] with 9999 (or other values
> out of the range zero to one) used to indicate "no-data". Typically, values
> are rendered in gray tones. The TIFF "SampleFormat" tag indicates when data
> is encoded in this form.
> Commons Imaging does not currently support data that uses the floating-point
> sample format. It does define a constant in the TiffTagConstants.java file
> which is named SAMPLE_FORMAT_VALUE_IEEE_FLOATING_POINT. But this constant is
> not used in the code.
> I propose to at least implement read-support for images in this format. I am
> working to obtain permission to post a sample image which I will attach to
> this tracker item in the future.
> Currently, the TIFF parser provides output in the form of a BufferedImage.
> For the initial implementation, I recommend staying with that convention and
> resolving the floating point values to gray tones. Although this approach has
> the disadvantage that it will not provide an API for extracting the original
> floating-point values, it seems to me the safest tactic for an initial
> implementation.
> Development will require some caution to avoid degrading parser performance.
> The BitImageStream.readBits() method which reads samples (pixels) from the
> source data, currently returns the Java int type, which only supports 32
> bits. To support 64 bits, this function would have to return a Java long.
> The development effort will require testing to ensure that making a change of
> this type does not degrade performance for the mainstream TIFF data formats
> (probably this is only an issue on 32-bit operating systems).
> For those of you who are asking why someone would choose to store data using
> floating-point values (at the cost of 64 bits per pixel)... I don't really
> know. Putting aside the fact that it's in the spec (sort of) and somebody
> wants me to plot data from such images, I would have to say the motivation
> would probably be using TIFF files as a way of storing arbitrary data in
> gridded fields. The proposed changes wouldn't satisfy their requirements,
> but it is a first step in that direction.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
