Blender Support for ACES (Academy Color Encoding System)

[nanoSpawn]

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.

[nanoSpawn]

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.

[Pauan]

@nanoSpawn

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.

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.

@nanoSpawn

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.

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.

@nanoSpawn

ACES requires tons of things, is not enough to just use a display, you also need to setup textures colorspace.

Yes, but all of that already works just fine in Blender:

• If you’re using RGB textures you just specify Utility - sRGB - Texture in 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.

@nanoSpawn

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.

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.

@nanoSpawn

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.

The correct thing to do is to just use the OCIO environment variable.

@nanoSpawn

What Blender needs is a better and easier way to handle Ocio configs and work with OCIO.

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).

@nanoSpawn

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.

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.

[nanoSpawn]

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.

[kurk]

@nanoSpawn

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

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.

[troy_s]

@g3ntile

There’s no ACES support in Blender, and never will be.
Never. Ever.

For the 15th time, no.

ACES is ACES. There’s nothing to “support”. Go install the official repository for OpenColorIO and done.

@nanoSpawn

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.

Read this quote above. Someone who is sane and understands what has been communicated many, many times. Read their whole post.

@Pauan

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 ).

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.

@Pauan

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.

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.

@Pauan

And if I create an asset for one game engine and then port it to a different game engine, it will look the same.

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.

[nanoSpawn]

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.

[kurk]

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.

[troy_s]

@kurk

It would be nice if ACES can be used across multiple studios in the same way to get better image consistency

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.

@nanoSpawn

Because technically is not a color standard.

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.

[g3ntile]

@troy_s

There’s nothing to “support”. Go install the official repository for OpenColorIO and done.

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.

[Pauan]

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.

[Nequine]

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/

[Pauan]

@Nequine

As you should not pick ACEScg primaries anyway.

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.

@Nequine

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.

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).

[Nequine]

@Pauan

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.

You usually use the colorspace you display in. sRGB/REC709/DCIp3/REC2020 are the one you should select, not acescg.

@Pauan

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.

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.

@Pauan

You can use color_picking: lin_srgb which is the same as color_picking: Utility - Linear - sRGB

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.

@Pauan

I found that it doesn’t work as good as ACEScg, but it’s up to your personal preference.

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.

[Adeci]

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!

[kurk]

Do you mind explaining the steps you take in Blender and in Resolve for your ACES workflow?

[Adeci]

Sure, although currently I mostly use other applications for the final renders, but in the future I would like to keep it all in Blender (it would simplify so much!).

If an ACES OCIO config is set in your environment variables then Blender will use it. Make sure your textures are set to the correct color spaces (something like srgb_texrure for color or raw for data) and render an exr (the ACES convention is 16-bit half-float RGB). There shouldn’t really be much more to it, it should be like working in filmic currently just more standardized across applications.
Bring it into Resolve, set the clip input color space (probably acescg) and make sure Resolve is set to use ACES in the project settings (generally acescct to work in and output sRGB). Then just do what you normally do in Resolve to get the final look you’re after. You could even export your look as a lut or something and apply it as a look in your config file, so you can preview even closer to the final result in Blender (can even use variables in the config if you want to set per-shot looks, which is common in real productions that get looks from set, although I’m not currently doing it). End of the day what’s nice is all of it is really just for your viewport experience and getting the best preview to work with that’s consistent across applications (so you can properly light and color things and know what you’ll actually get in the end), the exr you render is still the same regardless.

So in summary it shouldn’t be much more complicated than rendering exrs like you normally would, and the viewport will display with the ACES RRT applied so you can work knowing how it will look in Resolve also. A good simplified config file that comes with Blender and is designed with names Blender uses would be ideal, but right now everyone is either doing their own thing or using the full default one which is just awful to work with. Having to go through hundreds of textures and babysit their color spaces any time the config changes is not ideal, and it’s even worse when you can’t actually see all the color space selections on the screen and you have duplicates with ambiguous madness (the generated ACES config REALLY should not be the default config users are expected to use, hence me coming here and requesting Blender be the one to update their default config to add an ACES alternative to filmic that works seamlessly).

The current vfx reference platform is OCIO 2.0 and ACES 1.2 with 2.1 and 1.3 respectively for next year, so things are moving along and getting ironed out. Like I said I’m pretty sure they’re including built-in ACES transforms in OCIO now, so you really just need a good config file. Other renderers like Redshift and Octane have already incorporated an ACES default with OCIO 2.0 and the Redshift config is already using the built-in ones.

[Adeci]

Just to make things clear ACES is not trying to be some perfect color space, that’s not the point. The point of ACES is to be a STANDARD color pipeline, and with that comes compromises. Those compromises are necessary to keep ACES as simple and transparent as possible while covering all the major bases.

We could argue all day of what an ideal color pipeline looks like (and based on the length of this thread it looks like people have), but that’s missing the point. ACES was designed with its compromises in mind, they are intentional. Sure storing 16-bit half-float linear RGB is not the most efficient way to store color, but it is unambiguous and ubiquitous. Sure they could use something more efficient like YUV, some integer encoded log, but those decisions would add complexity and ambiguity. 16-bit in theory has plenty of precision as long as you’re not abusing your values in the grade or using finicky luts, it’s 10-bit with a 5-bit exponent.

The RRT is not meant to be your final “look” (unless you want it to be). It’s more like having default safety rails to make sure you’re not viewing clipped values and always working under some standard film curve. Typically I go for a film emulation type look, and I would make sure it looks the same with or without ACES, but I still work under ACES and the RRT rather than completely going off and doing my own thing because working under a standard is generally better. Even without the look applied you’re at least in the ballpark of something you can work with and you have the input and output benefits of the ACES standard being standard.

[troy_s]

@Adeci

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.

This is completely false.

It has everything to do with not being a management system. It doesn’t work.

@Adeci

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).

This is also completely bunko.

The AP1 primaries are a stimulus based specification, and literally are bogus non-existent rubbish stimulus values that have no basis in real radiometric electromagnetic radiation. RGB rendering is stimulus rendering to begin with, and will always attenuate vastly differently to a closer-to-spectral model. There’s simply no comparison.

And the problems with ACES are far greater than simple gamut concerns. The very mechanics are broken, and again, it isn’t a colour management system as a result.

@Adeci

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.

This is more rubbish.

The fact that the working stimulus space is vastly larger than the destination is indeed a solid chunk of the problem, compounded and made worse by per channel lookups that distort the stimulus entirely.

While important, it’s only a portion of the broken output that ACES delivers.

@Adeci

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.

It is saying that the creative film response informed a century of subtractive based image making, building atop of thousands of years of subtractive based painting. If one doesn’t quite understand the difference between additive stimulus projection and the mechanic that forms the image versus the subtractive model, it is worth looking into.

@Adeci

ACES was designed with its compromises in mind, they are intentional.

Nope. Plenty of the dozens of problems with ACES were accidents. Follow the history.

Worse, it imbues work with a rather hideous digital RGB based aesthetic that is entirely unavoidable without doing as the majority of things that “use” it do; invert the output transform in an attempt to negate it.

For more information, it’s worth reading Chris Brejon’s piece. It specifically covers how the number of productions that have used ACES is completely erroneous. Further, some studios mandate an ACES interchange, and as such, great effort has been enforced to work around it.

[Adeci]

@troy_s

It has everything to do with not being a management system. It doesn’t work.

I mean it DOES work and plenty of high end studios use it or variants of something similar to it. I would be curious what exactly “doesn’t work”.

@troy_s

The AP1 primaries are a stimulus based specification, and literally are bogus non-existent rubbish stimulus values that have no basis in real radiometric electromagnetic radiation. RGB rendering is stimulus rendering to begin with, and will always attenuate vastly differently to a closer-to-spectral model. There’s simply no comparison.

The AP1 primaries are at the edge of the color locus which represents the response to pure wavelengths, so yes the AP1 primaries can be represented as pure wavelengths and no other combinations of wavelengths will give the same result so effectively that’s what they are.

A pure spectrally based color science is currently completely infeasible and is pretty pointless to talk about, and would make no difference (at least for representation of final images) for petty much every existing display type. For the rendering itself, sure, there is a case to be made for working spectrally. But there are currently no standards for how to handle that and it’s well outside the scope of ACES to define what that kind of change would look like. ACES is primarily a pipeline for interchange with existing software and color science, defining it spectrally would break compatibility with pretty much every software and require completely new ways of representing color digitally (almost all software, including renderers are RGB, and even when they represent more wavelengths internally they’re still mostly taking RGB input, interpreting that, and creating an RGB output).

CG work is also not the bulk concern of ACES. CG work is an optional part of the film pipeline, and the bulk of production would benefit even less from being spectral while making everything much more complex. Like I’ve said ACES is an effective compromise that is meant to be practical given the current state of things, not some “perfect” ideal.

@troy_s

The fact that the working stimulus space is vastly larger than the destination is indeed a solid chunk of the problem, compounded and made worse by per channel lookups that distort the stimulus entirely.

You only very rarely encounter colors outside of sRGB in the real world, mostly coming from light sources with narrow bands of wavelengths, which tend to be rare unless you’re working with lasers for some reason. Even my example with LEDs is unlikely because even LEDs aren’t super narrow wavelengths. So while AP1 is indeed larger, in practice you should not be working anywhere near the extremes in the first place, and if you are that’s on you. But if for some niche reason you have to, some basic gamut compression should be enough in most cases, and I even think new ACES versions are doing some of that. If you have an actual example (done properly) that counters that I’d be curious to see it.

@troy_s

Worse, it imbues work with a rather hideous digital RGB based aesthetic that is entirely unavoidable without doing as the majority of things that “use” it do; invert the output transform in an attempt to negate it.

For more information, it’s worth reading Chris Brejon’s piece. It specifically covers how the number of productions that have used ACES is completely erroneous. Further, some studios mandate an ACES interchange, and as such, great effort has been enforced to work around it.

I’m already familiar with the Chris Brejon piece and it still does not discredit the value of ACES. He has an insistence on how colors resolve to white, but that also requires more complex color transformations. The RRT is not to everyone’s liking, but yes if you want a very specific look then go ahead and do it with the inverse RRT, no one is stopping you. Or if you’re really that strongly opposed then use something else for final output, not everyone is going to be happy.

But for the most part standard criticisms about the RRT (like the contrast and shoulder) can be resolved in the LMT. The RRT is not the end all be all look, it’s more like a safety and standard and in theory should have minimal “look” (obviously people will disagree on that). The look itself is up the the artist but that doesn’t remove the fact that there has to be something to compress the wide range of scene values, and the RRT has plenty of reasons behind it. We could argue about the RRT all day, there’s a level of subjectivity to it, but it’s not really meant to be your final look anyway and hyper focusing on the look of it is sort of missing the point of ACES.