[Bf-compositor] use alpha premultiplication in linear Color Space?

Sun Apr 6 10:42:06 CEST 2014

Hi Bartek,
thanks for your link.
Computer generated images are rendered directly with their own associated
alpha since the alpha itself is a property of each RGB channel and not just
a mask.
So unassociating the alpha is a "trick" we have to use to edit (ex post)
the colors properly.
Chatting with Troy I understood a couple of important things that I havent
got in the IRC discussion with Ton and Lukas.
I must admit Ton at a certain point told me there is a difference between
operation in the nodestree and in the display but at that time I just
ignored this information because I havn't got the importance of this
statement.

By default the OpenGL render of the image displayed in the viewer always
try to keep the correct image in the meaning of the correctness of a CG
image even if it has been forced to be unassociated.

This is definitelly clear when you see (according to my previous samples)
an image that IS NOT alpha associated but that IS DISPLAYED as if it should
be...

According to how separate and combine RGBA nodes works (they just get the
intensity of each channel as it is given at input time) I should have seen
an RGB image + its unassociated alpha but again, the  viewer output "guess"
(hope I'm using the correct term here) it's an associated alpha image and
render a result that is not what is really given by the output of the
combine node.

To prove my statement here a series of image that perfectly represent what
drove me completely crazy.

The output of the tree should be in both the display mode (color and
color+alpha) equal to the next image [1]:

https://lh4.googleusercontent.com/-pAdrH9hboyk/U0EDzz4eQ4I/AAAAAAAAI5s/bZxeEu-0Eds/w1246-h870-no/err06.jpg

What you get in color + alpha mode is this alpha associated visual
representation [2]:
https://lh3.googleusercontent.com/-NASTIfNg2Zo/U0ECBdj5mFI/AAAAAAAAI5M/uIYj0twvlzg/w1246-h870-no/err01.png.jpg

Moving to  color only you get an image that I would never expect an image
twice unassociated (once by the node separate RGBA and once by the display)
but that look perfect [3]:
https://lh6.googleusercontent.com/-WlaTlXci6E0/U0ECBdfoMxI/AAAAAAAAI5M/5ZmiNh8SUlo/w1246-h870-no/err02.png.jpg

How this image can be like so? Color only should or should not discard
"mask information" that are not associated to the RGB channels?
In fact as soon as I add an alpha convert node the display shows what I
guess should have been the result of the  displayed image [4]:

https://lh3.googleusercontent.com/-1MppyPtA0Zs/U0ECC3n7avI/AAAAAAAAI5M/3IhFhZ61_RE/w1246-h870-no/err04.png.jpg

 And now let me explain further from an artist point of view that do not
spend time to go deep in this topic what seems wrong
I'm looking in the color + alpha mode and I see image [2]
then I go to color only and I get image [3]
so I'm oriented to think, nice the colors are properly
unpremultiplied/unassociated during the separate / combine process
then I add an alpha convert and I get the effect of an image twice
associated [5]:

https://lh3.googleusercontent.com/-LptQp3DEoWo/U0ECC2s1OtI/AAAAAAAAI5M/A_B3XPF_06k/w1246-h870-no/err05.png.jpg

How can I know that the operation made at display time aren't linked to the
one made on the tree??
Should display represent the same output as the nodes do in your opinion?

Thanks for your time and the patient to follow this thread :)
Francesco

2014-04-05 21:27 GMT+02:00 Bartek Skorupa (priv) <
bartekskorupa at bartekskorupa.com>:

> Hey,
>
> In November last year I wrote my thoughts about this issue. Nodes IMO are
> fine, but display is broken and causes a lot of confusion:
> http://wiki.blender.org/index.php/User:Bartekskorupa/Display_Issues
>
> Cheers,`
>  Bartek Skorupa
>
> www.bartekskorupa.com
>
> On 5 kwi 2014, at 14:03, Francesco Paglia <f.paglia.80 at gmail.com> wrote:
>
> Hi Lukas,
> You're perfectly right, there are no issue with the combine rgba node.
> Since I still  think there's something that sounds me strange I went on
> trying to understand what's wrong with me or the node tree! :)
>
> Finally I got what got me in error!
> This button:
>
>
> https://lh6.googleusercontent.com/-8d9zmPWcEdo/Uz_wFciddLI/AAAAAAAAI30/-1I878DqlLU/w259-h72-no/color%252Balpha.png
>
>
> As you can see from the next image you're looking to a Visually associated
> alpha image even if it is not really.
>
>
> https://lh4.googleusercontent.com/-E3QP6SAS9TE/Uz_wFwk9HyI/AAAAAAAAI30/CeDw2snn6Jk/w1016-h812-no/visually.png
>
>
> Here comes all my erroneous thought because as soon as I looked at that
> image I was driven to think it was correctly premultiplied but it was not!
>
> Then once plugged it in the alpha over the image again looked visually
> correct.
>
>
> https://lh5.googleusercontent.com/-0XvpRceiXx8/Uz_wF7EvhxI/AAAAAAAAI30/6LmwOsQlOhE/w957-h807-no/over.png
>
>
> As soon as I started editing the alpha value the errors in the tree become
> evident... But since the image looked premultiplied and visually correct I
> was driven to hundreds of incorrect thought about how the nodes work.
>
> So here comes my "final" thought:
> Should unassociated images be properly showed in that display mode?
>
>
> Thanks
>
> Francesco
>
>
> 2014-04-04 17:53 GMT+02:00 Lukas Tönne <lukas.toenne at gmail.com>:
>
>> The RGBA separate and combine nodes are fine IMO, they work just as
>> expected. What could be useful would be to extend the "Set Alpha" node with
>> an optional setting to handle premultiplication.
>>
>> As discussed on IRC what happens is that, when replacing the alpha
>> component (either by "combine rgb" or "set alpha"), the rgb color
>> components are still premultiplied with the old alpha value, thus giving an
>> incorrect resulting associated color value.
>>
>> input color: (r,g,b,a) = (R*a, B*a, G*a, a), where (R,G,B) is the
>> "original" unassociated color value
>> replacing alpha: (r,g,b,a') = (R*a, B*a, G*a, a') i.e. the resulting
>> color uses a wrong alpha factor for premul
>> desired result: (r',g',b',a') = (R*a', G*a', B*a', a')
>>
>> Here's an example file that contains a node group which correctly
>> replaces rgb along with alpha to the desired premultiplied color:
>> http://www.pasteall.org/blend/28164
>>
>> This node group would be the alternative "Set Alpha" implementation when
>> the proposed "premul" option is enabled.
>>
>>
>> On Fri, Apr 4, 2014 at 4:45 PM, Francesco Paglia <f.paglia.80 at gmail.com>wrote:
>>
>>> After a discussion on blendercoders I understood why I had to add the
>>> premult node at the beginning and at the end of my nodetree.
>>>
>>> The fact is that combine and separate rgba do not take into account any
>>> property of the input.
>>> The separate don't know if an input have associated or unassociated
>>> alpha and the combine strictly act as a "container of independent channels"
>>> that have to be further recombined.
>>> This drive to the need of unassociate the alpha at the beginning of the
>>> tree and to reassociate it at the end of the modification of the alpha
>>> channel to make it properly working.
>>>
>>> I got confused because after combining the channels previously separated
>>> I have not get any of the result I could expect but an image equal to the
>>> original...
>>> Here what I could expect:
>>>
>>> 1° the correct image with a lower alpha intensity
>>> 2° an image with a lower alpha and black artifact
>>> 3° a fully opaque rgb image (equal to the orginal but with black color
>>> where the alpha should be) with an unassociated alpha
>>>
>>> Since non of those result came up to me I started thinking in a wrong
>>> way that lead me to write the original post.
>>> After a bit of discussion most of the question have been solved but
>>> after further thinking and with the discussion in mind I'm even more
>>> convinced that with my setup I should have get the third result.
>>>
>>> I think there's still some issue in the combine rgba node.
>>>
>>>
>>>
>>> 2014-04-04 14:37 GMT+02:00 Francesco Paglia <f.paglia.80 at gmail.com>:
>>>
>>> Hi Ton,
>>>> let me say I used the term Fade because I was used to it coming from
>>>> other Compositing packages.
>>>> I mean the value of a pixel of a channel multiplied by another value
>>>> should output the result of the multiplication .
>>>> Alpha over comes later... after this operation!
>>>>
>>>> I think an image would explain much more than 100 words especially if
>>>> my jargon isn't really appropriate :)
>>>>
>>>>
>>>> https://lh4.googleusercontent.com/-f-dm0O5h_qs/Uz6nQz4s9qI/AAAAAAAAI14/CsFT1RmOzmw/w1358-h309-no/noprem.png
>>>>
>>>>
>>>>
>>>>
>>>> 2014-04-04 13:45 GMT+02:00 Ton Roosendaal <ton at blender.org>:
>>>>
>>>> Hi,
>>>>>
>>>>> "Fade" can mean too many things.
>>>>> You mean: "Image should become transparent - during an alpha-over
>>>>> operation"?
>>>>>
>>>>> Well to start with - such effects look much different in linear, than
>>>>> in non-linear spaces.
>>>>>
>>>>> And realize: premultiplied RGBA = alpha should not be changed. Not!
>>>>> Straight alpha - yes, that you can do with what you like.
>>>>>
>>>>> -Ton-
>>>>>
>>>>> --------------------------------------------------------
>>>>> Ton Roosendaal  -  ton at blender.org   -   www.blender.org
>>>>> Chairman Blender Foundation - Producer Blender Institute
>>>>> Entrepotdok 57A  -  1018AD Amsterdam  -  The Netherlands
>>>>>
>>>>>
>>>>>
>>>>> On 4 Apr, 2014, at 13:25, Francesco Paglia wrote:
>>>>>
>>>>> > Hi, hope I used a right title for this topic.
>>>>> > I've just setup a simple nodegroup to make a fade node.
>>>>> > Here the tree:
>>>>> >
>>>>> >
>>>>> https://lh4.googleusercontent.com/-Mos7IL6bx4E/Uz6VHnKqZ3I/AAAAAAAAI1U/zJJ7zOFnRWQ/w1176-h368-no/fade_nodesetup.png
>>>>> >
>>>>> > As input of this group I've a renderlayer, if I'm not wrong the
>>>>> compositor works with a linear workflow so why I have to add make alpha
>>>>> straight at the beginning and a premultiply at the end to make it working
>>>>> properly?
>>>>> >
>>>>> > Thanks for your help
>>>>> > Francesco
>>>>> >
>>>>> > --
>>>>> > Francesco Paglia
>>>>> > Vfx and Production Supervisor
>>>>> >
>>>>> > mobile  +39 347.82.12.473
>>>>> > e-mail   f.paglia.80 at gmail.com
>>>>> >
>>>>> > _______________________________________________
>>>>> > Bf-compositor mailing list
>>>>> > Bf-compositor at blender.org
>>>>> > http://lists.blender.org/mailman/listinfo/bf-compositor
>>>>>
>>>>> _______________________________________________
>>>>> Bf-compositor mailing list
>>>>> Bf-compositor at blender.org
>>>>> http://lists.blender.org/mailman/listinfo/bf-compositor
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Francesco Paglia
>>>> Vfx and Production Supervisor
>>>>
>>>> mobile  +39 347.82.12.473
>>>> e-mail   f.paglia.80 at gmail.com
>>>>
>>>>
>>>
>>>
>>> --
>>> Francesco Paglia
>>> Vfx and Production Supervisor
>>>
>>> mobile  +39 347.82.12.473
>>> e-mail   f.paglia.80 at gmail.com
>>>
>>>
>>> _______________________________________________
>>> Bf-compositor mailing list
>>> Bf-compositor at blender.org
>>> http://lists.blender.org/mailman/listinfo/bf-compositor
>>>
>>>
>>
>> _______________________________________________
>> Bf-compositor mailing list
>> Bf-compositor at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-compositor
>>
>>
>
>
> --
> Francesco Paglia
> Vfx and Production Supervisor
>
> mobile  +39 347.82.12.473
> e-mail   f.paglia.80 at gmail.com
>
>  _______________________________________________
> Bf-compositor mailing list
> Bf-compositor at blender.org
> http://lists.blender.org/mailman/listinfo/bf-compositor
>
>
>
> _______________________________________________
> Bf-compositor mailing list
> Bf-compositor at blender.org
> http://lists.blender.org/mailman/listinfo/bf-compositor
>
>

-- 
Francesco Paglia
Vfx and Production Supervisor

mobile  +39 347.82.12.473
e-mail   f.paglia.80 at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-compositor/attachments/20140406/1d2bd7af/attachment-0001.htm 