2.8 Color management #60582

New Issue

pistol ioan · 2019-01-16T23:57:57+01:00

pistol ioan commented

2019-01-16 23:57:57 +01:00

Using different settings for Color Management will result in different input colors that you see with your eyes in the RGB input node even if is the same color code, for example, FF0000
This can be confusing but also can drive to mistakes, because you may think that is something but is something else instead.

Please consult the image and video demonstration.
In the below image, both examples use the same color code: FF0000,

https://youtu.be/LuwhNC2N-cE

colors.blend

Using different settings for Color Management will result in different input colors that you see with your eyes in the RGB input node even if is the same color code, for example, FF0000 This can be confusing but also can drive to mistakes, because you may think that is something but is something else instead. Please consult the image and video demonstration. In the below image, both examples use the same color code: FF0000, ![6789led.png](https://archive.blender.org/developer/F6310280/6789led.png) https://youtu.be/LuwhNC2N-cE [colors.blend](https://archive.blender.org/developer/F6310337/colors.blend)

pistol ioan commented

2019-01-16 23:57:57 +01:00

Added subscriber: @istoltoto

pistol ioan commented

2019-01-17 00:19:01 +01:00

Also, I guess because of this the color spectrum is also different which can result in bigger problems when you want to use harmony colors.

Also, I guess because of this the color spectrum is also different which can result in bigger problems when you want to use harmony colors. ![6578led.png](https://archive.blender.org/developer/F6310554/6578led.png)

pistol ioan commented

2019-01-17 00:22:37 +01:00

I think is normal that the inputs from nodes to be the same no matter what Color managements you may use.
Or at least to have an option to choose.

I think is normal that the inputs from nodes to be the same no matter what Color managements you may use. Or at least to have an option to choose.

Brecht Van Lommel commented

2019-01-17 01:13:21 +01:00

Added subscriber: @brecht

Brecht Van Lommel commented

2019-01-17 01:13:21 +01:00

Changed status from 'Open' to: 'Archived'

Brecht Van Lommel closed this issue

2019-01-17 01:13:21 +01:00

Brecht Van Lommel self-assigned this 2019-01-17 01:13:21 +01:00

Brecht Van Lommel commented

2019-01-17 01:13:21 +01:00

This is by design. If you want to be able to see colors with values > 1.0 as you can with Filmic, colors with smaller values need to become darker.

Maybe more control over this would be useful, but it's outside the scope of a bug report.

This is by design. If you want to be able to see colors with values > 1.0 as you can with Filmic, colors with smaller values need to become darker. Maybe more control over this would be useful, but it's outside the scope of a bug report.

pistol ioan commented

2019-01-17 02:04:38 +01:00

Regard to this, also if you make a print-screen the RGB color in Blender and put in Photoshop or Gimp and make Eyedropper to the color, will be a different color from Blender.

All the colors are wrong, the codes, the colors spectrum, inputs, outputs, render. it's crazy.....

Regard to this, also if you make a print-screen the RGB color in Blender and put in Photoshop or Gimp and make Eyedropper to the color, will be a different color from Blender. All the colors are wrong, the codes, the colors spectrum, inputs, outputs, render. it's crazy..... ![5678d.png](https://archive.blender.org/developer/F6311344/5678d.png)

pistol ioan commented

2019-01-17 02:05:12 +01:00

I suppose this is another bug, or a bad design haha

Brecht Van Lommel commented

2019-01-17 02:12:41 +01:00

It's the trade-off you make for physically based rendering, things are more complicated and you can't just use print-screen and expect things to match.

Paul R commented

2019-01-18 06:49:32 +01:00

Added subscriber: @intracube

Paul R commented

2019-02-13 15:42:04 +01:00

In #60582#601282, @istoltoto wrote:
I suppose this is another bug, or a bad design haha

This is a design conundrum; should the various UI colour swatches factor in the colour management view transforms and exposure setting, or instead use a normalised range? Currently they do the latter.

But, the eyedropper and viewport do take into account exposure/view transforms, so there's a discontinuity there.

On a separate issue; there isn't a colour management configuration that avoids the colours slowly drifting if you keep eye-drop an object's own geometry in the 3d viewport - so I don't know what colour space the swatches and viewport are operating in - (it doesn't look to be sRGB primaries / EOTF.)

Tested with both Cycles in 2.79 and Eevee in 2.80.

This last part potentially looks like a bug.

> In #60582#601282, @istoltoto wrote: > I suppose this is another bug, or a bad design haha This is a design conundrum; should the various UI colour swatches factor in the colour management view transforms and exposure setting, or instead use a normalised range? Currently they do the latter. But, the eyedropper and viewport *do* take into account exposure/view transforms, so there's a discontinuity there. ---- On a separate issue; there isn't a colour management configuration that avoids the colours slowly drifting if you keep eye-drop an object's own geometry in the 3d viewport - so I don't know what colour space the swatches and viewport are operating in - (it doesn't look to be sRGB primaries / EOTF.) Tested with both Cycles in 2.79 and Eevee in 2.80. This last part potentially looks like a bug.

GuillermoEspertino commented

2019-02-13 19:22:16 +01:00

Added subscriber: @GuillermoEspertino

GuillermoEspertino commented

2019-02-13 19:22:16 +01:00

This comment was removed by @GuillermoEspertino

*This comment was removed by @GuillermoEspertino*

Joaquín Kierbel commented

2019-02-13 20:16:42 +01:00

Added subscriber: @JoaquinKierbel

Joaquín Kierbel commented

2019-02-13 20:16:43 +01:00

Actually, those color boxes only look different in regards to what it's selected in the "Display device" setting, not the view-transform, which causes no changes on the appearance of the color box.
So in the only sense that those boxes are "managed" is that they are tied to the "sRGB" field in the Display Device setting, but nothing else.
So yes, if you change that setting to any other option available (like None in the captures from this report) they look something else instead of sRGB-like, but that is it. View-transform isn't in the chain there, regrettably. All color related fields in Blender's UI should at least have a checkbox to go through the pipe of all transforms in the color-management panel.

I remember discovering that when evaluating the fact that the RGB values for those colors are linear, but the HSV values are sRGB. But if you change the Display device to "None" in 2.79, they are both linear. Unfortunately, this got further broken in 2.8, where HSV is now truly hard-coded to sRGB, and this -however convoluted- workaround to set linear values in HSV mode doesn't work anymore.

The eye-droppers are a different discussion, right now they are pretty much useless for anything beyond what you would get from picking colors from a screen-capture of itself.

Actually, those color boxes only look different in regards to what it's selected in the "Display device" setting, not the view-transform, which causes no changes on the appearance of the color box. So in the only sense that those boxes are "managed" is that they are tied to the "sRGB" field in the Display Device setting, but nothing else. So yes, if you change that setting to any other option available (like None in the captures from this report) they look something else instead of sRGB-like, but that is it. View-transform isn't in the chain there, **regrettably**. All color related fields in Blender's UI should at least have a checkbox to go through the pipe of all transforms in the color-management panel. I remember discovering that when evaluating the fact that the RGB values for those colors are linear, but the HSV values are sRGB. But if you change the Display device to "None" in 2.79, they are both linear. **Unfortunately, this got further broken in 2.8**, where HSV is now truly hard-coded to sRGB, and this -however convoluted- workaround to set linear values in HSV mode doesn't work anymore. The eye-droppers are a different discussion, right now they are pretty much useless for anything beyond what you would get from picking colors from a screen-capture of itself.

Paul R commented

2019-02-14 12:14:41 +01:00

In #60582#620115, @JoaquinKierbel wrote:
Actually, those color boxes only look different in regards to what it's selected in the "Display device" setting

Yep, although I hesitated to say the UI colours are tied to the display device setting since they look slightly skewed;

an emission shader of (1.0, 0.0, 0.0) with the default sRGB display device and sRGB EOTF doesn't give an 8 bit (255, 0, 0) value to the screen - its (248, 1, 1) - which seems more than just a rounding error.

EDIT: Ignore the above. It looks like my troubles are from a non-standard OCIO config file.

> In #60582#620115, @JoaquinKierbel wrote: > Actually, those color boxes only look different in regards to what it's selected in the "Display device" setting Yep, although I hesitated to say the UI colours are tied to the display device setting since they look slightly skewed; an emission shader of (1.0, 0.0, 0.0) with the default sRGB display device and sRGB EOTF doesn't give an 8 bit (255, 0, 0) value to the screen - its (248, 1, 1) - which seems more than just a rounding error. --- **EDIT:** Ignore the above. It looks like my troubles are from a non-standard OCIO config file.

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

2.8 Color management #60582