Malcolm,

I don't see that the reference space should be separate in the profile. It's important, but it is just a role. Where the reference sits in the xml or yaml should matter much. Although quite a bit of effort is going into making the configuration files readable one of the goals of ocio, so I thought, was to not manually edit these files. I would imagine that there will be binary versions of configurations files not long after luts can be fully embedded.

As a personal implementation preference I would only want to implement the definition of the reference as a pointer to another colorspace.

Just my 2 cents.

-Joseph



________________________________________
From: ocio...@... [ocio...@...] On Behalf Of Malcolm Humphreys [malcolmh...@...]
Sent: Monday, October 25, 2010 5:48 AM
To: OpenColorIO Developers
Subject: [ocio-dev] Reference !<Colorspace>

Do you think the 'reference' colorspace should in a separate section in the profile? This would be similar to the PCS in the icc world. It could be an extra line 'reference: !<ColorSpace> ...' before the colorspaces in the profile. The 'reference' name could be reserved so that colorspace -> reference transforms could work the same.

I can see this working as roles with ROLE_REFERENCE but it really feels like a more central OCIO concept than roles and should be separated.

Also looking at the serialization with to_referance and from_referance, I'm thinking it would be easy to read if it was structured like this? what do you think?

--from--
to_reference: !<GroupTransform>
children:
- !<FileTransform> {src: "", interpolation: unknown}
- !<CineonLogToLinTransform>
max_aim_density: [2.046, 2.046, 2.046]
neg_gamma: [0.6, 0.6, 0.6]
neg_gray_reference: [0.434995, 0.434995, 0.434995]
linear_gray_reference: [0.18, 0.18, 0.18]
from_reference: !<GroupTransform>
children:
- !<ExponentTransform> {value: [1, 1, 1, 1]}
--from--

--to--
reference:
to: !<GroupTransform>
children:
- !<FileTransform> {src: "", interpolation: unknown}
- !<CineonLogToLinTransform>
max_aim_density: [2.046, 2.046, 2.046]
neg_gamma: [0.6, 0.6, 0.6]
neg_gray_reference: [0.434995, 0.434995, 0.434995]
linear_gray_reference: [0.18, 0.18, 0.18]
from: !<GroupTransform>
children:
- !<ExponentTransform> {value: [1, 1, 1, 1]}
--to--

.malcolm

I'm not sure what promoting the reference colorspace to something
special - either in the API or the format - buys us. Can you provide
details on how this would make things simpler (or any other benefits
you see)?

Coming clean, I have to admit that in our internal SPI Color library
(the predecessor to OCIO) we actually never exposed a function call to
query the name of the reference colorspace in 7 years of use. There
was always a call to query scene linear, but the fact that this also
happened to be the internal profile connection space was never
relevant to end users.

My thought in adding it to OCIO was for completeness sake when
spec'ing out the ROLE listings, but until it has an obvious use case
perhaps we should remove ROLE_REFERENCE? It can always be added back
in, when needed. (This is probably the API corollary to premature
optimization, where you speculatively add a feature that only adds to
confusion and in practice is never used).

I do believe that understanding what a particular color configuration
uses as its connection space is critical, but in my opinion this is
best solved textually at a configuration level (i.e. config docs).

Thoughts?

In terms of your specific suggestions, I think I would prefer to have
the reference color space just be another colorspace, with no
particular distinction. While it doesn't have a transform block, it
does have all the other colorspace markup, so it really does feel
'colorspace-like'. I could also foresee a situation where someone was
using the connection space implicitly, and it wasn't intended to be
either named or used by the end user. (We havent done this, but I see
no reason to disallow it).

Addressing the extra nesting added to your .ocio transform block, your
version doesn't strike me as any more readable.
old: to_reference.children
new: to.reference.children

Isn't redundant nesting bad?

Perhaps there is a better name for the "to_reference" and
"from_reference" values? I'm totally open to revising that enum name.

-- Jeremy

My concern is when/where we want to have different primaries on
different shows. 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.

In the SPI examples, there was never more than one set of primaries in
use, but that seems unrealistic for the future. Right?

RGB

Rod,

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
management?

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
context.

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

Rod,

This is my partial follow-up to Jeremy's response.

A reference space is a useful concept and Imageworks will use them for AMPAS IIF implementation. The colorimetry will match the specification but how that will be arrived at will be subject to show requirements. . It is going to be a colorspace that will be tailored per production.

OCIO is being cast in ICC like terms that aren't fully relevant. OCIO lacks a color management module portion to handle the gamut mapping and other conversions done in an ICC CMM. OCIO has a different design. It is a framework. Pieces of management can be bolted together without anything 'to clever' happening. OCIO does not specify colorimetry; It is necessary to explicitly document the colorimetric meaning of your transformations. This makes OCIO simplistic and gives the control needed to create any case. OCIO provides the flexibility to implement reference spaces as colorspaces. It also leaves you fully free to define that role as you see fit allowing many individual color pipeline to exist.

-Joseph