Nuke output differs in ACES vs Non-ACES

I’m on a job that shot with the X-OCN codec in Slog3 SGamut3.cine - they are not grading with ACES but I am VFXing in ACES.

When I output my comp I use the OCIO colourspace to go ACEScg > input - Slog3 - SGamut3.cine

However when I do this, it doesn’t match their footage and it’s off ever so slightly. If I were to open a Nuke and turn off ACES, and was to output with a non-Ocio colourspace node, I have to choose Slog3. Doing this matches at their end so I have to assume it’s differences in the ODT.

So how can I deliver with their preferred version of Slog3? If I had used the same IDT as ODT this would probably not be an issue, BUT the XOCN codec comes in with its own SDK and options, and needs to be interpreted as Linear. So I feel like I’m missing a step somewhere.

Hi Lee,

Not familiar with XOCN in Nuke but some general checks I can think off…

Do you mean Linear with SGamut3.cine primaries? Is that also what has been set on the read node to convert it to the working space ACEScg? Can you decode to SLog3 as well from the raw settings? Does that work?

And perhaps check if it makes a difference using an OCIOv1 vs v2 config (ACES 1.2/1.3)

Are you delivering ProRes/DNxHR? Or sending back EXRs. If the latter, perhaps better to send in SGamut3.cine/Linear instead?

What you want to do is set the input transform on the read node the same as the output transform on the write node (assuming you are returning in the same format as received). So you would read in as sLog3 and write as sLog3 and it should look identical because it is a noOp.

Also it says here that XOCN is 16-bit linear so I’d think you’d want to use the Linear S-Gamut3 rather than log. Linear S-Gamut3 is included in the OCIOv2 config that comes with Nuke (the ACES studio config). I don’t believe the OCIOv1 config has that.

I believe Nuke can only read MXF files with X-OCN codec, but not write them, so what format are you using for interchange? If it is EXR as @Shebbe suggested, you could write that out in Linear S-Gamut3. Normally for a VFX pull we’d ask them to deliver it to us in EXR, or more broadly have then deliver the material in a format that we can return it in.

Thanks Derek, I have tried this option before with the same logic but I couldn’t get a match. I will try this again when I’m next with the footage and try to provide some screenshots of the problem!

It may not be that getting my input and output to match, it’s more about getting my output to match their input, who are not using ACES.

Many thanks!

Is it possible the camera used was a Sony Venice? In that case the Venice S-Gamut3.Cine IDT differs slightly from the standard one. A direct SDK decode to ACEScg of Venice X-OCN will effectively be using the Venice IDT, so you would need to use the same to invert that out.

Ah, I think I’m following now! You are doing a direct decode of the X-OCN file and it’s doing whatever it’s doing under the hood. We are all assuming this is linear S-Gamut3, but you are observing that when you set the output to that it does not seem to match the input.

So maybe as @nick Nick suggested, it’s not reading it in as linear S-Gamut3 but instead as Linear Venice S-Gamut3. At any rate you are kind of in a guessing game. There are a whole bunch of possibilities with Sony. From the studio OCIO config we have:

S-Log3 S-Gamut3
Linear S-Gamut3

S-Log3 S-Gamut3.Cine
Linear S-Gamut3.Cine

S-Log3 Venice S-Gamut3
Linear Venice S-Gamut3

S-Log3 Venice S-Gamut3.Cine
Linear Venice S-Gamut3.Cine

I think ideally the pull facility would deliver the pulls in an interchange format that Nuke can both read and write (like EXR) and communicate the color space that those files are in if not in ACES. Trying to do “image forensics” in Nuke is quite challenging! Generally speaking I’ve found Resolve to be a better tool for that than Nuke.

Aah yes I’ve not mentioned but I have tried using the Venice flavour of the IDT with the same issue.

If I am not using ACES I can get it to match the SDK’s input by using plain SLog3 on output. So it’s making me think the ocio version is doing some extra change - possibly a white point adjustment?

ACES’ white point is different but it shouldn’t matter as you’re transforming back to SGamut3.cine via the same matrix.

I did a test with sample footage A005C039 3rd clip from their site. I couldn’t find a difference. My setup was as follows.

Nuke Default:

  • Decode to SGamut3.cine, read input scene linear
  • Colorspace node Linear->SLog3

OCIOv2.1 ACES Studio:

  • Decode to SGamut3.cine, read input Linear/SGamut3.cine
  • OCIOColorSpace ACEScg->SLog3/SGamut3.cine

Hybrid OCIOv2.1 ACES Studio + Nuke nodes:

  • Decode to SGamut3.cine, read input Linear/SGamut3.cine
  • OCIOColorSpace ACEScg->ACES 2065-1
  • ColorMatrix → SGamut3.cine->ACES2065-1 inverse direction (matrix taken from the config)
  • Colorspace node Linear->SLog3

I wanted to do the hybrid version to see if the transfer function made a difference within the same config.

All were saved to 12bit dpx and there is no difference between them. I’m running NukeNC but here are my files if you want to have a look. We may not be on the same Nuke version / Sony SDK but I hope that doesn’t matter…

Thank you Shebbe - I’m really itching to get back at my desk to try this now.

So the difference here is my read node is set to Linear ACESCg and not the linear S3gamut.cine. I was trusting that linear is linear and that’s all it should be. Really hoping this is all it is.

Which colourspace did you take the matrix from in the config? I’d like to try this method too so I’m understanding each step.

Finally, because the problem is actually how it looks in Resolve, could you try your exported DPX files in resolve against the original clip? Im most intrigued about the ACES 2.1 studio config. The colonist has it set up as a plain Resolve with no adjustments to the default.

The colourist also wants them in ProRes4444 - is there anything to be aware of with this?

That should explain the difference you have. Nuke default config doesn’t really have a working space. It’s ‘color spaces’ only contain transfer functions. Traditionally most compositing was done by only converting whatever material’s transfer function into linear but often not considering the color space’s gamut. When you use ACES the working space is set as ACEScg (AP1/Linear) so any material you bring in needs to be converted to it, both transfer function and primaries. This happens on the read node by setting it to what the source is, in your case Linear/SGamut3.cine. If you keep it as scene_linear you are assuming it’s already in the working space so when converting back out the primaries get converted only once hence the mismatch.

From Linear/SGamut3.cine. If you browse to the config file itself and open it in a text editor you can see all de definitions.

This also matches as far as I could tell, but because I’m in NukeNC I could only reformat to HD so I’m seeing scaling algorithm differences. But not color.

Only that ProRes4444 is lossy compression so there will be slight numerical differences on the non composited parts of the image. Shouldn’t be that visible though. If their requirement isn’t that critical it’s fine I’d say. Otherwise I’d opt for SLog3/SG3.cine DPX or Linear/SG3.cine EXR files.

shebbe you are hero of the week…
Yes I get it now with Nuke linear - I was expecting the option in the Sony SDK section under Mxf options to be where you’re setting the gamut and the input transform should be left at Linear. I still don’t know what that section is for but I’ll give your advice a try.

This is a problem that’s been bugging me for the best part of 3 years now so this hoping this is it!

It’s slightly convoluted using raw files because from the SDK part you need to decide to what you’d like to decode to, in case of X-OCN this is always in linear for Nuke’s implementation but you still get to choose the primaries. Then the input transform is for the OCIO config part where you need to tell what the file should be read as (which should always match what you decode to) so it just like any other file can convert from the read node to the working space of the config. It may have made more sense to expose both gamut and transfer function on the SDK but since it’s somewhat expected that Nuke users composite in linear they may have felt leaving it forced linear was a cleaner option.

I had a chance to try this out and it finally works. I completely get it now.
Thanks so much for your help. This means I can correctly start making EXR plates knowing they will work under the show LUT and can be fed to any non-ACES workflow too!

PS I owe you lot a beer

1 Like