[Bf-committers] Color space and alpha issues

[Tobias Oelgarte]

Hello,

I can't really agree with it. As you described we have two cases and one 
problem.

First is the blending of an entire image with an alpha part that only 
says what parts are transparent. This can be handled sufficently by 
RGB+A(Mask) since RGB doesn't play a big role.

The Second case is an object with masked out/transparent background. To 
keep the border intact so that the background doesn't influence the 
blending you would need a different sampling/antialiasing between RGB 
and A. The Alpha-Channel would be antialiased as usually at the edge. 
RGB would follow a different rule. It would be inclusive anitialiasing. 
That means every "Ray" that hits the foreground object would contribute 
to RGB. Every Ray that misses or hits the background would be excluded 
from the RGB contribution. In the result the border (inside/outside) of 
RGB would not be antialiased, giving it the correct color value if 
blended over another image with help from the correctly antialiased 
alpha channel.

If that is the case then RGB+A should be always sufficient. I may not be 
100% up to date, but could you construct a case in which this wouldn't 
be sufficient to do anything in non premultiplied alpha?

Greetings from Tobias Oelgarte

Am 19.12.2011 14:53, schrieb Brecht Van Lommel:
> Hi,
>
> I think the way this should work is good defaults that work without
> the user having to think about it, and then extra controls for those
> who want more control.
>
> It's not true that unassociated stores most information, it can't
> store a rendered object that is both transparent and emitting light.
> This information is lost when storing a render in unassociated alpha
> format.
>
> Thinking of a render output as a color + mask is also problematic for
> other reasons. You can't take an image with both foreground and
> background, apply a mask and get only the foreground object. Pixels
> that are partially transparent (because of antialiasing or material
> transparency) should only contain color from the foreground object.
>
> The information that is lost with associated alpha is in pixels that
> are entirely transparent (in float precision it's possible to get back
> the info for partially transparent pixels). Thinking of color + mask
> works for a binary alpha mask, but for partially transparent pixels
> it's often the wrong mental picture.
>
> Brecht.
>
> On Mon, Dec 19, 2011 at 2:03 PM, James Ruan<ruanbeihong at gmail.com>  wrote:
>> 2011/12/19 François T.<francoistarlier at gmail.com>:
>>>>
>>>>
>>>> If it does, it makes more sense to go with added complexity and force
>>>> the artist to learn the ins and outs of alpha for certain operations.
>>>>
>>>>
>>> As usual I'm more for the teaching rather the hiding :)
>>> As Matt said, only comp expert are going to want to mess with this anyway
>>> (I'm even sure some expert will bypass it in some cases). But people who
>>> wants to get serious about it will have to learn it no matter what with any
>>> application out there
>>>
>>>
>>> cheers,
>>>
>>> F.
>>>
>>>
>>> --
>>> ____________________
>>> François Tarlier
>>> www.francois-tarlier.com
>>> www.linkedin.com/in/francoistarlier
>>> _______________________________________________
>>> Bf-committers mailing list
>>> Bf-committers at blender.org
>>> http://lists.blender.org/mailman/listinfo/bf-committers
>> 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.
>> So giving every node in Node System to choose there input and output
>> format is not a good option.
>>
>>
>>> The issue with compositing is that the image buffers are not just used for
>>> final storage and distribution, but they're used as a work-in-progress
>>> scratch pad, and it's often that the way you work with channels doesn't
>>> always represent something logical (eg. keeping masked out RGB pixels
>>> around so you can retrieve them later).
>> +1. Good internal representation should store the most info. And
>> RGB+mask alpha is the best choice for compositing.
>>
>> 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).
>> 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.
>> --
>> James Ruan
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>