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...@mikrosimage.eu>:
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...@mikrosimage.eu>:
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
> compare the resulting LUT (using a VectorField node) with the output of a OCIOColorspace node, there a noticable shift.
The Vectorfield node is a bit buggy - even if you write out a no-op lut (CMS test pattern->GenerateLUT) you get a luminance shift with several formats:
> 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.
Think the "ociobakut --format flame" and lustre 3dl bakers have fixed cube sizes, as I guess the applications only accept these sized LUT's?
If that's true, would be easy to add a more generic --format 3dl that respects the cube size (and have the flame/lustre formats error usefully of you try and change the cube size)
The Vectorfield node is a bit buggy - even if you write out a no-op lut (CMS test pattern->GenerateLUT) you get a luminance shift with several formats:
http://opencolorio.org/FAQ.html#what-are-the-differences-between-nuke-s-vectorfield-and-ociofiletransform
Think the "ociobakut --format flame" and lustre 3dl bakers have fixed cube sizes, as I guess the applications only accept these sized LUT's?
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...@mikrosimage.eu>:
Please let me know if you have any other compatibility issues with 3dl export.
-- Jeremy