[
https://issues.apache.org/jira/browse/IMAGING-312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Lucas updated IMAGING-312:
-------------------------------
Description:
Commons Imaging sometimes misinterprets TIFF files that have 4-byte RGB samples
but do not define alpha. In some cases, these images are treated as
semi-transparent when they should be opaque. Commons Imaging is not unique in
this regard... Windows Photo Viewer does the same thing.
The TIFF specification allows RGB images to be encoded with 4-bytes per pixel.
It would be natural to assume (as Commons Imaging does) that the 4th byte is
the alpha channel and that it would have values of 0xff in the case where
pixels were opaque. However, the interpretation of the 4th byte depends on
information in the TIFF "ExtraSamples" tag.
It turns out that there are images in-the-wild that use 4 bytes, but populate
the 4th byte with junk values. For example, there are a number of older aerial
photographs from the US Geological Survey (USGS) that do this. These images
give an ExtraSamples tag with a value of zero. But the TIFF specification
calls for images to be treated as having alpha channels only if the
ExtraSamples field carries a value of either 1 or 2. When ExtraSamples has a
value of 0, the 4th byte is to be ignored.
So while the USGS TIFF files are in compliance with the TIFF specification,
they use an unintuitive behavior. Because the Commons Imaging library assumes
that the 4th byte would be specified with valid-alpha values, it does not
render the images correctly.
There are many examples of this phenomenon on the USGS Earth Explorer website.
One specific example:
* High Resolution Orthoimagery
* Dataset: 201203_connecticut_state_lot1_ct_0x3000m_utm_cnir
* Entity: 2818289_18TYL425825
* File: 18tyl425825.tif
*Proposed Fix*
I propose to do the following:
* Extend the TiffImageParser logic for detecting alpha to assume hasAlpha is
true if and only if the ExtraSamples tag is supplied and contains values 1 or
2.
* Provide a hasAlpha accessor for the ImageBuilder class (is should really have
one anyway)
* Enhance the DataReaderStrips and DataReaderTiles classes to check hasAlpha
when processing RGB images that have 4 samples per pixel samples.
*Concerns*
At this time, I am not sure what to do if an RGB TIFF image uses 4-samples per
pixel but the ExtraSamples tag is not provided. At this time, I have not seen
an example of this, but my collection of sample TIFF files is rather narrow and
I would not rule it out.
was:
Commons Imaging sometimes misinterprets TIFF files that have 4-byte RGB samples
but do not define alpha. In some cases, these images are treated as
semi-transparent when they should be opaque. Commons Imaging is not unique in
this regard... Windows Photo Viewer does the same thing.
The TIFF specification allows RGB images to be encoded with 4-bytes per pixel.
It would be natural to assume (as Commons Imaging does) that the 4th byte is
the alpha channel and that it would have values of 0xff in the case where
pixels were opaque. However, the interpretation of the 4th byte depends on
information in the TIFF "ExtraSamples" tag.
It turns out that there are images in-the-wild that use 4 bytes, but populate
the 4th byte with junk values. For example, there are a number of older aerial
photographs from the US Geological Survey (USGS) that do this. These images
give an ExtraSamples tag with a value of zero. But the TIFF specification
calls for images to be treated as having alpha channels only if the
ExtraSamples field carries a value of either 1 or 2. When ExtraSamples has a
value of 0, the 4th byte is to be ignored.
There are many examples of this phenomenon on the USGS Earth Explorer website.
One specific example:
* High Resolution Orthoimagery
* Dataset: 201203_connecticut_state_lot1_ct_0x3000m_utm_cnir
* Entity: 2818289_18TYL425825
* File: 18tyl425825.tif
*Proposed Fix*
I propose to do the following:
* Extend the TiffImageParser logic for detecting alpha to assume hasAlpha is
true if and only if the ExtraSamples tag is supplied and contains values 1 or
2.
* Provide a hasAlpha accessor for the ImageBuilder class (is should really have
one anyway)
* Enhance the DataReaderStrips and DataReaderTiles classes to check hasAlpha
when processing RGB images that have 4 samples per pixel samples.
*Concerns*
At this time, I am not sure what to do if an RGB TIFF image uses 4-samples per
pixel but the ExtraSamples tag is not provided. At this time, I have not seen
an example of this, but my collection of sample TIFF files is rather narrow and
I would not rule it out.
> Alpha-channel setting not interpreted from ExtraSamples tag
> -----------------------------------------------------------
>
> Key: IMAGING-312
> URL: https://issues.apache.org/jira/browse/IMAGING-312
> Project: Commons Imaging
> Issue Type: Bug
> Components: Format: TIFF
> Affects Versions: 1.0-alpha2
> Environment:
> Reporter: Gary Lucas
> Priority: Major
>
> Commons Imaging sometimes misinterprets TIFF files that have 4-byte RGB
> samples but do not define alpha. In some cases, these images are treated as
> semi-transparent when they should be opaque. Commons Imaging is not unique
> in this regard... Windows Photo Viewer does the same thing.
> The TIFF specification allows RGB images to be encoded with 4-bytes per
> pixel. It would be natural to assume (as Commons Imaging does) that the 4th
> byte is the alpha channel and that it would have values of 0xff in the case
> where pixels were opaque. However, the interpretation of the 4th byte depends
> on information in the TIFF "ExtraSamples" tag.
> It turns out that there are images in-the-wild that use 4 bytes, but populate
> the 4th byte with junk values. For example, there are a number of older
> aerial photographs from the US Geological Survey (USGS) that do this. These
> images give an ExtraSamples tag with a value of zero. But the TIFF
> specification calls for images to be treated as having alpha channels only if
> the ExtraSamples field carries a value of either 1 or 2. When ExtraSamples
> has a value of 0, the 4th byte is to be ignored.
> So while the USGS TIFF files are in compliance with the TIFF specification,
> they use an unintuitive behavior. Because the Commons Imaging library
> assumes that the 4th byte would be specified with valid-alpha values, it does
> not render the images correctly.
> There are many examples of this phenomenon on the USGS Earth Explorer
> website. One specific example:
> * High Resolution Orthoimagery
> * Dataset: 201203_connecticut_state_lot1_ct_0x3000m_utm_cnir
> * Entity: 2818289_18TYL425825
> * File: 18tyl425825.tif
> *Proposed Fix*
> I propose to do the following:
> * Extend the TiffImageParser logic for detecting alpha to assume hasAlpha is
> true if and only if the ExtraSamples tag is supplied and contains values 1 or
> 2.
> * Provide a hasAlpha accessor for the ImageBuilder class (is should really
> have one anyway)
> * Enhance the DataReaderStrips and DataReaderTiles classes to check hasAlpha
> when processing RGB images that have 4 samples per pixel samples.
> *Concerns*
> At this time, I am not sure what to do if an RGB TIFF image uses 4-samples
> per pixel but the ExtraSamples tag is not provided. At this time, I have not
> seen an example of this, but my collection of sample TIFF files is rather
> narrow and I would not rule it out.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
