|
Piotr Stanczyk <piotr.s...@...>
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
|
|
|
Jeremy Selan <jeremy...@...>
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
|
|
|
Jeremy Selan <jeremy...@...>
I may have misunderstood you question upon a second read.
Are you hoping to compute the inverse 3dluts dynamically as needed at
runtime? Or is this a precomputation step?
-- Jeremy
toggle quoted message
Show quoted text
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
|
|
|
Piotr Stanczyk <piotr.s...@...>
I would like to do both. Ideally, for each forward lattice we would
have an on disk representation of the inverse.
However, in the cases that an inverse is not present I would like to
be able to compute the inverse on the fly, as it were.
Indeed, we may well use the same library to generate the on disk file
so I guess I am asking about the dynamic part ...
I'm still digesting your earlier post :)
Piotr
toggle quoted message
Show quoted text
On Tue, Apr 17, 2012 at 2:50 PM, Jeremy Selan <jeremy...@...> wrote: I may have misunderstood you question upon a second read.
Are you hoping to compute the inverse 3dluts dynamically as needed at
runtime? Or is this a precomputation step?
-- Jeremy
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
|
|
|
Piotr Stanczyk <piotr.s...@...>
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
toggle quoted message
Show quoted text
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
|
|
|
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
|
|
|
