[Bf-committers] Color space and alpha issues

[James Ruan]

2011/12/21 gespertino at gmail.com <gespertino at gmail.com>:
>> -----Original Message-----
>> From: James Ruan <ruanbeihong at gmail.com>
>
>> I don't think the opposite of teaching is hiding. I think we need a
>> uniform format for alpha. Artists don't need to know in which format
>> there file is stored or processed. Only the well defined result
>> counts.
>
> Adopting a recommended format for alpha is good, as long as artists
> have control over it across the composite.
> However I don't agree that artists don't need to know which format
> files use. It's an extremely important factor and you can't assume
> which is the correct since different applications (Blender included)
> allow to store alpha without respecting formats specifications. And
> even if applications would store alpha following specifications, some
> formats (like Targa and Tiff, for instance) allow both types of alpha.
> You can try guessing, like one of the options in After Effects, but
> it's not a bullet-proof method and could misinterpret some files, like
> premultiplied files with luminescent colors.
>
>> So giving every node in Node System to choose there input and output
>> format is not a good option.
>
> No, it's not for every node in the node system. Just for the
> input/output nodes, so the artist can choose, and more importantly to
> avoid color management to introduce errors (color management shouldn't
> affect alpha channel, and converting premultiplied data does it).
>
>> +1. Good internal representation should store the most info. And
>> RGB+mask alpha is the best choice for compositing.
>
> Not when you only need to transform, blur and alpha-over CG
> renderlayers, for instance.
> Every compositing tree is different and you can't assume which alpha
> format is better. Both are needed.
> Sticking with unassociated alpha has as many problems as associated
> alpha, and some situations are completely impossible with unassociated
> alpha (again, luminescent premul).
> Apart from that, how do you preserve the original info (I mean
> RGB+mask) after some alpha-over or blur nodes?
> I wouldn't say that unassociated is the best choice for compositing.
> It's one of the two available choices.
>
>> Maybe, we can handle both format by adding a tag in the imbuf, then
>> define a RECOMMEND format for certain application (eg. premultiplied
>> for rendering buffers). Image that used in other format will be
>> converted to the RECOMMEND for only once. This will add a lot of code
>> for checking and converting the format of imbuf though. But by using a
>> cache, we can find a balance between CPU and Memory (maybe disk
>> cache). And it's a good habit to check the input data and outputs to a
>> RECOMMEND format (always assuming others doing wrong and do it right
>> itself).
>
> That wouldn't be bad, but it's impossible to make it perfect.
> This is a simple example showing how easy is to blow it:
> I have a straight alpha image flagged as unassociated. It's an image
> introduced to the comp using the input>image node.
> I want to multiply the diffuse pass from a render layer on my image.
> That pass hasn't the renderlayer's alpha channel... how do you flag
> it? is it RGB? Is it straight RGBA with fully opaque alpha? is it
> premultiplied RGBA with fully opaque alpha?
> What's the flag after the multiply operation? Let's say the result
> will end up flagged as straight alpha.
> Now I want to use the renderlayer's alpha as the alpha channel for the
> result of the mix. So I Use a set alpha node. The original RGBA
> information was tagged as straight, so I assign a new alpha and it
> should stay straight, right?
> But it doesn't. Because the diffuse pass I multiplied has a black
> background already, and if I'm using OSA the result will be, in
> practical terms, the same than a premultiplied image*
> So if I keep treating the result as straight alpha I'll get black
> fringes in the next alpha-over or blur node, because if those nodes
> are aware of the incoming flag, they will pre-multiply the alpha
> (because it's needed for those operations) and introduce a double
> premul fringe.
>
> *) I stress "in practical terms", I take the liberty to misuse the
> term "premultiplied" to point that a difusse pass with the render's
> alpha set is pretty much the same than a premultiplied combined of the
> same mesh with a diffuse-only material.
>
I'm sorry that I failed to follow your opinion. I don't understand why
double premultiply will happen if each internal buffer's tag is
correctly set to what its content should be. If it goes wrong, it must
be something that breaks the rule. Certainly, every image entering the
composite system must indicates its format and outputs a straight
alpha( actually recommended) to the system.

And actually I don't see any problem to introducing emitting in
partially transparent image with the format straight alpha.
As a blender user, if followed by your 'teaching not hiding' doctrine,
I would be the first student to understand the complexity of the
problem.

So let me show my understanding of this problem. Correct me at any
misunderstanding.
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;
Another is for internal representation which is stored as four * four
bytes floats ranging almost very small to very big.
The conversion between that two is followed by 0.0 to 1.0 mapping to 0 to 255.
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. That's an restriction of
integer file format not the straight alpha itself.
Why blur/defocus and alpha over needs premulitplied format? Can't it
be represented in straight float without any info lose? 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?

>> Or we just use the unassociated alpha everywhere since it preserves
>> most info and do conversions every time it is needed.
>> After all, it should be easy, simple and correct for the users. They
>> should not care about in which format their image is stored.
>
> As Francesco said, premul/postdivide is for compositors what topology
> is for modelers. Artists should care about it because it's essential
> to get good results.
> If that isn't important, I don't see why the compositor should be
> improved. Unexperienced compositors are already used to compensate
> alpha fsckups with dilate/erode nodes, masks, curves and all kinds of
> hacks to get visually acceptable results avoiding alpha problems.
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers



-- 
James Ruan