Color Management Improvements #68926
Labels
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset System
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Viewport & EEVEE
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Asset Browser Project
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Module
Viewport & EEVEE
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Severity
High
Severity
Low
Severity
Normal
Severity
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
68 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#68926
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Original source: https://wiki.blender.org/wiki/Source/Render/ColorManagement
Blender integrates OpenColorIO, but still misses some functionality to make it fully possible to use for example the ACES configuration.
Shader Nodes
Cycles and Eevee shader nodes need to support arbitrary working color space:
Color Picker
Compositing & Output
6beaa29791)5baa3ec)OpenColorIO Config
Display
<USE_DISPLAY_NAME>UI
*File I/O
Added subscriber: @dfelinto
#96421 was marked as duplicate of this issue
Added subscriber: @MaciejJutrzenka
Added subscribers: @frameshift, @Mets
I think @frameshift will appreciate this.
Added subscribers: @Jeroen-Bakker, @troy_s, @brecht
Great to see that the wiki document made it into a task. I would like to suggest this task to be made a parent task of all other open tasks regarding the subject. It's great that this task is finally here - it would be even better if we make it an overview of everything else - stuff like #46860, #34684, #68242, #67832, etc. Then at least we have a bird's eye view on the scope of what needs to be done.
If I can share some input, I've been doing some research over the past few months, about the state of things in Blender and how other software generally tackles the subject. The following is a result of that + feedback from @troy_s and @brecht.
Input / Output
I would suggest a different approach. Other software generally uses a set of input rules for the user to determine, but with default settings originating in the roles determined in the OCIO config. I've been taking a look with @Jeroen-Bakker at how Blender reads those roles, and there's still a bit of hardcoding there.
Maybe this is the right spot to finally get rid of the confusing View as Render flag, and expand the Save as Render checkbox to the more granular UI that users actually need.
This includes leaving the Display out of the file encoding. See #58805.
I've been thinking about an improved UI to expose all this to the artist. Generally, it's essential for the Color Management properties panel to be subdivided into Output and View panels. The following is heavily inspired by Maya and Nuke, and again, with defaults set by the Roles in the OCIO config.
Display
The ACES view transform was designed for the ACES ecosystem, and it shouldn't be used in a differently managed workflow. It's like throwing Filmic on an Adobe RGB image.
To be honest, ACES itself is outside the scope of Blender's responsibility. What the software is responsible for, is allowing any OCIO config, including ACES, to be used as intended.
Color management on UI controls
Troy posted an article on the old wiki about a problem with curves. The general issue is that every context requires a different transform on the UI to make sure the linear data we are manipulating is mapped correctly. For example sRGB for albedos (display linear energy), Filmic for renders (if that’s the transform we view them through), Z-depth (linear from some range to another) etc. It needs to be selectable by the user.
ASC-CDL, for example, can work on linear and log, but the UI responds totally differently depending on the encoding. Slope on scene linear data is exposure. Slope on log encoded data is a power function. Offset on log is a multiply, hence exposure.
I suppose this is the right spot to mention that in a colour picker when using the ACES config, the RGB sliders are the only reliable way to pick your colour. Both HSV and the colour wheel make the coordinates go bananas.
Compositor
What I'm aware of:
Yes. This.
Rarely present if ever. Would need to remain configurable per buffer.
Immensely useful immediately.
Bad idea. ACES is ACES and should remain an external configuration. Doing so would be a mountain of work and confuse everyone into thinking “they are doing ACES” as we have seen in the past.
See above. Woefully bad idea.
Beneficial to all Apple hardware as well as the climb towards HDR10 / Dolby Vision. Minimum should be 12 bit, downgraded as required. Dolby Vision is a 12 bit representation.
+?
Other than that, most of Sam’s comment is pretty spot on.
I would add that for the “exports” it is critical, and an “Advanced” makes sense here so, for example, you could render out entire shots subject to a particular look, and change the look for another shot. That is, think a stackable series of transforms ala the Texture stack. Simple to implement, and powerful. With a sane default as per Sam’s offering.
Regarding UI, that’s a huge one. Given software cannot know what a pixel pusher is trying to achieve, it is a fundamentally impossible task to properly display the arbitrary data. Is it an alpha? An albedo? A scene referred emission? A normal? A depth? Each of those would require potentially different transforms applied for interacting with the data, as well as unique display approaches via views etc.
Sam’s comment about fundamental ground truth assumptions for data is also prudent. That is, by default, the sane output of a path tracing engine such as Cycles should be assumed for all nodes. Display referred manipulations are fine, but they must not be the default. Same as with alpha encoding state.
Grease Pencil needs therapy. Also it would help if garbage unmanaged code from other sloppy crap software ceased being blindly grafted onto Blender. See D3638.
Added subscriber: @lichtwerk
Added subscriber: @item412
Found a few more related tasks that might be worth listing here.
Some of them are quite old, but the fact that they are still marked as open, at least warrants a check for whether they should be. Especially the ones containing lengthy discussions that I'm not sure how valid they are today.
Added subscriber: @Dogway
I subscribe most things noted here but I write some observations below.
In the Transform Preferences, Rendering Space should be labeled as Working Space as involving also the Compositor and Sequencer.
The Image Editor needs a Viewing Transform option clearly visible since going back and forth to the Color Management panel is counterproductive.
LiftGammaGain should stay since many videos are composited, edited and graded in Rec.709, and many workflows involve this space but Lift should be fixed, it behaves as Lift+Power.
Also LOG based controls should be included like a Contrast with a Pivot option (add Pivot to the contrast node?)
Shadow/Midtone/Highlight control wheels should be included for LOG based secondaries.
A LUT node to apply different luts not only for artistic but also technical transforms, tonemappers, etc.
(link )
Added subscriber: @McSwiff
Correct.
Also correct. Just like the Save as Render flag, View as Render should make way for a more granular UI (Color Space is already there, but View Transform is not).
Note that the settings inside the Color Management panel don't even influence the view inside the Image Editor, as they only pertain to rendering and output.
View as Render is not only useless and badly named, it's also incorrect to use it. An image used as input should not have a transform used for viewing output slapped onto it. The checkbox should be replaced by a View Transform enum, also stored per image datablock.
Just because your input material is Rec. 709, doesn't mean that it is display referred. On the contrary - the Blender compositor operates linearly, which is where Lift/Gamma/Gain breaks. The algorithm works on shadows, midtones and highlights, which are impossible to separate when using scene referred data.
Again, compositing is a linear affair. The log controls you mention (including a shadows/midtones/highlights separation) are geared towards a grading workflow. Which should not happen on linear data, unless the tools use a log shaper if both input and output are stored linearly, like in an ACES workflow. But I digress.
It's beyond the scope of this task, but @troy_s did suggest a dedicated Grading Editor with correct controls for a log-based workflow. This editor would for example allow the colourist to work on NodeTrees linked to VSE strips, which is similar to e.g. DaVinci Resolve.
That Pivot option, however, is something that could very well be added to colour manipulation nodes already present in Blender, like Brightness/Contrast, but also Slope/Offset/Power.
LUT nodes, enums for every node, .. all ways to prep data more adequately for the nodes they're about to go through.
Added subscriber: @MD.FahadHassan
Just want to mention #69562 here as well
In case someone interested in Natron/Nuke merge node math.
These are the implementation papers. I was able to create some mix nodes preserving luminance for production following these math. Hope it helps.
edit: [Not Valid]
Most of those are display referred and don’t work @cgvirus. Those are the same broken formulas in the Mix node. Luminance based formulas are an entirely other matter.
Natron has a completely broken colour pipeline and is not exemplary in this regard.
Hi, @troy_s thanks for the reply. Which app/s could be taken as a reference point for scene referred pipeline? I am interested to experiment it in deep. Thanks.
@MD.FahadHassan The Nuke Merge nodes by default assume scene referred and will only change to the display referred versions with the horribly titled “Video Colorspace” check box toggled to on. OpenImageIO has the same swapped out formulas that Nuke uses. You will notice that things like Screen etc. will work with scene referred emissions, but is completely different from the
A+B - (A*B)for example.@troy_s Thanks for the hints! Yes, I noticed a huge f-stop difference with some shots lately.
I think I am getting this scene referred conundrum now. Should we explore ACES as well? If you could kindly provide us some papers to read that would be great! Thanks.
ACES is really tangential; it’s just a simple series of transfer functions and a reference working space that is more or less BT.2020 for use with CGI / rendering / compositing.
If one focuses on the three classes of buffers being display referred emissions, scene referred emissions, and non-color data, the rest is vastly easier to understand.
Thanks for all the hints! Going to dig it deep. I will eventually disturb you annoyingly in forums :) @troy_s
Also linking D2547 here. In my opinion not absolutely essential, but the discussion is lengthy and should not be disregarded.
Added subscriber: @RainerTrummer
Added subscriber: @DaveStromberger
Added subscriber: @Stefan_Werner
Added subscriber: @PeterBaintner
#71357 was made yesterday by @Jeroen-Bakker and would resolve a huge amount of the current problems.
#71389 is a small thing, but relevant to the issue.
Added subscriber: @Memento
Added subscriber: @BintangPratama
Added subscriber: @AndreaMonzini
Just a reminder for #71705 to also be CM aware.
Yep. That’s sRGB unmanaged hell dumpster from what I can see.
Added subscriber: @Pipeliner
Added subscriber: @BSannholm
Added subscriber: @JasonClarke
Added subscriber: @CobraA
Hey Guys.
I made a thread on the devtalk about [[
https://devtalk.blender.org/t/color-management-in-the-viewport-solid-mode/12830| Color Management in the Viewport (Solid Mode)
]], to be honest i don't understand why it doesn't get color managed or can use the workbench's rendered mode in a way, because the materials & textures look washed out and if you do a viewport render then they're different from what you see in the viewport...
this has happened to many people especially those who are using the grease pencil & doing renders which i believe you guys had to switch the view transform to standard & will probably cause more problems down the round ( after seeing the difference i can't unsee it anymore).
I think it can be simplified to not have to switch to the workbench engine rendered mode in the first place, especially that the workbench engine doesn't offer anything big besides being able to do color management ,hit 12 which is the same as the viewport render option , maybe compositing but it doesn't use any shading nodes....
It would be better if the solid mode in both Cycles & Eevee can use color management, like a checkbox to enable the workbench's rendered mode from there or something clever.
Solid mode always uses the Standard transform, which by default has more contrast that Filmic. It's unclear to me what kind of setup you are using to get low contrast in solid mode.
There must be a separate view transform, since the view transform is tied to lighting and can include artistic effects that get in the way of viewing and editing the scene in solid mode. Workbench as a render engine has many uses cases outside of color management.
It's the same setup for both excpet for small changes for the rendered mode to get better colors & higher contrast.
That's true. but how? since we can't control solid's mode "look" in anyway.
A fixed transform to sRGB’s display linear output also breaks with any device with difference colourimetry to sRGB, including Display P3 devices.
There’s no assumption that display linear is “more or less contrast”; it is literally just a canvas for output.
If the goal is to have a higher contrast output, it makes sense to work that into an aesthetic transform that has augmented contrast?
If you've set up the colors to be this dull with the Standard transform with the default Blender configuration, then I think you've picked the wrong colors in the material and are trying to compensate for them in the wrong place. Or there is some kind of bug or configuration issue.
Colors can be altered but you can't change the textures and you can't control the display viewport settings, it's only through the rendered mode that you can alter the standard transform to be more contrasty &pop out for both the viewport and renders
You can change textures. If you want lighting, blend modes and compositing to work well then the colors used for them need to make sense, trying to fix them afterwards in the view transform will not work well and is not a use case we should support.
Mentioning #72420 here. It's a design task, so it's a solution rather than a problem!
Added subscriber: @ClinToch
Added subscriber: @mrlemonyfresh
Added subscriber: @slowburn
Added subscriber: @Blackx
Added subscriber: @Linuz
for me - acescg is working quite good, and blender support is needed.
Where it works, kind of, by replacing the colormanagement folder the downside is picking colorspaces for the assets textures and super nasty: changing colors in all rgb fields is nearly unusable ;)
so if anyone has time, would be great to have aces inside
ACES itself is outside of Blender's scope, as is any other colour pipeline. OpenColorIO is what Blender should support and implement 100% correctly, which is where the majority of issues are. Once those are fixed, your ACES OCIO config will work.
Added subscriber: @tintwotin
Timeline for OpenColorIO v2
{F8891657, size=full}
A talk about OCIO v2: https://youtu.be/7e0SSka8Ar8?t=1754
Added subscriber: @Russ1642
Added subscriber: @ionarn
Added subscriber: @Gehrig
Added subscriber: @Slowwkidd
Added subscriber: @mmdanggg2
Added subscriber: @YegorSmirnov
Added subscriber: @SamGreen
Added subscriber: @Stat_Headcrabed
Added subscriber: @clayhands
Added subscriber: @RobertWesseling
Added subscriber: @LaurynasKel
This issue was referenced by
f193b1afb3This issue was referenced by
b10d8e330eAdded subscriber: @Blendify
This issue was referenced by
27b78c9c94Added subscriber: @baoyu
And here goes the OCIO v2.0.0-rc1! The official release is coming ; )
https://github.com/AcademySoftwareFoundation/OpenColorIO/releases
Added subscriber: @wenna666
Added subscriber: @EAW
@EAW, please leave updating tasks to Render module members.
There is no requirement for the config to be named
config.ocio, that's just the name of the config we ship.Unclear what this means.
We do not have an OpenColorIO patch, only a workaround in the Blender code that makes no sense to contribute.
Just hoping ACES support. And BTW, when it's implemented how to deal with the relatively huge file size increasing because of the huge ACES library files?
ACES works fine in Blender now if you want to use it, aside from the stuff listed in "Shader Nodes" above. (and lookdev mode, which doesn't have a way to set input color space for the backgrounds, they're assumed to always be in the rendering space).
@brecht could you take a look at the many suggestions that have been posted here, and consider updating the task description with them? They have been made a long time ago.
While it's unlikely that major changes happen soon, said suggestions are well-intended, yet on the verge of being completely forgotten underneath a task description that still lacks important stuff while addressing non-essential targets.
As the "aside from"s you said, just makes it unusable.
And what's more I found that the 3D viewport and image viewer of blender just simply don't respect the ACES ocio config.
To prove it, just import a srgb image and set it's IDT to Utility-sRGB-texture and compare it with the results with another software that supports ACES.
It will be looked at when actual work starts on this. The tasks lists things that I am sure we should support and how, some of the suggestions I don't think are the proper solution.
Sounds good. I hope we can have a constructive discussion about those when the time comes.
Added subscriber: @pauanyu_blender
Added subscriber: @STEP-ANI-MOTION
Added subscriber: @Aeraglyx
Added subscriber: @fldbots
I found that the standard color management preset do not fit for direct tasks that need receive good shot without Photoshop and manipulations with EXR. I thrown out 'EXR' from my pipeline and I use 16 Bit Tiff (EXR do not apply 'Color Management' Setting) with follow color preset: Display devise: sRGB; View Transform: Raw; Look: High Contrast and there is the important detail - curves (1st point x: 0.00, y: 0.00; +1st (optional): x: 0:015, y: 0.25; 2nd point: x: 0.25, y: 0.76; 3th point: x: 0.7, y: 0.98; 4th point: x: 1.00, y: 1.00.).
I recommend to use it as standard when you try to fit scene lightings and materials. The settings Standard, Filmic and Filmic Log show this scene unpredictable.
Removed subscriber: @tintwotin
I find that your advice might be appreciated over at the colour science circles at maybe ILM, Filmlight, or Method Studios. Maybe you should take your random and poorly informed opinions over there and figure out how they receive them.
Here's the job board over at Apple too...
https://jobs.apple.com/en-ca/details/200242182/color-imaging-scientist
Added subscriber: @rsgnz
Added subscriber: @frances-murphy
Added subscriber: @GeorgiaPacific
this should get more love,please, the current Blender color management is lame, and makes professionals walks away from Cycles.
Added subscriber: @DarkKnight
I am not an expert in this area but aces makes it easier to export images to other programs. Can this be considered in the near future planning after cycles x rewrite?
Added subscriber: @Accelero
I have sat down and wrote an OCIO config with the new built in transforms. I sticked to the conversion system OCIO has setup with it's new built in transforms.
Texture Color Space -> Reference Space (ACES2065-1) -> RRT to CIE-XYZ D65 as Display Reference Color Space -> ODT to Display Color Space
Here is the config and a blend file with a simple color checker to test it out:
config.ocio ColorCheck.blend
The HDR Transforms are obviously not displayed correctly even if u have a capable monitor, since blender cannot output the necessary meta data to display HDR (drawing code / file output needs to be improved).
Some of the View Transforms like the HDR transforms for "P3 Gamma 2.6" and Rec.2020 with Rec.1886 transfer function don't make sense i think, because HDR capable Displays use either PQ or HLG tranfer functions anyway. But I left it in for testing purposes. This config could be used as a starting point or example on how to implement better ACES support and works already as is for SDR content.
Some things I've noticed while writing the config:
Another thing I wasn't able to verify is whether the values of the PQ and HLG transforms are correct. I would have to do more research on how exactly the PQ works, but at first glance the values seem to make sense. When the PQ is designed for up to 10000nits and ranges between 0..1 bright values got larger when switching from SDR view transform to HDR and higher nits transforms. All the transforms in the config are built in transforms from OCIO.
I hope this helps in making blender HDR and ACES compatible. If this is the wrong place for that, please point me to the right place, thank you.
This has nothing to do with the rubbish “gamut” solution, and everything to do with the broken fundamentals within ACES. There is no fixing it.
I did some quick improvements on the config.
be aware: RGB and HSV values in the color picker are scene linear (ACEScg) not sRGB. Only the color picker is sRGB. If you want to use Rec.709 scene linear primaries like default blender just change the scene linear color space to "Rec.709 Linear" at the beginning of the config.
The color picker is now displayed correctly for me. Not sure what the issue was.
In a production ready solution it would be nice to set the color space specifically for each color socket or have it in scene linear values like now but perhabs automatically change the color picker to display color space.
config.ocio
I’m not sure renaming the standard ACES “Utility - sRGB Texture” to “sRGB Color Picker” is a good idea, that will make Blender non-standard from other ACES implementations for no good reason. Isn’t it also missing the XYZ role, which is necessary for textures such as the Sky Texture node to be correctly in the render space? Also, should P3D65 be gamma 2.6? IIRC it is gamma 2.2 in the standard ACES config, as using D65 with P3 primaries typically goes hand-in-hand with gamma 2.2 as well (aka, the “Apple Display P3” space)
In general, I’m struggling to see the advantages of this config over the standard ACES config, aside from maybe less clutter(which can be achieved by removing/commenting out IDTs) and having a Filmic Blender option left on (which was never designed to work properly with ACEScg renders anyway)
I quickly added the color picker space specifically for the color picking purpose to clamp inputs. I just forgot to hide it, it's not meant to be seen. I fixed this. For textures there is the "sRGB" space like default blender.
The sky texture looks wrong, but it appears to rely on Rec.709 Primaries for the scene linear space to work correctly. It is not color managed, but hard coded for Rec.709, I guess.
After a quick research I found the following: officially P3 is gamma 2.6, but Apple Display P3 uses gamma 2.2, so in practice P3 D65 is often used with gamma 2.2. I checked the source code and the built in transform in OCIO has gamma 2.6 for P3 D65. I quickly added a P3 D65 gamma 2.2 display space by gamma correcting 2.6 to 2.2.
The standard ACES config is barely usable with blenders UI, since there are too many color spaces, as you mentioned. The point was also to create a config with the new built in transforms from OCIO v2, which should be more accurate than Luts. I think it's also desirable to have a more streamlined/thinned config. Many color spaces in the standard ACES config will only ever be used by professionals, that would use their own config anyway. Having a user friendly config that could be shipped with an HDR/ACES compatible blender is necessary in my opinion. I'm not saying this is ideal, but it is a start. Right now there is a color management section in the render tab, but the only display to choose from is sRGB. This functionality should be expanded if blender is run on HDR or wider gamut displays, which are getting more and more available. To ensure good usability, the wording has to be precise, minimalist and conform with blender standards (e.g. I just kept the term Filmic, because I think it's easy to understand and people are used to it). The standard ACES config is a mess, thinning it is an option, but so are built in transforms which are afaik not yet implemented in the standard ACES config.
config.ocio
Hi, @Accelero, thank you for doing this.
Having user-friendly config is really helpful and ACES is a huge improvement over standard Filmic luts, especially with very bright saturated lights. Now rendering sunset with Nishita sky doesn't look like a toxic apocalypse anymore :) Also most image textures get correct color space assigned automatically, so there's no hassle opening and converting old scenes. Except for HDR images, where color space dropdown is just empty. Is this just a visual bug? Which transform should I use for HDRIs?
Also I noticed that the image gets quite a bit darker in the shadows when using Filmic transform with this config, compared to standard Blender. Is this intentional?
@slowburn Yes, the "Filmic" (ACES 1.1 SDR video RRT) tonemapping curve from ACES looks darker, that's just the way it is. The Sky Texture seems to need "Rec.709 Linear" as scene linear space set in the config to work correctly. I don't know what causes the environment texture to miss the drop down, but If u select a texture file, it appears. The correct setting depends on the color space of the HDRI but this is most likely "Rec.709 Linear" which is the same as "Linear" in default blender. Default blender works with Rec.709 Primaries.
Edit: The default color space for float textures wasn't updated. I set it to Rec.709 Linear.
Update: config.ocio
Currently the description of color spaces does not work for "Color Management" in the "Render" tab. For selection of color spaces in the texture node it pops up.
It would be nice to have a consistent support of OCIO config descriptions.
Removed subscriber: @troy_s
I made a quick mockup of how this could look like. But maybe someone from the industry could give some feedback, whether this is what is needed, or how it could be better implemented. The naming (Scene, Display) is of course just a placeholder. I just didn't come up with better, concise terms.
The “Scene” section is probably unnecessary, OpenEXR really shouldn’t have output CM applied to it, the standard of the format is to “dump the render buffer” so it should always keep the scene render space. If for whatever reason the rendering space is not the comp space, that should be harmonized on the comp side, IMO. And any other image format you probably want to perform a scene>display conversion. The display section looks good, but a “use view transform” checkbox that overrides the rest of it with the main scene CM settings would be good, and probably should be on by default, to ensure the render view is WYSIWYG for the output file.
Btw, the Sky texture DOES support color management, it relies on the OCIO “xyz” role to tell it how to convert from XYZ to the OCIO config’s reference space, from which it can then find its way to the space defined for the “rendering” role.
So Log space (e.g. ACEScct, Cineon) exports isn't a thing? Of course one can always get the log from the scene linear later.
In the case of OpenEXR it might be uncommon to have anything else than scene linear, but being able to convert primaries (AP0, AP1, Rec.709) might be useful on export. For other formats like saving textures, choosing color space might be useful and if the file saving is modified to run a color conversion before encoding the image file, it doesn't matter what file type. It would mean no additional work to have the dialog also for OpenEXR, but of course it can become a cause of error, if unknowingly changed.
Are there textures, where someone wants to convert different color spaces (AP0, AP1, Rec.709)? Having the color conversion on file saving in general possible, could solve many color space issues, but in the end it's a question of design philosophy. Do you want to give users the option, or does it create more confusion than benefit.
This or the dialog always opens with the main scene CM settings preselected. So if nothing is manually changed WYSIWYG. Same goes for the color-space-drop-down list, where the color space of the image-data-block or scene linear for Renders (e.g. OpenEXR) or as fallback, should be preselected. Your idea with the checkbox is safer, but it's an extra click.
I tried to get that to work, but I wasn't successful yet. The "XYZ"-role gets ignored in my case (I'm currently on blender 3.0 beta). Here is the config I am testing with. config.ocio
Display: sRGB, View Transform: Un-tone-mapped should look the same as default blender: sRGB, Standard. Scene linear space is ACEScg. The blackbody node just outputs its Rec.709 colors directly into ACEScg scene linear, ignoring the "XYZ"-role. Sky Texture doesn't work as expected even with Rec.709 scene linear space. I haven't figured out what the problem with the Sky Texture is either.
One useful option when saving linear EXR images would be to apply scene exposure. That would save one extra step of having to match exposure in external compositor. Full Exposure and Gamma sliders are probably an overkill, just a checkbox would be enough.
Removed subscriber: @Mets
Removed subscriber: @BintangPratama
Added subscriber: @chelaru
Added subscriber: @Nurb2Kea
Added subscriber: @AlexeyAdamitsky
This issue was referenced by
2b80bfe9d0This issue was referenced by
33f5e8f239I finally found out why the sky texture is not working correctly with other configs. The aces_interchange role overrides the xyz role as shown in this [commit ]] or directly in source. This is nowhere mentioned in the [ https:*docs.blender.org/manual/en/latest/render/color_management.html | manual and the reason why the xyz role never had an impact in my config since the aces_interchange is defined.
Furthermore there appears to be an error in the blender code, which causes aces 2065-1 to be interpreted in a wrong way by Blender and causes a color shift in the sky texture. However the sky texture renders correctly with the default config, because it does the same error like in the Blender code, which cancel each other out. I descriped and reported the bug here: #95368.
Removed subscriber: @item412
Added subscriber: @ssh4
Let me add some more issues that make ACES unusable in Blender.
At first current internal Blender ACES config completely lack of ACES color spaces, so no one even know that Blender use Ocio internally and have support for this.
In config only defined Classic Blender color spaces and look transforms.
And anyone who need use ACES color spaces usually follow variable web guides to download OCIO 1.2 config and set OCIO environment variable to downloaded ocio 1.2 config. For example original https://github.com/colour-science/OpenColorIO-Configs/tree/feature/aces-1.2-config
This immediately make available all ACES as well as hundreds of un-needed color profiles for Arri, Canon, Panasonic, RED and other cams. And immediately catch https://developer.blender.org/T72093 UX/UI bug with unusable for big lists color space selection menus.
After some cleanup of default OCIO config, and in some latest 3.2 builds this lists become usable but user found that old projects with sRGB, Filmic, etc. Open completely unusable, because all textures now open as ACES-AP0. Every new texture need manually switched to sRGB or Linear sRGB that make this step extremely slow on 8-16K 16bit textures that looks like Blender re read every time when user switch color space for texture.
And later, when user want to model something, him will find that Matcaps made in sRGB or Linear sRGB show totally wrong.
And no way to adjust Color Settings to make matcaps looks as they are designed.
I tried merge ocio and blender ocio configs, and this definitely possible. But i stick with "defaults". Blender expect default Linear (Utility) sRGB, Ocio expecting default ACES or ACEScg.
Probably solution in correct use of aliases, but not really sure who can do this. Blender devs or ACESdevs or this required work for both teams together.
Added subscriber: @renderart
Added subscriber: @Steven-6
This issue was referenced by
7aab508e32Added subscribers: @Eary, @dgsantana
Removed subscriber: @Steven-6
Added subscriber: @Harvester
I just noticed the updates on the task and wanted to float the suggestion of giving the user the choice of packing the config and luts into the blend file. So full portability even with custom configs within one blend file is retained.
The implementation could work something like this:
Add a checkbox to the
File>Externaldata menu to pack the OCIO config and it's dependencies into blend fileOn File opening: look for packed config first, and fallback to application default config
Display a Warning when there was a mismatch (e.g. in name) of the scene linear color space the scene was saved in and the one used in the config used on opening it
Something else to consider:
aces_interchangerole if defined, to make colors config agnostic and allow for automatic transformation on opening the blend file with a different config, that hasaces_interchangecorrectly definedI followed this thread 'Color Management Improvements', for a long time.
Now, I got an e-mail notification about ICC Profile and ACES.
Unfortunately, I am not a color scientist (We had one in the thread), but as I experienced ACES, this is going wrong. It has some of the strange kinds of hue shift bands we see also in the default view.
And I thought ICC profile is not applicable for Blender?
True. Everybody's hopped on the Aces train despite the fact that it's far from ideal. I think Blender should be Aces or Filmic agnostic, but behave correctly as much as possible in majority on scenarios.
In the meantime look at this nasty test
Let's keep this task focused on development planning, and leave the discussion for relevant devtalk topics. Please note:
I noticed this:
029b0df81aNot sure but I believe the lastest daily build I am using (
b90e892a1757) is already the version with this commit.Sadly this doesn't work. By doing so you are still hardcoding Rec.709 in your blackbody node, see my test result here:
Even with a wider gamut colorspace as the working space, the blackbody node would output this clipped result, that straight line right there is the edge of the Rec.709 gamut triangle.
AFAIK, the proper way to do it is to use
CIE 1931 XYZas the standard for blackbody chromaticity, and then convert it to other spaces as needed, instead of "Keep the existing Rec.709 fit".It is essential to use
CIE 1931 XYZbecause this is basically the working standard for chromaticity, literally every single RGB colorspace needs to use CIE XYZ as a standard reference, even ACEScg and ACES 2065-1. That's why I believe replacing the XYZ role with ACES_interchange is such a bad idea. CIE XYZ is literally the start of everything. CIE XYZ is a reprojection from LMS model which stands for Long, Middle, and Short cone cells in our human eye. CIE 1931 XYZ is not just a "wider gamut RGB colorspace similar to ACES", no, it is literally the pre-existing standard for all RGB colorspaces. At least this is how I understand it. Things need to be done properly.Please report potential bugs to the bug tracker, not in this task.
For Blender to be OCIO config agnostic and work in arbitrary colorspaces it is necessary to define built-in color producing functions like a Blackbody or Sky Texture node in a color space with a special "interchange" role. It should be preferred to use an color space for that purpose that theoretically encompasses all colors visible to the human eye. There are several color spaces that include the whole visible spectrum (without negative coordinate values) as well as even more "imaginary" colors, which are just mathematical artefacts of the way the visible spectrum has been parametrized and physically can't exist.
Two prominent examples of such color spaces are the
ACES 2065-1which is not inherently flawed or the cause of the problems of the ACES view transform. It's mere a "coordinate system for colors". And theCIE-XYZ [D65](https://archive.blender.org/developer/D65). Both of these color spaces would work fine for the role as "interchange" color space and it's basically a question of which one is more established. ACES tries to establish itself as a standard in the film industry and CIE has been around since 1931.Personally I'd say CIE-XYZ fits better for applications with a physical/scientifical background and ACES 2065-1 for film industry related things. So I find CIE more fitting as an interchange role for things with the aspiration to be somewhat physically/scientifically based like Blackbody, Sky Texture etc. One is more likely to find publishings in that field that are based on XYZ than on ACES. Therefore I'd vote for a comeback of the XYZ role in the config, more precisely an
CIE-XYZ [D65](https://archive.blender.org/developer/D65)interchange role.To address the problems of the ACES view transform that creates these unpleasant color shifts in certain extreme lighting scenarios, especially with blue colors:
There will always be problems like these with RGB rendering. Only spectral renderers can produce accurate colors, but at high cost, both computation wise aswell as configuration/complexity wise (materials etc). But ACES view transforms are more common and standardized than the Blender Filmic one, which is only used by Blender itself. So to create a behavior more similar to other software in the industry, adopting the ACES View transform is a good idea. Not to insult anybody that worked on the Blender Filmic View Transform (it is great and was a real step foreward in terms of realism compared to before), but there was probably a lot more work commited to engineering the ACES View Transform (at least it should) and there will probably be more commited to maintain and improve it in the future. And with OCIO having a built-in ACES View Transform that is performant and not LuT based, aswell as maintained by OCIO, which Blender is already commited to, why not use it instead?
Feel free to disagree or give your own input to the topic
Greetings
My understanding of CIE 1931 XYZ is a bit different.
The following is just my current understanding, please correct me if I am wrong.
AFAIK, CIE 1931 XYZ is a reprojection from LMS color model. And LMS color model is the direct study of human eyes' cone cells. Therefore CIE 1931 XYZ is directly related to human eye cells research. It is not a "wider gamut colorspace that encompasses all colors visible to the human eye", the cause-and-result relationship is inverted if you think of it that way. Because it is directly related to human eye cone cells response, therefore it naturally covers all colors we can see. And all later RGB colorspaces each needs to define their primaries with three sets of CIE XYZ values, becuase CIE XYZ is a reprojection of LMS, which means each RGB colorspace needs to use CIE XYZ to define their primaries cone cell response.
Both
ACES 2065-1andACEScgare problematic in a sense that they are defining their primaries with CIE XYZ just like all other RGB spaces, but the underlaying cone cells response level does not exist, because it is outside of the horseshoe-shaped standard observer model, it becomes a mere mathematical byproduct of the CIE XYZ math reprojection. So in my understanding, ACES is just not capable of replacing CIE XYZ, because it is built on top of CIE XYZ's mathmatical byproduct, not human cone cell responses. The situation is not just about "how large the gamut is, can it covers the entire horseshoe", it is also about "how it is related back to the meaning of color"This is a misunderstanding of what CIE XYZ is I believe. Again this is just my current understanding, correct me if I am wrong. As I said, CIE 1931 XYZ is directly related to human eye cone cell research LMS, therefore it is not really about physics, it's more about the standard observer human eye. (Though you could say that LMS is about cone cells' response to wavelengths and wavelengths are physics, I guess.) ACES 2065-1 is built on top of CIE 1931 XYZ since it still needs to define its three primaries with three sets of XYZ values, but it has some controversy because it does not make sense in the human cone cell response aspect. It is important to understand that color is not a physical property, but a combination of biological and psychological phenomenon in human visual perception.
Added subscriber: @Fastfinger
I created an OCIO config so that default-Blender, ACES, TCAMv2 and AgX configurations can be used all together.
While creating this I've marked 2 issues.
Also while making this config I wanted to hide some colors paces from the shader editor but keep them present in the display section. Only way I could do this is if I named the family to be "display" (I don't know if there's a better way or not). It can be confusing if same config is used for any other software since they present different segments for different families.
You can find the config I mentioned here, Google Drive link to Merged OCIO config
And I made a video about this with some additional details, here
That's my setup, and I'm pretty happy with it!
What's wrong with this setup?
config.ocio
Interesting attempt. Haven't throughly tested it but from my first glance, your Views should be Displays and your Displays should be Views.
Also your Film Looks don't work. I mean... Those Film Looks were present in Blender 2.79 but removed in 2.80, the removal was for a good reason: They don't work:
Yeah I agree with that, I found this an easier way to organize it within Blender. Also, wanted to keep how different views name their identical displays.
They are just an attempt at achieving some kind of look. I would like to start a discussion on this and figure out a way that would actually work.
I'm aware that Filmlight has its VisionLook which is paid and I haven't gotten the chance to play around with that.
I'd like some feedback on this, I'm using Cineon-log as a basis for FPE because this is what I'm used to from Davinci Resolve, but clearly it's not working. How should I approach it?
Added subscriber: @donmccurdy
This issue was referenced by
5baa3ecda6Added subscriber: @basvanbergen
This issue was referenced by
469ee7ff15This issue was referenced by
bdab538b30This issue was referenced by None@62941
This issue was referenced by
9d8fb80f21This issue was referenced by None@62943
Added subscriber: @Emi_Martinez
Added subscriber: @Dadido3
I'd like to note that Blender's OCIO implementation lacks support for useful QoL/UX features, such as regex file rule support
@Fastfinger mentioned this when i brought it up, thinking it was an issue with his config. But it was actually a lack of functionality within Blender itself.
https://github.com/Joegenco/PixelManager/issues/3
https://github.com/Joegenco/PixelManager/blob/master/config.ocio
example:
`file_rules:
This would make users lives easier, saving time changing colorspaces from sRGB to Non-color. This would also help mitigate problems with equivalent color spaces not being preserved when changing colorspaces. Ex. Someone who is using Filmic Non-Color, could have their non color texture be converted to ACES Utility Raw if it matches the regex, saving headache when using add-ons like PolyHaven's browser
Hello again!
I am expanding the Blender 4.0 config to have a lot of the things that the checklist in the original post included.
Its over here.
What would be cool is that if Blender had the option to assign a colorspace to the RGB node along with the other "RGB" value pickers.
By default, this would be in the rendering space. However it would give the option to the user to manage the RGB values by colorspace assigned to them AND it would allow for rendering space to be changed without affecting the RGB values.
Blender currently assumes all RGB values are in the rendering space, hence if an asset that was originally created for Linear Rec709 is used in any other rendering space (Be it Rec.2020 or ACEScg..) those values end up moving coordinates since Rec.2020 RGB is in a different position than Rec.709 RGB, adding a "selector" to RGB like the textues, would solve this.
@Fastfinger if you want contribute improvements to the config with Blender, it can be done with incremental pull requests that add one feature at a time. For example one for ACES RRT view transform, or an additional display, or additional input color spaces, etc.
We have no plans to add a configurable color space for every color property, but rather to provide some mechanism to convert between color spaces on import/export/link/append. I think doing these kinds of color space conversions at runtime leads to a messy workflow and inefficiencies.
So like having the ability to pack non-default color space information in the blend file? That would solves certain workflow issues, such as external render farms or exchanging files. Ex. Someone with an ACES config could pack their config with whatever file they are working with and share it with someone who is using AgX
My apologies if I come across as treating this like it's right click select.
The mechanism we plan to add is this from the issue description. We do not plan to pack configs, only include information about the scene linear color space in the .blend.
This would allow some basic interop for assets created with a different configuration. But automatic conversion is never going to be perfect, and in general there should be an agreed color space at the start of a project.
That is a great idea!
As long as the destination OCIO profile includes the colorspace or an alias of it this will work perfectly and users won't feel it.
Although this means it will need to allow minus values since some values will turn negative when doing this.
We may have to clamp those negative out of gamut values when going from wide gamut to a narrower gamut. In some cases they may work ok, in other cases they can break shaders, lights, painting, etc.
Hey all,
I am looking to make a simple contribution to Blender in this area. Okay the last time I wrote C++ code was in 1993 but I'm not going to let that stop me. There are two items in this task which seem like low-hanging fruit which I'd like to volunteer to take a bite if nobody else is actively working on it:
Support environment variable
BLENDER_OCIO, then fall back toOCIO(existing behavior) if it doesn't exist.I've already built my own Blender with this trivial feature so I'm past square one!
BLENDER_OCIOlocation might be safely writeable by Blender itself (unlike sayC:\Program Files\Blender Foundation\...), it would be trivial for someone to make a python add-on with "Press this button to update to @Fastfinger's latest OCIO").Provide a per-
.blendfile configuration parameter to point to an OCIO location, supporting \relative\to\project notationThis simple feature solves three problems:
These are minor improvements with material benefits, which I think I am capable of implementing. BTW I fully support @frameshift's proposal of a full-featured, Nuke-like Color Management UI but I'm not ready to boil that ocean yet.
Thanks in advance for any feedback.
Jon
Why just not make as in most apps where user can define the path to config using a GUI in options?
And I feel that most logical UX still:
A checkbox: Allow to ignore global OCIO_CONFIG
A path to User OCIO config, that in case of empty fall back to BLENDER_OCIO or global OCIO_CONFIG.
That way allow users who need to have not only VFX industry color spaces, always have their own cherry picked configs.
And allow to avoid some developers who use global OCIO_CONFIGs (that can be complicated for non Linux users)
I'd like to clarify a distinction between three proposed sources of OCIO config
BLENDER_OCIOenvironment variable if it exists, and falling back to theOCIOenvironment variable if it exists\\relative\to\project notationIf you are suggesting we should also have a UI field to specify the user-overridden OCIO config (say in Preferences -> File Paths), instead of (or in addition to) adding a
BLENDER_OCIOenvironment variable, that seems reasonable to me. There wouldn't really be a need for aBLENDER_OCIOenvironment variable at all in this case I suppose.Yes.
Usual CG artist on windows or macos work in GUI. And it’s better avoid Linux or coding UX patterns with environment variables when more user friendly allow change a settings via Options.
So I think that definitely should be settings via GUI that allow override any environment variables.
Because most of OCIO guides recommend to use OCIO Environment variable, that usually point to ocio config that never including blender specific settings.
Makes sense. I hope nobody minds if I split this into a separate issue to track my area of focus, "improvements to specifying the OCIO configuration location" and leave this thread for the more esoteric discussion of "improving internal handling of colorspaces", which are far beyond my skill level and not likely to be developed by me. That way we can track (and hopefully close) the development and testing of that minor UI & functionality improvement, while leaving this thread to the ongoing thoughtful discussions about colorspace processing.
I will post a couple implementation details in my issue 127050 and welcome any feedback there.
Also, since Linux wayland has color management support now, I think we should also add color management support for blender under linux+wayland.