[Bf-committers] Color picker redesign, continued

Bartek Skorupa (priv) bartekskorupa at bartekskorupa.com
Mon Oct 6 13:54:41 CEST 2014


Hey,

I was wondering if the discussion about HSV values is still ongoing or the decision has been made to leave it as is?
I'd like to refer to this part of Antony's post:
> 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.

I am one of those who kept using V of HSV model to specify the color values in linear space. Now it requires several unnecessary steps to be able to do it, so I was wondering if the way of setting colors using HSV will stay as is or it's going to be changed?


Thank you.

Bartek Skorupa

www.bartekskorupa.com

On 19 cze 2014, at 20:31, Antony Riakiotakis <kalast at gmail.com> wrote:

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



More information about the Bf-committers mailing list