Page MenuHome

Cycles ignores Texture Tab Color Space setting
Closed, DuplicatePublic

Description

System Information
Operating system: Windows 7 SP1, 64-bit, i7-4670K
Graphics card: NVIDIA GeForce GTX 1070

Blender Version
blender-2.80 branch

Short description of error
Cycles ignores Texture Tab Color Space setting (IDT) and burns the Display ODT into the image (tested on EXR format output)

Expected Behavior
Cycles should import the pre-transformed Texture from its [[ URL = https://developer.blender.org/T63571 | Color Space IDT ]] to Scene Working Space (scene referred space declared in OCIO configuration) and apply the Display ODT only in the Render Framebuffer (Display ODT option is also lacking in the Render Framebuffer).
Currently if you feed pre-transformed maps (at least for EXR format textures) it works as expected. Below a descriptive graph of the current chaotic behavior between 3D viewer and Cycles.

Details

Type
Bug

Event Timeline

Note this bug tracker is strictly for bugs, suggestions to improve the implementation are not tracked here.

Note that non-color data image files do have a color space and should not get any color transform applied at all. That's the point of them, they're things like normal or displacement maps. So it's not clear to me why a non-color EXR should be fixed with an IDT in your graph.

Jose (Dogway) added a comment.EditedApr 13 2019, 9:15 PM

Color Space setting that is broken. (See also T63571). So a solution is to fix it or remove it (hopefully the former). Currently the only practical implementation for OCIO is as a tonemapper which is a sad end for such a robust color framework.

non-color is a Blender-only term. The proper IDT for what you call non-color data is "Utility - RAW" in a proper OCIO workflow. This is what this ticket is about. Get rid of ambiguous color settings and rely on a proper OCIO implementation. Not saying that I'm a coder able to make it happen, but before closing both tickets it could be better if some discussion could be going on.

*In my graph there's not RAW images ("Utility - RAW" is a proxy for no-op), but a sRGB image that Cycles ignores to pre-transform from the IDT, the red note is what I think should be fixed, probably in T54659 as I found on your other comment.

Non-color is a term from the original SPI configurations. In those configurations the Raw color space has a different meaning, and it does in Blender too. This is not Blender-only, but comes from the creators of OpenColorIO.
http://opencolorio.org/configurations/spi_vfx.html

So if you report a bug you really should use the exact Blender terminology and provide .blend files, because otherwise it's going to be really confusing. I can't guess which other application's terminology you might be using.

Sorry for the confusion I was using aces 1.0.3 variant terminology from last year compared to spi-vfx which is like 7 years old.
Aren't there plans to update to a more modern aces variant OCIO framework?

If this ticket complies to T54659 it can be kept closed, tomorrow I will provide blend files and instructions.