Nuke & ACES HDR pipeline for beginner - help needed

Discussions - Using ACES VFX
,
1

I need to test an ACES pipeline in Nuke for an HDR delivery and I’m a generalist at a small studio - in no way an expert in colour and this is my first encounter with HDR.
I’m researching and reading what I can but wondered if somebody could help me with a few basics?

The summary of the task is compositing 3D renders from Maya over HDR footage provided in an ACEScct exr sequence. I am working on an HDR monitor in Nuke11.1

I can get the footage in and out of Nuke without any change, and I can composite my layers but when I output the composite and send it to the post facility, the 2 things arent balanced. My Maya layers look dark basically. The footage is perfect.

Here is my nuke setup - I must be making an error here

  1. Project settings:
    color management - OCIO
    OCIO config - aces_1.0.3
    workingspace - ACES - ACEScct
    monitor - sRGB
    8 bit files - Input-sRGB
    16 bit files - Input sRGB

Footage read node - colSpace - ACES-ACEScct

Maya layer (tiff seq as it’s an outline only renderable by Maya software) - colspace - Input-Generic-sRGB

writenode - colspace - ACES-ACEScct/ exr with ‘write ACES compliant EXR’ checked on.

Viewer1 - set to ‘sRGB(ACES)’

If anyone has any suggestions it would be much appreciated.

2

What platform are you on?
What sort of HDR display are you using?

3

Windows 10, dell ultrasharp 27, 4k. Up2718Q
Sorry, should have mentioned that.

Thanks,
Neil

4

OK, it’s a little hard to be too specific without knowing everything. But reading through, a few things pop out.

I’d set you workingspace to ACEScg, as compositing operation should in general be done in a scene linear space, not a log space like ACEScct.

AFAIK, Nuke doesn’t have any way of handing a HDR view buffer off to windows, so it’s unlikely your getting a HDR display result, despite your display being capable of it.

Your Write node should be set to ACES2065-1, as all ACES compliant files should be scene linear AP0 data, not ACEScct log data.

When you’re doing HDR comp work without a HDR display, you need to regularly and liberally use the expose down control on the viewer to look at your work down multiple stops. It your comp looks good there, you should be fine, if it fall apart, you’re going to run into problems in HDR (This is good practice generally, but it’s critical for HDR).

5

Thanks for the info - it’s surprising how little documentation there is on some of this stuff. The Foundry website wasn’t clear, and from reading a few posts, I thought Nuke was able to output an HDR viewer on windows.
This is probably naive, but why offer a viewer working space of Rec2020 if it can’t actually output it on an HDR monitor thats set to Rec2020?
I will try compositing in SDR and use the exposure controls as you described.

6

Currently Windows is the only platform with a working HDR window compositor, and is also the minority platform for Nuke.

The Rec2020 PQ viewer makes more sense under something with zero OS color management (like CentOS 6) hooked up to a HDR display (of course, the rest of the UI looks like hot garbage, but the viewer looks great).

It also makes sense where you might be using a different display transform for a secondary monitor out.

You’re on the bleeding edge a bit here.

7

Not 100% on topic, but a word of warning about Nuke 11 and ACES:

The write node, if you check on “Make ACES-compliant” or whatever it’s called, it will indeed write to the constrained ACES container (I think); but it also writes out EXR/chromaticity metadata as AP0. Which is fine, if you’re certain that you are actually writing out AP0…

… but if you’re not, or if you’re not sure, please don’t render “as ACES” unless you’re certain! I have a ticket in with Foundry about this, and I think they’re gonna, like, include a tooltip to warn people against just blindly ticking that box…

The situation is made a little more confusing, because although Nuke 11 can read and pass through the B-Stream that chromaticity metadata, it’s actually of a specific type (vec2) of Metadata that isn’t supported on the Metadata edit node.

I don’t want to hijack this thread — I’m sorry if I did, I’ll leave you to your regularly scheduled broadcast — but, one last time. Loud and clear: Mind your metadata! Bad metadata is so much worse than none, and Foundry is coming dangerously close to degrading the reliability of EXR metadata in general — and if they’re not gonna provide a way to update the metadata as it transforms, we’re going to have to be mindful ourselves…

1 Like
8

Thanks Zach - not at all hijacking. Thanks for adding to the discussion.
I had been selecting ACES compliant - but without realising the potential implications.

9

Hello everyone,

we were wondering about this ‘write ACES compliant EXR’ option.
What does it do exactly ? Does it write EXR metatdat as AP0 ?

We are rendering in ACEScg and doing compositing as well in ACEScg.
Should check this option in Nuke when writing the final exrs for our DI delivery ?

Thanks for your insight,

Chris

10

This has been answered in this post :slight_smile:

Thanks guys !