Dynamic color configuration

srluka <srl...@...>

I view these as two separate problems. One is gathering color
information. The other is performing color transforms. OCIO seems to
be focused on the latter. I would like to see the OCIO API stay open
enough to where we can use its color transform capability outside the
confines of a fixed color pipeline. The hybrid approach Jeremy
described may be just what we are looking for.

Another thing I would like to maintain the option for, and that was
hinted at in Jeremy's first response, is different mappings between
color spaces. As an example, when converting two RGB spaces with
different white points you have the option of preserving absolute
colorimetry or performing some form of chromatic adaptation. With a
static configuration, it seems like you have to pick one or the other
since each half of the conversion is built into the color space
definition. So you either have a chromatically adapted workflow, or
you don't. Also, it's a little weird in the sense that the chromatic
adaptation (if you were to use it) would have to be already built into
each colorspace definition (ICC D50 anyone? or maybe you would prefer
ACES D60?) but it may not be explicitly stated. I think this may be
problematic so long as the colorspaces define the halfway conversion
to the reference ("linear") space. There may need to be some
additional option for defining the connection space if we expect to
use anything other than a straightforward colorimetric transform.

On Jun 28, 10:44 am, Rod Bogart <bog...@...> wrote:
Agreed.  The issue isn't how to do the conversion, it is how to
determine the input arguments.

But OCIO has this problem anyway.  There is no definition for how a
given image can help influence what conversion is used.  In a
commercial tool, the conversion is chosen by the user, where the list
of options is everything in the config.

OCIO has routines to do a conversion if the "conversion name" is
provided.  OCIO could easily have routines to do conversions if the
gamma-matrix-gamma is provided.  Either way, commercial tools have to
decide if the conversion hints come from the user, the filename, the
header, the environment, or whatever.


On Sat, Jun 26, 2010 at 5:19 PM, Jeremy Selan <jeremy...@...> wrote:
I thought of a simpler way to summarize the topic:
In dynamic colorspaces, the color transforms are dependent upon a set
of potentially changing input arguments.
Our ideal solution is one where the input argument handing is
standardized so that OCIO can be supported out of the box in
commercial tools. But, the logic that interprets input arguments would
be structured to allow the use of facility-specific code and
-- Jeremy