[Bf-committers] Color space and alpha issues

James Ruan ruanbeihong at gmail.com
Wed Dec 21 15:12:46 CET 2011


2011/12/21 Troy Sobotka <troy.sobotka at gmail.com>:
> On Dec 20, 2011 10:41 PM, "James Ruan" <ruanbeihong at gmail.com> wrote:
>> Certainly, every image entering the
>> composite system must indicates its format and outputs a straight
>> alpha( actually recommended) to the system.
>
> Recommended?  I would need some citations as just about every industry
> compositor I have spoken with prefers an associated alpha representation as
> it more closely models an emissive representation of light.
>
>> And actually I don't see any problem to introducing emitting in
>> partially transparent image with the format straight alpha.
>
> It cannot be done. Only associated alpha can properly represent emissive
> RGB as the over operation becomes an add.
>
> It is fundamentally impossible to express an emissive pixel using
> unassociated alpha due to the over operation. Consider emissive yellow such
> as that from a candle flame with no opacity:
>
> 1,1,0 RGB with 0 alpha.
>
> In an unassociated system, the over operation would be:
>
> (Over.RGB * Over.Alpha) + (Background.RGB * (1 - Over.Alpha)) or
> (RGB * 0) + (Background * 1)
>
> Nothing is added. Now consider the identical as expressed with associated:
>
> Over.RGB + (Background.RGB * (1 - Over.Alpha)) or
> (1,1,0) + (Background.RGB * 1)
>
> Only in the associated alpha representation does the math result in an
> additive scenario. The actual formulas change for associated versus
> unassociated.
>
>> When we talk about alpha format, it has two meaning:
>> One for file format RGBA is stored as four bytes integer ranging from 0
> to 255;
>
> Bit depth has little to do with the representation and implications of the
> two classes of alpha.
>
>> The conversion between that two is followed by 0.0 to 1.0 mapping to 0 to
> 255.
>
> This is subject to color transformations and the non linear
> representations. Diffuse white and middle grey values may be varied in some
> linear system models, but that is again tangential to the discussion.
>
>> So storing an luminescent partially transparent color image to an
>> integer format must use premultiplied alpha format because RGB bigger
>> than 1.0 means something and must be remapped to the range of 0 to 255
>> multiplied with alpha as a coefficient, so reverse that can get RGB
>> bigger than 1.0 just as it is produced.
>
> This is a wee tad confused. ;)
>
>> That's an restriction of
>> integer file format not the straight alpha itself.
>
> Despite the above confusion, the conclusion remains incorrect.
>
>> Why blur/defocus and alpha over needs premulitplied format? Can't it
>> be represented in straight float without any info lose?
>
> Visualize a two by two grid with red pixels on the left and blue on the
> right. If the blue were 0% opaque, a blur would be contaminated by the blue
> color as it relies on a window of pixels to achieve the blur. The only
> method to achieve a correct blur is via a multiply to knockout the blue to
> reduce the blue to zero emission so as to not contaminate the blur. This is
> associated alpha.
>
>> I don't
>> understand the restriction here.
>> Is it possible to care about format only at FILE IO part but maintain
>> uniform in the internal representation?
>
> Not quite as again, at various junctures of a composite, an artist might
> require both formats to exist simultaneously.
>
> Both associated and unassociated alphas have a role in compositing
> depending on artist needs. It is an unfortunately common mistake for
> individuals to treat them as interchangeable and synonymous as both feature
> unique attributes.
>
> I hope that helps to clarify some of the confusion.
>
> With respect,
> TJS
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers

Thanks for clearing that. My understanding of emitting color is not
right. In that system total transparent pixel can have a color that
means the emit of light. And that is allowed in the compositing. I
wonder how to convert it (associated RGBA(1,1,0,0) )to the
unassociated format since divide by zero problem. So is it really
common to introduce emitting color system into image compositing? I
think that might be the original sin for the problem. Should image be
just 'printable' or to say it never emit light but only residue of
some part of light being absorbed. That's more nature. Sorry if it
drift away from the topic.

-- 
James Ruan


More information about the Bf-committers mailing list