[Bf-committers] Color space and alpha issues

[Troy Sobotka]

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