Hello all !
I'm having a look at IIF config.ocio and I was wondering how you build
the aceslg2_to_Rec709.cube LUT for the rrt_odt_r709 colorspace.
I'm asking because when I compare an OCIOColorspace node (in : aces, out :
rrt_odt_r709) and two TuttleCTL nodes (one with the RRT 2.2.1 and another
with the REC701 softproof ODT), there are some differences :
- a small shift
- + some noise in yellows with OCIOColorspace node.
Here's a screenshot of my nuke scene and a jpg export with TuttleCTL nodes
and an OpenColorIO Node.
For my tests, I'm using an XRite colorchart shot with a Red One and exported
in EXR thanks to REDCineX (ACES option enabled).
am I mis-using the OCIOColorspace node ?
Anyway, I will be pleased to understand how the LUT was processed and
configured in the ocio config file.
I don't fully understand the purpose of the AllocationTransform vars before
the FileTransform :
- !<ColorSpace>
    name: rrt_odt_r709
    family: rrt_odt_r709
    bitdepth: 32f
    isdata: false
    allocation: uniform
    allocationvars: [0, 1]
    from_reference: !<GroupTransform>
      children:
        - !<AllocationTransform> {allocation: lg2, vars: [-10.4739,
5.52607]}
        - !<FileTransform> {src: aceslg2_to_Rec709.cube, interpolation:
linear}


Thanks a lot !
Marie

Thanks for the quick answer and the explanation :)
I tried this afternoon to create my own aceslg2_to_Rec709 LUT but I'm still
not sure to understand how it should work.
I started to give a quick try with the Nuke Log2Lin node to see what
happened.
So I connected a CMSTestPattern + a Nuke LogToLin node + my 2  CTL node (RRT
+ ODT) + a generate LUT to create a logToLin_RRT_ODTr709.cube.
I also create a linToLog.cube (which correspond to Nuke LinToLog).
And I set the rrt_odt_r709 colorspace like this :
from_reference: !<GroupTransform>
      children:
        - !<FileTransform> {src: linToLog.cube, interpolation: linear}
        - !<FileTransform> {src: logToLin_RRT_ODTr709.cube, interpolation:
linear}
When I compare the two CTL nodes and the OCIOColorspace, that's not that bad
but there's a kind of offset + gamma shift...
 A picture is often better than a long talk away (I put the viewer in sRGB
instead linear to emphasize the shift on the screenshot).
Where's my mistake ?
Thanks a lot :)
Marie

On Tue, Oct 4, 2011 at 7:24 PM, Jeremy Selan <jeremy...@...> wrote:

Marie,

Thanks for catching this!   The currently shipping IIF configuration
is based on an older specification (I forget the exact version, but
it's around 8 months old), so my hope is the versions will explain the
differences you are seeing.  We've wanted to update to the latest RRT
for awhile now, so let us take a stab at it and we'll see if it fixes
everything.  We will also take care to note in the profile which RRT
version it is specifically, to help avoid ambiguity in the future.

The noise (discontinuity) you are seeing in the 3d RRT lut is an
artifact of how we originally generated this table, we'll make sure
it's all fixed in the updated version.

The AllocationTransform you mention describes a linear -> log
transform (a perfect mathematical log operator), where the range from
( 2^-10.4739 , 2^5.52607)  is rolled into (0.0-1.0) for sampling with
a 3d lut.  The lut was generated by taking a 3d lattice image (0-1) ,
unwarping it through the inverse of the transform, and then applying
the analytical rrt.

Thanks!

-- Jeremy


2011/10/4 Marie Fétiveau <m...@...>:

Hello all !
I'm having a look at IIF config.ocio and I was wondering how you build
the aceslg2_to_Rec709.cube LUT for the rrt_odt_r709 colorspace.
I'm asking because when I compare an OCIOColorspace node (in : aces, out
:
rrt_odt_r709) and two TuttleCTL nodes (one with the RRT 2.2.1 and
another
with the REC701 softproof ODT), there are some differences :
- a small shift
- + some noise in yellows with OCIOColorspace node.
Here's a screenshot of my nuke scene and a jpg export
with TuttleCTL nodes
and an OpenColorIO Node.
For my tests, I'm using an XRite colorchart shot with a Red One and
exported
in EXR thanks to REDCineX (ACES option enabled).
am I mis-using the OCIOColorspace node ?
Anyway, I will be pleased to understand how the LUT was processed and
configured in the ocio config file.
I don't fully understand the purpose of the AllocationTransform vars
before
the FileTransform :
- !<ColorSpace>
    name: rrt_odt_r709
    family: rrt_odt_r709
    bitdepth: 32f
    isdata: false
    allocation: uniform
    allocationvars: [0, 1]
    from_reference: !<GroupTransform>
      children:
        - !<AllocationTransform> {allocation: lg2, vars: [-10.4739,
5.52607]}
        - !<FileTransform> {src: aceslg2_to_Rec709.cube, interpolation:
linear}


Thanks a lot !
Marie

Your example looks good to me.  Can you test the sub components of
your transform?

If you skip the ctl nodes, and only try the log2lin portions, does
that result in an identity transform?

Feel free to send me your lut files / .nk files offline, I'd be happy
to take a look as well.

-- Jeremy

2011/10/5 Marie Fétiveau <m...@...>:

Thanks for the quick answer and the explanation :)
I tried this afternoon to create my own aceslg2_to_Rec709 LUT but I'm still
not sure to understand how it should work.
I started to give a quick try with the Nuke Log2Lin node to see what
happened.
So I connected a CMSTestPattern + a Nuke LogToLin node + my 2  CTL node (RRT
+ ODT) + a generate LUT to create a logToLin_RRT_ODTr709.cube.
I also create a linToLog.cube (which correspond to Nuke LinToLog).
And I set the rrt_odt_r709 colorspace like this :
from_reference: !<GroupTransform>
      children:
        - !<FileTransform> {src: linToLog.cube, interpolation: linear}
        - !<FileTransform> {src: logToLin_RRT_ODTr709.cube, interpolation:
linear}
When I compare the two CTL nodes and the OCIOColorspace, that's not that bad
but there's a kind of offset + gamma shift...
 A picture is often better than a long talk away (I put the viewer in sRGB
instead linear to emphasize the shift on the screenshot).
Where's my mistake ?
Thanks a lot :)
Marie

On Tue, Oct 4, 2011 at 7:24 PM, Jeremy Selan <jeremy...@...> wrote:

Marie,

Thanks for catching this!   The currently shipping IIF configuration
is based on an older specification (I forget the exact version, but
it's around 8 months old), so my hope is the versions will explain the
differences you are seeing.  We've wanted to update to the latest RRT
for awhile now, so let us take a stab at it and we'll see if it fixes
everything.  We will also take care to note in the profile which RRT
version it is specifically, to help avoid ambiguity in the future.

The noise (discontinuity) you are seeing in the 3d RRT lut is an
artifact of how we originally generated this table, we'll make sure
it's all fixed in the updated version.

The AllocationTransform you mention describes a linear -> log
transform (a perfect mathematical log operator), where the range from
( 2^-10.4739 , 2^5.52607)  is rolled into (0.0-1.0) for sampling with
a 3d lut.  The lut was generated by taking a 3d lattice image (0-1) ,
unwarping it through the inverse of the transform, and then applying
the analytical rrt.

Thanks!

-- Jeremy


2011/10/4 Marie Fétiveau <m...@...>:

Hello all !
I'm having a look at IIF config.ocio and I was wondering how you build
the aceslg2_to_Rec709.cube LUT for the rrt_odt_r709 colorspace.
I'm asking because when I compare an OCIOColorspace node (in : aces, out
:
rrt_odt_r709) and two TuttleCTL nodes (one with the RRT 2.2.1 and
another
with the REC701 softproof ODT), there are some differences :
- a small shift
- + some noise in yellows with OCIOColorspace node.
Here's a screenshot of my nuke scene and a jpg export
with TuttleCTL nodes
and an OpenColorIO Node.
For my tests, I'm using an XRite colorchart shot with a Red One and
exported
in EXR thanks to REDCineX (ACES option enabled).
am I mis-using the OCIOColorspace node ?
Anyway, I will be pleased to understand how the LUT was processed and
configured in the ocio config file.
I don't fully understand the purpose of the AllocationTransform vars
before
the FileTransform :
- !<ColorSpace>
    name: rrt_odt_r709
    family: rrt_odt_r709
    bitdepth: 32f
    isdata: false
    allocation: uniform
    allocationvars: [0, 1]
    from_reference: !<GroupTransform>
      children:
        - !<AllocationTransform> {allocation: lg2, vars: [-10.4739,
5.52607]}
        - !<FileTransform> {src: aceslg2_to_Rec709.cube, interpolation:
linear}


Thanks a lot !
Marie

Ok, I didn't figure out what were the particularities of "lustre" and
"flame" 3dl formats. That makes sense. I needed a 3dl so I used by default
the flame format.
But it is still strange to me : when using the --cubesize 32, the generated
LUT is really on 32 segments. Only the header is on 17 segments. If I
replace the 17 header by a 32 header, the LUT works on Nuke and RV (with a
17 header, I get weird colors).
Does that mean that Flame, always need a 17 header but can neverthemless
parse other size LUTs ?
thanks !
Marie

This feels like a bug (not having the shaper lut obey the specified size).

If I remember correctly (the last time I tested at least) flame only
supportex size 17 luts, so even if we make the fix it wont effect
that.  The real test would be to validate the lustre can load a 3dl
with a sized 32 header.

-- Jeremy


2011/10/28 Marie Fétiveau <m...@...>:

Ok, I didn't figure out what were the particularities of "lustre" and
"flame" 3dl formats. That makes sense. I needed a 3dl so I used by default
the flame format.
But it is still strange to me : when using the --cubesize 32, the generated
LUT is really on 32 segments. Only the header is on 17 segments. If I
replace the 17 header by a 32 header, the LUT works on Nuke and RV (with a
17 header, I get weird colors).
Does that mean that Flame, always need a 17 header but can neverthemless
parse other size LUTs ?
thanks !
Marie