Date   

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


Re: pyOCIO Windows compilation error against Python36

renaudtalon@...
 

That's great news, thank you !


Re: pyOCIO Windows compilation error against Python36

Michael Dolan
 

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.


On Wed, Oct 23, 2019 at 1:01 PM <renaudtalon@...> wrote:
Sorry for re-opening this so late. I did test the fix I thought work among other few things but I can't get OCIO to work with Python 3+ on Windows.
I tested with both OCIO 1.1 and OCIO 2.0 (master branch) and I can't compile against Python3. Any news on when this will be supported ?
Thank you.


Re: pyOCIO Windows compilation error against Python36

renaudtalon@...
 

Sorry for re-opening this so late. I did test the fix I thought work among other few things but I can't get OCIO to work with Python 3+ on Windows.
I tested with both OCIO 1.1 and OCIO 2.0 (master branch) and I can't compile against Python3. Any news on when this will be supported ?
Thank you.


Cancelled Event: OpenColorIO TSC meeting (weekly) - Monday, 14 October 2019 #cal-cancelled

ocio-dev@lists.aswf.io Calendar <ocio-dev@...>
 

Cancelled: OpenColorIO TSC meeting (weekly)

This event has been cancelled.

When:
Monday, 14 October 2019
9:30am to 10:00am
(UTC-07:00) America/Los Angeles

Where:
https://zoom.us/j/924729729

Organizer: Michael Dolan michdolan@...

Description:
Weekly meeting of the OpenColorIO TSC.

Add topics to the meeting agenda.

Meeting notes listed by YYYY-MM-DD.md format at: 
https://github.com/imageworks/OpenColorIO/tree/master/docs/tsc/meetings


Join Zoom Meeting
https://zoom.us/j/924729729

One tap mobile
+16699006833,,924729729# US (San Jose)
+16465588656,,924729729# US (New York)

Dial by your location
        +1 669 900 6833 US (San Jose)
        +1 646 558 8656 US (New York)
        +1 877 369 0926 US Toll-free
        +1 855 880 1246 US Toll-free
Meeting ID: 924 729 729
Find your local number: https://zoom.us/u/abo9cwSMxj


Re: Expected release of OCIO from its new home in AcademySoftwareFoundation/OpenColorIO

jrb@...
 

Thanks for the update Michael,

 That all makes sense. I saw that assignment bug and got worried that cut wasn't something I should really consider. Looking forward to 2.x.

Cheers,
- James

301 - 320 of 2170