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.
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.
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.
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.
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.
At our studio it’s necessary to convert plates to ACEScg for a simplified and unified workflow within the studio. This is especially useful if you need to use the plates in Maya / Houdini for lighting as you don’t need to worry about setting colorspace roles on file nodes (and worse, the inability to set a specific colorspace target in the Arnold Renderview for the background image only) and it therefor leads to less colorspace issues when working with freelance talent.
Everyone knows everything is done in ACEScg, from DMP, to textures, to lighting, to comp. Only when exchanging with other studios do we convert back to ACES 2065 to avoid misunderstandings.
We do exactly the same thing, less margin for errors with artists pulling in CG renders incorrectly into Nuke and treating them as ACES2065-1. Whilst its an extra step to do final delivery back to clients in ACES2065-1 its offfset by the smoother internal workflow.
May I ask a simple question for clarification? So, when compositing assets in ACEScg and wishing to export ACES2065-1, would adding the following nodes at the end be correct:
OCIOCOLORSpace (in - ACESsg, out - ACES2065-1)
Write (*.exr, “Write ACES compliant EXR” tick ON)?
Thank you in advance!
