Aces 2024 to 2025 color problem
-
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
-
Hi MaverickMongoose, were you able to solve this issue? I'm having the same problem where my EXR renders look overly saturated in C4D 2025.
-
Hi point-year,
I am sorry that you have run into this as well.
Please have a look here:
https://support.maxon.net/hc/en-us/articles/8658038724124-Cinema-4D-2025-0-2-October-9-2024?_gl=1%2A1dsz0xe%2A_gcl_aw%2AR0NMLjE3MjM3NDc4MTkuQ2owS0NRand6dmExQmhEM0FSSXNBRFF1UG5YamdjYlREbjRwM3RXMFhZYlBKQTZNMHB4OHBGcFJrRFdZMzBxLUFLWXAxRTNJX3gxakpVMGFBdjZHRUFMd193Y0I.%2A_gcl_au%2ANDIyODM2MDMyLjE3MjgwMjAxMTQ.Have you updated to the latest version?
All the best
-
@point-year Yep, if you update to the latest version of C4D and Redshift it should work as expected, it was just a bug
-
Thank you very much, Maverick Mongoose,
For confirming it.
My best wishes
-
Yes it works now, thank you!
-
Hi point-year,
Thank you very much for your reply. I'm glad it is working for you.
Enjoy!
