Blender Support for ACES (Academy Color Encoding System)

If you are just looking for wide gamut rendering, check out Spectral Cycles X branch, which covers the entire visible locus. And again, ACES does not solve the problem on wide gamut end, look at these spectral renders I posted:

Spectral rendering is the future, ACES doesn’t work well with spectral rendering (both AP0 and AP1 cannot be produced by mixing wavelengths so strictly speaking ACES does not work with spectral rendering at all. Though there are some algorithms trying to map it back to the closest point on the horseshoe locus before turning it to spectra, but why not use BT.2020 then?) Therefore, ACES is not future proof.

You can have ACES’ output transform by loading ACES’ OCIO config. My above test images were done this way. But again it produces broken result and the people that forces you to use ACES is very likely unaware of the difference bewteen TCAMv2 result and ACES result (I.E. show them TCAMv2 result and they won’t even notice that it was not ACES), so let’s use the better one.

That “trend” is what I mean by “if you are forced to use ACES”. If you are forced to use ACES just because downstream in your pipeline the other people are using ACES in their software, or you need to make a shot for a movie and all other shots were made with ACES output transform so if you use a different one it will stand out… This is kind of sad, and I feel sorry for this situation. If you are forced to use ACES, you can load the OCIO config and use it. ACES is having an OCIOv2 config with no external luts so some people’s argument about “ACES config being too large and needs Blender’s native implementation” no longer stands. The ACES OCIOv2 config is only 16.2kb in size. But still, it produces broken result, so don’t touch ACES if you don’t have to.

2 Likes

Here I made a wide gamut render with Spectral Cycles today for you (the EXR file is encoded in Linear CIE XYZ D65, you can just import to Blender and in the colorspace setting select XYZ):

Here is what it looks like with AgX Punchy Look:

Character copied from Blender’s offical demo file for pose library.

Here is ACES output Transform version for comparison:

Here is the CIE XY plot to prove to you this is indeed wide gamut:

If you want to know how it feels like to work with wide gamut renders, here you go, do some experiment, and have fun.

2 Likes

Thx for taking your time to make an example and usage guide, yes I can see in this case other output transform would be more suitable and natural, given the saturation of all ranges.

Having ACES as the defacto output transform definitely cause CG and Game makers to bias towards a certain set of pictures that make ACES shine the most. (high contrasted scene, which you see in all those AAA games and cyberpunk movies)

Though a question, if my working space is still rec.709 (eg. we sample the EXR in XYZ color space but we shade in linear sRGB), doesn’t the input transform already had to remap the gamut to sRGB range? So the rendering result we see is mostly due to final tone mapping, as wide gamut was lost at input stage?

Out-of-gamut values in RGB relative encoding becomes negative values. Negative values are tricky, very very tricky, because they are basically the values that the encoding model fails to encode, so relative to the context of that RGB colorspace, negative values are meaningless. But in a broader context, when you put it back to the absolute CIE XYZ model, we can say those negative values can retain its meaning relative to this broader context. But that requires future research to find a better way to handle negative values to turn them back into meanful values. Currently the most common way of handling negative values is to clamp it. AgX does it too.

One of the most challenging problem wide gamut brings to our table is negative values. You generally won’t have negative values if you are just working with Rec.709 all the time. When you try to use wide gamut, negative values will come for sure, because the RGB colorspace with the purest primaries possible is Rec.2020 (let’s not count ACES’s AP1 and AP0 because they are not possible) and spectral rendering can still render values outside of Rec.2020, so simply making the triangle larger is not going to solve the problem.

More about the aspect of negative values I am going to refer to @troy_s 's post in a Blender Artists thread:

1 Like

Hi guys, just want to add my 2 cents to this topic.

As someone who does Minecraft rendering, Filmic is normally pretty good. However, I find that ACES looks much better (in my opinion at least) compared to Filmic with High Contrast, though I can’t place my finger on why it looks better.

I would love to see native ACES support in Blender, it avoids issues with configuration and keeping false color for measuring exposure intensity.

The reason why you would feel ACES look better really depends.

First did you make sure the color inputs are all BT.709 across your comparisons? If you use ACEScg as input with ACES output transform, what you are seeing is the clipping of the more saturated parts.

If you made sure your inputs are all BT.709, then what you are seeing might be the darker contrast that you might feel “punchy”, or the hue shifting (skewing) that you cannot control at all.

It is a strong look that you might feel “punchy” at first glance, but it really is just clipping/skewing and your creative freedom would ultimately be limited by it.

__

Honestly speaking, I would say this: both Filmic and ACES suck, let’s stop arguing for ACES vs Filmic and let’s move on to something better.

Let’s stop comparing two things that are for sure not good enough, let’s focus on the more future-proof things available.

People sometimes mistaken me as a “Filmic defender”, no, I am here to say “Yes, Filmic sucks.” On the Rec.709/sRGB side, Filmic view transform has Notorious Six hue shift (skew), it is glaring and ugly. On wide gamut side, Filmic actually doesn’t work for spectral rendering, I believe it’s safe to say that Filmic is not future-proof. Filmic needs to be replaced by something better, I think everyone agrees with this.

As I said:

This is an objective truth: ACES is not future proof.

For example the ACES view transform doesn’t work with wide gamut, as you can see:

Image Formation: ACES Output Transform
RGB Rendering Primaries: Rec.2020

This is Rec.2020, the RGB colorspace with the purest primaries possible.

Let’s see Filmic with Rec.2020:
Image Formation: Filmic - Base Contrast Look
RGB Rendering Primaries: Rec.2020

You can see that Both Filmic and ACES suck.

Let’s see AgX with Rec.2020:
Image Formation: AgX - Punchy Look
RGB Rendering Primaries: Rec.2020

You can see on first glance that this is so much better than Filmic and ACES. But upon closer look, you would see AgX is clipping the two greens there. I believe this is due to AgX not having better ways to handle negative values, AgX simply clamps them.

Let’s take a look at TCAMv2:
Image Formation: TCAMv2 - No Look
RGB Rendering Primaries: Rec.2020

Upon first glance this is so much better than AgX again, the two green stripes there are no longer identical and there are not hue shift(skews) whatsoever. This is due to TCAMv2 having some method to deal with negative values, if you manually clamp the negative, you end up with something similar to AgX.

Note, Blender’s color management is not yet ready for advanced negative value handling. As I tested, Eevee clamps negative values from wide gamut textures in the shading nodes with flickering when you move the viewport angle. Cycles CPU clamps negative values from wide gamut textures in the shading nodes while Cycles GPU doesn’t clamp them. I wanted to report the bug but without things like TCAMv2 shipped with Blender, I don’t know how to write the bug reproducing steps. I might report the bug in the future when the time comes, now it’s just too early I guess.

Although TCAMv2 is so much better, you can still see some clippings in there. I am not sure whether one of the the Looks that come with the none open-source TCAMv2 would have the solution to this, but since it’s not open source, it’s out of reach for me and I cannot test it.

There is another open source option: OpenDRT, but it currently does not have OCIO implementation. From my test in Davinci Resolve though, OpenDRT is as good as TCAMv2. If OpenDRT ever gets an OCIO version, it could be a TCAMv2 open source alternative.

And note that AgX was design to be a “bridging step towards something better”, for now replacing Filmic with AgX is the most realistic option.

Let’s stop asking for the ACES output transform, and let’s stop arguing “Filmic vs ACES”, they both suck. Let’s look at the future, look at AgX, and the potential OCIO version of OpenDRT (TCAMv2 is only a testing option for us. Since it’s not open source, we cannot ship it with Blender). I would say first get AgX’s development done and let’s replace Filmic with AgX first. And along the way, this will expose many more color management problems Blender has, let’s make sure we make bug reports and let’s hope for a brighter future. (For example AgX needed the OCIO v2 aliases feature and now 3.2 has fixed the aliases bug.)

(A friendly note, if you think AgX with none Look is too grey, try using the Punchy look. And Apearance views are just the looks baked into the view for compatibility with other software that don’t support looks, so when you use the Apearance views, make sure you are using none Look, otherwise you would see posterization)

EDIT: My version of AgX now comes with more improvent, welcome testers:

6 Likes

Interesting, AgX looks cool

I’ve noticed there’s a few branches with more recent commits, which branch should I download?

I think you can try out the main branch. Other branches are not yet user-ready.

AgX looks really good, I think I might continue using it

I think adding ACES to Blender (for people that need it for their pipelines) and replacing filmic with AgX would be a wise move. I can’t go back to filmic after seeing this:
AgX

Filmic

6 Likes

I agree, Filmic also lose differentiation and clarity in highlights when u make high contrast, but Agx still has differentiation of highlight intensities,

I made a new ACES config for Blender. I made a thread about it at Blender Artists:

Here’s the summary of what I did:

  • I deleted over 300 of color spaces that are useless for most Blender users. I left 28 color spaces that looked marginally useful, even though I have a hard time trying to imagine use cases for most of them. You really only need 4: Utility Raw, Linear, sRGB Texture and ACEScg.
  • I deleted the LUTs that were no longer required to make the setup smaller. The remaining LUTs are still 237 mb unpacked, though.
  • I hid most Output color spaces. They are used only in view transforms now. If you want them back, change their “family” attribute from display to Output.
  • I kept the view transforms in case anyone needs them.
  • Most importantly, I made the config use proper Blender’s roles.
  • Changed the default roles so that HDR environments are assigned the Linear sRGB color space on import. This means, however, that if you import actual ACES EXR textures they will also use the Linear sRGB color space. Change to ACEScg or whatever your color maps actually are.
  • I also made it so that sRGB Base Color (non-EXR) textures are properly assigned the “sRGB - Texture” color space on import.
    Roughness, normal and other non-color maps seem to be importing properly as raw data.
2 Likes

Hi,

that’s funny.
My OCIO differs only by color picking in ACES and adding (what I forgot):
!< ColorSpace >
name: Input - ADX - ADX10

Plus I was to lazy to kick out all the unused Luts.

But I’m still wondering what the ACES 1.3 version brings, if Brecht isn’t quicker.
But always the same problem. The people who have knowledge of ACES and such, miss out on knowledge in blender AND vice versa… :frowning: :slightly_smiling_face:

But this OCIO setup we use, works very well for me since Blender 2.93.

Hello!

Well, I guess It’s a good thing we came up with the same config, It gives me hope I didn’t get something horribly wrong.

I’m really not sure which color space I should use for the color picker. I tried changing it around but I don’t see much difference, or more likely I don’t know what to look for. Can someone explain it better?

I used a simple python script to check which lut files weren’t mentioned in the config and then deleted them.

It looks like ACES 1.3 is mostly bug fixes. And what do you mean about Brecht? What’s he working on?

Edit:

I tested the color picker some more, I’ve tried
ACEScg
sRGB - Texture
Linear - sRGB
Output - sRGB
And they all look consistently wrong. I can’t pick a color in the texture paint mode with flat shading and paint it back.


Here’s how it works with the default Blender (Filmic) settings:

The texture is ACEScg EXR, by the way.
The same test with AgX:

@Nurb2Kea
Can you please do the same test with your config when you have the time?
Here’s the blend file I use for testing:

If the color picker works properly for you, would you mind sharing your config.ocio file?

Hi,

when rendering and working in ACES it makes sense to have the color picker the same!
The view transform is still RGB, but we change the color profile for each image etc. so you work with ACES color picker.
Brecht said in one of the forums here or on blenderartist that he is looking into it and already changed some ACES things in blender, but I can’t remember where exactly. So they are aware of ACES, but will take some releases until it maybe comes to blender as we would like. (like light linking…)

Oh, I see. There are color spaces introduced in 3.2 that make it possible to import ACES textures properly, but they still look off in Filmic. I thought that’s what it was about.

Regarding the color picker, I’m absolutely confused. It samples correct colors if you use the S hotkey in texture paint mode, but if you use the eyedropper icon from the color picker pop-up palette, the sampled colors are all wrong. It looks like it’s hardcoded or something. I tried setting the color picker both to ACES - ACEScg and Utility - sRGB - Texture, same results:

From what I experienced with blender 3.0, when i were using sRGB as picker it wasn’t working, but with the later versions 3.2 -3.4 it works. But these are mainly alphas or betas or just released with corrective updates missing.

And that they are both picking the same color means it’s correct.
You need an ACES ( wider color room) image containing a color that can’t be displayed in sRGB.
When using the picker with an sRGB picker setup, you should get an odd value.

Because you’re working in ACES but your view transform is showing you sRGB…
If I’m not totally wrong ! :slightly_smiling_face:

I did some more testing. It looks like the color picker in the node editor is working properly.
It is affected by the setting in the config file. If I set the color_picker role there to ACEScg, it becomes linear. If you set it to sRGB it becones non-linear.
ACEScgsRGB
In both modes, however, the node editor color picker always samples correct values from the viewport.

The texture paint color picker, on the other hand, always stays linear. And it always samples wrong colors from the viewport. It samples the right colors from the Image editor, though. A way to sample correct colors in the texture painting mode is to use the S hotkey. That seems to be working perfectly no matter what.

Is the texture paint color picker just poorly implemented? Can someone more knowledgeable explain this?

3 Likes

Yes I agree, supporting something extra doesnt make any bad, but in devtalk, people keep going against supporting even extra things when noone wants to remove old alternatives.

I fully agree with you when someone try to harshly convince or insist and ignoring the points u make and telling other things or giving wrong alternative/ or no alternatives to prevent any advancement or new additions instead of compromisising or finding middle way but turning into ego-fights just by throwing their own technical details. Devtalk usually turn into a quarrrel instead of being respectful to new ideas and finding middle way. Rude words is not acceptable. There should be some rules about constructive actions and being over-reactive to new additions

1 Like

He’s explained it more times than he can remember and since people don’t fully grasp his points, and still refute strawmen, he eventually got tired of that.

Even worse, people that hasn’t read what he’s written about the topic all over the internet expect him to explain things again, that’s not how it works specially in such a technical field.

2 Likes