Re: A qq on 3d luts


Jeremy Selan <jeremy...@...>
 

Correct.

You're only going to define a single colorspace (i.e., the same you
have now), but for each colorspace you will explicitly define 2 sets
of transforms, specifying each direction explicitly (where 3d luts are
only applied in the forward direction).

The list of colorspaces will appear identical in client apps across both cases.

Under the hood, when a clients queries the transform from ColorSpace A
to ColorSpace B, it will rely on querying the list in the appropriate
direction. So if previously, going from A->B worked by applying a
3dlut, then the 'automatic' conversion from B->A would fail. But if
you define both directions, A->B and B->A will both be valid
transformations.

You can, of course, hang yourself with this flexibility by defining
forward and inverse transforms which are not matched pairs. So please
avoid that.

ociocheck (command-line app included with OCIO) will print out which
color spaces are applicable bidirectionally, vs. input-only or
output-only. Look for "output-only" in the listing.

-- Jeremy

On Tue, Apr 17, 2012 at 3:23 PM, Piotr Stanczyk
<piotr.s...@...> wrote:
nice ... so I presume that the utility functions for returning the
number of color spaces will take this into account and not show me
'double' entries?

Also, given the set up below, is it sufficient to simply set the
direction of the transform in the client code?

tks

- Piotr

On Tue, Apr 17, 2012 at 2:48 PM, Jeremy Selan <jeremy...@...> wrote:
We do something similar internally.

(Indeed, we probably use the same inverse code you do.  CTL's
scattered data point interpolation, anyone?) :)

In any OCIO::ColorSpace, you can define the transform used to convert
either 'to reference', 'from reference', or both.  In this case, we
will define both.

Real World Example:

 - !<ColorSpace>
   name: qt16
   family: qt
   equalitygroup:
   bitdepth: 16ui
   description: |
     qt16 :colorspace used for burning the video look into rgb files
   isdata: false
   allocation: uniform
   to_reference: !<GroupTransform>
     children:
       - !<FileTransform> {src:
OZ-2D-HDPrj.14July2011-Inv.Autodesk.3dl, interpolation: linear}
       - !<ColorSpaceTransform> {src: rclg16, dst: lnf}
   from_reference: !<GroupTransform>
     children:
       - !<ColorSpaceTransform> {src: lnf, dst: rclg16}
       - !<FileTransform> {src: OZ-2D-HDPrj-14July2011.Autodesk.3dl,
interpolation: linear}

-- Jeremy


On Tue, Apr 17, 2012 at 2:45 PM, Piotr Stanczyk
<piotr.s...@...> wrote:
Hi,

I have a library that wraps color processing engines including OCIO.
This library has a call to inverse. Whilst I am able to generate the
inverse of a 3d lut (with all the usual caveats and edge cases) I am
not sure how I can 'register' the existence of this object with OCIO.

I was thinking I would need a abstracted stream interface for this or
something along the lines of:

* internally generate the inverse 3d lut
* register it with OCIO
* store a 2nd OCIO transform that is parameter synced with the forward transform

Should I be looking at deriving a custom transform instead?  Any
thoughts would be most welcome ....

Piotr

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