I just rolled out a new iif profile, with updated 3dluts.

You'll note that inside the iif profile (in the lutimages subdir) are
the lattice images used to bake the rrt / odt into 3d luts. So you
should be able to use these image to bake any rrts you may be using
into a lut suitable for inclusion in the profile.

Please let me know if, using this updated approach, you are not able
to recreate an identical result.

-- Jeremy

On Mon, Oct 10, 2011 at 2:58 PM, Jeremy Selan <jeremy...@...> wrote:
> 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
>>
>>
>