[
https://issues.apache.org/jira/browse/IMAGING-102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Lucas updated IMAGING-102:
-------------------------------
Description:
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.
was:
The TIFF specification defines a data form for storing pixels as either 32-bit
or 64-bit floating point values given in the IEEE 753 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.
> 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
