BIG color problem, color is NEVER reliable, is there a possible solution?

[JuanGea]

Ok, I’ve done some tests, and I had a very interesting talk with @troy_s looking for a solution to a problem we`ve been having since ages, it’s clear to me that Filmic is the way to go, great for that.

Now, we’ve detected some inconsistencies that people that work with me has been telling me constantly, and it has been a big problem because the time required to configure a shader properly increased A LOT because of this problem.

Basically, there is no way to trust in colro when you work with shaders, and there is no way to get a consistent result when you work with shaders, the render part is clear, but the shaders part, or it is actually broken, or it’s something that makes you work in the big blindness, because you cannot define the color you need.

Check this picture, the greys are, theoretically, all the same, but they are not, and the wood texture is completely different, so when we define an albedo color in a image editing software, like Photoshop, because a client ask us to use their branding color, it’s useless because the color will be totally destroyed when you load the texture in Blender.

Also when you decide a color for the Base Color channel, no matter if you use an RGB node, or you use the color slot in the Principled Shader, what you choos is not what it’s rendered at all, like the color picker is not corrected as the render, so you are blind, and it’s impossible to correctly configure the shaders.

Here is the picture, I hope it’s clear enough, it’s 2560 x 2560, so if you see it small, open it in a new tab in the browser, but I think the problem is quite clear there:

And here I’m totally lost on who to mention, I will mention @brecht because this is render related, and also @dfelinto in case he knows who can check this.

In any case, this is totally inconsistent, and makes or job very hard with the shaders, I hope it’s seen as a problem, not sure if it’s a bug or not, but it actually it’s a big problem.

[brecht]

Blender (like most 3D apps) works in linear color space, while Photoshop usually works in something like sRGB or AdobeRGB. So, indeed the value 0.18 does not mean the same in both. You could configure Photoshop to work in linear color space. I don’t think it would make much sense for Blender to do shading in anything else than a linear color space. If you need to match a color from an image, you can use the color picker on the image in Blender rather than copying the numerical value from Photoshop.

If you are doing something like motion graphics or logos where branding colors matters, I don’t think Filmic is a good choice. What Filmic does is similar to printing out the image and then taking a photograph. The result is going to depend on both the lights and the camera used. If the render could somehow account for the light setup (which is generally impractical) and you did try to match the colors exactly, it would look out of place with the rest of the objects in the scene. And it also means doing non-physical things. For example to get a color value like 1.0 out of Filmic requires an otherwise purely reflective object to emit light, and very bright light at that.

[troy_s]

I think this is a bug @brecht. I walked over the issues and it seems like some sort of strange double up in the 8 bit path. EXR output works, but 0.18 linear is correct in working space, and comes out 0.63; completely weird.

[JuanGea]

Thanks for this.

i’ve been digging into this with @troy_s and it seems that there is some kind of problem, when I save the diffuse color pass to an RGB 16bit EXR I get back in the viewer the correct values (under standard view transform) but when it’s saved to PNG 8 bit, the result is not correct, like the in the render viewer,

I’m not sure if I can explain this correctly, it’s a bit complex, let me show you the pictures, this is the upper image saved as EXR 16bit RGB, the diffuse color pass is correct, the wood is like the texture:

This is the sme but saved as PNG 8bit:

[JuanGea]

This is the 0.63 value that @troy_s saw, from the 0.18 grey from the right plane:

[brecht]

Are you using Save as Render (which applies the Filmic view transform) when saving the diffuse pass as PNG? It’s currently always enabled for PNGs, since that’s the correct value for the Combined pass.

For other passes like Diffuse Color it could be disabled automatically, if renderers specify which passes contain an albedo. For something like Diffuse Direct though there is no good value, saving to 8bit means you’re either clipping HDR colors or applying the view transform too early. This is the reason OpenEXR exists, to save intermediate image files like this without data loss.

[troy_s]

I think he’s gone to bed. I spent about two hours chasing this. Things I know:

1. The 0.63 value is utterly incomprehensible
2. The working space value is correct as 0.18
3. 8 bit output, including viewport appears hooped
4. Had him test using float input, with no change
5. Had him test 32 bit float output, and lo and behold, seems correct

Tested with light unit strengths of 1.0. Using display linear output-ish via “Standard”.

I originally speculated that it was a double up of transfer function, but the value output should be 0.71 or so, not the strange value.

Definitely feels like something going sideways in the 8 bit code path.

[JuanGea]

Hi @brecht.

I get the linear color thing, and understand the “save as render” and " view as render", it´s something we can live with , however could be great to have a node to counteract the transform being done in te texture inside the shader to be able to work in the actual Albedo in the 2D software, however I understand that may not be possible.

But what I find rather important is to correct the color picker, right now when we pick a color it´s a completely different color than what we see in the render, I´m not talking just about matching it with a texture, but when we manually configure the color of a shader, it´s impossible to be precise with a color and in the end it ends up being a guessing game, which makes it rather hard to configure a shader.

So color correct the color wheel and the color picker (or at least having an option to see the corrected values) could be very helpful to avoid that inconsistency in the workflow.

Also, finally, what @troy_s said

[brecht]

I can’t reproduce the bug to get that 0.63 value. If you think there is a bug, report to the tracker with .blend files and exact steps to reproduce.

In the future we can add an option to the color picker to show colors with either Standard or the scene view transform. But what shows up in the render is still going to depend on the lighting, this can only be “precise” in very specific cases.

[JuanGea]

When I refer to colors trasnformed I refer onoy to colors visible in the Diffuse Color pass, the Albedo, of course the representation with lighting and other things will vary

And that will be very helpful I’m sure.

Thanks @brecht

[MikeFutcher]

I would personally like to be able to have Blender set to Filmic colour space, and to be able to import an image into the compositor, and have it come out exactly as it was.

[Sai-Kiran]

In render properties, just change the option to “Standard” in color management