Thanks for sharing the materials! I learnt a lot reading and watching them! From the slides, it sounds like instead of ACES, we should go for TCAMv2 instead? I am curious how Filmic Blender is doing comparing with TCAM v2, which was dubbed to be “currently the most advanced Colour Management Workflow in the world” in the slides.
The underlying mechanic is quite different, which is the bulk of the difference. Digital sensors record intensities, that are in turn mathematically fit to immutable chromaticities of light. The lights go up or down in emission strength, but never change their chromaticities.
Film on the other hand, was a constant trade off from thick dye to nothing. That is, less chroma with better “brightness” representation.
That little nuance is the detail that has been completely lost with “tone mapping” and the other random garbage out there. It requires actual engineering, not just slapping an intensity curve to be applied to the independent stimulus channels.
I try to look forward. I believe strongly that we should move past emulation, and learn from the things that film did well, and then work toward that sort of a fundamental mechanic in a future looking direction.
Currently, the vast majority of approaches are just accidents and massaging of accidents on top of other accidents. This leads to the claim of some systems like ACES as being “colour management systems” which is hilarious, because it does not work.
TCAMv2 can work quite well, and it isn’t even worth uttering in the same breath as ACES. Baselight actually tries to be a management system.
That said, I’d suggest that it’s worth trying. I believe that the “perform all manipulations on open domain light” is a tad ahistorical, and in fact can get in the way of some legitimate manipulations. But that’s another rabbit hole…
Filmic Blender was designed for a specific context, with specific constraints. It is also almost a decade old in terms of the general audience understanding of the importance of image formation. Could it be vastly better? Absolutely. Did it make concessions along the way to help folks understand and adopt it? Absolutely.
5 Likes
Nope. That’s one that I a while back. Thanks. Removed it.
ACES doesn’t work.
I understand it clearly now.
This is like a koan. Me must open our minds to contradiction to transcend the ego.
Can we have an official ACES support for Blender?: There’s already official ACES support in Blender.
Where is it?: you must install JTheNinja’s version.
Where is that version? nobody knows.
Is this one in github contributed by troy_s and jtheninja?: no. ACES doesn’t work.
So, let’s state it cleary for other people finding this thread and needing ACES support:
There’s no ACES support in Blender, and never will be.
Never. Ever.
And that no one knows what combination of colorspace and transform makes resolve read blender .EXRs the right way in any color managed project. Just stick to 16 bit tiffs with crappy alpha channels.
Thank you for your time sir. 
My two cents here.
Asking for “ACES” support is outright wrong, and the wrong way to ask for things. What Blender needs is a better and easier way to handle Ocio configs and work with OCIO. The current way of having a ColorManagement/ folder somewhere with “hardcoded” stuff that pretty much only works for Blender Cycles is wrong, and brings many problems.
Like for example, Blender default CM is forced upon the framebuffer at all times and doesn’t give addon devs an easy way to just bypass it when needed, having to do some hacks.
Octane and Renderman bring upon the table their own OCIO management that overrides Blender’s, one would think it would be better to just use Blender OCIO pipeline, if there was any.
At the end of the day, ACES is just another OCIO config, asking for “ACES support” completely neglecting OCIO is wrong, with a proper OCIO support Blender would support ACES and whatever you’d throw at it, being future proof.
Also, there’s this certain obsession with ACES, when in fact it’s more of a pipeline than anything else, a toolset to make life easier for studios that brings no benefits to individuals. Should serve as a clue that many many studios avoid ACEs completely or use it only to standardize the transport of textures and footage, removing it when in the pipeline.
You can use Blender EXR in fusion by simply loading, using the OCIO Colorspace node with Filmic Log and then one of the transform LUT. It’s close enough to be almost 1:1, and honestly, close enough to dismiss the small differences and use Blender just as a renderer and a guide. What you need and want is consistence in the rendered results.
ACES requires tons of things, is not enough to just use a display, you also need to setup textures colorspace.
Anyway, if you need ACES so much, the easiest way is by just replacing in your Program Files/Blender/DataFiles/ColorManagement folder the Filmic config by the ACES config of your choice, and then setup everything accordingly. This way you’ll look at ACES processed imagery in your Blender and you’ll be able to expect roughly the same in Fusion/Nuke/AE, whatever. I just made the test, and as long as texture color space is ACES, etc. you get exactly the same results. What is wrong is to feed a render with Textures using Filmic sRGB space and pretend ACES to work correctly with that.
Just remember that Blender Cycles, using Filmic, has every default setup so you have minimal fiddling, with ACES you’ll have to setup literally everything that has to do with color in Blender.
Which, btw, is how ACES work.
11 Likes
And also, understand something, when Troy says “ACES doesn’t work” he does not mean “in Blender”. He literally means the sentence as is.
People sees ACES as magic that makes renders beautiful without bothering in the slightest what’s OCIO, how does it work, how to use it, etc. They want a 5 minutes youtube tutorial giving 4 easy steps to follow for amazing renders.
And OCIO doesn’t work like that, at all.
7 Likes
That’s not the case. All you have to do is set the standard OCIO environment variable, and it will work with all programs that support OCIO (including Blender).
You can also use the official OCIO configurations for ACES, and it also works fine. You just have to set Color Management -> Sequencer to ACES - ACEScg and keep the View Transform as sRGB.
There are lots of other ACES color spaces, but ACEScg is correct for rendering.
There are various issues with OCIO in Blender (such as with the color picker), but for the most part it works fine both in Eevee and Cycles.
It also has benefits for individuals. As I explained before, many game engines (Unreal, Unity, Godot, BabylonJS, ThreeJS, etc.) support ACES.
The point of using ACES is consistency: if I create an asset in Blender and texture paint it, I am guaranteed to get the same result in the game engine.
And if I create an asset for one game engine and then port it to a different game engine, it will look the same.
Yes, but all of that already works just fine in Blender:
-
If you’re using RGB textures you just specify
Utility - sRGB - Texturein the Image Texture. -
If you’re using raw RGB textures (normal maps, metallic / roughness maps, etc.) then specify
Utility - Raw. -
If you’re using linear RGB textures (like EXR or HDR) then specify
Utility - Linear - sRGB.
These are the same as the sRGB, Non-Color, and Linear options in Filmic. Your workflow is exactly the same, you’re using the same JPEG or PNG textures that you normally would.
You can use any RGB texture (that you created or downloaded from the internet), though it will appear darker than you expect. This is not a bug in Blender, it’s just how ACES works (similar to how Filmic makes RGB textures look too bright and washed out, every color space makes compromises).
You can compensate for that by increasing the brightness of your lights, or increasing the Gamma / Exposure (under Color Management). Or you can just brighten the texture itself.
Another annoyance is that Blender doesn’t organize things into categories… it just displays hundreds of color spaces in the dropdown. But that’s something which can (and should) be fixed.
You can workaround that by just editing the ACES config.ocio and deleting the color spaces you don’t need. You can delete pretty much everything, except for the things listed under roles.
That’s not the case. Using ACES is just as easy as using Filmic, you’re just using Utility - sRGB - Texture instead of sRGB. And you’re using Utility - Raw instead of Non-Color. It’s really not any more complicated or difficult.
The correct thing to do is to just use the OCIO environment variable.
I agree, there are definitely many rough edges with Blender’s OCIO support. It works but it’s not ideal.
However, in addition to fixing OCIO, it would be useful to have ACES built-in to Blender, so it can be easily selected in the dropdown without needing to manually install it and set it up.
In order to install ACES, you have to download 6.17 GB, even though only 1.84 GB is actually needed. And mucking around with the environment variables is not fun for artists (though I’m a programmer so it doesn’t bother me).
In practice most of the ACES configuration isn’t needed, so if it was included built-in to Blender then it could be cut down significantly (saving even more space).
I don’t think most people here are choosing ACES because it’s the best color space, or the prettiest, or anything like that. They’re choosing it for consistency and compatibility with other programs.
If all you want is good renders, then Filmic is just fine. The problem is when you need to integrate Blender with other programs, that’s when ACES becomes useful.
7 Likes
I would appreciate reading my whole post instead of going up and down replying to individual paragraphs. I do know how to use ACEs in Blender, I do know how to change Filmic by anything else in Blender, or just export an EXR and use a tonemapper of my choice in Fusion or AE. That was not my point.
My point is that Blender makes it convoluted to change OCIO config, and IMHO, the in between solution of forcing the BF to integrate ACEs in the official builds is not ideal.
the ideal thing is to have in the preferences a Color Management tab where we can load whatever OCIO config we need and set some basic configuration, and thus being able to use it. Even better if the Color Management tab allowed to save presets and the files loaded an existing preset (or did a fallback to Filmic if failed), so I could seamlessly use Filmic or ACEs or TCAM projects if needed to.
Second, I also made the point about ACES and consistency, is exactly what it was created for, it’s the whole purpose of it, to have a color pipeline consistent throughout the whole process. It’s the biggest virtue it has, and it’s a HUGE thing. Saying this so we make sure we’re not disagreeing in some core concepts here.
I, by the way, appreciate you took the effort to explain how to setup textures, etc. using ACES, it’s also what I said (just didn’t explain how, but I reckon now being more didactic would have strengthened my point, lesson taken). But you should agree with me that unless some defaults are set, it forces to manually setup the textures imported, and skipping a texture can bring problems.
I almost agree with you in all of your post but the last paragraph, I do indeed think ACES brings a layer of complexity, over a time and automating some processes can become a transparent process, as transparent as using the builtin Filmic, and ACES does that on any DCC anyway, Blender wouldn’t be the exception. But individuals working isolatedly in Blender don’t really need ACES, and if you work texturing from Painter (which is a huge mess regarding color management), you have problems unrelated to Blender here.
My main disagreement with you is in your last paragraph. Sadly, many people fail to understand what ACES really is, a tool to have consistent color management along a pipeline, and instead only see it as a different tonemapper that compresses HDR to LDR better than Filmic. This does not happen only on Blender, but also Maya, Max, C4D, etc., many people see ACES as an industry color management that should be used because is industry color management, without really stopping pondering the implications.
And as Troy and other experts in ACES have pointed out, ACES has problems regarding tonemapping. It suffers of severe color skewing and does not compress that well, studios usually modify it and tweak it a lot to have a usable thing. Does not mean people should rule out ACES, but instead they should try and compare other tonemappers and then make an informed opinion.
Of course any TD can disregard all of my post, since as said, ACES is very powerful to offer consistence, but not really needed, there are many ways to get consistence without using ACES.
I stand by my point, there are already ready releases of ACES, strip down to a few hundred MBs, easy to download, install and use. Blender needs a color management tab and make it easier to use and config OCIO without needing to touch global environment variables. Even Maya offers that.
6 Likes
That sounds counterproductive for cross studio work. If every studio has their own internal ACES config files then we can’t talk about a standard.
For the 15th time, no.
ACES is ACES. There’s nothing to “support”. Go install the official repository for OpenColorIO and done.
Read this quote above. Someone who is sane and understands what has been communicated many, many times. Read their whole post.
While this is technically correct for swapping out OpenColorIO configurations, it is also not the entire picture. There are some nodes and expected roles that require tweaking to support alternative primaries. The luminance coefficients and the XYZ role come to mind, but there may be others that I can’t remember. Those changes by the way are the sorts of bare minimum things that anyone who seeks to use alternative configurations should feel comfortable adjusting. If they are not, that’s a terrific indicator that they are not ready for the additional complications associated with changing the configuration.
This is outright false, as I’ve tried to explain.
For the folks who are patient and willing to learn, ACES is a stimulus based mapping, and as a result, it provides no such thing as colour management. It cannot, because it botches the stimulus management side, which all sensation management is based on top of.
Specifically, for every stimulus mixture that cannot be represented at the display, it will distort in a device dependent manner. That means that what you will see on an sRGB display will be broken in a unique way compared to a DCI-P3 display, and extremely broken differently with an HDR display.
The system is broken. It does not work. So even if one wants to accept the aesthetic nightmare fuel, it also doesn’t work as a management system.
Academy == True
Colour == False, because colour is a sensation metric.
Encoding == False.
System == False.
Had they stuck to the origins of the design, it would have been:
Academy == True
Colour == Not quite true
Encoding == True
System == True
But they shifted gears, and the entire architecture and design is impossible to manage colour, which is a sensation, because it does not properly manage stimulus.
Bzzt. Totally wrong, and is part of the con job misconception peddled by folks who know nothing about colourimetry or advanced colourimetry, and instead lean on the myths and rubbish peddled by YouTube clickbait.
NanoSpawn is of the sorts of minds we need to cultivate here. We would all do well to interrogate the concepts as they have.
2 Likes
Because technically is not a color standard. As said, is a tool to ensure consistence throughout a studio pipeline. Not a standard between studios, software and devices.
I did not mean to say that it is a color standard. It would be nice if ACES can be used across multiple studios in the same way to get better image consistency given it is not uncommon to share and outsource partial work in projects to others or even deliver shots from one studio to another during a production.
It doesn’t achieve this. All it is is yet another bunch of accidents coupled together. It’s not consistent in the way that people assume it would, leaning on the authority of the Academy.
It did indeed begin life as a stimulus encoding, but it attempts to do more.
If you read the official ACES Central website, you’ll see this bit of totally inaccurate rubbish:
So it indeed claims to be a colour management system, but even a layperson with a shred of ability in Python can quickly demonstrate that the claim is extremely far from the reality.
Again, it does a per-channel stimulus based approach, which is like taking individual notes from a guitar without any care as to the chords they form. It just doesn’t work.
Thankfully, there’s been a solid tidal wave of pushback recently, as more and more folks realize that there’s no clothes on the emperor. It’s just a con job.
4 Likes
Thank you. I already did that. Before hitting this thread. In fact that was the reason I ended up here. It’s messy. And you find a lot of version of ACES for Blender out there. All claiming to be the only one working. Including one by yourself that now you deleted.
By “support”, people expect, in their unbelivable dumbness of non-dev-meathead-user, to just click a dropdown menu somewhere and choose ACES.
Don’t bother to answer this, I understand very clearly your position.
2 Likes
By the way, I was able to fix the color picker in Blender by editing the config.ocio file and changing this line…
color_picking: Output - sRGB
…to this:
color_picking: ACES - ACEScg
In addition to fixing the weird behavior of the color picker, it also shows you exactly what color you are using.
The only downside is that now it’s possible to select physically impossible colors, so you need to be careful to not make your colors too saturated.
1 Like
This is not a fix, As you should not pick ACEScg primaries anyway.
The colorpicker could provide better options though. I believe we should be able to pick srgb_linear color while it is displayed thought the ODT of the config, which is not possible atm.
To add some food for thought, you can check out this article :
https://chrisbrejon.com/articles/ocio-display-transforms-and-misconceptions/
There are valid reasons to pick any of the colors in the ACEScg gamut (or even the ACES2065-1 gamut). HDR monitors do exist, and other mediums exist too.
And in particular, by using ACEScg for the color picker, it means that the color picker will match with the renderer, in other words “what you see is what you get”. I find that directness to be useful.
You can use color_picking: lin_srgb which is the same as color_picking: Utility - Linear - sRGB
I found that it doesn’t work as good as ACEScg, but it’s up to your personal preference.
And yes, it would be useful to be able to customize the picking and the display separately (instead of both at the same time).
You usually use the colorspace you display in. sRGB/REC709/DCIp3/REC2020 are the one you should select, not acescg.
This is kinda wrong as well. For the renderer, everything is RGB colors, it is colorspace agnostic at its core.
The second part of this part is particularly wrong and is a missconception that I often hear. No, you don’t pick what you see if you select ACEScg primaries that your sceen can’t display, at all. The ODT/RRT part of the color pipeline are rendering the colors for you to be able to see them on your monitor. Pick ACEScg on a non ACEScg monitor, and it will introduce bias/skewing depending on which colorspace you are viewing things.
And the actual ODT/RRT of aces1.2 are already introducing a LOT of hue skewing with sRGB primaries only.
By doing that, you won’t see the color properly displayed in the color picker and the color you pick in it won’t match what you have in render.
And no, it is not about preferences. Even though at one point in the creative process colors are subjective to the taste of the artist, you have to setup things correctly 1st if you don’t want to have things bite you back further down.
2 Likes
Just want to put my vote in here that Blender should have ACES in its OCIO config by default.
I, like many many others, render exrs to composite externally and grade in Resolve. The filmic Blender is arbitrary and not standard for working in a color pipeline.
As far as the issues with ACES presented here it really mostly ONLY boils down to the out-of-gamut issue, which is not actually such an issue if implemented properly. If the input color spaces are correct, in other words all the color pickers and sRGB textures are read properly as sRGB (which can be flagged in OCIO too, if we’re trying to respect OCIO properly) you should not be inputting out-of-gamut values in the first place. AP1 also has the elegant property of basically representing pure wavelengths, so in theory not such a bad property to have for a renderer, and it’s wide enough that you won’t run into much limitations outputting for wider range displays (a future user should not be limited sRGB displays in my humble opinion).
Even if you have gamut clipped values, there are ongoing efforts with ACES to deal with that in a standardized way, ACES 1.3 has added some gamut compression and you can always do your own gamut compression in Resolve or with a look. But in actual practice if things are input in the right color space the case of actual gamut clipping should be very rare since you should almost never be inputting those values almost never see them in the real world outside of LED lights and lasers.
Simply saying “well just download the ACES config and use that” is not a good answer. By default the full ACES config has an insane number of color spaces that Blender’s UI is simply not designed to handle, the menu goes completely off the screen, and there are a lot of redundant and confusingly named spaces. Also Blender and its tools are not setup to intelligently set those spaces. From what I understand OCIO 2 literally has ACES transforms built-in, the Blender team could simply make a config file with an ACES option using built-in transforms and file-rules/names that work best with Blender as-is and that would go a long ways from the jump. Hell keep filmic as an option too, but at least if people want to work in a standard color pipeline they’ll be able to out of the box.
And just to harp in on the discussion above, color-picking should be sRGB by default in my opinion. I don’t think artists should be messing with ranges beyond sRGB for input since pretty much all the texture programs are working with and producing sRGB colors and the standard output is sRGB. It’s good to have the potential of the AP1 colors for the render color space without exposing it for input where it will very likely be abused. There may be a case for using “wavelengths” though for more extreme cases with lights or lasers or something niche like that, but you should have to deliberately state that.
And as for film cameras and spectral colors, digital cameras also have spectral responses so I don’t know what the film comparison is really trying to say. In the end both digital and film are reduced into RGB primaries, that’s what we display. Every camera sensor and every film stock will have their own spectral properties, so you can’t really make blanket statements about capabilities. But at the very least if you work with different cameras they should each have their own ACES IDT you can use so everything is in the same working color space as a good starting point!
4 Likes