[gdal-dev] GDAL alpha channels

[Even Rouault]

Le mardi 29 mai 2012 23:12:45, Frank Warmerdam a écrit :
> Craig,
> 
> My opinion is that applications should assume alpha is not pre-multiplied.
> I have been hesitant to "un-premultiply" premultiplied TIFF images - partly
> because it is hard to hit all the appropriate code paths safely and partly
> because the result will be lossy.
> 
> Going forward GDAL should do one of two things:
> 
> 1) provide a metadata item so applications can know those rare
> circumstances when alpha is pre-multiplied.
> 
> 2) un-premultiply premultiplied alpha when encountered.
> 
> As you note it doesn't really matter when alpha is primarily used
> for on/off masking so we have gotten away over the years with
> only a few complaints about the topic.

There will be likely a compatibility problem if we do this, because GDAL up to 
now writes TIFF RGBA images with EXTRASAMPLE_ASSOCALPHA (pre-multiplied), but 
I think in most cases the data that people have feed in the GTiff driver was 
not pre-multiplied. So if we un-premultiply this would cause issues in case 
the alpha value is not 0 or 255.

And a few other software seem to also actually ignore the flag. For example, I 
gdal_translated autotest/gcore/data/stefan_full_rgba.png (that contains values 
in the alpha band that are different from 0 and 255) to a TIFF image, and 
opened it with GIMP and resaved it as a PNG. The out PNG is the same as the 
input PNG. Same with the 'convert' utility from ImageMagick.

Other interesting experiment, open the original PNG with GIMP and save it as a 
TIFF : GIMP also sets the extra sample flag to EXTRASAMPLE_ASSOCALPHA but 
writes non-associated values.
With convert from ImageMagick, PNG->TIFF gives EXTRASAMPLE_UNASSALPHA this 
time, but the data is still non-associated.

So, basically those 2 software happily ignore the value of the extra sample 
flag, write different values for it, and interpret it as unassociated.

On the other hand, I've tested with GlobalMapper, and it displays only 
correctly the TIFF converted with ImageMagick (the one where 
EXTRASAMPLE_UNASSALPHA is set). So at first sight, it seems to honour the flag 
properly.

The temporary conclusion of that is that there are likely images in the wild 
where the value of the flag does not reflect the reality of the imagery 
values... But, GDAL should likely be fixed to set EXTRASAMPLE_UNASSALPHA to 
better reflect the way it is generally used (presumably).

Best regards,

Even