Aces 2024 to 2025 color problem
-
Hi again Dr Sassi, I tried to render a project made in C4d 2024 in the new 2025 version today but I'm having trouble with the colors.
I know there's been a big update to the color management in the new c4d so I'm sure there's just a setting I need to change, but here's what seems to be happening:
In C4D the renders are identical between 2024 and 2025 within the Picture Viewer, however, when I bring the EXR outputs into Resolve, the colors are very different between 2024 EXR and 2025 EXR - 2025 version looks super saturated or maybe there's something weird with the gamma?
The output file size is different too even though its the exact same project file and frame.
Is it adding some extra color transform on output maybe?
Here's my test scene which I rendered in both versions, and the resulting EXR files from each: https://we.tl/t-ndBFQ0EZ1j
You're probably the most qualified color expert out there so Im hoping you can point me in the right direction.
Cheers
-
Thanks for the files, MaverickMongoose.
Yes, that is an internal glitch. Since the colors are stronger, it is clear that the used colorspace (Primaries) is much smaller, which leads to larger numbers, and if used (unconverted) in a larger colorspace, the colors "explode".
I went through all the colorspaces and thinkable, but they do not seem to be a good fit in combination with any typical Gamma.
It is not the new OCIO version. I also checked both versions (2024 and 2025) with the same OCIO set. Not change.
I placed some color chips into your scene to check if the Effectors have a problem or the UserData Color, but no luck either.
In other words, I searched for a workaround or temp-fix, but all my ideas won't work; it needs to be done in code, not based on anything doable otherwise.
Sorry.
All the best
Fingers crossed it is fixed ASAP.
-
Doh! I guess I'll just go back to R 2024 in that case, should have known better than to upgrade straight away;)
Good to know its a bug though and not me!
Is this only an issue with 2024 files in 2025? Would I still get problems with color if I started a fresh 2025 scene?
Thanks again
-
Hi Maverick Mongoose,
Perhaps time to dig a little bit deeper, to answer this and what to do now.
I have gotten many questions about ACEs over the years. After a while, this leads me to ask, what is the reason for using ACES, and how is it managed along the pipeline?
The main answer (subjective summary) was the filmic look of the result.This is kind of a problematic idea, as ACES is all about color fidelity based on the filmed content. So what makes this look appear for some? When a larger dynamic and colorspace needs to be converted into a very tiny space without clipping.
This means it happens only if pushed in the small used color space, sRGB or REC 709. Here, strong Gamut Compressions and Tone Mapping are applied. There is the reason for color shifts; There is no Look change without color value changes. (But that is also one of the most common complaints: the Logo color doesn't match anymore.) If the same content is exported into an HDR format(BT 2100, for example) with a REC 2020 Color Space (which modern Laser can reproduce already, then there is very little need for Tone Mapping. Since it is smaller than AP0, the ACES 1.3 Color Compression might be very useful.
The next point is how the scenes in Cinema 4D and Redshift 3D are exposed. We can produce ACES 2065 or ACES cg (even cc or cct) in Cinema 4D/Redshift 3D, allowing for HDR values and giving us the option to ignore any ACES IDT. The IDTs are developed carefully for using cameras, for example, linearize the data and expect the gray value to be set precisely, individually for each camera model! After all, this is a system that mixes and matches cameras. In all these years, no one has asked if that is important, to set the exposure right. Imagine to do what we do on set with Cinema 4D/Redshift 3D: move a stop or two up/down and look at what the Tone Mapping does with it when exported to the tiny sRGB/REC 709 space.
The next question is, how has someone handled it during the decade we worked in Linear Light Workflow (LLW) with 32bit/channel float and OpenEXR files? How was the workflow to not clip the gamut or the dynamic exporting to the various color space targets?
All of that is very similar to ACES, which linearizes the data, then works in float to reproduce photorealistic behaviors of light and move out to different Color Spaces. LLW and ACES are very similar in this regard. ACES is not so new. It is just more defined and supportive here.
After all, if one needs ACES, playing it safe would be recommended with the current release and either using the Linear Light Workflow, as it is the Default now, or staying for a moment until it is solved in 2024.
My best wishes.
-
Thanks for the detailed response - I agree that the old Linear workflow was easier and more reliable, but I find my renders look far better with the larger color space offered with aces.
I personally don't concern myself too much with the technical side of color as its way too big a concept, Im just trying to set up a solid workflow so I don't need to think too much about it from job to job. Its worked well up to this point but now with the changes suddenly the colors are all off although if anything its supposed to be easier now.
I'll get in touch with Maxon and see if there's anything they recommend, thanks again
-
Yes,, MaverickMongoose, sRGB is pretty small.
The problem is often not the final result, but the option to color process (correcting/grading) is way more limited with sRGB as a finish pipeline. Once clipped, the differentiation is gone.
When coming from ACES 2065-1 and reducing it to ACEScg (the compromise format, not the storage format, going by the creators of ACES), ACES 1.3 introduced the Gamut Compression option, meaning the differentiability is not lost; only the saturation is a little bit lower on the Gamut borders.I assume we will see constant improvement in screens in the future, and working in ACES will pay off big times.
Cheers