[Bf-committers] Color space and alpha issues

[f.paglia.80 at gmail.com]

Hi all,
I'm really interested in this discussion since I found myself unable to understand how alpha works in the blender compositor and how I can clearly use it.

In my quite long experience with many compositing system I always had the need to keep separated RGB from any other channel, alpha included since anything but RGB describe the color of the image.

As an artist I would never take care of how blender internally handle the premultiplication but while making the network of nodes I must have the chance to premult or postdivide an image every time I need it because there are so many situation where a choice in this field as to be taken.
Situation that require postdivided img:
1. Avoid black edges around obj
2. Better color correction handling
3. More saturated half transparent layer
4. Capability of work or undestand how to modify that half transparent edges
5. Ability to treat color and alpha in a separated manner
Of course a the end of the chains there are almost always premultiplied images.

About the "teaching part"
For a compositor being able to handle premult/ postdivide is quite like for a modeler make the right topology.

Hope this is usefull for further proposal/ discussion! :)

Francesco



E-Mail Sent via BlackBerry from BT Mobile

-----Original Message-----
From: James Ruan <ruanbeihong at gmail.com>
Sender: bf-committers-bounces at blender.org
Date: Mon, 19 Dec 2011 21:03:43 
To: bf-blender developers<bf-committers at blender.org>
Reply-To: bf-blender developers <bf-committers at blender.org>
Subject: Re: [Bf-committers] Color space and alpha issues

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