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 <[email protected]> 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 [email protected] 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 >> <[email protected]> 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 >> [email protected] >> http://lists.blender.org/mailman/listinfo/bf-committers > > _______________________________________________ > Bf-committers mailing list > [email protected] > http://lists.blender.org/mailman/listinfo/bf-committers _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
