[
https://issues.apache.org/jira/browse/IMAGING-312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17413798#comment-17413798
]
Bruno P. Kinoshita commented on IMAGING-312:
Hi [~gwlucas] ,
Excellent issue description, thanks a lot. I had a look at the TIFF spec rev
6.0 this morning. I think the specification could do a much better job at
saying that when that field is 0 it must be ignored. I read it as values
greater than 0 are used to choose what to do about the extra data... but since
it didn't explicitly say "if 0 then ignore the extra data" I think I understand
why a developer would forget to handle cases where ExtraSamples is to be
ignored, even if we have the extra data.
I think we should go with your solution and choose later - based on user
feedback - whether we need a parameter to enable/disable it, or maybe raise an
exception in some special situations.
Thanks!
Bruno
> 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
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> 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)