<p dir="ltr"><br>
On Jun 8, 2014 3:39 AM, "Kévin Dietrich" <<a href="mailto:kevin.dietrich@mailoo.org">kevin.dietrich@mailoo.org</a>> wrote:<br>
><br>
> @Troy: Care to spare some links ?<br>
><br>
> And your math is almost the same: (A || B) <= 1 ? screen : lighten; </p>
<p dir="ltr">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. </p>
<p dir="ltr">> 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.</p>
<p dir="ltr">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.</p>
<p dir="ltr">HSV can be a tricky beast.</p>
<p dir="ltr">Formulas that use hard coded weight values to achieve a luminance would be incorrect. In particular, forcing sRGB luminance values would be grossly incorrect.</p>
<p dir="ltr">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.</p>
<p dir="ltr">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.</p>
<p dir="ltr"><a href="http://www.easyrgb.com/index.php?X=MATH&H=20#text20">http://www.easyrgb.com/index.php?X=MATH&H=20#text20</a></p>
<p dir="ltr">Ignore the 255 and it should work, with scaling of the values to 1.0, and leaving V at the scene referred max.</p>
<p dir="ltr">It would be extremely useful to test your image formulas on scene referred imagery to prevent glaring oopsies with scene referred images.</p>
<p dir="ltr">With respect,<br>
TJS</p>