Re: Reference !<Colorspace>

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


Answering your short email with a long essay... (just had a coffee)

My concern is when/where we want to have different primaries on
different shows.
I understand your concern.

If we wanted to solve this today -- leveraging OCIO -- the simplest
approach would be to use naming conventions to denote differences
between shows. Colorspaces would only have identical names if they
were cross-show compatible, and all other 'show specific' spaces would
be uniquely named at a facility level.

Say, for example, you had Show A which used rec709 primaries, and Show
B which used P3 primaries. You could define 2 profiles:

Show A OCIO Profile: (r709 primaries)
-colorspace: lin_709
transform: none
-colorspace: lin_p3
transform to_reference : p3_to_r709.mtx

Show B OCIO Profile: (p3 primaries)
-colorspace: lin_p3
transform: none
-colorspace: lin_709
transform to_reference: r709_to_p3.mtx

Then, when you encountered an image on disk, as long as you could
uniquely identify it as belonging to either lin_709, or lin_p3 it
could be loaded, and work sensibly on either show. This has minimal
ambiguity, and doesnt rely on any 'dynamic' conversions. If you load
an image on Show A, it uses Show A's profile. Load it on Show B, it
uses Show B's profile. If, during production on "B", you encounter an
unforseen color issue you can tweak B profile, and show A will stay
locked off in its own sandbox. Ideal interoperability ruined? Yes.
But do both shows deliver? Yes. :) ... Load it on show C?
(which doesnt know about lin_p3 or lin_709)? It wont know about that
color space, and will throw an error rather than silently guessing at
an answer. Also a good thing.

Of course, this approach relies on your facility creating inoperable
profiles (and not introducing ambiguous naming), but it's already in
your power to do so.

The fleshed out Imageworks OCIO profiles we'll be releasing later this
week (hopefully) are NOT the only way of working. We would of course
presume that any large facility would use prefer to used a completely
customized workflow. But, our hope is that our profiles may be useful
at small facilities where they just want a reasonable answer right out
of the box.

We would be delighted if other studios or vfx shops distributed their
OCIO profiles, and would love to roll them in as default examples as
well! What better way to learn about alternate approaches to color

Rod- if you're allowed to say publicly - how many sets of color
primaries are we discussing here? Is it a handful of predefined
options, or do you foresee a situation where you'll have dozens of
sets of primaries (and/or white points) being used on a single show?
How are you managing this problem currently?

As we've discussed before, if you truly won't know about what sets of
primaries will be allowed until runtime, or if we're talking about
more than a handful of primaries, then the only sensible option is to
use a dynamic colorspace plugin API. (which will let you create
transforms on the fly.) I am still very enthusiastic about adding
this, though being realistic on time, I don't believe we'll be able to
get to it before the new year.

At SPI we do have more than one set of primaries in use, but very
rarely within the same show. When we do need to interchange image
assets between shows, we often create a custom colorspace suited for
that purpose. This flexibility / explicitness is often preferable to
doing the "right" thing automatically, as "right" often depends on

A simple example: Say you have a texture asset (diffuse color?)
from our P3 primary show, and you want to re-use it on a 709 show.
What conversion is most appropriate? If you want to preserve the
absolute look (such as for a low saturation blue skydome), probably a
matrix transform is justified. But, what if you want to use it as a
source texture, where it will undergo further image manipulation? The
P3->709 conversion has a substantial potential to introduce clipping,
if it's going to undergo further color correction anyways, loading it
in 'raw' may be preferable. I'll ignore related topic of white point
adaptation, but I could forsee some circumstances where you would want
to preserve the look of the original white point, and other
circumstances where one may prefer to have equal code values in p3 map
to equal code values in r709.

 So the reference space is probably a particular RGB
space (rather than XYZ), and it is not obvious what that is by
examining a to_linear function.
I am curious... it sounds like you're grasping for some sort of
system where the reference colorspaces are tagged with enough
information so that OCIO is able to build up transforms between
unrelated profiles automatically. Am I correct here? What sort of
information would be required to be tagged on the reference space to
allow this?

Unfortunately, in VFX work it's quite common to use a set of primaries
that are only defined implicitly (in that they're a 1D transformation
away from a log scan). If I were to link up one of these VFX
workflows with a colorimetricly 'pure' CG profile, what should happen?

If a 1d-linearized log scan *is* the only definition of the reference
colorspace, what could the OCIO profile to be tagged with to allow you
to undo it? A film stock? Note: The Academy's work with IIF is an
attempt to answer this question, and the complexities they have
encountered with the IDTs + RRTs very much demonstrate how hard this
issue is to solve with a "one size fits all" approach. Hell, it's
required a new film scanning spec!

Wrapping this whole complex issue into "naming" is a rather tidy solution.

Color management is in many ways a huge can of worms, and the question
of whether OCIO will -- or should -- succeed is very much still up in
the air. It's my strong belief that to give OCIO 1.0 its best chance
at becoming a success, it's preferable to keep it as close as possible
in philosophy to the workflow we've validated at SPI these last years.
We've had successful visual effect shows and successful animated
features that have relied on completely different approaches to color.
Different configurations. Same library. Same plugins. This approach
is what we want to share with OCIO. From my perspective, there's
minimal amount of SPI-ness left in OCIO at this point. And the major
conceptual assumptions we've made are probably best left in there,
lest we screw up the good in pursuit of perfect.

I have no misconceptions that OCIO will solve 100% of the color
problems out there, but if it's flexible enough to let the majority
of facilities (both big and small) plug into it, then it will at least
be a step in the right direction.

You are allowed to strongly disagree. I like learning new things. :)

-- Jeremy

Join to automatically receive all group messages.