Date   

Re: nuke-default's sRGB and ACES 1.1 sRGB

Eberhard Hasche
 

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@gmail.com>
An: "ocio-dev" <ocio-dev@lists.aswf.io>
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.


Re: nuke-default's sRGB and ACES 1.1 sRGB

Gonzalo Garramuño
 

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.


Re: nuke-default's sRGB and ACES 1.1 sRGB

Eberhard Hasche
 

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@gmail.com>
An: "ocio-dev" <ocio-dev@lists.aswf.io>
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


Re: nuke-default's sRGB and ACES 1.1 sRGB

Gonzalo Garramuño
 

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.


Re: nuke-default's sRGB and ACES 1.1 sRGB

Gonzalo Garramuño
 

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


Re: nuke-default's sRGB and ACES 1.1 sRGB

Eberhard Hasche
 

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@gmail.com>
An: "ocio-dev" <ocio-dev@lists.aswf.io>
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?


Re: nuke-default's sRGB and ACES 1.1 sRGB

Gonzalo Garramuño
 

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?


Re: nuke-default's sRGB and ACES 1.1 sRGB

Gonzalo Garramuño
 

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


Re: nuke-default's sRGB and ACES 1.1 sRGB

Eberhard Hasche
 

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@gmail.com>
An: "ocio-dev" <ocio-dev@lists.aswf.io>
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".


Re: nuke-default's sRGB and ACES 1.1 sRGB

Eberhard Hasche
 

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@gmail.com>
An: ocio-dev@lists.aswf.io
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".


nuke-default's sRGB and ACES 1.1 sRGB

Gonzalo Garramuño
 

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


Re: Problems using OCIO with QT and QtOpenGLWidget

Patrick Hodoul
 

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


Re: Problems using OCIO with QT and QtOpenGLWidget

haggi@...
 

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 during openGl drawing process which is called GL_INVALID_OPERATION. The 2d and 3d textures are fine, the only remaining problem is the described one in the new stackoverflow question you mentioned. I removed the ocio code to reduce it to a minimum code. So the problem is simply my insufficient knowledge of OpenGL I suppose.


Re: Problems using OCIO with QT and QtOpenGLWidget

Patrick Hodoul
 

Hi Haggi,

https://stackoverflow.com/questions/58857698/qtopenglwidget-with-opencolorio-gpu-results-in-black-image
The thread disappeared from stackoverflow so I do not have access to all the source code anymore.

vec4 col = texture3D(tex1, vec3(vTexCoord.st, 0));
The default implementation from ociodisplay is tex1 for the image texture (the 2D texture), and tex2 for the 3D LUT texture (the 3D texture).

Here is the default GLSL ociodisplay fragment shader code:
    // Generated by OpenColorIO
 
    vec4 OCIODisplay(vec4 inPixel, 
        sampler3D lut3d) 
    {
    vec4 out_pixel = inPixel; 
    out_pixel.rgb = max(vec3(1.17549e-38, 1.17549e-38, 1.17549e-38), vec3(1, 1, 1) * out_pixel.rgb + vec3(0.00390625, 0.00390625, 0.00390625));
    out_pixel.rgb = vec3(1.4427, 1.4427, 1.4427) * log(out_pixel.rgb) + vec3(0, 0, 0);
    out_pixel = vec4(0.0769231, 0.0769231, 0.0769231, 1) * out_pixel;
    out_pixel = vec4(0.615385, 0.615385, 0.615385, 0) + out_pixel;
    out_pixel.rgb = texture3D(lut3d, 0.96875 * out_pixel.rgb + 0.015625).rgb;
    return out_pixel;
    }
 
 
 
    uniform sampler2D tex1;
    uniform sampler3D tex2;
 
    void main()
    {
        vec4 col = texture2D(tex1, gl_TexCoord[0].st);
        gl_FragColor = OCIODisplay(col, tex2);
    }

Using the wrong sampler could be an explanation as well as not binding resources. In plain OpenGL, the code for the latter is:
    glUseProgram(g_program);
    glUniform1i(glGetUniformLocation(g_program, "tex1"), 1);
    glUniform1i(glGetUniformLocation(g_program, "tex2"), 2);


Note:
There is another similar thread on stackoverflow, is that the same problem?
https://stackoverflow.com/questions/58879364/how-can-i-solve-gl-invalid-operation-error-with-qopenglwidget

Regards,
Patrick




Re: Problems using OCIO with QT and QtOpenGLWidget

haggi@...
 

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, vec3(vTexCoord.st, 0));

I get the expected results. So if I now use the ocio generated shader I get an GL_INVALID_OPERATION during drawing. The problem lies here:

vec4 OCIODisplay(vec4 inPixel, 
    sampler3D lut3d) 
{
vec4 out_pixel = inPixel; 
out_pixel.rgb = max(vec3(1.17549e-38, 1.17549e-38, 1.17549e-38), vec3(1, 1, 1) * out_pixel.rgb + vec3(0, 0, 0));
out_pixel.rgb = vec3(1.4427, 1.4427, 1.4427) * log(out_pixel.rgb) + vec3(0, 0, 0);
out_pixel = vec4(0.047619, 0.047619, 0.047619, 1) * out_pixel;
out_pixel = vec4(0.714286, 0.714286, 0.714286, 0) + out_pixel;
out_pixel.rgb = texture3D(lut3d, 0.96875 * out_pixel.rgb + 0.015625).rgb;
return out_pixel;
}

The line:
out_pixel.rgb = texture3D(lut3d, 0.96875 * out_pixel.rgb + 0.015625).rgb;
produces the GL_INVALID_OPERATION error. If I exchange the
0.96875 * out_pixel.rgb + 0.015625
with something like vec3(.5, .5, .5) I get no error and a solid color as expected. So now I have no idea what I can do.


Re: Problems using OCIO with QT and QtOpenGLWidget

haggi@...
 

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.


Re: Problems using OCIO with QT and QtOpenGLWidget

haggi@...
 

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 check the content of the 3d texture in opengl? I tried it with this fragement shader:

varying vec2 vTexCoord;
uniform sampler2D tex1;
uniform sampler3D tex2;
void main() {
   vec3 t = vec3(vTexCoord, 0.0);
   gl_FragColor = abs(texture3D(tex2, t));
}

to get part of the content of the 3d texture. Even if the content does not make any sense, I should see something if the content is not 0.0, is this correct? So if I see nothing, the 3d texture is black.


Re: Problems using OCIO with QT and QtOpenGLWidget

Patrick Hodoul
 

Hi,

As a first investigation step, did you try using `ociodisplay` directly (i.e. as-is):
  1. `set OCIO=C:/daten/coding/imgview/imgView/AE_OCIO/config.ocio`
  2. `ociodisplay.exe -v c:/daten/testBilder/bake.jpg`   where `-v` displays extra information
  3. Select the same color space

The fragment shader code is perfectly fine (MatrixOp + LogOp + Lut3DOp), and it compiles so I can only think of something related to the OpenGL setup and/or Input texture definition.

Regards,
Patrick


Re: Problems using OCIO with QT and QtOpenGLWidget

haggi@...
 

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 = inPixel;
        out_pixel.rgb = max(vec3(1.17549e-38, 1.17549e-38, 1.17549e-38), vec3(1, 1, 1) * out_pixel.rgb + vec3(0, 0, 0));
        out_pixel.rgb = vec3(1.4427, 1.4427, 1.4427) * log(out_pixel.rgb) + vec3(0, 0, 0);
        out_pixel = vec4(0.047619, 0.047619, 0.047619, 1) * out_pixel;
        out_pixel = vec4(0.714286, 0.714286, 0.714286, 0) + out_pixel;
        out_pixel.rgb = texture3D(lut3d, 0.96875 * out_pixel.rgb + 0.015625).rgb;
        return out_pixel;
    }

The line line
out_pixel.rgb = vec3(1.4427, 1.4427, 1.4427) * log(out_pixel.rgb) + vec3(0, 0, 0);
results in a black color what means log(out_pixel.rgb) is zero. Any ideas why this is the case?


Problems using OCIO with QT and QtOpenGLWidget

haggi@...
 

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 seems to work fine. But since the Qt-Opengl workflow is a little bit different, I suppose I make some mistakes because as soon as I try to use the ocio fragment shader, the image becomes black. If someone could give me a hint I'd really appreciate it.

The cpp code of an example and the whole question can be found here.

https://stackoverflow.com/questions/58857698/qtopenglwidget-with-opencolorio-gpu-results-in-black-image

281 - 300 of 2155