[Bf-compositor] Question regarding changes to blending modes

Troy Sobotka troy.sobotka at gmail.com
Sun Jun 8 17:44:08 CEST 2014


On Jun 8, 2014 3:39 AM, "Kévin Dietrich" <kevin.dietrich at mailoo.org> wrote:
>
> @Troy: Care to spare some links ?
>
> And your math is almost the same: (A || B) <= 1 ? screen : lighten;

The key here is that the almost gracefully deals with all scene referred
values. 1.0 has no meaning in a scene referred set of data values, and the
algorithms cannot therefore rely on values like 1.0.

> Also here I'm not dealing with 32-bit floats, I'm trying to find a better
way to handle Hue, Sat, Val and Col blend operations to not use RGB <-> HSV
conversions which are flawed by design and produce artfacts.

I am not quite understanding why you wouldn't be dealing with float values
as Blender's reference space is inherently float, and the default model is
scene referred.

HSV can be a tricky beast.

Formulas that use hard coded weight values to achieve a luminance would be
incorrect. In particular, forcing sRGB luminance values would be grossly
incorrect.

If any of your image algorithms require luminance coefficients, it would be
prudent to use OpenColorIO's configuration based luminance coefficients,
and as such based on the primaries of the selected reference space.

There are a few scene referred and agnostic HSV formulas out there, where
the values would end up scaled to 0.0 to 1.0 for H and S.

http://www.easyrgb.com/index.php?X=MATH&H=20#text20

Ignore the 255 and it should work, with scaling of the values to 1.0, and
leaving V at the scene referred max.

It would be extremely useful to test your image formulas on scene referred
imagery to prevent glaring oopsies with scene referred images.

With respect,
TJS
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-compositor/attachments/20140608/bf398ab1/attachment.htm 


More information about the Bf-compositor mailing list