I recently noticed a discrepancy in the sRGB output transform of nuke-default's and ACES' one. Basically, Nuke's seems to have an additional 2.2 gamma transform while ACES does not seem so pronounced. What's weird is that the ACES OCIO transform matches the equivalent CTL transform, but the nuke-default's output looks more like what is expected of the clips I am feeding (comparing them to a sample PNG taken from a web page from where I downloaded the clip from).

I tested the images both with my viewer and with the DJV viewer with same results.

Can somebody shed some light into the issue?

Find attached the two images of the "problem".

Hi Gonzalo,

the main problem with sRGB (and Rec709) in ACES is that nuke-default is adding the sRGB-Transfer Function to the linear material,
whereas ACES is also applying a Render Transform (RRT+ODT) which deals with the HDR content, and in order to make space for the content above 1.0
a value of 1.0 is compressed to 0.8 which makes the export appear darker.

A more profound discussion is here:

https://acescentral.com/t/nuke-srgb-aces-srgb-not-the-same/2292

Cheers Eberhard

----- Ursprüngliche Mail -----
Von: "Gonzalo Garramuño" <ggarra13@...>
An: ocio-dev@...
Gesendet: Mittwoch, 4. Dezember 2019 17:58:10
Betreff: [ocio-dev] nuke-default's sRGB and ACES 1.1 sRGB

I recently noticed a discrepancy in the sRGB output transform of
nuke-default's and ACES' one. Basically, Nuke's seems to have an
additional 2.2 gamma transform while ACES does not seem so pronounced.
What's weird is that the ACES OCIO transform matches the equivalent CTL
transform, but the nuke-default's output looks more like what is
expected of the clips I am feeding (comparing them to a sample PNG taken
from a web page from where I downloaded the clip from).

I tested the images both with my viewer and with the DJV viewer with
same results.

Can somebody shed some light into the issue?

Find attached the two images of the "problem".

Hi Gonzalo,

second thought only to get us on the same page: The problem may be raised in the input section.
Is it a RED Sequence you are reading in?
If so, to my knowledge there is no way to do a primary conversion from
REDWideGamutRGB to an arbitrary target color space in default Pre-ACES Nuke colormetrically correct. Only the
Transfer function is removed and the color values are passed "as they are" (belonging to the chosen RED color space). So if you want to compare Nuke-default - Nuke ACES you got to
get the 3x3 primary conversion Matrix from The REDWideGamutRGB white paper, either to Rec709 or CIE XYZ and then convert it further to the target color space.
Whereas in Nuke ACES the complete color conversion is performed correctly (removing the Log3G10 Transfer Function and performing the primary conversion using a 3x3 matrix from
REDWideGamutRGB to the working color space chosen in Nuke – most of the Time ACEScg).

I hope the thoughts may help. The topic using pre-ACES.1.0.3? (Nov. 2016)
RED conversions is complex. We did some research and would recommend using the IPP2 color pipeline
in the (ACES) Nuke input. All settings are automatically correct. There should be no problem at all, although the ACES IDT
keeps the RED material very slightly reddish.

Eberhard



----- Ursprüngliche Mail -----
Von: "Gonzalo Garramuño" <ggarra13@...>
An: "ocio-dev" <ocio-dev@...>
Gesendet: Mittwoch, 4. Dezember 2019 17:58:10
Betreff: [ocio-dev] nuke-default's sRGB and ACES 1.1 sRGB

I recently noticed a discrepancy in the sRGB output transform of
nuke-default's and ACES' one. Basically, Nuke's seems to have an
additional 2.2 gamma transform while ACES does not seem so pronounced.
What's weird is that the ACES OCIO transform matches the equivalent CTL
transform, but the nuke-default's output looks more like what is
expected of the clips I am feeding (comparing them to a sample PNG taken
from a web page from where I downloaded the clip from).

I tested the images both with my viewer and with the DJV viewer with
same results.

Can somebody shed some light into the issue?

Find attached the two images of the "problem".

On 5/12/19 04:04, Eberhard Hasche wrote:

Hi Gonzalo,

the main problem with sRGB (and Rec709) in ACES is that nuke-default is adding the sRGB-Transfer Function to the linear material,
whereas ACES is also applying a Render Transform (RRT+ODT) which deals with the HDR content, and in order to make space for the content above 1.0
a value of 1.0 is compressed to 0.8 which makes the export appear darker.

A more profound discussion is here:

https://acescentral.com/t/nuke-srgb-aces-srgb-not-the-same/2292

Cheers Eberhard

Hi, Eberhard.

Yes, that's more likely what I am seeing.  Thanks for the detailed explanation.

Cheers,
Gonzalo

On 5/12/19 04:45, Eberhard Hasche wrote:

Hi Gonzalo,

second thought only to get us on the same page: The problem may be raised in the input section.
Is it a RED Sequence you are reading in?

Yes, it was a RED sequence, but I was just testing it with scene_linear.

I hope the thoughts may help. The topic using pre-ACES.1.0.3? (Nov. 2016)
RED conversions is complex. We did some research and would recommend using the IPP2 color pipeline
in the (ACES) Nuke input. All settings are automatically correct. There should be no problem at all, although the ACES IDT
keeps the RED material very slightly reddish.

Eberhard

What's the IPP2 color pipeline?  Is it some Nuke node, some OCIO config transform or the IPP2 function that appears in the RED SDK?

Hi Gonzalo,

IPP2 is the RED Image Processing Pipeline #2, introduced three or four years ago which is closer to the ACES concept.
If you read in RED footage choose the settings at the attached image in Nuke's Read node and you are on the safe side.
To get those settings in the Read Node color space line choose: (Colorspaces) --> Input --> RED --> REDLog3G10 -
REDWideGamutRGB.


Cheers

Eberhard

----- Ursprüngliche Mail -----
Von: "Gonzalo Garramuño" <ggarra13@...>
An: "ocio-dev" <ocio-dev@...>
Gesendet: Donnerstag, 5. Dezember 2019 18:45:50
Betreff: Re: [ocio-dev] nuke-default's sRGB and ACES 1.1 sRGB

On 5/12/19 04:45, Eberhard Hasche wrote:

Hi Gonzalo,

second thought only to get us on the same page: The problem may be raised in the input section.
Is it a RED Sequence you are reading in?

Yes, it was a RED sequence, but I was just testing it with scene_linear.

I hope the thoughts may help. The topic using pre-ACES.1.0.3? (Nov. 2016)
RED conversions is complex. We did some research and would recommend using the IPP2 color pipeline
in the (ACES) Nuke input. All settings are automatically correct. There should be no problem at all, although the ACES IDT
keeps the RED material very slightly reddish.

Eberhard

What's the IPP2 color pipeline?  Is it some Nuke node, some OCIO config
transform or the IPP2 function that appears in the RED SDK?

On 5/12/19 15:06, Eberhard Hasche wrote:

Hi Gonzalo,

IPP2 is the RED Image Processing Pipeline #2, introduced three or four years ago which is closer to the ACES concept.
If you read in RED footage choose the settings at the attached image in Nuke's Read node and you are on the safe side.
To get those settings in the Read Node color space line choose: (Colorspaces) --> Input --> RED --> REDLog3G10 -
REDWideGamutRGB.


Cheers

Eberhard

Hi Eberhard,

I tried that with my viewer (setting the ocio colorspace input to Input - RED - REDLog3G10 - REDWideGamutRGB) and set the display/view to ACES->sRGB and the results were all colors like a Warhol painting :D.  I must have missed something.

Cheers,
Gonzalo

On 5/12/19 18:14, Gonzalo Garramuño via Lists.Aswf.Io wrote:

On 5/12/19 15:06, Eberhard Hasche wrote:

Hi Gonzalo,

IPP2 is the RED Image Processing Pipeline #2, introduced three or four years ago which is closer to the ACES concept.
If you read in RED footage choose the settings at the attached image in Nuke's Read node and you are on the safe side.
To get those settings in the Read Node color space line choose: (Colorspaces) --> Input --> RED --> REDLog3G10 -
REDWideGamutRGB.


Cheers

Eberhard

Hi Eberhard,

I tried that with my viewer (setting the ocio colorspace input to Input - RED - REDLog3G10 - REDWideGamutRGB) and set the display/view to ACES->sRGB and the results were all colors like a Warhol painting :D.  I must have missed something.

Cheers,
Gonzalo

One thing I noticed is that I get different results in decoding the clips with RED's PixelType_HalfFloat_RGB_Interleaved and PixelType_16Bit_RGB_Interleaved.  The 16 Bit clip seems to be in log space, but none of the RED - Log* transforms works with it.

Hi Gonzalo,

strange!

It is interesting. Maybe there is a look buried in the MetaData i. e. a tinting
or some white point problem.
May you give me the link to the RED-file?

Cheers

Eberhard


----- Ursprüngliche Mail -----
Von: "Gonzalo Garramuño" <ggarra13@...>
An: "ocio-dev" <ocio-dev@...>
Gesendet: Donnerstag, 5. Dezember 2019 22:14:46
Betreff: Re: [ocio-dev] nuke-default's sRGB and ACES 1.1 sRGB

On 5/12/19 15:06, Eberhard Hasche wrote:

Hi Gonzalo,

IPP2 is the RED Image Processing Pipeline #2, introduced three or four years ago which is closer to the ACES concept.
If you read in RED footage choose the settings at the attached image in Nuke's Read node and you are on the safe side.
To get those settings in the Read Node color space line choose: (Colorspaces) --> Input --> RED --> REDLog3G10 -
REDWideGamutRGB.


Cheers

Eberhard

Hi Eberhard,

I tried that with my viewer (setting the ocio colorspace input to Input
- RED - REDLog3G10 - REDWideGamutRGB) and set the display/view to
ACES->sRGB and the results were all colors like a Warhol painting :D.  I
must have missed something.

Cheers,
Gonzalo

On 6/12/19 03:16, Eberhard Hasche wrote:

Hi Gonzalo,

strange!

It is interesting. Maybe there is a look buried in the MetaData i. e. a tinting
or some white point problem.
May you give me the link to the RED-file?

Cheers

Eberhard

It happens with any RED file, but if you want one to try, try the first clip (the one with the guy in the motorcycle) from the sample 3d files:

http://downloads.red.com.s3.amazonaws.com/sample-r3d-files/w8kvv-sth-48fps-10to1redcode_FF.RDC.zip

When I decompress it as HalfFloat and try the Log* WideGamutRGB, I get a posterized look.  When I decompress it as 16bit short, I get a better but too dark image.

Hi Gonzalo,
maybe you should consider that something in your pipeline is broken.

I tried your file out and all worked fine. Attached are two Nuke files (one ACES 1.1, the other
Nuke default) with all necessary color conversion nodes.
I rendered out two 1/8th resolution jpg images set to Rec709. The only difference in the color pipeline is that with the nuke-default image,
the picture-rendering part is missing, so it is clamped at 1.o whereas the
aces image is a bit brighter because parts of the luminance above 1.o has been rolled in.


cheers

Eberhard

----- Ursprüngliche Mail -----
Von: "Gonzalo Garramuño" <ggarra13@...>
An: "ocio-dev" <ocio-dev@...>
Gesendet: Freitag, 6. Dezember 2019 11:22:37
Betreff: Re: [ocio-dev] nuke-default's sRGB and ACES 1.1 sRGB

On 6/12/19 03:16, Eberhard Hasche wrote:

Hi Gonzalo,

strange!

It is interesting. Maybe there is a look buried in the MetaData i. e. a tinting
or some white point problem.
May you give me the link to the RED-file?

Cheers

Eberhard

It happens with any RED file, but if you want one to try, try the first
clip (the one with the guy in the motorcycle) from the sample 3d files:

http://downloads.red.com.s3.amazonaws.com/sample-r3d-files/w8kvv-sth-48fps-10to1redcode_FF.RDC.zip

When I decompress it as HalfFloat and try the Log* WideGamutRGB, I get a
posterized look.  When I decompress it as 16bit short, I get a better
but too dark image.

On 6/12/19 13:02, Eberhard Hasche wrote:

Hi Gonzalo,
maybe you should consider that something in your pipeline is broken.

I tried your file out and all worked fine. Attached are two Nuke files (one ACES 1.1, the other
Nuke default) with all necessary color conversion nodes.
I rendered out two 1/8th resolution jpg images set to Rec709. The only difference in the color pipeline is that with the nuke-default image,
the picture-rendering part is missing, so it is clamped at 1.o whereas the
aces image is a bit brighter because parts of the luminance above 1.o has been rolled in.


cheers

Eberhard

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 sRGB/Rec709.

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 display/view transform.

Thank you very much for the Nuke scripts, btw.  I had to download a demo of nuke but it was worth it.

Hi Gozalo,

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.

Cheers

Eberhard

----- 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,
maybe you should consider that something in your pipeline is broken.

I tried your file out and all worked fine. Attached are two Nuke files (one ACES 1.1, the other
Nuke default) with all necessary color conversion nodes.
I rendered out two 1/8th resolution jpg images set to Rec709. The only difference in the color pipeline is that with the nuke-default image,
the picture-rendering part is missing, so it is clamped at 1.o whereas the
aces image is a bit brighter because parts of the luminance above 1.o has been rolled in.


cheers

Eberhard

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
sRGB/Rec709.

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
display/view transform.

Thank you very much for the Nuke scripts, btw.  I had to download a demo
of nuke but it was worth it.

On 7/12/19 04:38, Eberhard Hasche wrote:

Hi Gozalo,

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.

Glad to know.

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.

Currently, I cannot get the same result with the sRGB/rec709 of ACES.  I get a close to good, but darker  and more saturated image, as I got with exrs.  This is the issue with the RRT+ODT.

I don't need to set the color space to Input - Red - RedLog3G10 - RedWideGamutRGB as that is created by the RED SDK automatically when I load the .r3d file as a half float image.   That's what I meant by not using the middle node in the nuke default script (the matrix transform you had) and instead using a scene linear setting for the input.  With that, I got it to match the output you were getting from Nuke12.

When using the ACES config file, the sRGB/rec709 (ACES) are darker due to the RRT+ODT issue as you pointed out before, so I get a darker image instead of a brighter one, following a similar approach to setting the input to scene linear.

Not sure if I am explaining myself properly.

On 7/12/19 15:26, Gonzalo Garramuño via Lists.Aswf.Io wrote:

When using the ACES config file, the sRGB/rec709 (ACES) are darker due to the RRT+ODT issue as you pointed out before, so I get a darker image instead of a brighter one, following a similar approach to setting the input to scene linear.

Okay, here's a crazy one.  If I decode the R3D clip as 16 bit, and I set the input color space to Output - Rec.709 and set the view to Rec.709, I get a matching picture to the one you saved out from Nuke12.

It is clear the RED SDK does some magic behind the scenes, but it isn't clear to me what or why.

On 7/12/19 17:41, Gonzalo Garramuño via Lists.Aswf.Io wrote:

It is clear the RED SDK does some magic behind the scenes, but it isn't clear to me what or why.

Okay, I found out what magic it is.  The R3DSDK has an ImageProcessing struct and I was not setting it.  Once I set it to the camera settings, everything started to match.  Note that besides the camera settings there is the RMD sidecar settings which Nuke can load with Load RMD.  By default, with no image settings set, the RMD file is used.  That's why I was not matching at all.

Now, all is good with all RED files I tried.

--
Gonzalo Garramuño