ARRI LogC IDT in After Effects doesn't match Resolve or Baselight

[migabar (Miga Bär)]

I’ve been playing around with the now official OCIO integration in After Effects and pretty quickly bumped into two limitations or discrepancies.

1. The first issue I found was that when using the ACES Studio config in OCIO the inverse display space IDTs are missing, which makes it next to impossible to correctly interpret any sRGB, Rec709 or otherwise display referred footage. Even though I know we could argue if one should ever use these sources anyway, this feels like a pretty big deficiency in this config. On the forum I found previous mention of this issue, and the simple quick ‘n’ dirty fix seems to be to switch to the ACES 1.2 config in the OCIO control panel. At least that’s a workaround for some cases.

2. I noticed that LogC footage, when interpreted as ARRI - V3 LogC (EI800) - Wide Gamut will result in a slightly different image than when the regular ARRI IDT is applied in Resolve or Baselight. The contrast curve is visibly the same, but the skintones skew a bit more towards green in After Effects. Interestingly this isn’t the case with ARRI RAW footage, only with LogC encoded footage.

Steps I took in this test procedure:

• In Resolve, created a timeline that contained a ACES 2065-1 source (from the gamut compress test material), a Rec709 MacBeth chart and ARRI’s Isabella reference file as LogC ProRes. Each shot is on the timeline one at a time but also as a composited shot where the latter two images are PiP on top of the first image.
• Created a fake VFX pull of this timeline, converting everything to ACES 2065-1 exr’s with PIZ compression.
• Setup After Effects to work in ACES Studio config, imported my VFX pull and the three sources. Interpreted the source clips the right way (this is where I found out that the closest thing for the Rec709 MacBeth chart was the Rec709 Texture IDT which of course doesn’t result in a full inverse Rec709 → ACES).
• When comparing my VFX pull to the separate sources, the ACES 2065-1 source matched 100%, the Rec709 source was way off as expected and the Isabella reference image showed a green shift in After Effects.
• Switching the OCIO config to ACES 1.2 fixed the Rec709 issue, as the appropriate IDT is available in that config, but the Isabella reference showed the exact same shift.
• I rendered out what After Effects made of my sources to ACES 2065-1 and pulled that back into Resolve to verify that the same green shift was visible in Resolve.
• At this point I took a sidestep to Baselight to verify which of the other two setups was incorrect. Isabella rendered through Baselight in a full ACES pipeline matches the image that Resolve creates in ACES .
• All of the above leads me to think that there is something wrong with the implementation of the LogC3 IDT in After Effects or even in OCIO. Although I do hope that I am missing something and just made a mistake on my end.

Can someone verify that they’ve encountered the same issue, or does anybody have an idea of what I might be doing wrong?

Finally, I made some screen shots. In the below image you will see Baselight/Resolve’s rendering of Isabella on top and After Effects interpretation at the bottom.

These screenshots are from within After Effects, but the same shift can be seen when comparing the images in Baselight or Resolve.

[shebbe (Shebanjah Klaasen)]

Hi Miga,

@migabar

The first issue I found was that when using the ACES Studio config in OCIO the inverse display space IDTs are missing, which makes it next to impossible to correctly interpret any sRGB, Rec709 or otherwise display referred footage.

I don’t think it’s directly an ACES OCIO issue, but rather an implementation issue. We can achieve inverse display transforms via the use of OCIODisplay which AE unfortunately didn’t implement yet prior to release. I believe OCIOv2 is designed to be set up in the way ACES has implemented it, with displays being separated from color spaces so the Studio and CG config are pretty much what they should be.

Your point was also brought up recently in this thread where I mentioned that it could help to give Adobe some feedback on this to make them more aware of how much of an issue this really is.

@migabar

I noticed that LogC footage, when interpreted as ARRI - V3 LogC (EI800) - Wide Gamut will result in a slightly different image than when the regular ARRI IDT is applied in Resolve or Baselight.

Are you sure that this is caused by OCIO? AFAIK there is a misinterpretation happening with ARRI .mxf files (ProRes) on a Mac in Adobe Premiere and After Effects likely due to the encoded matrix coefficients being bt.601 instead of bt.709 but it’s always assuming the latter. This issue isn’t seen on Windows. (Or it was the other way around).

[migabar (Miga Bär)]

Hi Shebbe,

Thanks for the quick and clear responses. As for the inverse display transforms, you are right that this is an implementation issue rather than a core OCIO deficiency. Thanks for highlighting the thread where it came up previously, that was the thread I was also referring to. I will definitely do my part and give Adobe this feedback.

In regards to the ARRI LogC issue, that is very interesting information, thanks for that. As I mentioned, my tests brought me to believe it had to do with OCIO or the OCIO implementation, but I do think that the known issue you raise is a more probable cause for the color shift. I’ll try to get my hands on a Windows machine with Adobe license to see if I can replicate the issue there. I’ll report back here with my findings.

[migabar (Miga Bär)]

Finally had a chance to check on a Windows computer, and indeed: the debayer from ARRI RAW now matches the IDT applied to a LogC3 image. I just now realise that I have not checked if they also match the image in Resolve, so I’m not sure if they are both correct or both wrong. But at the very least it’s clear that the LogC3 application in After Effects on Mac is doing something wrong.