[gdal-dev] GDAL alpha channels

[Craig Bruce]

Tamas Szekeres <szekerest at gmail.com> wrote:

> I have added a ticked for such an issue long ago, but I don't remember
> what would be the expected solution.
> http://trac.osgeo.org/gdal/ticket/2279
>
> There should be an external config option to instruct the driver which
> representation should be used.

I think it would be better for GDAL to present a single alpha model through
its interface, as it does with the pixel-is-area vs. pixel-is-point
issue.  As far as I am aware, TIFF is the only common format that uses
a pre-multiplied alpha.  However, pre-multiplied alphas present a number
of problems, including strange or non-integration with color models other
than RGB, and throwing away useful information.  For example, if you take
a pre-multiplied RGBA TIFF and need to write it out to a nodata-valued
output format (effectively, a 1-bit alpha channel), you need to recreate
the information that pre-multiplication threw away, and this can only be
done approximately.  The better fixed model to use is non-pre-multiplied,
like PNG uses.

At the moment, all GDAL applications process alpha values incorrectly
(since it's not possible _to_ process them correctly).  I'm not sure
if many people have noticed this or if or what they've done about it,
if anything.  The problem may be obscured because for sources with
alpha values of only 0 and MAX, there really isn't a problem.  Do any
applications expect pre-multiplied alphas?  If so, they're only getting
them from some TIFF images and are processing other sources incorrectly.

--------------------------+----------------------+--------------------------
Dr. Craig S. Bruce        | Ph 819-771-8303 x205 |             CubeWerx Inc.
Senior Software Developer |   Fax 819-771-8388   |  Gatineau, Québec, Canada
csbruce at cubewerx.com      |  http://csbruce.com/ |  http://www.cubewerx.com/
--------------------------+----------------------+--------------------------
            "All the world's a player and we are merely stages."