Hey all, I’m not super familiar with color management, and less so with how blender does color management. Did a couple searches here, and there’s a lot of discussion on color management for renders, but not for materials.
I’ve been building a lot of procedural materials recently for arch-vis, and I’ve noticed some weird stuff with how blender deals with colors, and I end up having to balance a lot of gamma corrective nodes.
Materials are all emission nodes with power set to 1. annotations added in photoshop.
It seems to me that blender default sets the procedural textures to a linear workflow, which needs to be corrected to blend materials correctly. Inversely, though, images seem to default to sRGB, which means that anytime I want to blend images together via a procedural material, I need to use a gamma correction.
It’s all super confusing and frustrating haha. I’m probably missing something really stupid.
Hey man, that’s kinda helpful haha, but doesn’t really solve the problem. So the non-color data just sets images to be linear, like the top two default textures in the image above. The top two textures on the right should be reversed to match up I guess.
The problem is still dealing with textures and procedural materials interacting. Example case, I’m mixing two images together via a noise texture. A default, linear noise is going to favor one texture. Every time I do that, I need to correct the gamma so it mixes them evenly.
Kinda frustrating, especially if you’ve got a really complicated material.
can you post a pic of your mix setup. I know some blend modes in blender like overlay are not accurate in blender because it does the operation in linear and the operation was made for gamma adjusted, so you would have to use a gamma correct node to undo the gamma then add the overlay node , then add back the gamma.
basically any add, subtract, divide , multiply operation will work as expected. Screen , overlay, etc will not give the results as expected.
This is a simple mix color, using noise as the factor… mixing between two checkerboard patterns. As you can see the top is default, and it favors the bright checkerboard. To get it to be more correct, you have to add a gamma correction, as in the bottom material.
Say I need a texture inverted, for a bump map, etc. I put gamma on a gradient, then mix it with a clouds (in this case overlay). Before inverting it, it looks correct:
When I invert it however, it performs a linear(?) invert on my sRGB mix, resulting in an imbalanced invert. The solution now is that I have to remove the gamma before the mix operation, and set the gamma correction after the invert.
This is a massive problem, especially when you have a complicated material. I’ve hacked by in situations like this, but to do this correctly you would potentially have to duplicate your entire material operation just so the invert operation works correctly.
mixing the gradient with the texture one way requires a 2.2 gamma before mixing. Inverting that, however, leaves it washed out on one side. in this example I put in a .45 gamma (which is the inverse of the 2.2 gamma I thinkkkk?) PRE MIX in order to get the gradient to blend across the plane. In this case though the bottom material doesn’t solve the issue because the contrast is all messed up.
just realized that in this case, probably the better solution for the invert is probably the post invert gamma correction??? still doesn’t look quite right. wtf I’m lost.
I’m so confused about all of this right now haha. I don’t know how blender decides to use a linear or a sRGB color space in material operations, and I’m very confused about how blender uses sRGB images with linear procedural textures. Right now when I’m making materials it’s a guess for me what any operation is actually going to give me.
Good gosh there are plenty of things to cut through here.
Let’s start with:
What sort of material you are making?
What are your expectations, or, do you expect that a material that “looks correct” in one wretched situation (Hello Photoshop) will “look correct” in Blender?
There is a huge map here to discover, but it will need to start with where you are.
Your issue is that you are looking at the result through the view transform (which by default does linearized sRGB > sRGB), but judging it as though you were not. To go back to your checkerboard example, the lower one LOOKS correct because your de-gamma hack and the view transform are cancelling each other out. Remove the view transform in color management settings, and the result is as you originally expected: the top checkerboard is correct, the bottom one favors dark colors.
Your later examples get crazy because you are now inserting unneeded de-gammas prior to doing operations like overlay and invert, which is going to cause all sorts of mess. This is why the shading pipeline uses linear gamma for everything, precisely so you don’t have to deal with this. Textures are assumed to be non-linear, so they are converted to linear sRGB (it’s hardcoded sRGB primaries atm…sorry about that).
The whole point of “linear workflow” is to do everything with linear gamma and transform back to the display gamma at the very end of the pipeline, once all the other math is done.
which… I don’t even know what’s going on there. In order to get what I would expect the invert to do, I now have to hack it manually with brightness/contrast, trying to fix it.
Invert is clearly not visually inverting it. I’ve lost a lot of time adding things like this to a very complicated material, and then realizing after a render than it’s definitely not doing what I’m expecting it too.
edit:
@J_the_Ninja ok, that starts to make some sense, although I’m not sure it would solve the bump map issue. What render transform should I be using for that? And what would the workflow for that be? would I have to do a separate operation to saved pngs?
Again, disable color management and try all of your examples again. This latest grunge example ALSO behaves exactly how you’d expect it to once you get rid of the view transform. You can just pass the invert node in your example directly to the bump node. It IS an exact invert of your color map. It just no longer appears to be after being passed through the view transform back to display gamma. You can also use the “invert” checkbox on the bump node, although that only helps for the specific case of bump maps.
But in any case, you don’t actually have a problem here. All of the things you think are happening here are not really happening. They appear to happen because you are looking through a non-linear view, then acting like you are looking through a linear view.
To give a really simple numbers example:
Start with a channel at 0.3. You’re trying to invert it, you expect 1-0.3=0.7
Except due to your gamma corrected view, what you’re REALLY doing is comparing 0.3 ^ 0.454 to 0.7^0.454. These are 0.58 and 0.85, which are of course not inverse values of each other.
Except no shader input is being run through this same transform, so you keep trying to compensate for a transform that is not happening to any shader inputs, just your final result when you go to look at it.
What you see in the viewport is NOT the values that get passed to the shader, unless you have turned your color management view to linear/off
I believe you, I super do. but I also don’t understand at all haha. I’m so sorry.
so I’ve turned off all color management, in the color management panel. Inverting my albedo still gives me a result I’m not expecting, and influences my bump map in a way that needs correction.
I think I understand that plugging values into emission nodes and comparing them visually is wrong, but the bump seems to still be influenced by those values… they’re real to a certain extent.
Is there a color management setting that I’m missing? Or am I just super missing the point?
@dracoroot7 I’ll check out your file in a little bit. gotta get dinner.
Is there a color management setting that I’m missing? Or am I just super missing the point?
Yeah, you turned off the view transform by setting the display device to “none”, but then you sort of re-implemented it with the exposure and gamma sliders. You need to put those back to their defaults (exposure=0, gamma=1), THEN what you see in the viewport will be the actual values in the shader. Yes, this makes the view dark. That’s how it’s supposed to look when you are looking at the actual scene-referred values directly.
Ok, I think I understand. Setting the color management to none changes the way we perceive the albedo, and lets it match the bump closer. So how do I implement this in a practical way?
obviously changing the color management has destroyed the scene. In addition, (and this hurts especially for arch-viz), I don’t have access to the extra range of light information filmic gives.
I understand the answer now, but a solution that is “correct” seems exponentially more difficult to work with / not returning something that’s visually better. Are there any resources on workflow in such an environment?
EDIT: here’s that same frame in sRGB filmic, using a scene gamma of .45 … how bad of an idea is that?
You’re not supposed to disable the view transform in final rendering, just to see what your shader is.
I’m not trying to give you a solution to your problem, I’m trying to explain to you why you don’t have one in the first place, or at least not the one you think. What exactly is wrong with your bump maps? Not the values you think you are putting into the bump map, the actual result of the bump map shader in the final render.
Ok, I think I understand. Setting the color management to none changes the way we perceive the albedo, and lets it match the bump closer. So how do I implement this in a practical way?
Only how you perceive it when viewing the values with node wrangler. The values being passed to the shader are the same either way.