Alexa ACES bright saturated Color Clipping

Fri Oct 18, 2019 10:29 pm

I'm getting Color clipping from the Alexa aces transform in Flame, It seems to be a known problem for Arri, as they list it as a "gotcha" on their FAQ. However, they are referencing chromatic aberration around bright headlights, and I'm seeing it in very saturated Astura tubes against a dark scene. Which I assume is the same issue, which they say is that the colors are "falling outside the gamut of colors that the ACES rendering transform is designed to handle".

Has anyone had this problem?
Does anyone have a solution to this?

I'm attaching Arri's Screenshot of the car headlights from their faq website, and also a still of the issues I'm seeing in flame.

Flame Settings:

Aces 1.1

Clip Format Settings:

Input Color Space > LogC (v3 - EI800) / AlexaWideGamut

Working Space > ACEScg
Posts: 1
Joined: Mon Oct 14, 2019 11:51 pm

Re: Alexa ACES bright saturated Color Clipping

Fri Nov 15, 2019 12:49 am


I'm the author of those web pages and the primary ARRI participant in ACESNext efforts. I'm also on vacation until December 2nd but the workflow group asked me to speak up here.

Let's assume that this is a recent version of Flame, which is likely as you have ACES 1.1 installed. I don't know if ACES 1.1 is provided by SynColor, but it seems likely and given what I know of the relevant developers from OpenColorIO 2.0 development, I doubt you are seeing a Flame implementation error.

So. There are three things that can cause ugly color clipping like that:

Color analysis errors, where the conversion from camera native to some encoded space (be it ALEXA Wide Gamut or ACES AP0) is in error. This isn't the forum for a color science course but suffice it to say we use an error-minimized 3x3 to go to AP0, as you can see in our published IDTs, and it has the same type of inexactness that any other vendor's IDT would have.

Clipping for colors that are inside the spectral locus (correctly or not) but outside AP1. The first step of the RRT is a hard clip from AP0 to AP1. If your deep blues are outside AP1 but inside the spectral locus, they will all collapse to the boundary color and it will be ugly.

Very rarely there is a third issue which is that color which are JUST inside the AP1 boundary can render to just outside the AP1 boundary and clip but, causing the same issue mentioned in the prior point, but I doubt that's it.

ALEXA Wide Gamut actually has some space to accommodate blues that are incorrectly deduced to be outside the spectral locus (and outside AP0). Those are mapped smoothly back into your destination color space (Rec. 709, for example) by the ARRI rendering transform. That they are outside AP0 (and thus would have negative ACES values) is just an convenience for the ARRI image capture and rendering path, and they are just as valid as, say, using negative numbers to refer to the number of seats left for an oversubscribed public event.

It's really hard to say what's going on by looking at your images especially since your ACES 1.1 and 'Legacy' render aren't starting from the same frame. If you want, we can pick this up again when I am back in the office. My email address is, with the two capitalized letters removed. If you can get permission to share the original ARRIRAW or LogC frame, we can use a combination of the ARRIRAWConverter app and Nuke to figure out what's going on. I should post out that to do that, we will have to process the same frame with both image processing chains; it's not practical to make comments based on two different frames, as you did in your post. (Also, if the things that went wonky were self-luminous sources, anything you can gather on that source (if it was a cinema light, then make, model, and light or ballast settings) will help.

Again, I'm on holiday until the first week of December. But ping me then if you're still interested and we will poke at this.

Best regards--

Joseph Goldstone
Image Science Engineer
Vanowenstraße 3700
Burbank CA
Posts: 1
Joined: Wed Nov 13, 2019 11:49 am

Return to Workflow