3DL cube format.

bsloan <bsl...@...>

Yes. Agreed. The importer can use the fuzzy greater-than-1/2-max
heuristic for guessing the bit-depths of A and B.
...and be correct most of the time.

On May 26, 7:14 pm, Jeremy Selan <jeremy...@...> wrote:
Cool, thanks for the info.   So it sounds like when we want to write a .3dl
exporter, we'll need to specify which flavor of .3dl to write.  However, on
the import side it still sounds like we'll be able to get away with a
generalized import, presuming we're a bit clever with the bit-depth
interpretation.  Would you agree?

-- Jeremy

On Wed, May 26, 2010 at 7:08 PM, bsloan <bsl...@...> wrote:
Regarding 3dl --
The lore I've been fed is that Mitch Bogdonowicz formerly of Kodak
wrote (invented? burped?) the 3dl "specification" when he was at Kodak
as a quick and dirty solution of 3D LUT ASCII serialization.
Various interpretations have since been adopted (supported?)  by
Arri,  Autodesk, Assimilate and others.
Yes, the initial 1D monochrome shaper array is in some cases in a
different bit depth from the 3D rgb array. What's more, various
applications choke if the header comment fields (those preceded with
a"#") are not 'just so'  (eg. truelight's tl-utils).
I guess the point is that there isn't just one spec for it. Maybe the
way to deal with 3dl is to treat different interpretations as
different formats:
ugly -r- us.