[Blender] Experiencing Broken Linear Rec 709 in ACES 2.0

[buckleysean2003 (Sean Buckley)]

Hello I’m new here, so I apologize if i get anything wrong but I was under the impression that the new Linear Rec. 709 (sRGB) was a replacement for Utility - Linear - sRGB, However, it produces the wrong colors in Blender 4.4, Is this a blender issue, did i author my textures wrong, or produced the wrong config. Weirdly I got ahead of this issue by using the ACES 2.0 config in Unreal Engine 5.6 which included the original Utility - Linear - sRGB colorspace. I do not feel comfortable using this frankenstein OCIO solution and would like something more official. I hope I don’t have more misconceptions because Color Management is already incredibly confusing lol.

ACES 1.3 Utility Linear sRGB/ACES 2.0 Utility Linear sRGB Unreal 5.6 config.

Versus ACES 2.0 Linear Rec 709 (sRGB)

[TooDee (Daniel Brylka)]

Hi Sean,

please check first if you get an improvement when trying the Blender 4.5 beta.
Blender 4.4 has a bug that is fixed in 4.5 with OCIOv2 configs.
https://projects.blender.org/blender/blender/issues/137598

This is not only happening with ACES 2.0, but also with ACES 1.3.

Best

Daniel

[buckleysean2003 (Sean Buckley)]

Sorry, it is still occurring in the Blender 4.5 Beta “blender-4.5.0-beta+v45.b6cccca6617c-windows.amd64-release” If you wish I could provide the UE5.6 config for reference.

[TooDee (Daniel Brylka)]

Yes, please do. I think this could be helpful.

[buckleysean2003 (Sean Buckley)]

drive.google. com/file/d/1nlLsC2SA9XxNSgADFYGnb3RGg8H93cDx/view?usp=sharing

Here you go, this config is used i believe in UE5.6 when you pass r.HDR.Aces.Version 2 when you want to use ACES 2.0 when you select ACES AP1 dev.epicgames .com/documentation/en-us/unreal-engine/working-color-space-in-unreal-engine

Moderators sorry I evaded the link rules, desperate times call for desperate measures.

[TooDee (Daniel Brylka)]

Thanks,

I am not familiar with this OCIO config, but it seems to me that the View Transform “UE” is simply not the same as the ACES 2.0 SDR view transform when reading the comments in the config.

The UE config seems to use linear-sRGB as its working colorspace whereas ACES uses ACEScg.

I would assume when you use the UE config in UE and Blender you would end up with the same results.
Hopefully, when using the ACES 2.0 config in both tools you should end up getting the same results too.

I am not sure what config you use in each DCC, so maybe I am misunderstanding your question.

[ChrisBrejon (Christophe Brejon)]

Hello

Looking at your screenshots and question, do you expect that they match ?

Because ACES 1.3 and ACES 2.0 have very different “algorithms” in their respective Output Transfoms.

Thanks !

[shebbe (Shebanjah Klaasen)]

I think @ChrisBrejon is on to something. Looking at that UE OCIO config it is an OCIOv1 config and it doesn’t look like it has neither ACES 1.x or ACES 2.0 output tranfsorms, only UE’s “filmic tonemapper” which was based on ACES 1.0 output transforms.

AFAIK UE’s own tone mapper is not updated to reflect the rendering of ACES 2.0’s output transforms (unless they specifically said so in a recent release?). So presumably if you need a spot on match, you have to use the config you shared here which emulates how UE’s tonemapper renders. Or use an ACES OCIO config instead of the built in tone mapper in UE5 and then use that same config in any other application in your pipeline.

Regardless, it’s likely that the above is the issue rather than the Linear sRGB/709 color space definition.

[buckleysean2003 (Sean Buckley)]

Okay let’s take a step back because I think either I’m confused or I’m being misunderstood, I was under the impression that the Linear Rec 709 colorspace was supposed to be identical or near identical to the old Utility Linear sRGB space, not that the output transforms are identical. this was in the blender texture viewer not in the viewport. example ACEScg 1.3 and UE config, both have matching colors in the texture viewer but their output transform are different. With the UE one being less agressive than ACES 1.3. Maybe I’m misunderstanding how output transform work, but what I was expecting was simply that upgrading ACES 2.0 would wash out my renders somewhat and not break my textures.
another is example OpenDRT, Rec 709 with sRGB display device doesn’t break the textures. It’s different to ACES 1.3 but the differences are not that extreme that I would be forced to reauthor every texture.

[ChrisBrejon (Christophe Brejon)]

I think I understand better now. This is an interesting case.

Let´s see if I got it right :

• You are “fine” with an expected change of “look” between different Output Transforms (more or less contrast or “washed-out” for instance).
• You are concerned about a possible broken “look” with ACES 2.0.

By “broken” you mean the high contrast and saturation on the ears for instance ? I am not a texture artist, so I just want to make sure I follow you. Basically what do you mean by this :

@buckleysean2003

somewhat and not break my textures.

Is there any way you can share this ex or even just a crop of the ear ?

Thanks !

EDIT: “Utility-Linear-sRGB” and “Linear Rec709” should be the same, yes.

[buckleysean2003 (Sean Buckley)]

Thank you for trying to understand, but basically it’s less that it’s a broken “look” or output transform it’s more that the texture colorspaces themselves have been broken with the changes in ACES 2.0, when I posted the UE5.6 example, I was under the impression it was based on ACES 2.0 because of the commit log on Unreal Engine GitHub. So I thought something was broken on the official ACES config side. The UE5.6 output transform is different from the ACES 1.3 ACEScg, yet the texture remain relatively unchanged. So the new Linear Rec 709 will give the impression of character with relatively fair skin, some sort of skin malady, at least with the examples provided.

All the stuff here is technically public as part of the https://blendercharacterproject.org/ I’ve been working on. If you want to take a look at the textures directly without downloading blender, It should be here. Release v1.5.0 · seenbuklee/CharMorph-Vitruvian · GitHub Perhaps i authored the textures wrong.
Thank you for your help.

[ChrisBrejon (Christophe Brejon)]

I had a quick look at :

• character/Vitruvian/textures/4K/skin_light_col.1001.exr
• using my OCIO config (GitHub - chrisbrejon/DAS-UBER-OCIO-Config)

I haven´t spotted anything unusual.

If you look at the Viewer option on the top right part of the screenshot, you will see each picture formation used (OpenDRT, ACES 1.0, ACES 2.0…).

Maybe there is something wrong with the config you used ? Sorry I cannot help furthermore.

[buckleysean2003 (Sean Buckley)]

Perhaps you are correct that the config is wrong, because your config also works.

the config that is broken for me is cg-config-v3.0.0_aces-v2.0_ocio-v2.4.ocio

[buckleysean2003 (Sean Buckley)]

@carolalynn I brought this issue up on github, perhaps this will be a more efficient way to get the ball rolling.

[carolalynn (Carol Payne)]

Hi Sean, as others have noted, the crux of the issue here is how you are viewing the textures.

The color spaces are identical, but the viewing transforms in these configs are far from it. A test you can do: both of these configs come with an “un-tone-mapped” view transform. If you try setting your viewer to that in each of these configs, do the results match?

[buckleysean2003 (Sean Buckley)]

Here’s raw option

Unreal Config

Aces 2.0 Official

The results are clearly different even when viewing it with the Raw transform.
And here it is with the untonemapped option

ACES 2.0 Untonemapped option.

Unreal Config has the monitor option which sort of matches the untonemapped option as it doesn’t have something listed as untonemapped in the options. Still if you look at the texture viewer, in the bottom left, something is clearly wrong regardless of the view transform.

[conlen (Conlen Breheny)]

Hi Sean,
I downloaded the Blender 4.5.0 beta and the configs linked in your thread and was able to get a matching result for the face texture between the two configs, as well as my own config as a third control.

I plugged the texture in as an emissive texture with strength 1 on the blender shader, and set the view transform to naive sRGB/untonemapped (called “Monitor” in the unreal config, and “Un-tone-mapped” in the other two).

I don’t use Blender so I am unsure why the background hdri looks different between the three images (I didn’t touch the default HDRI settings), but if you crop just the face texture from these three images you can see they are identical (when viewed in context with the different looking HDRI they appear to be different, although that is just a perceptual illusion from simultaneous contrast).

[buckleysean2003 (Sean Buckley)]

Hi, i think you misunderstand what i want somewhat. I do actually want to work with a respective config’s tonemapped view transform. I can handle the differences but they shouldn’t break things completely, all the view transform I previously mentioned as working did change what the textures looked like as they obviously would but they didn’t produce results that obviously changed the artistic intent behind the textures. As seen in the bottom left texture viewer, this unusual behavior is only seen in the official ACES 2.0 configs

See in the bottom left the texture viewer and in the 3d viewport it seems correct. Now i don’t know why there’s a disparity but I do know that only the official ACES config has this issue, Chris Brejon’s config works, OpenDRT works, UE config works, ACES 1.3 works, but ACES 2.0 doesn’t work with it’s SDR 100 nits view transform.

[buckleysean2003 (Sean Buckley)]

i think the way you can understand the issue better is that view as render is disabled by default in blender’s image viewer. If you do this it matches, still i’m of the opinion that something is wrong with the official ACES 2.0 config either on blender’s side or the config’s side.

[jedsmith]

I didn’t know much about Blender’s color management so I decided to do some poking around. Using the OCIO config you posted above ( cg-config-v3.0.0_aces-v2.0_ocio-v2.4.ocio ), it appears that “View As Render” in the Image Editor window does nothing. I’ve confirmed this in both Blender 4.5.0 beta and Blender 4.4.3 on Linux. If View as Render is enabled, changing the various options in the Render Properties → Color Management has no effect. If using the standard blender ocio config, it does have an effect. Assuming I’m not missing something obvious, if this is a bug it should probably be reported to the blender devs. (Assuming it’s a blender issue not an OCIO issue, which seems likely).

So if there is no OCIO view transform being applied, we can only assume that the image data in the texture is being dumped directly to the display without any “Picture Formation” or OCIO View Transform. The end result is that the image data in the texture is converted to the “working colorspace” of blender, which I believe is determined implicitly by the scene_linear role of the OCIO config. Other more sophisticated software like Nuke or Gaffer allows the user to set the working colorspace seperately from the scene_linear role, which is often desireable. And if it’s not clear, the working colorspace defines what colorspace images are converted into when loaded, and what colorspace images are converted from when exported.

In the default blender OCIO config, the scene_linear role is set to rec.709 gamut linear. In the ACES 2.0 OCIO config, it is set to ACEScg. It seems that your confusion stems from this difference. Here are two screenshots elaborating on this theory:

Above is a blender with the cg-config-v3.0.0_aces-v2.0_ocio-v2.4.ocio OCIO config loaded. The colorspace of the texture has been set to ACEScg. Since the colorspace of the texture has been set to same thing as the working colorspace, no change is made to the pixel data, and it is dumped directly to the display.

Above is a blender with the cg-config-v3.0.0_aces-v2.0_ocio-v2.4.ocio OCIO config loaded, however in this screenshot I’ve modified the scene_linear role to be “Linear Rec.709 (sRGB)”. The colorspace of the texture has also been set to “Linear Rec.709 (sRGB)”. Since the colorspace of the texture has been set to same thing as the working colorspace, no change is made to the pixel data, and it is dumped directly to the display.

The images appear to match.

If the view transform were active in the color management pipeline, then this behavior would not be the same. Instead of Image Data -> Working Space -> END, it would be Image Data -> Working Space -> View Transform. In the latter case, when a view transform is present, the end result would be the same (assuming the view transform processes were identical between the different OCIO configs), even though the working colorspaces were different. This is because the “View Transform” step converts from the working colorspace, does some Picture Formation Process, and ends up in your display colorspace. If the working colorspaces change, the end result is still the same because we have color management from start to finish.

After cursory inspection, honestly I’m pretty shocked at how insanely poor the color management system in Blender is… But like I said I am no expert so maybe I’m missing many things.

Hope it helps.