Color problem aces 2023 to 2025

[Wenneker]

We appear to have a problem that is similar to what is mentioned in this post:
https://cineversity.forums.maxon.net/topic/1305/aces-2024-to-2025-color-problem
We hoped it would be fixed after updating to the latest version but unfortunately the problem persisted.

These are the beauty OAV's from both 2023 and 2025.

Everything we render to file in C4D 2025 comes out with colors that are more saturated than we had before when we were rendering with 2023.
In the pictureviewer and the RS renderview there is no such difference between the different versions.

I've uploaded the renders and the C4D project here if you want to take a look:
https://wenneker-amsterdam.filemail.com/d/rxwkpnawwauemoi

Thanks,
Bart

[Dr. Sassi]

Hi Bart,

I have set up a file in 2023.2.2 and opened it in 2025.1.3

I get differences that in difference mode are shown in the image below ( A rainbow gradient was used 100% and 200% brightness)

Your two examples look like this in difference mode, just to give anyone reading along a comparison.

Please note that sRGB is a very small colorspace requiring tone mapping in ACES. ACES is a system that merges many sources into one unifying space and any dynamic coming from practical footage.
The typical and misleading idea is to render and use the smallest colorspace as output, which will change things, especially when the next version of ACES comes. The core idea should be always, to render in ACES AP-0 or internally (Studio wise) in AP-1, and have things sorted out in post.

Since the ACES 2.0 is nearly ready for the public, while changing the output for small color spaces (!), please let me share this below even though I assume you are aware of this, but since I write in a forum:
There is a huge misunderstanding, surely pushed by many, that ACES makes things more filmic [sic]; the target of ACES is to not (!) alter anything at all, to mix and match all cameras and other sources that match at least the gray card values (without no match). OpenEXR as ACEScg does not directly conform, as exposure might vary. This is often not suggested on various YouTube channels.
The "filmic," or whatever some artists think about, comes from the simple fact that a tone-map function heavily alters the output for super small color spaces (sRGB and REC 709). If one supplies data for today's screen in REC 2020 or even REC 2100, in HDR, then that tone-mapping is not applied, and the effect seen with the small spaces is gone. I don't know why anyone works in ACES and then exported it to sRGB.

I will check your file; perhaps just leave the floor object in and the cube and delete anything else, then save it as C4D and share it here directly.

Alternative
Please use Dropbox, Google, Adobe, Apple, or Wetransfer.
For security reasons, I do not have any other option.
Please don't zip or even use rar, nor Tiny URL or something similar, the URL just pasted here, no HTML wrapper. Thank you, and I am sorry for the extra work.

All the best

[Wenneker]

Hi Dr. Sassi,
Thanks for replying. I'm having trouble understanding the context behind the remark about the srgb export. Prehaps because you couldn't open the linked files. We render in ACEScg and write the files in this colorspace aswell it's just for viewing purposes that I applied a viewLUT.
Fortunately one of you colleges from support was able to open the project and could point out a change in behaviour between 2025 and prior versions. I will paste it here in case someone has the same problem.

[Wenneker]

Hello,

Thank you for your files.

As I can see you want to save a 16 Bit/Channel MultiPass EXR, which the issue comes from.
Currently this is a limitation of the OpenEXR user interface, if you use 16-bits instead of 32-bits, the result is a baked view transform with darker colors.

To get correct results for 16-bit, you need to set the EXR export to 32 Bit Depth but you need to activate "Use 16 Bit Floats":

Our development is aware of this confusing interface settings and try to find a better solution in the future!

BTW: If you use the AOV Direct Output, you also get the correct output.

I hope that helps.

Kind regards,

Jörn Gollob

Cinema 4D Technical Support

[Dr. Sassi]

Hi Bart,

Thanks for sharing the reply.

Yes, that is why I asked for files. To see what the whole set is.
My typical workflow here is to recreate the question and answer from that, not from memory or with a long list of questions.

That is a similar problem that sRGB or REC 709 has; all values above 100% are tone-mapped to fit into 100%. A part of the 0-100% is squeezed to enable that.

Typically, why did my sRGB comment come up? Tone Mapping is not the only part; there is a Gamut Compression from ACEScg to sRGB. This means color values are moved. Both create a color shift. (The core reason why people have Logo Colors.)

When both are applied, the changes can be heavy.

Yes, the Open EXR, including the half-float part, should not be affected.

In the ACES documentation, the 32bit/float/channel is the format for any storage and external exchange in AP-0 (the largest colorspace). ACEScg came later and is a format that should be used only internally, but it might show limitations in some cases. Hence, I typically do not use it in my work. But yes, it is widely used, based on many applications that can use the AP-1 colorspace but not the AP-0. I created the graphic for the documentation to show that. Cinema projectors, if newer, can reproduce already REC 2020.

https://help.maxon.net/r3d/cinema/en-us/#html/Color+Management+-+OCIO+ACES.html
It shows clearly how many green tones, and a stripe between red and blue is excluded in AP-1.

The 16bit/float/channel has limitations, even without the implementation limitations in C4D currently (in dynamic and color) but typically can hold the stops of dynamic that practical cameras have. However, many data-based AOVs need 32bit/float/channel.

As a side note, ACEScg has no Color Space flag (insde the file) requirement based on ACES papers. The ACES itself in 32bit/float/channel has. If open an ACEScg, but sadly also ACES in some external apps, the Color space has to be set manually (not converted!) I wrote to Adobe about that for many years, but it has not been solved completely. However, the result can be different colors.

All the best