Color Picker applies color management incorrectly in 2.71 #41287

New Issue

Blender Version
Broken: 2.71 (hash: 9337574)
Worked: all versions prior to 2.71

Short description of error
The color picker in 2.71 seems to apply color management to values that should be in linear space.

Exact steps for others to reproduce the error

open the color picker from a node in the node editor
under RGB selection set the values to 0.5
switch to HSV and note that the value field reads 0.735 ( ~0.5**(1/2.2) )
compare to the behavior of previous versions

The value listed under HSV after following those steps should be 0.5, as color for materials and the compositor should be in linear space. Blender 2.71 is incorrectly applying the display color management to these values; this can be seen by changing the 'Display Device' setting in the Scene / Color Management panel and looking at the HSV value field again.

**Blender Version** Broken: 2.71 (hash: 9337574) Worked: all versions prior to 2.71 **Short description of error** The color picker in 2.71 seems to apply color management to values that should be in linear space. **Exact steps for others to reproduce the error** - open the color picker from a node in the node editor - under RGB selection set the values to 0.5 - switch to HSV and note that the value field reads 0.735 ( ~0.5**(1/2.2) ) - compare to the behavior of previous versions The value listed under HSV after following those steps should be 0.5, as color for materials and the compositor should be in linear space. Blender 2.71 is incorrectly applying the display color management to these values; this can be seen by changing the 'Display Device' setting in the Scene / Color Management panel and looking at the HSV value field again.

Changed status to: 'Open'

Added subscriber: @MaiLavelle

#54610 was marked as duplicate of this issue

#45792 was marked as duplicate of this issue

#43405 was marked as duplicate of this issue

#41498 was marked as duplicate of this issue

#43025 was marked as duplicate of this issue

#41869 was marked as duplicate of this issue

#40131 was marked as duplicate of this issue

Added subscriber: @mont29

Antony, believe you are maintaining color picker?

We switched the color picker to use HSV values in gamma space now - this will be changed back to linear in the future.

Added subscribers: @suboptimal, @ideasman42, @Psy-Fi, @totoro-4, @troy_s

◀ Merged tasks: #40131.

Color management on pickers and swatches goes much further than merely transfer curves.

I will state it again; if the color pickers and color wheels are not color managed, an artist cannot control what actual colors they are looking at.

There is no such thing as absolute RGB, and there is much variance across devices (studio wide gamuts to 75% sRGB to 95% sRGB) that to not have wheels and swatches managed is nothing short of fatal.

I think merging the two issues likely conflates what is happening and its relevance.

Color management on pickers and swatches goes much further than merely transfer curves. I will state it again; if the color pickers and color wheels are *not* color managed, an artist cannot control what actual colors they are looking at. There is no such thing as absolute RGB, and there is much variance across devices (studio wide gamuts to 75% sRGB to 95% sRGB) that to not have wheels and swatches managed is nothing short of fatal. I think merging the two issues likely conflates what is happening and its relevance.

Ok, there seems to be some confusion of the issue here... I'll try to be more clear.

I'm going to abbreviate some words here to save space:

SLCS - Scene Linear Color Space
DDCS - Display Device Color Space

In the color picker there are two places for user interaction: The wheel (or box) that displays color on the screen, and the numerical input fields. The wheel is displayed in DDCS. The numerical inputs within the context of the Node Editor should be in SLCS.

The problem here is with the numerical inputs, not the on-screen color display wheel (which is correct as far as I can tell).

The numerical inputs should be in SLCS for Material Editing and Compositing.

What this means is this: If you create two Diffuse Nodes and set their colors to RGB(.5, .5, .5)/HSV(0, 0, .5) and use an Add Shader Node to add them, the result is equivalent to a signal Diffuse Node with color RGB(1, 1, 1)/HSV(0, 0, 1). This property is important for creating materials and for compositing.

Also note that nodes such as the Combine HSV node accept SLCS inputs, and having the color pickers numerical inputs match this SLCS keeps everything consistent. Having them different doesn't make sense and is confusing. The behavior of the Combine HSV node also cannot be changed, existing shaders rely on this SLCS behavior. It only makes sense to change the color pickers behavior back to SLCS to match.

Finally the color values in the context of materials and compositing don't represent actual display colors. For materials the values represent the amount of reflected (or transmitted) light a surface will produce. The final display color is influenced by external factors such as light sources. Having the numerical inputs in DDCS doesn't fit the context these values are in.

Please review these documents and bug reports:

http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Post_Process/CM_And_Exposure
http:*web.archive.org/web/20130823123021/http:*www.blender.org/development/release-logs/blender-256-beta/color-management/

https://developer.blender.org/T38031
https://developer.blender.org/T27945

Ok, there seems to be some confusion of the issue here... I'll try to be more clear. I'm going to abbreviate some words here to save space: SLCS - Scene Linear Color Space DDCS - Display Device Color Space In the color picker there are two places for user interaction: The wheel (or box) that displays color on the screen, and the numerical input fields. The wheel is displayed in DDCS. The numerical inputs within the context of the Node Editor should be in SLCS. The problem here is with the numerical inputs, not the on-screen color display wheel (which is correct as far as I can tell). The numerical inputs should be in SLCS for Material Editing and Compositing. What this means is this: If you create two Diffuse Nodes and set their colors to RGB(.5, .5, .5)/HSV(0, 0, .5) and use an Add Shader Node to add them, the result is equivalent to a signal Diffuse Node with color RGB(1, 1, 1)/HSV(0, 0, 1). This property is important for creating materials and for compositing. Also note that nodes such as the Combine HSV node accept SLCS inputs, and having the color pickers numerical inputs match this SLCS keeps everything consistent. Having them different doesn't make sense and is confusing. The behavior of the Combine HSV node also cannot be changed, existing shaders rely on this SLCS behavior. It only makes sense to change the color pickers behavior back to SLCS to match. Finally the color values in the context of materials and compositing don't represent actual display colors. For materials the values represent the amount of reflected (or transmitted) light a surface will produce. The final display color is influenced by external factors such as light sources. Having the numerical inputs in DDCS doesn't fit the context these values are in. Please review these documents and bug reports: http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Post_Process/CM_And_Exposure http:*web.archive.org/web/20130823123021/http:*www.blender.org/development/release-logs/blender-256-beta/color-management/ https://developer.blender.org/T38031 https://developer.blender.org/T27945

I tend to agree with maisef here in that language is useful.

My addition to this is that the reference space, that is the internal working float buffer space, will almost always have different primaries from the output space, and most certainly twisted from the display's unique output.

Extending the basic example of the color wheel, when we map the relative RGB values of minimum (0.0) to maximum (1.0), these require a transformation of intensity to the low dynamic ranges of displays and other outputs. However this is only one half of color.

The other half is the actual chromaticity of the R, G, and B channels. Every output context is unique; from paper to display screens. All displays too have unique dispositions, even within identical models. Even broad categories have tremendous variation; from a 75% sRGB to a 95% sRGB to a wide gamut. Every single display will have tremendous variations in the color (chromaticity) of the R, G, and B colored lights.

When the reference space layout of the color wheels is mapped to an output, it must route through OCIO for this very reason. There is simply no way to have an artist get a rendering of the color they are attempting to choose otherwise.

Applying a transfer curve (intensity curve) is not enough and never will be. A full transformation has to occur, and that must be routed through OCIO.

I tend to agree with maisef here in that language is useful. My addition to this is that the *reference* space, that is the internal working float buffer space, will *almost always* have different primaries from the output space, and most certainly twisted from the display's unique output. Extending the basic example of the color wheel, when we map the relative RGB values of minimum (0.0) to maximum (1.0), these require a transformation of intensity to the low dynamic ranges of displays and other outputs. However this is only one half of color. The other half is the actual chromaticity of the R, G, and B channels. Every output context is unique; from paper to display screens. All displays too have unique dispositions, even within identical models. Even broad categories have tremendous variation; from a 75% sRGB to a 95% sRGB to a wide gamut. Every single display will have tremendous variations in the color (chromaticity) of the R, G, and B colored lights. When the reference space layout of the color wheels is mapped to an output, it *must* route through OCIO for this very reason. There is simply no way to have an artist get a rendering of the color they are attempting to choose otherwise. Applying a transfer curve (intensity curve) is not enough and never will be. A full transformation has to occur, and that must be routed through OCIO.

Added subscriber: @khtrammell-1

Hey guys -

I'm also experiencing negative effects of this change, as demonstrated in this video: http://youtu.be/CoCYlHJrdBw

I agree with maiself that "this property is important for creating materials and for compositing" and would welcome the former behavior - I believe "linear". My apologies, I'm trying to make sense of the past comments but it gets a bit technical. Do I understand from psy-fi that the former behavior will return in the next Blender release?

Thanks for all the hard work!

Hey guys - I'm also experiencing negative effects of this change, as demonstrated in this video: http://youtu.be/CoCYlHJrdBw I agree with maiself that "this property is important for creating materials and for compositing" and would welcome the former behavior - I believe "linear". My apologies, I'm trying to make sense of the past comments but it gets a bit technical. Do I understand from psy-fi that the former behavior will return in the next Blender release? Thanks for all the hard work!

At the request of Pablo, I quickly did up the explanation above to highlight the bug from a colorimetry side.

Color Primaries

All color spaces have unique primaries. This means that the color data references intensities with unique colors for each primary color.

Display Primaries

All displays have unique primaries.
Even identical displays with identical panels will have variations.

Without Color Managment

Without color management, the data values in an image are dumped directly to the output without consideration for their intentions. This leads to random output.
Even massively expensive displays, printers, and other outputs require careful color management.

With Color Management
It is only with a carefully designed color management system that colors mean anything other than random junk. Consideration for the source color space and destinations has to happen in order for this system to be complete and give meaning to the data values.

At the request of Pablo, I quickly did up the explanation above to highlight the bug from a colorimetry side. **Color Primaries** - ***All*** color spaces have unique primaries. This means that the color data references intensities with *unique* colors for each primary color. ![500px-Different-colorspaces.png](https://archive.blender.org/developer/F134228/500px-Different-colorspaces.png) **Display Primaries** - ***All*** displays have unique primaries. ![500px-Display-primaries.png](https://archive.blender.org/developer/F134221/500px-Display-primaries.png) - Even ***identical*** displays with identical panels will have variations. ![500px-Different-primaries.png](https://archive.blender.org/developer/F134220/500px-Different-primaries.png) **Without Color Managment** - ***Without*** color management, the data values in an image are dumped directly to the output without consideration for their intentions. This leads to **random** output. - Even massively expensive displays, printers, and other outputs require careful color management. ![500px-No-color-management.png](https://archive.blender.org/developer/F134222/500px-No-color-management.png) **With Color Management** - It is only with a carefully designed color management system that colors mean anything other than random junk. Consideration for the source color space and destinations has to happen in order for this system to be complete and give meaning to the data values. ![500px-With-color-management.png](https://archive.blender.org/developer/F134223/500px-With-color-management.png)

I would add that many artists are going to likely split right down the middle on this regarding whether to display the transfer curve as perceptual (current) or display linear (previous) and there is no right or wrong, but rather expectation and experience.

Again, it makes this entirely plausible to select the transfer curve on an artist by artist basis. There are plenty of times an artist wants a perceptual view of that gradient, as I am sure Kent and others will acknowledge.

Psy, if you are reading, we chatted about this at the OCIO BoF at SIGGRAPH. OCIO is adding the concept of primaries (for the chromaticity side) and isolating the transfer curve (for the perceptual intensity side) for individual spaces, so this will need to be revisited likely when it lands.

I would add that many artists are going to likely split right down the middle on this regarding whether to display the transfer curve as perceptual (current) or display linear (previous) and there is no right or wrong, but rather expectation and experience. Again, it makes this entirely plausible to select the transfer curve on an artist by artist basis. There are plenty of times an artist wants a perceptual view of that gradient, as I am sure Kent and others will acknowledge. Psy, if you are reading, we chatted about this at the OCIO BoF at SIGGRAPH. OCIO is adding the concept of primaries (for the chromaticity side) and isolating the transfer curve (for the perceptual intensity side) for individual spaces, so this will need to be revisited likely when it lands.

Great writeup, sobotka! It all makes much more sense to me now. I suppose the most relevant example of this for me is when I render/composite my image on my right monitor exactly how I want, yet when I drag the image to my left monitor the color is barely different enough to be annoying. While it is annoying, it's quite minor compared to shifting a fundamental aspect of building materials.

Can we have the option of both, like a checkbox on the color wheel node that enables linear vs perceptual behavior of that specific node? Or perhaps the issue is more global and we could enable/disable it globally in system preferences?

Great writeup, sobotka! It all makes much more sense to me now. I suppose the most relevant example of this for me is when I render/composite my image on my right monitor exactly how I want, yet when I drag the image to my left monitor the color is barely different enough to be annoying. While it is annoying, it's quite minor compared to shifting a fundamental aspect of building materials. Can we have the option of both, like a checkbox on the color wheel node that enables linear vs perceptual behavior of that specific node? Or perhaps the issue is more global and we could enable/disable it globally in system preferences?

It all makes much more sense to me now. I suppose the most relevant example of this for me is when I render/composite my image on my right monitor exactly how I want, yet when I drag the image to my left monitor the color is barely different enough to be annoying. While it is annoying, it's quite minor compared to shifting a fundamental aspect of building materials.

You have to remember that the internal model is assumption based currently (via the config) which assumes sRGB primaries. Every space has different primaries, which means that dumping raw values (even curved for perceptual or not) is completely whack on a wide gamut, and still quite whack on an sRGB display, as they vary quite significantly.

If you get a basic colorimeter, you can get consistent views on content in the viewer, just not the wheel.

The good news is Psy has promised to address this. I was going to dig in, but I worry I will miss some gotcha in the code.

Can we have the option of both, like a checkbox on the color wheel node that enables linear vs perceptual behavior of that specific node? Or perhaps the issue is more global and we could enable/disable it globally in system preferences?

I am more inclined to believe that a selection box makes sense to cover the varying needs. Sometimes perceptual is great, sometimes a linearized version. And even with perceptual, there are varieties.

This has me leaning toward a UI element, which I think Psy is open to as well.

> It all makes much more sense to me now. I suppose the most relevant example of this for me is when I render/composite my image on my right monitor exactly how I want, yet when I drag the image to my left monitor the color is barely different enough to be annoying. While it is annoying, it's quite minor compared to shifting a fundamental aspect of building materials. You have to remember that the internal model is assumption based currently (via the config) which assumes sRGB primaries. Every space has different primaries, which means that dumping raw values (even curved for perceptual or not) is completely whack on a wide gamut, and still quite whack on an sRGB display, as they vary quite significantly. If you get a basic colorimeter, you *can* get consistent views on content in the viewer, just not the wheel. The good news is Psy has promised to address this. I was going to dig in, but I worry I will miss some gotcha in the code. > Can we have the option of both, like a checkbox on the color wheel node that enables linear vs perceptual behavior of that specific node? Or perhaps the issue is more global and we could enable/disable it globally in system preferences? I am more inclined to believe that a selection box makes sense to cover the varying needs. Sometimes perceptual is great, sometimes a linearized version. And even with perceptual, there are varieties. This has me leaning toward a UI element, which I think Psy is open to as well.

So an update...

Looks like the most recent HSV wheels actually fix the chromaticity issues I cited above. Sadly the value slider was also part of that transform.

I've worked on a first pass at a patch to at least abide by the color_picking role (why did it get renamed from color_picker? ARGGGH) and now it seems to work. Would need testing by anyone that can compile.

I added a role conversion, so the chromaticity of the wheel is still as per the display transform, but the gradient slider for value should abide by the role set in the config.ocio file. I also changed the config.ocio to be Linear, and look to make it selectable by default.

Psy: It seems that the actual UI display is still completely linear, and I'd love to know where the graphical drawing portion is so that I can try to fix it to match the transfer curve selected by the role. I am thinking it is in interface_widgets.c, but maybe I'm wrong?

See #41498 F105190

So an update... Looks like the most recent HSV wheels actually fix the chromaticity issues I cited above. Sadly the value slider was also part of that transform. I've worked on a first pass at a patch to at least abide by the color_picking role (why did it get renamed from color_picker? ARGGGH) and now it seems to work. Would need testing by anyone that can compile. I added a role conversion, so the chromaticity of the wheel is still as per the display transform, but the gradient slider for value should abide by the role set in the config.ocio file. I also changed the config.ocio to be Linear, and look to make it selectable by default. Psy: It seems that the actual UI display is still completely linear, and I'd love to know where the graphical drawing portion is so that I can try to fix it to match the transfer curve selected by the role. I am thinking it is in interface_widgets.c, but maybe I'm wrong? See #41498 [F105190](https://archive.blender.org/developer/F105190/color_picker.diff)

◀ Merged tasks: #41498.

Please do not open a new task in such cases, only adds noise…

So I have completely redone how the original HSV wheel handled color, and tested quite extensively.

I believe that the many flips to and from display are not necessary.

What I have done, is implement the role feature for color_picking. This effectively lets an artist set the transfer curve to be whatever they need for a given set of tasks. For example, if you require a perceptual curve, you could set to a log or sRGB transfer. If you require a linear transfer, you can specify linear.

The code below is a snippet, and I'd need @Psy-Fi to have a peek at it to see if he sees any issues.

I have completely commented out the ui_block_to_display_space_v3 code, so that it is a complete no-op.

I then take the HSV resultant value, and convert the value to the artist-driven transfer curve as above prior to generating the RGB values from it.

Finally, immediately before drawing to screen, I put the original value back so that the inversion back to RGB (scene linear reference space) is perfect, and color manage the final RGB output value to accommodate a proper primaries transform to screen if there is one. I have tested the following code with properly adjusted primaries, and it does work correctly.

This all seems to work extremely well, but I will need @Psy-Fi's wonderful brain and eyes to look at things before I go any further.

Here's the code change for reference:

static void ui_draw_but_HSVCIRCLE(uiBut *but, uiWidgetColors *wcol, const rcti *rect)
{
    const int tot = 64;
    const float radstep = 2.0f * (float)M_PI / (float)tot;
    const float centx = BLI_rcti_cent_x_fl(rect);
    const float centy = BLI_rcti_cent_y_fl(rect);
    float radius = (float)min_ii(BLI_rcti_size_x(rect), BLI_rcti_size_y(rect)) / 2.0f;

    /* gouraud triangle fan */
    const float *hsv_ptr = ui_block_hsv_get(but->block);
    float xpos, ypos, ang = 0.0f;
    float rgb[3], hsvo[3], hsv[3], col[3], colcent[3];
    int a;
    bool color_profile = ui_color_picker_use_display_colorspace(but);
    struct ColorManagedDisplay *display = ui_block_display_get(but->block);

    /* color */
    ui_get_but_vectorf(but, rgb);

    /* since we use compat functions on both 'hsv' and 'hsvo', they need to be initialized */
    hsvo[0] = hsv[0] = hsv_ptr[0];
    hsvo[1] = hsv[1] = hsv_ptr[1];
    hsvo[2] = hsv[2] = hsv_ptr[2];

    *if (color_profile)*    ui_block_to_display_space_v3(but->block, rgb);

    ui_rgb_to_color_picker_compat_v(rgb, hsv);
    copy_v3_v3(hsvo, hsv);

    CLAMP(hsv[2], 0.0f, 1.0f); /* for display only */

    /* exception: if 'lock' is set
     * lock the value of the color wheel to 1.
     * Useful for color correction tools where you're only interested in hue. */
    if (but->flag & UI_BUT_COLOR_LOCK) {
        if (U.color_picker_type == USER_CP_CIRCLE_HSV)
            hsv[2] = 1.f;
        else
            hsv[2] = 0.5f;
    }

    // Value based on artist setting transfer curve via color_picker role.
    rgb[0] = rgb[1] = rgb[2] = hsv[2];
    IMB_colormanagement_scene_linear_to_role_v3(rgb, COLOR_ROLE_COLOR_PICKING);

    // Store the previous Value temporarily in the Green channel.
    rgb[1] = hsv[2];
    hsv[2] = rgb[0];

    ui_color_picker_to_rgb(0.f, 0.f, hsv[2], colcent, colcent + 1, colcent + 2); //TROYREMOVE

    glShadeModel(GL_SMOOTH);

    glBegin(GL_TRIANGLE_FAN);
    glColor3fv(colcent);
    glVertex2f(centx, centy);

    for (a = 0; a <= tot; a++, ang += radstep) {
        float si = sin(ang);
        float co = cos(ang);

        ui_hsvcircle_vals_from_pos(hsv, hsv + 1, rect, centx + co * radius, centy + si * radius);

        *Restore the original Value so that the entire circular wheel can be properly* color managed, and then color manage and adjust for primaries.
        hsv[2] = rgb[1];

        ui_color_picker_to_rgb_v(hsv, col);
        IMB_colormanagement_scene_linear_to_display_v3(col, display);

        glColor3fv(col);
        glVertex2f(centx + co * radius, centy + si * radius);
    }
    glEnd();

    glShadeModel(GL_FLAT);

    /* fully rounded outline */
    glPushMatrix();
    glTranslatef(centx, centy, 0.0f);
    glEnable(GL_BLEND);
    glEnable(GL_LINE_SMOOTH);
    glColor3ubv((unsigned char *)wcol->outline);
    glutil_draw_lined_arc(0.0f, M_PI * 2.0, radius, tot + 1);
    glDisable(GL_BLEND);
    glDisable(GL_LINE_SMOOTH);
    glPopMatrix();

    /* cursor */
    ui_hsvcircle_pos_from_vals(but, rect, hsvo, &xpos, &ypos);

    ui_hsv_cursor(xpos, ypos);
}

So I have completely redone how the original HSV wheel handled color, and tested quite extensively. I believe that the many flips to and from display are not necessary. What I have done, is implement the role feature for color_picking. This effectively lets an artist set the transfer curve to be whatever they need for a given set of tasks. For example, if you require a perceptual curve, you could set to a log or sRGB transfer. If you require a linear transfer, you can specify linear. The code below is a snippet, and I'd need @Psy-Fi to have a peek at it to see if he sees any issues. I have completely _commented_ out the ui_block_to_display_space_v3 code, so that it is a complete no-op. I then take the HSV resultant value, and convert the value to the artist-driven transfer curve as above prior to generating the RGB values from it. Finally, immediately before drawing to screen, I put the original value back so that the inversion back to RGB (scene linear reference space) is perfect, and color manage the final RGB output value to accommodate a proper primaries transform to screen if there is one. I have tested the following code with properly adjusted primaries, and it does work correctly. This all seems to work extremely well, but I will need @Psy-Fi's wonderful brain and eyes to look at things before I go any further. Here's the code change for reference: ``` static void ui_draw_but_HSVCIRCLE(uiBut *but, uiWidgetColors *wcol, const rcti *rect) { const int tot = 64; const float radstep = 2.0f * (float)M_PI / (float)tot; const float centx = BLI_rcti_cent_x_fl(rect); const float centy = BLI_rcti_cent_y_fl(rect); float radius = (float)min_ii(BLI_rcti_size_x(rect), BLI_rcti_size_y(rect)) / 2.0f; /* gouraud triangle fan */ const float *hsv_ptr = ui_block_hsv_get(but->block); float xpos, ypos, ang = 0.0f; float rgb[3], hsvo[3], hsv[3], col[3], colcent[3]; int a; bool color_profile = ui_color_picker_use_display_colorspace(but); struct ColorManagedDisplay *display = ui_block_display_get(but->block); /* color */ ui_get_but_vectorf(but, rgb); /* since we use compat functions on both 'hsv' and 'hsvo', they need to be initialized */ hsvo[0] = hsv[0] = hsv_ptr[0]; hsvo[1] = hsv[1] = hsv_ptr[1]; hsvo[2] = hsv[2] = hsv_ptr[2]; *if (color_profile)* ui_block_to_display_space_v3(but->block, rgb); ui_rgb_to_color_picker_compat_v(rgb, hsv); copy_v3_v3(hsvo, hsv); CLAMP(hsv[2], 0.0f, 1.0f); /* for display only */ /* exception: if 'lock' is set * lock the value of the color wheel to 1. * Useful for color correction tools where you're only interested in hue. */ if (but->flag & UI_BUT_COLOR_LOCK) { if (U.color_picker_type == USER_CP_CIRCLE_HSV) hsv[2] = 1.f; else hsv[2] = 0.5f; } // Value based on artist setting transfer curve via color_picker role. rgb[0] = rgb[1] = rgb[2] = hsv[2]; IMB_colormanagement_scene_linear_to_role_v3(rgb, COLOR_ROLE_COLOR_PICKING); // Store the previous Value temporarily in the Green channel. rgb[1] = hsv[2]; hsv[2] = rgb[0]; ui_color_picker_to_rgb(0.f, 0.f, hsv[2], colcent, colcent + 1, colcent + 2); //TROYREMOVE glShadeModel(GL_SMOOTH); glBegin(GL_TRIANGLE_FAN); glColor3fv(colcent); glVertex2f(centx, centy); for (a = 0; a <= tot; a++, ang += radstep) { float si = sin(ang); float co = cos(ang); ui_hsvcircle_vals_from_pos(hsv, hsv + 1, rect, centx + co * radius, centy + si * radius); *Restore the original Value so that the entire circular wheel can be properly* color managed, and then color manage and adjust for primaries. hsv[2] = rgb[1]; ui_color_picker_to_rgb_v(hsv, col); IMB_colormanagement_scene_linear_to_display_v3(col, display); glColor3fv(col); glVertex2f(centx + co * radius, centy + si * radius); } glEnd(); glShadeModel(GL_FLAT); /* fully rounded outline */ glPushMatrix(); glTranslatef(centx, centy, 0.0f); glEnable(GL_BLEND); glEnable(GL_LINE_SMOOTH); glColor3ubv((unsigned char *)wcol->outline); glutil_draw_lined_arc(0.0f, M_PI * 2.0, radius, tot + 1); glDisable(GL_BLEND); glDisable(GL_LINE_SMOOTH); glPopMatrix(); /* cursor */ ui_hsvcircle_pos_from_vals(but, rect, hsvo, &xpos, &ypos); ui_hsv_cursor(xpos, ypos); } ```

Shouldn't this color management first check that color management is used?

So as to (for example) not apply to theme colors which are sRGB always.

Shouldn't this color management first check that color management is used? So as to (for example) not apply to theme colors which are sRGB always.

So as to (for example) not apply to theme colors which are sRGB always.

Thanks for this comment Campbell.

I am a little confused on a couple of points, so I will toss them out and see if anyone can offer guidance:

Theme colors as sRGB. I have hunted through the code and see nowhere where the theme is defined as sRGB. Neither in transfer curve (the intensity to LDR transform as given in the default Blender OCIO config) nor the chromaticity (the color / hue of the values). It makes sense that a UI abide by a space, but I fail to see it. The patch I am working on does in fact make the transfer curve artist selectable and is displayed in the gradient picker portion. Color bands and all other UI elements should be color managed.
Where else would this apply? I am unclear what aspect of the above code would apply elsewhere? The gradient portion of the color picker should be artist selectable, as the patch will handle. The colors within the circle must also route through CM to properly display on various displays and outputs. I cannot see sRGB being terribly useful anywhere, aside from perhaps non-artistic elements such as background greys or color coded theme needs.

> So as to (for example) not apply to theme colors which are sRGB always. Thanks for this comment Campbell. I am a little confused on a couple of points, so I will toss them out and see if anyone can offer guidance: - Theme colors as sRGB. I have hunted through the code and see nowhere where the theme is defined as sRGB. Neither in transfer curve (the intensity to LDR transform as given in the default Blender OCIO config) nor the chromaticity (the color / hue of the values). It makes sense that a UI abide by a space, but I fail to see it. The patch I am working on does in fact make the transfer curve artist selectable and is displayed in the gradient picker portion. Color bands and all other UI elements should be color managed. - Where else would this apply? I am unclear what aspect of the above code would apply elsewhere? The gradient portion of the color picker should be artist selectable, as the patch will handle. The colors within the circle must also route through CM to properly display on various displays and outputs. I cannot see sRGB being terribly useful anywhere, aside from perhaps non-artistic elements such as background greys or color coded theme needs.

@troy_s, this last patch addresses the transfer curve portion issue but display interpolation is still done in a linear manner across endpoints of the triangles that make up the color wheel during display. Also you'd need to change the code in the vertical widgets to use the unmodified value for displaying the slider, see ui_draw_but_HSV_v. also would probably need to be hooked up in the update functions. Pretty much everywhere ui_rgb_to_color_picker_compat_v, ui_color_picker_to_rgb_v or rgb_to_hsl_v (maybe I forget some even) exist, code should be checked for compliance.

EDIT:
The theme issue is the color property that we discussed. This is the if (color_profile)
check that you have commented out.

Some color properties are considered to be in display space already. Of course we could convert those to the color picker role to get color interpolation in that space. That would work provided inversion is possible in the first place, of course.

@troy_s, this last patch addresses the transfer curve portion issue but display interpolation is still done in a linear manner across endpoints of the triangles that make up the color wheel during display. Also you'd need to change the code in the vertical widgets to use the unmodified value for displaying the slider, see ui_draw_but_HSV_v. also would probably need to be hooked up in the update functions. Pretty much everywhere ui_rgb_to_color_picker_compat_v, ui_color_picker_to_rgb_v or rgb_to_hsl_v (maybe I forget some even) exist, code should be checked for compliance. EDIT: The theme issue is the color property that we discussed. This is the if (color_profile) check that you have commented out. Some color properties are considered to be in display space already. Of course we could convert those to the color picker role to get color interpolation in that space. That would work provided inversion is possible in the first place, of course.

@troy_s, theme colors are passed directly to OpenGL, so the color picker shouldn't do any conversions in that case.

@troy_s I find it strange that you use the red component of the full color transform to get the value...Also I am troubled because I don't think the visual result on the wheel would represent what you get when you click on it...I should test locally for that though.

@Psy-Fi:

this last patch addresses the transfer curve portion issue but display interpolation is still done in a linear manner across endpoints of the triangles that make up the color wheel during display. Also you'd need to change the code in the vertical widgets to use the unmodified value for displaying the slider, see ui_draw_but_HSV_v. also would probably need to be hooked up in the update functions

I guessed at the linear interpolation, but I cannot see an easy way past it. Would be ideal to have a bit buffer for both, then simply color manage as needed. Needless to say, the linear interpolation happens between small gaps, and is more correct than previous, including accounting for transfer curve adjustments in display LUTs.

This is the if (color_profile) check that you have commented out.

Just a proof of principle. I can add that back, although I am unsure when this code would be called and not need to be color managed?

I find it strange that you use the red component of the full color transform to get the value...Also I am troubled because I don't think the visual result on the wheel would represent what you get when you click on it...I should test locally for that though.

The transfer curve side of color is always a 1D transform or formula on intensity, so it is simply a cheat here to avoid rewriting a v1 code block. I copy the value to all three channels, transform, then used the red channel arbitrarily; they should all be uniform given it is achromatic. The result though also syncs with the artist's chosen transfer, and properly aligns the palette to the value. It does need testing of course.

Also, this reversibility is extremely frustrating. It is ugly as hell for CM. Wiser would be to have the to-be-displayed colors stored somewhere always, and then do a single direction toward correction. Almost always display corrections are 3D LUTs, and the goofy back and forth architecture makes this impossible.

@ideasman42:

theme colors are passed directly to OpenGL, so the color picker shouldn't do any conversions in that case.

Some GL blitting functions assume sRGB transfer curves, which is problematic. The color however, always must be corrected if it is for artistic purposes, with no exceptions.

Thanks for the comments folks.

@Psy-Fi: > this last patch addresses the transfer curve portion issue but display interpolation is still done in a linear manner across endpoints of the triangles that make up the color wheel during display. Also you'd need to change the code in the vertical widgets to use the unmodified value for displaying the slider, see ui_draw_but_HSV_v. also would probably need to be hooked up in the update functions I guessed at the linear interpolation, but I cannot see an easy way past it. Would be ideal to have a bit buffer for both, then simply color manage as needed. Needless to say, the linear interpolation happens between small gaps, and is more correct than previous, including accounting for transfer curve adjustments in display LUTs. > This is the if (color_profile) check that you have commented out. Just a proof of principle. I can add that back, although I am unsure when this code would be called and not need to be color managed? >I find it strange that you use the red component of the full color transform to get the value...Also I am troubled because I don't think the visual result on the wheel would represent what you get when you click on it...I should test locally for that though. The transfer curve side of color is always a 1D transform or formula on intensity, so it is simply a cheat here to avoid rewriting a v1 code block. I copy the value to all three channels, transform, then used the red channel arbitrarily; they should all be uniform given it is achromatic. The result though also syncs with the artist's chosen transfer, and properly aligns the palette to the value. It does need testing of course. Also, this reversibility is extremely frustrating. It is ugly as hell for CM. Wiser would be to have the to-be-displayed colors stored somewhere always, and then do a single direction toward correction. Almost *always* display corrections are 3D LUTs, and the goofy back and forth architecture makes this impossible. @ideasman42: >theme colors are passed directly to OpenGL, so the color picker shouldn't do any conversions in that case. Some GL blitting functions assume sRGB transfer curves, which is problematic. The color however, always must be corrected if it is for artistic purposes, with no exceptions. Thanks for the comments folks.

This comment was removed by @troy_s

*This comment was removed by @troy_s*

Added subscribers: @EduardoMaldonado, @Sergey

◀ Merged tasks: #41869.

Added subscriber: @david_black

Hi, are there any updates?

I didn't use 2.71 due to a few Cycles memory and other render issues (now fixed). So only recently came across the colour wheel changes. Must admit finding it confusing, in 2.70a (and previous Blender versions) an equal RGB of .500 logically equates to HSV value of .500, now it equals .735.

Since the change, will people be creating scenes with incorrectly setup materials? Brecht previously mentioned keeping material values below .800 but now an equal RGB of .800 equates to an HSV value of.906. So the first thing someone is likely to do is lower the HSV value to .800, which is an equal RGB of .604.

Photoshop being colour managed still appears to use a linear scale for colour picker selection across HSB and RGB?

Thank you kindly for your time,
David

Hi, are there any updates? I didn't use 2.71 due to a few Cycles memory and other render issues (now fixed). So only recently came across the colour wheel changes. Must admit finding it confusing, in 2.70a (and previous Blender versions) an equal RGB of .500 logically equates to HSV value of .500, now it equals .735. Since the change, will people be creating scenes with incorrectly setup materials? Brecht previously mentioned keeping material values below .800 but now an equal RGB of .800 equates to an HSV value of.906. So the first thing someone is likely to do is lower the HSV value to .800, which is an equal RGB of .604. Photoshop being colour managed still appears to use a linear scale for colour picker selection across HSB and RGB? Thank you kindly for your time, David

@david_black You are mixing apples and oranges when discussing Photoshop. Photoshop operates on curved non-linear display spaces by default, and I believe it only recently, if at all, color manages the wheel. So it is in no way linear, nor even belongs in this discussion.

The issue is much larger than linear versus non-linear, and requires a deeper bit of code that is on the map, but not yet in place to the best of my knowledge.

@david_black You are mixing apples and oranges when discussing Photoshop. Photoshop operates on curved non-linear display spaces by default, and I believe it only recently, if at all, color manages the wheel. So it is in no way linear, nor even belongs in this discussion. The issue is much larger than linear versus non-linear, and requires a deeper bit of code that is on the map, but not yet in place to the best of my knowledge.

Thank you sobotka, for you informative reply. It could be interpreted as being a little harsh, but I am sure it is not intended that way. Writing from an artist’s perspective, I was unaware it is wrong to compare the perceived way Blender and Photoshop handle their respective colour picker selection.

Moving forwards, until your code is added, is there an artist friendly conversion method while entering values to maintain a previous (2.70a) style workflow? Or, would it be possible to (temporally) add a check box on the colour picker, so an artist can chose to see values represented as (2.70a) linear?

Thank you

Thank you sobotka, for you informative reply. It could be interpreted as being a little harsh, but I am sure it is not intended that way. Writing from an artist’s perspective, I was unaware it is wrong to compare the perceived way Blender and Photoshop handle their respective colour picker selection. Moving forwards, until your code is added, is there an artist friendly conversion method while entering values to maintain a previous (2.70a) style workflow? Or, would it be possible to (temporally) add a check box on the colour picker, so an artist can chose to see values represented as (2.70a) linear? Thank you

Apologies. You are quite right... It was never intended as harsh.

There is currently no easy solution, as the problem (like so many) is complex. An artist wants to see the proper colors in a color wheel, and that means that the wheel itself must always be color managed for color, or chromaticities.

However, in the current layout, all of the color management transforms bundle both the chromaticities (color) and transfer curve (the linear versus curved aspect) into a single transform. They need to be unbundled as the patch begins to address.

Apologies. You are quite right... It was never intended as harsh. There is currently no easy solution, as the problem (like so many) is complex. An artist wants to see the proper colors in a color wheel, and that means that the wheel itself *must* always be color managed for color, or chromaticities. However, in the current layout, all of the color management transforms bundle both the chromaticities (color) and transfer curve (the linear versus curved aspect) into a single transform. They need to be unbundled as the patch begins to address.

Added subscriber: @padone

Actually Blender has two main issues:

There is no way for an artist to enter sRGB colors for the materials. It should be added a sRGB tab to the color panel allowing the artist to enter sRGB values to define a color.

Forcing an artist to enter linear values instead of sRGB is the same as forcing someone to enter binary numbers instead of decimals. Linear values don't mean anything to artists. Artists are used to Photoshop or Painter that use sRGB space, the same as almost any graphics application around.

Please add a sRGB tab.

Blender is good in importing sRGB textures, for example from png or jpg formats, but it fails to import sRGB material colors, for example from dae fbx obj or 3ds formats.

If you import a obj file with mtl defining a dark red sRGB 0.5 0 0, Blender will import the dark red as a linear value. That is totally wrong because it is a sRGB value. This is true for all the other formats as well, dae fbx 3ds etc. This is why imported models have a "washed-out" look. If the model uses textures instead of materials to define colors then the problem doesn't arise because textures are handled correctly.

Please fix the importing of sRGB materials the same as you fixed the importing of sRGB textures.

If you are interested my post #43025 explains those points more in deep but basically these are the things that need to be fixed. Please let me know what you think.

bye :)

Actually Blender has two main issues: 1) There is no way for an artist to enter sRGB colors for the materials. It should be added a sRGB tab to the color panel allowing the artist to enter sRGB values to define a color. Forcing an artist to enter linear values instead of sRGB is the same as forcing someone to enter binary numbers instead of decimals. Linear values don't mean anything to artists. Artists are used to Photoshop or Painter that use sRGB space, the same as almost any graphics application around. Please add a sRGB tab. 2) Blender is good in importing sRGB textures, for example from png or jpg formats, but it fails to import sRGB material colors, for example from dae fbx obj or 3ds formats. If you import a obj file with mtl defining a dark red sRGB 0.5 0 0, Blender will import the dark red as a linear value. That is totally wrong because it is a sRGB value. This is true for all the other formats as well, dae fbx 3ds etc. This is why imported models have a "washed-out" look. If the model uses textures instead of materials to define colors then the problem doesn't arise because textures are handled correctly. Please fix the importing of sRGB materials the same as you fixed the importing of sRGB textures. If you are interested my post #43025 explains those points more in deep but basically these are the things that need to be fixed. Please let me know what you think. bye :)

The importer issue is different than this issue. Probably original issue shouldn't have been merged here.

About sRGB vs linear, probably the cleanest solution is to have a toggle to see the linear or srgb value for properties that are linear.

The importer issue is different than this issue. Probably original issue shouldn't have been merged here. About sRGB vs linear, probably the cleanest solution is to have a toggle to see the linear or srgb value for properties that are linear.

Forcing an artist to enter linear values instead of sRGB is the same as forcing someone to enter binary numbers instead of decimals. Linear values don't mean anything to artists. Artists are used to Photoshop or Painter that use sRGB space, the same as almost any graphics application around.

@padone, your anecdotal references here are not useful. If you look above, you will see an extremely capable artist @khtrammell-1 speak of needing linearized values. @padone, the inference is that you are unaware of the needs of both transfer curved and linearized values?

Please add a sRGB tab.

This would be irrelevant in all pipelines that use a non-sRGB / 709 reference space. Remember that many small studios must target DCI-P3 or REC 2020, and both references would not desire inputting values in a limited and constricted gamut such as 709 / sRGB.

@Psy-Fi I still believe the most logical option is as follows, of which the wheel is 80% there:

Implement role_color_picker that is the pure transfer curve.
Provide a group box below the picker that changes the role and defaults to the config. This would allow an artist to toggle between an LDR transfer curve transform and a linear as needed.
In theory, to address Mr. Selan's suggestion in the linked references above, we would likely need a primaries transform via role_primaries (set to raw?) or something, so that the actual HSV circle can be managed to whatever reference space without the transfer curve applied to the circle. This is a relatively minor detail in the grand scheme of things, but would address his comment.
The default display transform could then be role_primaries followed by the role_color_picker or role_transfer or whatever. The first would be a noop by default, which maintains the exact behavior in Blender, while fixing this issue and beginning to fix the working space issues.

> Forcing an artist to enter linear values instead of sRGB is the same as forcing someone to enter binary numbers instead of decimals. Linear values don't mean anything to artists. Artists are used to Photoshop or Painter that use sRGB space, the same as almost any graphics application around. @padone, your anecdotal references here are not useful. If you look above, you will see an extremely capable artist @khtrammell-1 speak of needing linearized values. @padone, the inference is that you are unaware of the needs of both transfer curved and linearized values? > Please add a sRGB tab. This would be irrelevant in all pipelines that use a non-sRGB / 709 reference space. Remember that many small studios must target DCI-[P3](https://archive.blender.org/developer/P3.txt) or REC 2020, and both references would not desire inputting values in a limited and constricted gamut such as 709 / sRGB. @Psy-Fi I still believe the most logical option is as follows, of which the wheel is 80% there: - Implement role_color_picker that is the pure transfer curve. - Provide a group box below the picker that changes the role and defaults to the config. This would allow an artist to toggle between an LDR transfer curve transform and a linear as needed. - In theory, to address Mr. Selan's suggestion in the linked references above, we would likely need a primaries transform via role_primaries (set to raw?) or something, so that the actual HSV circle can be managed to whatever reference space *without* the transfer curve applied to the circle. This is a relatively minor detail in the grand scheme of things, but would address his comment. - The default display transform could then be role_primaries followed by the role_color_picker or role_transfer or whatever. The first would be a noop by default, which maintains the exact behavior in Blender, while fixing this issue and beginning to fix the working space issues.

@Psy-Fi
I agree that shouldn't be merged .. but unfortunately it was .. I'll try to open a collada bug report and we'll see ..

I also agree about the linear/srgb toggle. Two RGB tabs are probably cumbersome. It seems to me that technicians need to access linear space values for math computations, while artists need srgb values to define colors. So a way to handle both is really needed.

@troy_s
In general artists work in srgb space for videos and adobe rgb for paper. Then do a color conversion to match the output device. So srgb is good even if your final output is different (rec709 dci or whatever). At least this is how they recommend to work at Eizo (see page 13).

Color Management with 3D CG

Thank you very much to both of you for your reply :)

@Psy-Fi I agree that shouldn't be merged .. but unfortunately it was .. I'll try to open a collada bug report and we'll see .. I also agree about the linear/srgb toggle. Two RGB tabs are probably cumbersome. It seems to me that technicians need to access linear space values for math computations, while artists need srgb values to define colors. So a way to handle both is really needed. @troy_s In general artists work in srgb space for videos and adobe rgb for paper. Then do a color conversion to match the output device. So srgb is good even if your final output is different (rec709 dci or whatever). At least this is how they recommend to work at Eizo (see page 13). [Color Management with 3D CG ](http://www.eizoglobal.com/support/db/files/catalogs/ce/Color_Management_with_3D_CG.pdf) Thank you very much to both of you for your reply :)

In #41287#277823, @padone wrote:
@troy_s
In general artists work in srgb space for videos and adobe rgb for paper. Then do a color conversion to match the output device. So srgb is good even if your final output is different (rec709 dci or whatever). At least this is how they recommend to work at Eizo (see page 13).

This is completely incorrect, and you are again attempting to make your case based on inaccurate "all artist" types of statements.

When you are working on a project, you determine a reference working space at the beginning of the project. That may very well be sRGB / 709, but it is equally likely (and more so in the modern era) to target wider gamuts. sRGB / 709 primaries yield a vastly smaller gamut than DCI-P3 or REC 2020. There is simply no method to upgamut once you have chosen to work in a smaller gamut. Your gamut is constrained. The Eizo documentation here is not relevant, as it is merely offering up an example.

I would strongly encourage you to learn more about color management and color pipelines before making such claims.

> In #41287#277823, @padone wrote: > @troy_s > In general artists work in srgb space for videos and adobe rgb for paper. Then do a color conversion to match the output device. So srgb is good even if your final output is different (rec709 dci or whatever). At least this is how they recommend to work at Eizo (see page 13). This is completely incorrect, and you are again attempting to make your case based on inaccurate "all artist" types of statements. When you are working on a project, you determine a reference working space at the beginning of the project. That may very well be sRGB / 709, but it is equally likely (and more so in the modern era) to target wider gamuts. sRGB / 709 primaries yield a vastly smaller gamut than DCI-[P3](https://archive.blender.org/developer/P3.txt) or REC 2020. There is simply no method to upgamut once you have chosen to work in a smaller gamut. Your gamut is constrained. The Eizo documentation here is not relevant, as it is merely offering up an example. I would strongly encourage you to learn more about color management and color pipelines before making such claims.

@troy_s
I agree with you 100% in what you say. I'm not telling srgb is the only way. I'm just telling it is the most common way for traditional and home artists to work.

An artist used to Painter or Photoshop will find himself comfortable with srgb input rather than linear input.

Also the usual output device for a home artist is a good PC monitor with a good srgb space coverage. So srgb is the way to go. Then the artist can convert the output to dci for movies or rec709 for hd tvs using a video editing software like After Effects. Or he can convert pictures for printing in adobe rgb space using Photoshop.

Of course if you have an output device supporting rec 2020 and you know your output will be only uhd tvs, then you can base your whole pipeline to that color space. But I hope we can agree that it's not the usual case for a home artist.

That said, I really do care about your opinion since it is clear that you really know what you're talking about. Thank you very much for your reply.

@troy_s I agree with you 100% in what you say. I'm not telling srgb is the only way. I'm just telling it is the most common way for traditional and home artists to work. An artist used to Painter or Photoshop will find himself comfortable with srgb input rather than linear input. Also the usual output device for a home artist is a good PC monitor with a good srgb space coverage. So srgb is the way to go. Then the artist can convert the output to dci for movies or rec709 for hd tvs using a video editing software like After Effects. Or he can convert pictures for printing in adobe rgb space using Photoshop. Of course if you have an output device supporting rec 2020 and you know your output will be only uhd tvs, then you can base your whole pipeline to that color space. But I hope we can agree that it's not the usual case for a home artist. That said, I really do care about your opinion since it is clear that you really know what you're talking about. Thank you very much for your reply.

A few points, and I'd prefer to cover the follow ups via email as this report is already cluttered up enough for developers that need to tackle the complex issue. You can reach me here .

In #41287#277868, @padone wrote:
@troy_s
I agree with you 100% in what you say. I'm not telling srgb is the only way. I'm just telling it is the most common way for traditional and home artists to work.
[...]
But I hope we can agree that it's not the usual case for a home artist.

As per the Blender Foundation, small studios are a key target for Blender via the Blender About page . The color pipeline discussed in the above report covers these needs.

Also the usual output device for a home artist is a good PC monitor with a good srgb space coverage. So srgb is the way to go. Then the artist can convert the output to dci for movies or rec709 for hd tvs using a video editing software like After Effects. Or he can convert pictures for printing in adobe rgb space using Photoshop.

Of course if you have an output device supporting rec 2020 and you know your output will be only uhd tvs, then you can base your whole pipeline to that color space.

You are still misunderstanding how color and pixels work, and in doing so you are conflating display devices with reference working spaces and their details. There's plenty of complexity hidden here that you may not have been exposed to using other software tools.

This isn't merely about displaying colors on a screen or the accuracy thereof. This has to do with how RGB pixel values work in a scene referred rendering and compositing system, and understanding that the underlying reference space is configurable for a variety of contexts. The color transforms, from input, to reference, to output, is what is being discussed here.

There is no fundamentally quick and easy sRGB / 709 solution here as you are implying. I would hope you appreciate the developers you are speaking to are often fully aware of the issues you are trying to communicate and, in many instances, the implications of these seemingly minor decisions are huge within an imaging pipeline.

I sincerely hope you will email me so I can help you to research some of these topics further and perhaps aid in your comprehension of the issues.

A few points, and I'd prefer to cover the follow ups via email as this report is already cluttered up enough for developers that need to tackle the complex issue. You can reach me [here ](mailto:troy.sobotka@gmail.com?subject=Blender%20color%20management). > In #41287#277868, @padone wrote: > @troy_s > I agree with you 100% in what you say. I'm not telling srgb is the only way. I'm just telling it is the most common way for traditional and home artists to work. > [...] > But I hope we can agree that it's not the usual case for a home artist. As per the Blender Foundation, small studios are a key target for Blender via the [Blender About page ](http://www.blender.org/about/). The color pipeline discussed in the above report covers these needs. > Also the usual output device for a home artist is a good PC monitor with a good srgb space coverage. So srgb is the way to go. Then the artist can convert the output to dci for movies or rec709 for hd tvs using a video editing software like After Effects. Or he can convert pictures for printing in adobe rgb space using Photoshop. > > Of course if you have an output device supporting rec 2020 and you know your output will be only uhd tvs, then you can base your whole pipeline to that color space. You are still misunderstanding how color and pixels work, and in doing so you are conflating display devices with reference working spaces and their details. There's plenty of complexity hidden here that you may not have been exposed to using other software tools. This isn't merely ***about displaying colors on a screen*** or the accuracy thereof. This has to do with how RGB pixel values work in a scene referred rendering and compositing system, and understanding that the underlying reference space is configurable for a variety of contexts. The color transforms, from input, to reference, to output, is what is being discussed here. There is no fundamentally quick and easy sRGB / 709 solution here as you are implying. I would hope you appreciate the developers you are speaking to are often fully aware of the issues you are trying to communicate and, in many instances, the implications of these seemingly minor decisions are huge within an imaging pipeline. I sincerely hope you will email me so I can help you to research some of these topics further and perhaps aid in your comprehension of the issues.

@troy_s
That is amazing .. I am always ready to learn more and I'm sure you can point me to good resources .. don't want to waste your time though .. any advice you can give me to improve my workflow is very welcome :)

@troy_s That is amazing .. I am always ready to learn more and I'm sure you can point me to good resources .. don't want to waste your time though .. any advice you can give me to improve my workflow is very welcome :)

Added subscriber: @forsakenlight

Added subscriber: @knekke

Are there any news on this? I find it quite confusing to have different values whether I chose RGB or HSV...

Added subscriber: @Inwader77

Interesting fact: this bug is active in all RGB selectors(in nodes, materials, textures, world settings), but we will have proper working in "color balance"node color selectors only. In all versions.

@Inwader77: Chances are “proper working” means “completely broken” in terms of color management.

In #41287#330063, @troy_s wrote:
@Inwader77: Chances are “proper working” means “completely broken” in terms of color management.

i don't understand, why "completely broken" maybe in this node we have other errors, but with value all properly - value equal maximum of R G and B. for Lift, gamma and Gain color selectors only, in image input color slector - working with bug.

> In #41287#330063, @troy_s wrote: > @Inwader77: Chances are “proper working” means “completely broken” in terms of color management. i don't understand, why "completely broken" maybe in this node we have other errors, but with value all properly - value equal maximum of R G and B. for Lift, gamma and Gain color selectors only, in image input color slector - working with bug.

In #41287#330066, @Inwader77 wrote:

i don't understand, why "completely broken" maybe in this node we have other errors, but with value all properly - value equal maximum of R G and B. for Lift, gamma and Gain color selectors only, in image input color slector - working with bug.

Alexey, in my opinion color picker is "completely broken" in term of proper color management:

There is error in calculation, from the user point of view. The HSV should be calculated to RGB in linear fassion, then user will have proper understanding how
the HSV translating to RGB.

Now in blender when i set 80% VALUE in (H=0, S=0, V=0.8) it is translate to RGB value = (.604, .604 , .604) which is incorrect and is not 80% of total spectrum brightness (from 0-1,).
it shoud be RGB (0.8, 0.8, 0.8)

RGB(0.8, 0,8, 0,8) is translated to H=0, S=0, V=.906 which is incorrect too.

Exact steps for others to reproduce the error
Please correct this simple calculation. It is for sure error. You can look for reference at other software (maxwell render, photoshop (where in 20% of brightness is RGB(51,51,51), etc).

> In #41287#330066, @Inwader77 wrote: > > i don't understand, why "completely broken" maybe in this node we have other errors, but with value all properly - value equal maximum of R G and B. for Lift, gamma and Gain color selectors only, in image input color slector - working with bug. Alexey, in my opinion color picker is "completely broken" in term of proper color management: There is error in calculation, from the user point of view. The HSV should be calculated to RGB in linear fassion, then user will have proper understanding how the HSV translating to RGB. Now in blender when i set 80% VALUE in (H=0, S=0, V=0.8) it is translate to RGB value = (.604, .604 , .604) which is incorrect and is not 80% of total spectrum brightness (from 0-1,). it shoud be RGB (0.8, 0.8, 0.8) RGB(0.8, 0,8, 0,8) is translated to H=0, S=0, V=.906 which is incorrect too. Exact steps for others to reproduce the error Please correct this simple calculation. It is for sure error. You can look for reference at other software (maxwell render, photoshop (where in 20% of brightness is RGB(51,51,51), etc).

The issue is the correct transformation of primaries for the reference space.

There is no reference standard implementation of HSV / HSL, so it is also impossible to compare exact results across different software packages, doubly so when Photoshop is a display referred package.

There is more to colour than the terms “linear” and “sRGB”. It largely revolves around:

Integrity of the colour primaries in the scene referred reference space and the correct display in the display referred output.
Arriving at suitable implementations of an HSV / HSL selector that works within the context of the colour management layer and the needs to flip between various colour spaces and encoding models.

Offering up examples using display referred values is wrong in this context, and also wrong for comparison purposes.

The issue is the correct transformation of primaries for the reference space. There is no reference standard implementation of HSV / HSL, so it is also impossible to compare exact results across different software packages, doubly so when Photoshop is a display referred package. There is more to colour than the terms “linear” and “sRGB”. It largely revolves around: - Integrity of the colour primaries in the scene referred reference space and the correct display in the display referred output. - Arriving at suitable implementations of an HSV / HSL selector that works within the context of the colour management layer *and* the needs to flip between various colour spaces and encoding models. Offering up examples using display referred values is wrong in this context, and also wrong for comparison purposes.

In #41287#330066, @Inwader77 wrote:

In #41287#330063, @troy_s wrote:
@Inwader77: Chances are “proper working” means “completely broken” in terms of color management.

i don't understand, why "completely broken" maybe in this node we have other errors, but with value all properly - value equal maximum of R G and B. for Lift, gamma and Gain color selectors only, in image input color slector - working with bug.

If you would be able to test why I made the claim, you could test the wheels against the Marcie image and colour configs here:
https://github.com/sobotka/psyfiTestingConfig

The wheels pass the test if the sample image behaves appropriately based on the colour selected. If you see odd colours as you adjust the wheel, the picker has colour management issues.

> In #41287#330066, @Inwader77 wrote: >> In #41287#330063, @troy_s wrote: >> @Inwader77: Chances are “proper working” means “completely broken” in terms of color management. > > i don't understand, why "completely broken" maybe in this node we have other errors, but with value all properly - value equal maximum of R G and B. for Lift, gamma and Gain color selectors only, in image input color slector - working with bug. If you would be able to test why I made the claim, you could test the wheels against the Marcie image and colour configs here: https://github.com/sobotka/psyfiTestingConfig The wheels pass the test if the sample image behaves appropriately based on the colour selected. If you see odd colours as you adjust the wheel, the picker has colour management issues.

What needs to be done to get it right?

In #41287#330410, @forsakenlight wrote:

In #41287#330066, @Inwader77 wrote:

i don't understand, why "completely broken" maybe in this node we have other errors, but with value all properly - value equal maximum of R G and B. for Lift, gamma and Gain color selectors only, in image input color slector - working with bug.

Alexey, in my opinion color picker is "completely broken" in term of proper color management:

There is error in calculation, from the user point of view. The HSV should be calculated to RGB in linear fassion, then user will have proper understanding how
the HSV translating to RGB.

Now in blender when i set 80% VALUE in (H=0, S=0, V=0.8) it is translate to RGB value = (.604, .604 , .604) which is incorrect and is not 80% of total spectrum brightness (from 0-1,).
it shoud be RGB (0.8, 0.8, 0.8)

RGB(0.8, 0,8, 0,8) is translated to H=0, S=0, V=.906 which is incorrect too.

Exact steps for others to reproduce the error
Please correct this simple calculation. It is for sure error. You can look for reference at other software (maxwell render, photoshop (where in 20% of brightness is RGB(51,51,51), etc).

> In #41287#330410, @forsakenlight wrote: > > >> In #41287#330066, @Inwader77 wrote: >> >> i don't understand, why "completely broken" maybe in this node we have other errors, but with value all properly - value equal maximum of R G and B. for Lift, gamma and Gain color selectors only, in image input color slector - working with bug. > > > > Alexey, in my opinion color picker is "completely broken" in term of proper color management: > > > There is error in calculation, from the user point of view. The HSV should be calculated to RGB in linear fassion, then user will have proper understanding how > the HSV translating to RGB. > > Now in blender when i set 80% VALUE in (H=0, S=0, V=0.8) it is translate to RGB value = (.604, .604 , .604) which is incorrect and is not 80% of total spectrum brightness (from 0-1,). > it shoud be RGB (0.8, 0.8, 0.8) > > RGB(0.8, 0,8, 0,8) is translated to H=0, S=0, V=.906 which is incorrect too. > > Exact steps for others to reproduce the error > Please correct this simple calculation. It is for sure error. You can look for reference at other software (maxwell render, photoshop (where in 20% of brightness is RGB(51,51,51), etc). ![1.png](https://archive.blender.org/developer/F228350/1.png) ![2.png](https://archive.blender.org/developer/F228352/2.png)

@Inwader77, the issue noted here is unrelated to this report.

This report has so many replies on different topics that I'd rather see the original report resolved and other topics can be handled separately.

@Inwader77, the issue noted here is unrelated to this report. This report has so many replies on different topics that I'd rather see the original report resolved and other topics can be handled separately.

HSV currently bypasses color pipeline conversion.

While its nice to make the color picker consistent in this respect, its not some mistake or error in code. Setting as TODO.

http://wiki.blender.org/index.php/Dev:2.5/Source/Development/Todo/UserInterface#UI_Widgets

HSV currently bypasses color pipeline conversion. While its nice to make the color picker consistent in this respect, its not some mistake or error in code. Setting as TODO. http://wiki.blender.org/index.php/Dev:2.5/Source/Development/Todo/UserInterface#UI_Widgets

Added subscribers: @KonstantinsVisnevskis, @lichtwerk

Added subscriber: @brecht

Changed status from 'Open' to: 'Archived'

Arching this old report in favor of #69562 (Manipulating saturation of colors (e.g via HSV or RGB curves, but also within color picker) shifts HUE), which has a more clear description and scope.

Added subscriber: @Eary

I am searching for the reason why the V in HSV is limited to 4.875, and I am being led to here. I have glimpsed through the entire page but I cannot really see where the number 4.875 is mentioned. Could someone explain to me why Blender currently limits the V in HSV to 4.875? And why would it have anything to do with the color picker?

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Color Picker applies color management incorrectly in 2.71 #41287