[
https://issues.apache.org/jira/browse/IMAGING-102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruno P. Kinoshita resolved IMAGING-102.
----------------------------------------
Fix Version/s: (was: Patch Needed)
Assignee: Bruno P. Kinoshita
Resolution: Duplicate
> 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: Improvement
> Reporter: Gary Lucas
> Assignee: Bruno P. Kinoshita
> Priority: Major
> Attachments: Sample64BitFloatingPointPix451x337.jpg,
> Sample64BitFloatingPointPix451x337.tif
>
>
> 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 was sent by Atlassian Jira
(v8.3.4#803005)
