2009.04.28 20:37 "Re: [Tiff] Question regarding unassociated alpha", by Chris Cox

Everyone seems to be using unassociated to mean that the alpha channel is not associated with the color data ­ ie: just extra information, not opacity.

" Unassociated alpha data is transparency information that logically exists independent of an image; it is commonly called a soft matte."

That implies that unassociated alpha is not opacity at all, or at best a selection/matte independent of the color data. That is how Photoshop and most other apps use the unassociated channels (though Photoshop will read and preserve up to 56 extra channels).

"Note that including both unassociated and associated alpha is undefined because associated alpha specifies that color components are pre-multiplied by the alpha component, while unassociated alpha specifies the opposite."

Then this tries to imply your version. A few video apps seem to treat unassociated channels this way (of course, the same apps screw up TIFF transparency in general, so that's not a good precendent).

Since these two sentences follow one another in the spec - I can see how folks might get confused.

Chris

On 4/27/09 2:14 PM, "Daniel McCoy" <mccoy@pixar.com> wrote:

From Chris Cox <ccox@adobe.com>, Mon, Apr 27, 2009 at 01:00:31PM -0700:

Unassociated alpha should never be premultiplied - it is not associated with the color channels. Only assoicated alpha should be premultiplied.

The statement "it is not associated with the color channels" seems like one that would be really easy to misinterpret.

It also seems important to make a distinction between "pre-multiply" and "multiply". For unassociate alpha, the color is always supposed to be eventually multiplied by the alpha channel, which stores opacity/coverage.

The tag is meant to indicate whether or not the sofware which wrote the image file has already done the multiplication or not.

(Background: Sam Leffler and I were the two who talked the tiff committee into adding this tag back in the previous century, so I am quite familiar with the original intent of the tag.)

EXTRASAMPLE_ASSOCALPHA - The sample is alpha representing coverage/opacity.

    The color has already been pre-multiplied by the value.
    The color value can be used directly in an over operation:

        Cnew = C + (1-AA) * Cbg

    To display the image, one usually does an implicit "over black"
    by discarding the alpha and just displaying the color.

EXTRASAMPLE_UNASSALPHA - The sample value is alpha representing coverage/opacity.

    The color has NOT been pre-multiplied by the value.
    The color value needs to be multiplied before being used in an over operation:

        Cnew = UA * C + (1-UA) * Cbg

    To display the image, one must do a more explicit "over black"
    by multiplying in the alpha and displaying the resulting color.

EXTRASAMPLE_UNSPECIFIED - the sample value is just data.

Please do not confuse with UNASSALPHA with UNSPECIFIED.

The code in question is in tif_getimage.c

I'm not entirely sure of all the things it's being used for these days, but back in the day, the module provided the TIFFReadRGBAImage() function for reading a wide variety of tiff images into a single generic internal image format suitable for immediate display or some kind of conversion, all without the burden of checking a bazillion tiff tags.

The generic image format was defined to be RGBA where A is associated alpha.

TIFFReadRGBAImage has been called in the past by the tools tiff2rgba.c and rgb2ycbcr.c as well as many different image display programs.

In the case of tiff2rgba.c, I do believe it sets the output extra samples tag to EXTRASAMPLE_ASSOCALPHA, so it is expecting the TIFFReadRGBAImage package to convert unassociated alpha into associated alpha, ie multiply.

In the case of rgb2ycbcr.c, there is no output alpha channel,

> so it is ex