2.8 Color management #60582

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

Added subscriber: @istoltoto

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.

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.

Added subscriber: @brecht

Changed status from 'Open' to: 'Archived'

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.

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.....

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

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.

Added subscriber: @intracube

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.

Added subscriber: @GuillermoEspertino

This comment was removed by @GuillermoEspertino

Added subscriber: @JoaquinKierbel

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.

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.

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

2.8 Color management #60582