good to hear that it is going better!
The OCIOColorSpace Node in then ACES script is only for demonstration and debugging sake.
You don’t need it in production.
When you set the Input (IDT) in the Read node correctly and view the Read node with the Viewer
set to Rec.709 (ACES) at one hand – or viewing the OCIOColorSpace node and set the Viewer to Raw (ACES) on the other should generate the same result.
Accordingly, with the Write node: Writing out the imagery directly after the Read node with a Write node, set to Output - Rec. 709
should produce the same result as writing out the images after the OCIOColorspace node with a Write node, set to Utility - Raw.
The middle Clamp node in the Nuke default script has the only purpose to clamp down values above 1.0,
to avoid potential problems and misinterpretations down the line.
It should work fine without it, but who knows where the imagery is going to.
----- Ursprüngliche Mail -----
Von: "Gonzalo Garramuño" <ggarra13@...>
An: "ocio-dev" <ocio-dev@...>
Gesendet: Samstag, 7. Dezember 2019 03:41:32
Betreff: Re: [ocio-dev] nuke-default's sRGB and ACES 1.1 sRGB
On 6/12/19 13:02, Eberhard Hasche wrote:
Hi Gonzalo,Dear Eberhard,
I can confirm that the Nuke default one is matching my version
completely, but without the middle node that you have in the Nuke
script. The RED SDK it seems already sends a half image with
RedWideGamutRGB baked in when you request a HalfFloat image buffer. So
for the nuke-default to work, I had to set scene-linear and my view to
Now, for the ACES pipeline, I am still struggling with it as it seems I
may need an additional transform node as you have in the nuke script,
which is not trivial as my viewer only accepts an image transform and a
Thank you very much for the Nuke scripts, btw. I had to download a demo
of nuke but it was worth it.