Blender Support for ACES (Academy Color Encoding System)

[Illasera]

Explain it to me in simple words, Why exactly " Blender desperately needs it"?

Scroll up, you already have configuration files that let you change color management, Hell, its in the video above me , what blender needs, is a better way to change and support color managements without playing the copy paste files game into the right directory.

And please stop shoving this broken color management model onto people because “Everyone else are using it”, if everyone else would jump off the roof, feel free to join.

And for the love of god, addressing ACES as color management and not as a way to transfer data around:
VISUAL ERRORS ARE NOT AN ARTISTIC CHOICE.

an artistic choice of colors is whatever the artist chooses and if lights are involved, keeping the color accurate without going haywire, bad lighting and coloring as a result of a bad color management is a SIDE EFFECT, NOT AN ARTISTIC CHOICE.

*Disclaimer, at some point all color managements we have today will reach some issues if you push lights hard enough, but some methods are BETTER than others.

[JuanGea]

@Illasera I agree with your main points, but there is a fact that cannot be ignored, and we’ve been recently in this situation:

When you work for a production as part of the pipeline, doing some VFX in Blender, you have to adapt to the production pipeline, and that means several things, but in general the most important thing is to deliver frames in ACES, we’ve been working for a Netflix production doing some VFX and ACES was not an option, it was mandatory, to be honest it was very easy to enable it once you know how to do it, and you don’t need to “break” filmic for that, just to use a .bat or .sh to run Blender with an environment variable that points to ACES.

But in any case, even when I think Filmic is way more correct, I also have to say that out of the box the visual results and the colors that come out of ACES where the ones required by our client, and in some other cases I found it to be a bit more vibrant and easier to work with by many artists.

• Is it broken? No doubt it is, I know it for a fact and it’s fully broken in some situations that are not as “corner” situations like the corner cases you can find for FIlmic.

• Is it a requirement for some projects? It is, full stop.

So in the end it could be nice to have ACES as a color management option (or an OCIO config option in settings) without breaking textures color management for example, right now for us I had to modify ACES 1.3 to ensure it auto recognizes the basic texture color management configuration and the filmic scenes are correctly loaded when we open them for the first time with ACES (for example using a filmic ready asset with ACES), but could be great if this could be made in both directions to make it easier to go from one to another, because once you have things configured in ACES you have to manually go back to filmic, so reconfigure all textures color managements.

Scenes are not so important, it’s just a setting, but textures are a pain.

So in sum, two situations here that I think are good reasons to have ACES as an OCIO config in addition to Filmic, officially in Blender:

1.- It’s a project requirement in many situations

2.- Having it natively will make easier to go back and forth between both OCIO configs.

The choice is not always in the artist hand

[Eary]

@JuanGea

but textures are a pain.

Try Aliases. It is OCIOv2 new feature that Blender supports from 3.2 and on, basically one colorspace can have multiple names, meaning the texture colorspaces can still be recognized as long as both old and new names are defined to be the same space in your new config.

[JuanGea]

Yep, that’s what I used in the ACES 1.3 config, I added required aliases to make it to recognize proper color space for textures coming from filmic and it worked great, but the other way around has to be done in the Filmic OCIO config, so every time I get a new blender version I would have to be modifying the filmic config.

That’s why I mean that the ideal situation is to have both OCIO configs in Blender and to have them to be as compatible as possible with aliases.

[EAW]

Built-in Configs

The OCIO Configs Working Group has put a lot of effort into building new ACES configs that take advantage of the features of OCIO v2 and that are informed by the learnings from the previous ACES configs. The new configs are available from the project’s GitHub repo: OpenColorIO-Config-ACES
To make them easily accessible, they are built in to the library itself and may be accessed directly from within applications that incorporate the OCIO 2.2 library.

For Users

Wherever you are able to provide a file path to a config, you may now provide a URI-type string to instead use one of the built-in configs. For example, you may use these strings for the OCIO environment variable.

To use the aces_cg, use this string for the config path::
ocio://cg-config-v1.0.0_aces-v1.3_ocio-v2.1

To use the aces_studio, use this string for the config path::
ocio://studio-config-v1.0.0_aces-v1.3_ocio-v2.1

This string will give you the current default config, which is currently the ACES CG Config::
ocio://default

In future releases, it is expected that updated versions of these configs will be added, each with a unique name string. However, the previous strings will continue to be supported for backwards compatibility.

Link to 2.2 release notes

---

As an example, creating a .bat file with the following will start Blender 3.5 using the ACES studio config:

Set "OCIO=ocio://studio-config-v1.0.0_aces-v1.3_ocio-v2.1"
START "Blender 3.5.0" "C:\blender-git\Release\bin\blender.exe"

[Illasera]

You pretty much went through all my pitfalls arguments.

1.)I didn’t mention in my post “Filmic” on purpose , because color management choice is up to the target medium and the “LOOK” of it are up to the artist, knowing that, i wrote that “All color managements have issues but SOME are better than others”, and you went to talk about the visuals while the discussion on why ACES is broken is pronounced in the visuals but it is a technical issue.

there are other color managements and matching looks for them.

2.)I wrote that i am not talking about ACES as a way to transfer data, you went and talked about ACES as a way to transfer data in the industry.

3.)Your point and that is the same point of EVERYONE else who made pro-ACES usage post here, is not that you are not getting ACES support but its that you are not getting it in the way you want, you want an easy button click from blender and not mess around with configs,

Whatever the solution is , blender must be color management agnostic, that means, no native support for it and no shipping of config files, if blender were to ship ACES config files within their release packages, that means they support it, they don’t and they can’t, they can only support what they have produced, the rest is up to you.

[Nurb2Kea]

Use chatGPT to write you guys a python script that swaps/exchanges the luts folder and ocio config of your choice with the one from vanilla blender.
If you do it right you can use any color room available.

That’s what I did.
I let the cycles cache and blender build folder be deleted, compile blender & exchange the color room files and folders.

Also here in the chat are any color rooms listed that can be used.
What you choose is up to you.

This way it’s quick and easy switched to whatever you want.
All that ‘looks’ is usually a thing for post.
I render everything in the biggest color room available, what gives me the most options/range in post,
dependent of what the post application uses.

So grab your favorite color room luts and configs, goto chatgpt and ask to generate a python script to do all that.
Took me 15 min. without coding knowledge.
Now I run this script, and everything is fine and working without any hassle !

EDIT: Also the ocio config also alows to change how different files are getting handled…
So what color space get’s applied when importing images etc…
(Just keep the coding syntex to not break the ocio.config file)

[JuanGea]

I disagree with your view of my message, it seems to me that you felt like I was going against you, I’m not, I understand your points but here is the thing for each point you mention:

1.- There can be many color managements, but in vfx/animation 3d production ACES is what is being used in general, and in the Blender sphere Filmic it’s what is being primarily used, and that’s why I mention them, and yes, I talk about the visuals because the people who in general use them are artists, not color technicians, and what they see is the feedback and the result of their work, they don’t understand the technicalities, so visuals play a big role in all this, be it technically correct or not.

2.- It’s not only about transfer data, is that it’s not the same to lit an scene with ACES enabled than to lit it with Filmic enabled, you have to fully change the configuration, color, etc… just changing the color, and you can “transfer data” because you have to send your outputs to the compositors, but if you have worked with FIlmic and the comper is working with ACES the result is totally different and the shading, lighting and render people will be crazy with the comments of the comper becuse they don’t see the same thing, Once again the visuals are important, we work with visual results, and we have to be in sync, no matter if you send a full float exr without color management enable,d the result will be different if you use Filmic in Blender and ACES in comp.

3.- You cannot do that, basically because Blender is a program used by a wide variety of users, seasoned pros that understand the technicalities of Color Management, new users that know nothing about color, and mid/advanced artists that want just this to work (think of Corona render users for example)
Why delivering ACES + Filmic is a good idea IMHO? Because you give the wider groups of users to generalized options, one more correct than the other, one delivers one aspect, the other delivers a different aspect, from that we can say that in Blender should be way easier to change the OCIO config, at least from preferences, I agree, but you cannot release Blender without any color management because you will end up people using standard like in the old days, which is horrible in general.

We can talk about Blender being color management agnostic, in for the most part it is agnostic, you cna use Filmic or use ACES, nothing changes, apart from the oiptions you have in the color management slots where this goes.

Should you support ACES or Filmic? Well, in the end it would be beneficial to deliver both together and have the option to change it, in the same way we have OpenVDB or Alembic or many other libraries.

Using aliases in filmic and ACES versions that come with Blender so you can avoid a headache to users it’s nothing capital or dangerous, you are just helping users that know little about this, and there are many iusers that now little about this.

So I’m not pro-ACES or pro-FILMIC, I’m pro-REALITY, and this means that ACES is what it’s used in part of the industry and you may be forced to used it like it or not, there are other color managements configs? yes, are they known by general users? nope, do they have a thread here? nope, so in the end, to benefit end users, delivering FILMIC and ACES is a good idea, being broken or not, it does not matter.

About the support, the blender team has not produced Alembic, or OpenVDB or other libraries, so IMHO the idea that the Blender team can only support what they have produced is not correct, Blender has many things that have not been produced by the blender team, and they support them as long as Blender is compiled with the library they use, this is not different with OCIO configs, in fact it’s way easier, since it’s just an OCIO config, not even a compilable library that has to be 100% compatible with the code users, it’s just a config.

[JuanGea]

@Nurb2Kea you cannot do that in a production team, the solution is to use the environment variable with a blender launcher and point the ocio config to the folder where you have the config you want to use.

Things are very different when we talk about freelancing or a very small team, than when we talk about team management, production control and pipeline control.

[JuanGea]

@EAW that is exactly what we are using

It’s a good way to go for the time being, but the correct path would be to have a setting in Blender that we can configure what OCIO configuration are we going to use, and have to defaults that we can change, FILMIC and ACES.

Non technical users find complex even the idea of having a .bat doing this, linux users sometimes find it weird too, and better not talk about mac, because things there are a bit more complex for artists in this regards, so, a setting in settings that takes effect in the following blender startup, and bringing both configs within Blender it’s good

[Illasera]

I figured at some point, someone would make the argument about 3rd party DLLs and python scripts, and that the blender foundation can’t write all of it , which is true, they have to use tools by others, but these are technical tools , while supplying a color management config can be considered a visual element.

a bit odd that you mentioned the following : “you will end up people using standard like in the old days, which is horrible in general.”
Here is an example for you, What if i want to have a scene that is unlit (Not affected by lights) and cartoon like style? you can bet i am going to use “Standard”, i think its the right tool.
while it can be bad “In general” as you mentioned, its great to have that option.

for other scenes, i think “AGX” and “TCAMv2” (with looks provided by the user) are the right tool, sometimes, for photography / realism aesthetics i may use “filmic”

so i do agree with having a variety for color management, my issues stem from the delivery system and the “Appeal to noobs” argument that i dislike,
Modeling is a hobby for me but it does not dismiss me from learning the technicalities, in fact you should FORCE people to learn these things instead of attempting to appeal to them, some youtuber or influencer should make those topics “Cool and popular”.

I got to read into the whole topic of color management and color theory in general because things didn’t work out the way i wanted them to look, so to resolve the issue, i had to START learning about the issues i was facing (these are massive topics) but it only helped me in self improving, knowing why colors and lights work the way they do and what are their limitation on both software and hardware sides (I think that having issues of things not working out of the get-go helped me in the long run).

[JuanGea]

@Illasera

Here is an example for you, What if i want to have a scene that is unlit (Not affected by lights) and cartoon like style? you can bet i am going to use “Standard”, i think its the right tool.
while it can be bad “In general” as you mentioned, its great to have that option.

Of course!

I never said to remove standard, I said to give options
We use Standard for cell shading, way better than any of the other two

@Illasera

it does not dismiss me from learning the technicalities, in fact you should FORCE people to learn these things

Here I disagree, you should not force anyone, and in some situations you need a starting point to teach things, and sometimes color management is one of the most complex things to teach and learn, so you start for someething “simple” and in a more advanced moment you teach more technical things, that are easier to understand when you have more artistic experinece.

I’m all to include other options in case they are sufficiently evolved, I’m not sure about the status of AGX, and I don’t know TCAMv2, but in the end the key is to have the option to easily change the OCIO configuration and to provide at least these two, or even change Filmic with AGX since AGX is basically new and better (theoretically at least, I have not tested it yet)

But you need to provide a basis for artists to work with, and to make it easy to change it, Filmic and ACES seem to me the most logical in this case

[Eary]

@JuanGea

I’m not sure about the status of AGX

@JuanGea

We use Standard for cell shading, way better than any of the other two

Think maybe I can mention this here, in my latest version of AgX, I have replaced the “Standard” option (used to be called “Display’s Native”) with “Guard Rail”, basically GR will do exactly the same as Display’s Native transform within the valid 0 to 1 range, once we go outside of that, we have chromaticity linear attenuation (the de-chroma to white thing) for above 1, and luminance correction for below zero. Basically a minimalist image formation option for people with the need. Darktable dev Sakari Kapanen helped us with this part of the development. But we are still testing so things are not settled yet.

[Illasera]

If that is the case, Consider renaming it to “Standard - Guard Rail” for the sake of clarity.

[Eary]

No, the name “Standard” was the one lacking clarity, the accurate name for it is “Display’s Native”, since it’s the native transform of the display device. Guard Rail is what it is, a fence before the cliffs (greater than 1 or less than 0).

[JuanGea]

@Eary I’m afraid that for cell shading the examples you show there are still not valid, the standard has the obvious problem you show in the image, but when that problem is not there the color you see in the image is 1:1 the color values picked by the artist, for example a corporate logo with corporate coded colors, however in the AgX example the color is a bit shifted, its not exactly there.

I know the technical reasons behind this, and it’s probably correct, but from an artist perspective in cell shading the majority of the time is easier to control the color manually if you have the exact values.
The thing is that in cell shading light don’t affect in the same way as in path tracing and you have direct coloring control over the lit and shadow parts and other details, so AgX may be a better implementation, and easier to work, than fimic, that I don’t know, but for cell shading I know that artists will want to keep using standard unless the first picture is 1:1, right now it is similar, but it’s not 1:1

[Illasera]

Yes sir, I understand that; but once again i will push on it further, You can’t make up names as you go, even if it does serve as a safety guard, we are not familiar with that term and since you are using something that already exist, name it as such and add “Guard Rail”,

I read your goal with “Guard Rail” in the previous post but others probably didn’t, so we need to make sure its clear to them as well.

If you think “Display’s Native” is more accurate , name it such and add “Guard Rail” to it.

[Eary]

@Illasera

If you think “Display’s Native” is more accurate , name it such and add “Guard Rail” to it.

Again, “Display’s Native” means display device’s native transform, in sRGB display’s case, we are talking about sRGB primaries and power 2.2 function. Name Guard Rail to be “Display’s Native” is not accurate, because it is not a pure power 2.2 function, and l said, it’s only designed to match “Display’s Native” within the [0, 1] domain.

@Illasera

You can’t make up names as you go

I don’t see why I can’t, Guard Rail again is another specially crafted image formation, just like AgX, if we can name AgX to be “AgX”, I can’t see why we can’t name Guard Rail to be “Guard Rail”.

@JuanGea

but when that problem is not there the color you see in the image is 1:1 the color values picked by the artist

It is designed to be 1:1, if it’s not in your tests, there can be two reasons that I can think of:

1. LUT resolution issue.

This one is hard to get right, you need to compensate for dynamic range vs resolution vs file size etc., the current state of the LUT is what I tested to be the best so far, but might change it in the future.

Regardless, the result is very close in my test, that I believe people should not be able to eyeball the difference. But please correct me if I am wrong here.

Let’s see… Tell me which one is Guard Rail and which one is Display’s Native:

2. It’s not designed to match the piece-wise sRGB function (like the one used in Blender master), but rather, the power 2.2 EOTF.

This decision is independent from Guard Rail, if we were to use Display’s Native, it will still be the 2.2 EOTF.

The reason for this decision was discussed here:

Feedback / Development: Filmic, Baby Step to a V2?

My understanding is, some monitors use piece-wise, some uses 2.2. If you use piece-wise file encoding with 2.2 monitor, you get crushed shadows , this was actually what the standard was designed for, crushing shadows for CRT monitor noise reduction or viewing condition etc. But this in today’s modern workflow is not longer desired, which is why using 2.2 is the modern choice, even if you encounter a piece-wise monitor, it would only lift your shadow a little. The risk of crushing shadows vs lifting shadows, I prefer lifting.

[L0Lock]

@Eary

@Illasera

You can’t make up names as you go

I don’t see why I can’t, Guard Rail again is another specially crafted image formation, just like AgX, if we can name AgX to be “AgX”, I can’t see why we can’t name Guard Rail to be “Guard Rail”.

You both right in a way, I guess it depends on the context. You are making a new thing, it makes sense to make a new name. When it comes to something people are already familiar to, it makes sense to use names they already know or maybe add a mention of the eventual difference, unless it really is diametrically different and should not be confused with what people would think it means with a standard name.

• “Guard Rail” : most likely will mean nothing to anyone unfamiliar with how colors work on a technical level - which i think is a lot of people. Just like “matrixes” mean nothing to many artists.
• “Standard” : most Blender users who have ever been in Blender’s Color Management Panel have an idea of what it is and means - even if they might be inaccurate or wrong about what it actually mean on a technical level. So it might be a wrong or stupid name, but it rings a bell to the mass.
• “Display’s Native” i think hits a middle ground ?

That was my two cents.

[Eary]

@L0Lock

“Display’s Native” i think hits a middle ground ?

Again “Display’s Native” is very specifically referring to the display hardware encoding, so not suitable here.

But if someone come up with a better name than “Guard Rail” it would also work I guess.