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.

Thanks Patrick, you are right, the result of the log is black because the values are negative, it works correclty.. stupid me. So it has something to do with the lookup table. Is there any way to

Hi, As a first investigation step, did you try using `ociodisplay` directly (i.e. as-is): `set OCIO=C:/daten/coding/imgview/imgView/AE_OCIO/config.ocio` `ociodisplay.exe -v

Found a possible reason for the black image. In the fragment shader code generated by ocio which look like this: vec4 OCIODisplayA(vec4 inPixel, sampler3D lut3d){ vec4 out_pixel =

Hi, I try to make a simple imageviewer with the help of QT and ocio. From the ociodisplay.cpp I tried to extract the needed pieces and transfer it to a Qt workflow. Displaying pictures with OpenGl

That's great news, thank you !

I'm currently writing new Python bindings for OCIO (with pybind11, targeting the 2.0 release), which will support Python 3 (and 2). Stills a ways to go, but it's in the works.