Re: Color space transform bidirectionality


Alan Jones <sky...@...>
 

Hi Jeremy,

On Fri, Aug 27, 2010 at 4:18 PM, Jeremy Selan <jeremy...@gmail.com> wrote:
Sorry for the delay in responding. (Had to attend to non-OCIO
responsibilities this week).
No worries :)

The approach you describe is exactly in line with what I've been
thinking. Excellent.
This is great news :)

But there's no code-level distinction
between the types.  Is there any benefit to doing so?
I agree, the only benefit is from a UI perspective to assist the user
in not doing something stupid. Downside to this is sometimes
there is a good reason to do something stupid. So perhaps it would
be best to go for some middle road (listing the logical ones first and
including the type of all transforms for instance).

I'd prefer to just call them "transforms" to leave open the possibility of other correction
math.  (For example, the grading lut could just as easily be a 1D lut,
a 3D lut, or a ASC-CDL).
Sounds like a logical choice of terminology to me.

Your processing pipeline is already expressed in the DisplayTransform.
 You specify the storage LUT (inputColorSpace), the displayLut
(outputColorSpace),  and also optional color correction(s).  (Which
can occur in any color space, including scene linear or a log-like DI
space).  The Nuke OCIODisplay node provides an example of using this
API.
Great stuff :) thanks for sharing. Slowly getting my head around how OCIO
works.

Cheers,

Alan

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