Re: Question about IIF config


Joseph Slomka <jsl...@...>
 

Marie,
 
I am VERY late to the party but a linear spaced 32 or 64 segment lut from aces to a ssrt/odt will be insufficent.
You can create a ACES ADX-> rrt/odt  32 or 64 lut and get acceptable results.  
 
 
-Joseph



From: ocio...@... [mailto:ocio...@...] On Behalf Of Marie Fétiveau
Sent: Thursday, October 27, 2011 7:45 AM
To: ocio...@...
Subject: Re: [ocio-dev] Question about IIF config

Great :)
That's much much better.
Thanks a lot !
I still have some small differencies comparing OCIOColorspaceNode and my two TuttleCTL nodes.
But I need to compare with CTLRender just to be sure it's not a pb with TuttleCTL.

I have another pb. When I export a 3DLUT thanks to ociobakeLut and compare the resulting LUT (using a VectorField node) with the output of a OCIOColorspace node, there a noticable shift. 
Here's my command : ociobakelut --inputspace aces --outputspace rrt_sRGB --format flame aces_to_ODT_sRGB.3dl

Assuming it's a LUT approximation problem, I tried to export 32, 64 and 128 segments LUTs. And indeed, the more I add segments, the less the shift is important.
But even at 128 segments (which is huge), there's still a tiny shift.

May be the RRT is so complex that a linear sampled LUT couldn't be enough ?

Anyway, on the way out I noticed a bug in ociobakeLut using the --cubesize option and exporting 3dl : the header is always computed for 17 segments.
For exemple with cubesize=32 :
header = 0 64 128 192 256 320 384 448 512 575 639 703 767 831 895 959 1023
should be = 0   33   66   99   132   165   198   231   264   297   330   363   396   429   462   495   528   561   594   627   660   693   726   759   792   825   858   891   924   957   990   1023

Thanks again.

Marie

On Wed, Oct 26, 2011 at 12:11 AM, Jeremy Selan <jeremy...@...> wrote:
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
>>
>>
>

Join ocio-dev@lists.aswf.io to automatically receive all group messages.