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 _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
