AWARE [SYSTEMS] Imaging expertise for the Delphi developer
AWare Systems, Imaging expertise for the Delphi developer, Home TIFF and LibTiff Mailing List Archive

LibTiff Mailing List

TIFF and LibTiff Mailing List Archive
April 2009

Previous Thread
Next Thread

Previous by Thread
Next by Thread

Previous by Date
Next by Date

Contact

The TIFF Mailing List Homepage
This list is run by Frank Warmerdam
Archive maintained by AWare Systems



Valid HTML 4.01!



Thread

2009.04.27 19:49 "Question regarding unassociated alpha", by Amir Ebrahimi
2009.04.27 20:00 "Re: Question regarding unassociated alpha", by Chris Cox
2009.04.27 20:03 "Re: Question regarding unassociated alpha", by Amir Ebrahimi
2009.04.27 20:07 "Re: Question regarding unassociated alpha", by Chris Cox
2009.04.27 20:26 "Re: Question regarding unassociated alpha", by Edward Lam
2009.04.27 20:28 "Re: Question regarding unassociated alpha", by Edward Lam
2009.04.27 20:32 "Re: Question regarding unassociated alpha", by Amir Ebrahimi
2009.04.27 20:45 "Re: Question regarding unassociated alpha", by Edward Lam
2009.04.27 20:49 "Re: Question regarding unassociated alpha", by Edward Lam
2009.04.27 20:54 "Re: Question regarding unassociated alpha", by Amir Ebrahimi
2009.04.27 21:22 "Re: Question regarding unassociated alpha", by Bob Friesenhahn
2009.04.27 21:14 "Re: Question regarding unassociated alpha", by Daniel Mccoy
2009.04.27 21:33 "Re: Question regarding unassociated alpha", by Amir Ebrahimi
2009.04.28 20:37 "Re: Question regarding unassociated alpha", by Chris Cox
2009.04.28 22:12 "Re: Question regarding unassociated alpha", by Daniel Mccoy
2009.04.29 03:37 "Re: Question regarding unassociated alpha", by Bob Friesenhahn

2009.04.28 22:12 "Re: Question regarding unassociated alpha", by Daniel Mccoy

From Chris Cox <ccox@adobe.com>, Tue, Apr 28, 2009 at 01:37:42PM -0700:
> 
> 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).

They should be marked "unspecified", not "unassociated".
There should only be one "alpha" channel, and it should be either
associated or unassociated.

"UNSPECIFIED" is for just data which can have any meaning.

"UNASSOCIATED" is indeed transparency, it just isn't premultiplied.
The idea of unassociated being that one can modify the transparency
channel without having to also modify the color information,
and vice versa, you can modify the color without modifying the transparency,
since the multiply will happen later.

"ASSOCIATED", the transparency has already been multiplied into the color,
so you cannot independently modify the color and transparency,
the premultiply has "associated" them with each other. 

> "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.

The spec is not worded the way I would have wanted it, 
but that was what made it past the print-oriented people who
made up the TIFF committee at the time.
It's a little tricky to explain, since the type of the alpha tag
is telling you how to interpret the *COLOR* values,
the alpha value is the same either way and should be interpreted the same.
The only difference between unassociated and associated is the color values.

It should probably state something more like:

There should be at most one alpha channel which can be either associated
or unassociated. There can be as many unspecified extra samples as desired.

That was the original intention.

Dan


> 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 expecting the the image to be essentially comped over
> > black before being converted, so it's expecting TIFFReadRGBAImage
> > to convert to associated alpha, ie. multiply.
> > 
> > The case of display programs is usally equivalent. The diplay program
> > is expecting associated alpha because it's either going to discard alpha,
> > or it's going to place the image over a background.
> > 
> > If you want to change TIFFReadRGBAImage to return RGBA where A might
> > or might not be associated, you will force all existing clients
> > to read the extra samples tag and perform any desired alpha operations itself.
> > Defeating the original purpose of TIFFReadRGBAImage.
> > 
> > Another possible solution which would not impact all of the existing
> > clients of TIFFReadRGBAImage() would be to add either another call
> > which defines its return format as unassociated alpha,
> > ie TIFFReadRGBUAImage(), or another alpha-agnostic function which
> > requires one to check the tag to see what kind of alpha it just read.
> > 
> > In other words, the code is correct if the package is defined
> > to perform an implicit UA -> AA conversion, which is always has in the past.
> > 
> > Dan McCoy - Pixar
> > 
> > 
> >> From: tiff-bounces@lists.maptools.org [tiff-bounces@lists.maptools.org] On
> >> Behalf Of Amir Ebrahimi [amir@unity3d.com]
> >> Sent: Monday, April 27, 2009 12:49 PM
> >> To: tiff@lists.maptools.org
> >> Subject: [Tiff] Question regarding unassociated alpha
> >> 
> >> I'm using libtiff via FreeImage in our development tool: Unity.
> >> 
> >> We've had an image support regression with TIFF files after switching
> >> to FreeImage/libtiff from the QuickTime SDK. A file with unassociated
> >> alpha still seems to be getting pre-multiplied in with the RGB
> >> channels. Is this by design? I'd like to get the TIFF file with RGBA
> >> channels intact without it being pre-multiplied. If the image had
> >> associated alpha, then it would make sense that it was pre-multiplied,
> >> however, that isn't the case.
> >> 
> >> In libtiff (v3.9.0) line 268:269 has these comments:
> >> 
> >> case EXTRASAMPLE_ASSOCALPHA: /* data is pre-multiplied */
> >> case EXTRASAMPLE_UNASSALPHA: /* data is not pre-multiplied */
> >> 
> >> which causes libtiff to use the following ContigPutFunc starting at
> >> line 1262:
> >> 
> >> putRGBUAcontig8bittile
> >> {
> >>         ...
> >>         a = pp[3];
> >>                 r = (a*pp[0] + 127) / 255;
> >>                 g = (a*pp[1] + 127) / 255;
> >>                 b = (a*pp[2] + 127) / 255;
> >> }
> >> 
> >> The alpha is still written out, however, why is the alpha being pre-
> >> multiplied here?
> >> 
> >> :: Amir Ebrahimi ::
> >> Developer @ Unity Technologies
> >> www.unity3d.com
> >> 
> >> 
> >> 
> >> 
> >> _______________________________________________
> >> Tiff mailing list: Tiff@lists.maptools.org
> >> http://lists.maptools.org/mailman/listinfo/tiff
> >> http://www.remotesensing.org/libtiff/
> >> _______________________________________________
> >> Tiff mailing list: Tiff@lists.maptools.org
> >> http://lists.maptools.org/mailman/listinfo/tiff
> >> http://www.remotesensing.org/libtiff/
> >