[Bf-committers] Color picker redesign, continued

[Antony Riakiotakis]

Hi,

In the 2.71 release I have unfortunately caused a small disturbance due to
my decision to change the HSV setting in color wheels to be in display
space.

Some explanation is due: This was to address an important issue of color
pickers, which was that you never got the exact color you chose, especially
for linear color properties.

The issue here, is that the color displayed is calculated by first doing a
non-linear transform (linear to srgb usually) followed by the linear
transform (barycentric interpolation on the rasterized triangle), while the
value calculated if we do the HSV calculation in linear space, is first
interpolation in HSV (linear interpolation for each "piece" of the HSV
circle) followed by the non-linear interpolation. It is only natural that
those two values will differ due to linear and non linear transforms not
being commutative.

The solution I have chosen for the 2.71 version is to make sure all HSV
values are in display space. This guarantees we always get the correct
color, which can then be transformed back to the linear space.

Sadly, we ran into issues:

First, it is a common workflow for people to tweak HSV values in linear
space. Especially on rendering this helps with giving an upper bound to
radiance reflected back from a material, by tweaking the color value.

Also for values greater than one, the non linear transform back to linear
rgb can give very bizzare results (See https://developer.blender.org/T40131)

Apparently we must do the interpolation in the property space, and then use
a per pixel transform (easily done by binding a pixel shader through OCIO)
to correct the result for display.

However, we also have another use case which is still not correct enough
and that gave rise to some discussions.

Apparently, it is beneficial to do the calculation on a different
intermediate space.
This is already done in our "Cubic" style color pickers which -still-
suffer from incorrect display of colors. Generally it may be that, in fact,
many spaces might be disarable as an intermediate calculation space. This
can be hardcoded but can also be configured, through a color picker role
for instance.

In such a workflow, HSV is still calculated in this intermediate space (I
am still unsure if HSV is defined exactly the same for each space though,
which would complicate things), the final display is calculated from pixel
shading and the selected color is taken by transforming from HSV to
intermediate space to initial color space.

Just hooking a display shader for linear properties can work for solving
the current issues, but I was wondering if fixing this might present an
opportunity to take more issues into account.