[Bf-committers] Color pipeline todo: alpha

[Brecht Van Lommel]

I like the names associated and unassociated because they don't
describe how you arrived at the color, just the way it is stored. For
rendering you don't premultiply things, it just comes out that way
naturally. Though perhaps the terms premultiplied/unpremultiplied are
more familiar to users.

Brecht.

On Thu, Dec 20, 2012 at 8:33 PM, Ton Roosendaal <ton at blender.org> wrote:
> Hi,
>
> The convention is probably based on where the graphics comes from.
>
> - Straight alpha:
> Painted graphics and exporting it with an alpha mask. Colors remain unchanged.
>
> - Unpremultiplied color:
> Images from render and composite, converted to display color.
>
> - Premultiplied color:
> A straight alpha image, converted to to premultiplied colors.
>
> Each is actually different :)
>
> -Ton-
>
> ------------------------------------------------------------------------
> Ton Roosendaal  Blender Foundation   ton at blender.org    www.blender.org
> Blender Institute   Entrepotdok 57A  1018AD Amsterdam   The Netherlands
>
> On 20 Dec, 2012, at 20:20, Troy Sobotka wrote:
>
>> On Thu, Dec 20, 2012 at 10:36 AM, Brecht Van Lommel
>> <brechtvanlommel at pandora.be> wrote:
>>> Premul for float and key for byte images could work.
>>
>> Just in the interest of consistency, if we are going with
>> "Premultiplied" naming convention, can we roll with the inverse of
>> "Unpremultiplied" and apply it consistently?
>>
>> I checked in with Mr. Selan and he suggested that "Unpremultiplied" as
>> consistent. Mr. Gritz uses[1] the TIFF convention of "Associated" and
>> "Unassociated" convention.
>>
>> I'm open to whatever naming convention we rest on, and only hope we
>> can apply it consistently throughout the interface. In particular, the
>> sidebar panels should likely list "Premultiplied" and the node
>> conversion should reference "Premultiplied" and "Unpremultiplied."[2]
>>
>> The "Color Unpremultiply" term should probably be re-evaluated to
>> avoid confusion, as it is an order of operations event, and the
>> current label is far to close to the other terms which can only amount
>> to greater confusion.
>>
>> Blender needs to take whatever path is most healthy for it, but we can
>> at least aim to apply the terminology consistently.
>>
>> With respect,
>> TJS
>>
>> [1] http://lists.openimageio.org/pipermail/oiio-dev-openimageio.org/2011-April/004193.html
>> [2] http://comments.gmane.org/gmane.comp.lib.openimageio.devel/1406
>> _______________________________________________
>> 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