Stefan,

This has been brought up before (previously by Rod), and it's a great question.

Thinking out loud...

From a purely technological standpoint, the API required to support a
dynamic color workflow is basically in place. Colorspaces can be
added, deleted, and modified at runtime. The only restriction is that
they need unique names, but thats an easy problem solve. (Also left is
to expose all of the transforms functions you'll need, but this is
easy).

But...

From a design standpoint this approach would have pipeline
implications. Any dynamic colorspace system would likely have custom
logic, and I'd have concerns about the portability of such a system.
My hope is to have support for OCIO in many applications (either as
plugins or natively) right out of the box, and wouldn't want
supporting dynamic colorspaces to throw a wrench in this plan.

So what are the possible implementations?

1) If you only rely on custom (facility specific) OCIO plugins, you
could use the embed the cleverness on your end, and use the existing
dynamic colorspace interface to make all the right things happen.
But this approach isn't ideal, as it would require each client to have
it's own implementation of the clever bits (or link against something
that does), and would prevent you from utilizing built-in OCIO support
in commercial apps. (Which, if OCIO succeeds, will be really
convenient).

2) Put ALL the intelligence in OCIO. Currently, if you have a
colorspace, you've got all you need to know about it. But... what if
colorspaces could have optional arguments? In your example, you could
define a single colorspace that had a section of it that was computed
based on the arguments. Chromaticities in, pixel processing out.

But this makes writing a generic plugin for OCIO much more difficult.
Consider our nuke support. Right now we have nodes that allow for
color space conversion in the comp graph, and custom read-write nodes
that use our colorspace processing instead of the built-in support.
The UI for both cases is essentially a list of strings (the colorspace
names) What would a plugin look like that supported dynamic
colorspaces arguments? The colorspace conversion node would have to
support dynamic parameters, and the artist would need an interface
more complicated than a popdown to deal with the (potentially
optional) options. (The args data could be endoded into a single
string, but this would not make it more artist friendly, probably less
so). I know of a few applications that support this level of plugin
interface customizability, but not many. Also, the read and write
nodes would need to be more complex, as they would be required to
parse the file metadata, and populate the colorspace args
appropriately. Though this task is not difficult, it is facility
convention specific and would require a customized plugin.

But we're going to have to tackle this issue anyways. In the current
SPI color system, while we don't use dynamic colorspaces (we chose to
avoid this for validation reasons), we do use dynamic Display
Transforms. Specifically, on visual effects shows, different shot /
sequences often have different artistic looks - specified by the DI
house - and it's incredibly useful to be able to plug these into our
pipeline. In a concrete example, we have Filmlooks that are constant
across a show, and ones that aren't. In our image viewer, you can
view images with "Film" - a generic look - or "Film Onset", which is a
shot varying look that encompasses onset viewing parameters as
manipulated by the client. It would be great if we could support both
systems (your dynamic colorspaces, and our dynamic viewing luts) with
one approach.

3) Why not a hybrid system? For example, I could envision a plug-in
system (which I previously denounced in a prior email), whose inputs
were a bunch of information (filename, file metadata, all environment
variables, etc), and a plugin had the opportunity to interpret this
information in a facility specific manner, and return a dynamically
constructed colorspace. Because the inputs to the custom logic were
on rails, the OCIO plugins could be standardized and have a chance to
work right out of the box, but there would also be a customizable API
that facility specific code could be written against. And, if you had
to send support for any custom part out of house, the dynamic
colorspaces could always be 'baked' to a non-plugin ocs system for
export.

This approach also feels cleaner because it would not require anyone
to agree on what the "right" mapping is (across facility, I mean).
In your example, what matrix will you use for the transform? It could
be a simple chromaticity mapping, but maybe some other facility would
need to support different white points, and thus would require a
chromic adaptation matrix. Or, maybe you're converting wide gamut P3
to r709, and gamut mapping must be considered... My point is that only
*you* know about the exact situational requirements for what transform
is most appropriate, so the code turning a set of primaries into an
explicit set of image processing operations is must be highly
configurable, and will likely be specific to the use cases you find
yourself working with. Another point for the hybrid plugin approach.


In terms of timeline, we're not quite at the point where I can look at
implementing a potential solution. I'm in middle of getting the GPU
chunk running, and after that will be paying attention to better
default configurations and adding additional client app support.
(which should put us near siggraph). But, after that I think it would
make sense to open this back up.

Is there some sort of really simple solution I'm missing? :)

-- Jeremy