Maniphest T63572

Cycles ignores Texture Tab Color Space setting
Closed, Duplicate
Actions

Assigned To
None
Authored By
Jose (Dogway)
Apr 13 2019, 2:32 PM
Tags
  • BF Blender
Subscribers
Brecht Van Lommel (brecht)
Jose (Dogway)

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.

Related Objects

Event Timeline

Jose (Dogway) created this task.Apr 13 2019, 2:32 PM
Brecht Van Lommel (brecht) closed this task as a duplicate of T63571: "Disable hard coded Color Space texture setting" checkbox.Apr 13 2019, 8:35 PM
Brecht Van Lommel (brecht) added a subscriber: Brecht Van Lommel (brecht).

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

Brecht Van Lommel (brecht) added a comment.EditedApr 13 2019, 8:52 PM

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) mentioned this in T63571: "Disable hard coded Color Space texture setting" checkbox.Apr 13 2019, 8:57 PM
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.

Brecht Van Lommel (brecht) added a comment.EditedApr 13 2019, 9:58 PM

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.

Jose (Dogway) added a comment.Apr 13 2019, 10:12 PM

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.