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

Glad to know. 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

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

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

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

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

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 -----

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

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

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

Yes, it was a RED sequence, but I was just testing it with scene_linear. What's the IPP2 color pipeline?  Is it some Nuke node, some OCIO config transform or the IPP2 function that appears in the RED

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

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

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

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

No problem. Asking a question is also a way to learn.

Sorry, that's my fault. Yes, indeed, I deleted the original question because the problem has a completely different reason I think. I added some more glGerError() functions and discovered an error

Hi Haggi, The thread disappeared from stackoverflow so I do not have access to all the source code anymore. The default implementation from ociodisplay is tex1 for the image texture (the 2D texture),

So I was able to find out that the 3d texture behaves correctly as much as I can say. At least if I fill it with random values and read it in the fragment shader with: vec4 col = texture3D(tex1,

The above code gives me black pixels even if the lut3dTex is filled with values of 1.0 so there must be a problem with the usage of the 3dtexture and Qt.