5
$\begingroup$

I noticed that the RGB sliders under color pickers are in linear mode, while HSV are in sRGB. Is there a way to chose to have all in linear or in sRGB ? Just to get cohesion. Do you think it's possible with an addon ? I am asking this because if I want an albedo with a value of 0.3 for example, and a hue of 0.85 and saturation of 0.2, I have to set RGB value at 0.3 to get the good value in HSV picker, and in this one I enter Hue and Saturation. That's a bit broken to me. Normally when converting to HSV, the value is the max of red, green or blue channel. So a color in RGB (0.5 ; 0.3 ; 0.1) should be in HSV( 0.3 ; 0.8 ; 0.5) and not (0.101 ; 0.525 ; 0.735).

Edit : I just found that it can be partially solved in the ColorManagement tab by switching display device from "sRGB" to "none", with the drawback to get a raw look in the 3D rendered view...

Edit 2 : I found a simple way to correct the raw look back to sRGB by using a gamma 2.2.

enter image description here

I guess it's close enough for some preview. But I lose the render view presets...

|improve this question|||||
$\endgroup$
  • 1
    $\begingroup$ You may have a misunderstanding about HSV. Value is not the max, it is a weighted sum of the colours. HSV is designed with the human eyeball in mind, and so there are weightings giving precedence to Green. See en.wikipedia.org/wiki/HSL_and_HSV#Lightness $\endgroup$ – sdfgeoff Jun 13 '16 at 10:55
  • $\begingroup$ There is no conversion when changing from RGB to HSL (or HSV), the color you set in HSV or RGB is the same, all values are between 0 - 1. If you check Photoshop for instance, Hue is 360 degrees, while Saturation and Lightness are in percentage, so in Blender a Hue value of 0.5, is 180 in Photoshop, Saturation and Lightness of 0.5 is 50% in Photoshop. In HSL (HSV), a value of 0 Hue, 0 Saturation, 0.5 Lightness, will be (0.214,0.214,0.214) in RGB, sorry, but I still don't understand what the problem is. $\endgroup$ – Georges Jun 13 '16 at 11:31
  • $\begingroup$ Ok, in wikipedia it says : in HSV, V is the max of the RGB components. In HSI (intensity), I is the average of the RGB components. And in HSL (lightness), L is the average of the max and the min of the RGB components. And finally with HSy (luma), it's the weighted average of RGB with 0.3R+0.59G+0.11R. So if you set a color in a diffuse node RGB(0.8,0.8,0.8) it should give you in whatever mode (0,0,0.8) and not (0,0,0.906) as it is actually in blender. Please do the test. It is because only RGB is in linear, the other modes are in sRGB which is gamma corrected (I think so, I am confused now) $\endgroup$ – tynaud Jun 13 '16 at 13:06
  • $\begingroup$ @sdfgeoff Actually, this is part of the problem with HSV; there is no canonical reference and every application is free to implement as required. V is in fact max(RGB), for reasons to exhaustive to list here. $\endgroup$ – troy_s Sep 11 '16 at 18:37
  • $\begingroup$ @tynaud You are not confused but rather trying to reconcile a bunch of crap online that amounts to paradox. What is "Value" is the question. The answer, to most folks familiar with colour, is the visual energy level of a mixture of colours. That means luminance weights for any given RGB set of colours. These are not equal, as the visual energy for green-yellow is much higher than reddish-orange, which is higher still than magenta-blueish. So even those weights you list are wrong. The proper weights are the Y position for 709 / sRGB lights. This is part of the reason behind max(RGB). $\endgroup$ – troy_s Sep 11 '16 at 18:48
4
$\begingroup$

Short answer: No. Not via the GUI widget that is. RGB should be linearized.

Longer answer: If more imagers around Blender begin to understand what an EOTF is, perhaps. The ideal solution is that all UI elements allow an imager to pick the transfer function as required by their current context. Editing normals within a given range? Use a particular linear transform. Manipulating a particular log? Use it. Etc.

Why is the widget nonlinear? Because it has to be corrected for your display output. That is, if the widget were not under a transform, and your reference were different from 709 lights, you would not see the right colour in the wheel.

There is an exhaustive thread located here for anyone interested in the nuances of this.

Until Blender chooses to permit an imager to select the colour transform required on a UI element, this is an impossible situation to solve for all imaging contexts.

Also, as stated many other places, not using a display transform and forcing a power curve is far from ideal and should be avoided at all costs. A better path is to have your voice heard and have Blender fix the broken colour pipe UI paradigm.

|improve this answer|||||
$\endgroup$
0
$\begingroup$

There are 5 different color picker modes that you can choose among in Blender, you can choose the one that suits you best from File > User Settings > System tab.
Remember to save user settings if you want to keep the changes you make when you start up Blender.

|improve this answer|||||
$\endgroup$
  • $\begingroup$ Sorry, I think I wasn't clear in my question. Actually it changes the look of the colorpicker, but how it represents the value under it (RGB, HSV, HEX) is always the same. I mean the RGB value are in linear space, but the HSV and HEX are in sRGB (which is gamma corrected). I will edit my question to explain more my problem. $\endgroup$ – tynaud Jun 13 '16 at 9:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.