Skipping the ACEScg EXR conversion

Hello hello!

New to this community after reading up on as much as I could in the past week or so.
Already got the jist of ACES, but recently had to dive deep(er) as I’m trying to implement it at our studio.
But my team is a bit reluctant to adopt it the way I read it to implement it.

How I understand it now is:

  • You’d convert live plates from, in our case, an Alexa Mini.
  • In Nuke, set the Read node Colorspace to Input - ARRI - V3 LogC (EI800).
  • Set a Write node with ‘write ACES compliant EXR’ ticked on.
  • Write EXR sequences with ACEScg in them.
  • Read these EXRs as raw/linear and comp the VFX on top of it.

So that’s how I understand it now.
But my team asked “why not comp straight onto the footage and not write those to EXR?”

So my question is if you could indeed do just that.
Make the VFX, rendered in ACEScg space and, in Nuke, use the plate as we receive it and just convert it with the Read node.
To then put the VFX on top.
And then I guess use an ‘OCIO Color Space’ node to convert the result to ACES2065-1 to send to final grading.

So with that, skipping the step of converting the plate to ACES EXR files.

Are there downsides to this?

Hello @Eckhart and welcome,

here is my tuppence :

I would avoid the ACEScg exr conversion.

  • In Nuke set the Read node Colorspace to Input - ARRI - V3 LogC (EI800).
  • Your working space in Nuke is ACEScg, so it converts automatically.
  • Comp straight onto the footage with ACEScg VFX renders.
  • Set a Write node with ‘write ACES compliant EXR’ ticked on and ACES2065-1 as a colorspace.

We should not tick “write ACES compliant EXR” if we do not write ACES2065-1 exr files.
No need to use an “OCIOColorSpace” node to convert before writing. Just set it directly in the Write node.

Chris

You should not check that box if you are writing ACEScg to an EXR. [Edit, I see @ChrisBrejon already said that!]. If you do so you are setting metadata that flags the EXR as ACES2065-1 when it is not. That risks misinterpretation of the image data further down the line.

If it works for your workflow, there is no requirement to create EXRs. Working from rushes and converting “live” to ACES is perfectly acceptable.

Thanks for the feedback!

So if I understand it correctly.
So then you’d only tick that box when you want to save the EXRs to deliver it for grading?
And then I have to set it to 2065-1 on the write node, correct?
It does explain why I got a slightly different result when reading those EXRs back in when I had ticked that box.

Then, what I was thinking is that if I’d want to use the plate as the background in a render view in for example Houdini or Maya.
I do have to export to EXR from in an ACEScg workspace, no?
So that it conforms to the ACEScg renders.

Thanks again!

Exporting ACEScg EXRs is commonly done, but not officially the correct ACES approach. Therefore you should not flag them as “official ACES” with that check box.

But in any case, metadata is not read and honoured in a lot of cases, so you always need manual input to confirm that a file is being correctly interpreted, and fix the interpretation if it is not.

Ok, so with your responses and some more reading I now understand it as that you’d only tick that checkbox when you want to provide the EXRs with the metadata saying “this is ACES 2065-1”.
But it is not necessary, even when the EXRs are in fact in 2065 (by setting it so on the Write node in Nuke), right?

The official recommendation is to add the metadata whenever exchanging ACES2065-1 files with another facility, if I recall correctly. To avoid any ambiguity. :wink:

Hope it helps,
Chris

2 Likes