[Bf-committers] Color space and alpha issues

[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