[
https://issues.apache.org/jira/browse/IMAGING-312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Lucas updated IMAGING-312:
-------------------------------
Attachment: Imaging312.png
> 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
> Attachments: Imaging312.png
>
>
> 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)
