Date   

Idea: Remove boost:shared_ptr

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

Would anyone be against us copying the shared_ptr implementation
internally into OCIO? That would let us make the OCIO boost
dependency optional, which would let it compile on a plain-vanilla OSX
install. The only other part of the code that relies on boost is the
testing framework, which is already if def'd. So if the user has
boost, you'll get the testing. If the user doesnt have boost, it will
skip testing.

Thoughts?

-- Jeremy


Review: Added missing role enum to python

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

Trivial addition, exposed ROLE_DEFAULT to python.

commit 82dd5a4666f7c5456361e9ec7d78107742e5b427

-- Jeremy


Re: ocio_core_tests linking issue on Ubuntu 10.10

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

I haven't seen that issue before, but it looks like it's related to
the testing framework (which relies on boost). I'll try to get an
Ubuntu machine up in the next few days for testing.

But... in the meantime, you can disable compilation of the testing app
by editing CMakeList.txt (in the root dir), and commenting out the
following line: (Add a "#" to make the line a comment).

#add_subdirectory (src/core_tests)

I can add this as a command-line configuration option if the hack has
to live beyond the week.

Please let me know if compilation succeeds with this line commented out?

Thanks!

-- Jeremy

On Tue, Nov 2, 2010 at 9:37 AM, Andrew Hunter <and...@aehunter.net> wrote:
Hey everyone,

I've encountered a linker issue on Ubuntu 10.10 with ocio-0.7.0. I was
wondering if anyone could shed some light on whats going on?


Linking CXX executable ocio_core_tests
/usr/lib/gcc/x86_64-linux-gnu/4.4.5/../../../../lib/crt1.o: In
function `_start':
(.text+0x20): undefined reference to `main'
collect2: ld returned 1 exit status
make[2]: *** [src/core_tests/ocio_core_tests] Error 1
make[1]: *** [src/core_tests/CMakeFiles/ocio_core_tests.dir/all] Error 2
make: *** [all] Error 2

Has anyone else been able to successfully build 0.7 on Ubuntu?

Cheers,

Andrew


New OCIO users email list

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

We're starting to get some actual OCIO users, so it's time to start a
new mailing list:

http://groups.google.com/group/ocio-users

This will focus on issues related to color profile development, artist
workflows, best practice, etc.
Please sign up if you're interested.

Thanks!

-- Jeremy


ocio_core_tests linking issue on Ubuntu 10.10

Andrew Hunter <and...@...>
 

Hey everyone,

I've encountered a linker issue on Ubuntu 10.10 with ocio-0.7.0. I was
wondering if anyone could shed some light on whats going on?


Linking CXX executable ocio_core_tests
/usr/lib/gcc/x86_64-linux-gnu/4.4.5/../../../../lib/crt1.o: In
function `_start':
(.text+0x20): undefined reference to `main'
collect2: ld returned 1 exit status
make[2]: *** [src/core_tests/ocio_core_tests] Error 1
make[1]: *** [src/core_tests/CMakeFiles/ocio_core_tests.dir/all] Error 2
make: *** [all] Error 2

Has anyone else been able to successfully build 0.7 on Ubuntu?

Cheers,

Andrew


Updated Color Profiles

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

Color profiles suitable for OCIO 0.7 have been posted, along with
basic documentation.

See https://sites.google.com/site/opencolorio/profiles for additional
information.

Note 1: Thanks to Joseph Slomka for putting these together!
Note 2: The docs on the spi-anim profile will be posted tomorrow.
Note 3: An additional profile, nuke-default, will be posted later this
week. It provides OCIO emulation for the current default Nuke color
processing.

-- Jeremy


Re: Reference !<Colorspace>

Joseph Slomka <jsl...@...>
 

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

-----Original Message-----
From: ocio...@googlegroups.com [mailto:ocio...@googlegroups.com] On Behalf Of Rod Bogart
Sent: Tuesday, October 26, 2010 5:14 PM
To: ocio...@googlegroups.com
Subject: Re: RE: [ocio-dev] Reference !<Colorspace>

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

On Mon, Oct 25, 2010 at 10:17 PM, Jeremy Selan<jeremy...@gmail.com> wrote:

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


Re: Review: Inital pass at searchpath impl

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

There's a lot of good ideas here, it's taken me a bit of time to think
through the implications.

I'm going to be out of town for the remainder of the week, perhaps we
could try an internet call early next week to discuss these specifics
further? (Skype, iChat, etc). Many of these points can probably be
hashed out easier live, and then we can summarize our thoughts back to
the list.

What about per shot balance grades and look / creative grades, I would cry if I needed to create a zip ocio profile per shot to do this. > Then re-syncing these profiles would be a nightmare.
Agreed. Under no circumstances are we going to make per-shot looks
complicated to use. We're in the same boat here.

JS: I think it will be preferable when possible to minimize the use of envvars.
MH: Can you elaborate on this?
Your approach to implementing per-shot looks - using environment
variables within search paths - is clever. However, I'm not sold.
The portion I'm concerned about is the use of environment variables as
a communications mechanism.

For an application (such as a compositor) where you're not changing
show / shot / sequence at runtime the use of envvars is no big deal.
For example, say you have a per-shot display lut
(/job/$SHOT/.../shotgrade.3dl). You could run a script which sets up
the shot environment, launch the APP, and everything just works.

However, consider an image-viewing tool which needs to flipbook
multiple shots (or whole sequences) back to back. I.e., the display
transform, as queried from OCIO, would be different based on the shot
name. Would this approach be possible using an envvar mechanism? I
dont believe so. Envvars are commonly locked down at launch time.
And, even if you could modify it at runtime as playback was in
progress, would you want to? How would you notifiy OCIO that it had
changed? This seems like a tricky implementation, and strikes me as
going down the path of evil.

I would prefer to promote this concept of 'variables' to be an
explicit communications mechanism, rather then using envvars as a
back-door. Alternate implementation options include:

* a config->setVariable option, where variables were available for
use in color transforms. (They could even retain the $SHOW $SHOT
syntax). This way the OCIO plugin could set it as needed, and with
the python API exposed in client apps the list of variables could even
be amended with facility code, as needed at runtime!

* Alternatively, with a less stateful implementation the variables /
arguments could be passed along in the config->getProcessor call. This
may be preferable to those computer scientists among us.

Either way, this passing of variables as arguments to a transforms is
half of the work towards allowing fully dynamic colorspaces. (The
other 1/2 being the plugin API to define the lists of transforms at
runtime).

Perhaps this is good reason to move forward on both ASAP?

-- Jeremy


Re: Review: OCIO namespace update

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

Excellent, thanks.

On Thu, Oct 28, 2010 at 2:31 PM, Malcolm Humphreys
<malcolmh...@mac.com> wrote:
Sorry I never noticed that section in the main CMakelists file, it all looks good.


Re: Review: OCIO namespace update

Malcolm Humphreys <malcolmh...@...>
 

Sorry I never noticed that section in the main CMakelists file, it all looks good.

"Jeremy Selan" <jeremy...@gmail.com> wrote:

Can you be more specific? Which CMakeLists file, the root one or the
one in src/core?

The main CMake file has this chunk,

# Set the default namespace
if(NOT OCIO_NAMESPACE)
set(OCIO_NAMESPACE OpenColorIO CACHE STRING
"Specify the master OCIO C++ namespace: Options include
OpenColorIO OpenColorIO_<YOURFACILITY> etc."
FORCE)
endif(NOT OCIO_NAMESPACE)

What is not working for you?
Can you nuke your build dir and try again 'fresh'?

-- Jeremy

On Wed, Oct 27, 2010 at 11:10 PM, Malcolm Humphreys
<malcolmh...@mac.com> wrote:
I think your missing a set() line in the CMakeLists.txt eg.
..
set(OCIO_VERSION
"${OCIO_VERSION_MAJOR}.${OCIO_VERSION_MINOR}.${OCIO_VERSION_PATCH}")
set(OCIO_NAMESPACE OpenColorIO)
..
Other than that it LGTM.
.malcolm
On 27/10/2010, at 9:16 AM, Jeremy Selan wrote:

OCIO namespace #define is now configured using the CMAKE
configure_file mojo.  This makes namespace errors far less likely, as
it's baked into the header that's a part of make_install.

commits:
d00581c9373806b85416115a58488d57a12be04a

--
Sent from my phone.


Re: Review: OCIO namespace update

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

Can you be more specific? Which CMakeLists file, the root one or the
one in src/core?

The main CMake file has this chunk,

# Set the default namespace
if(NOT OCIO_NAMESPACE)
set(OCIO_NAMESPACE OpenColorIO CACHE STRING
"Specify the master OCIO C++ namespace: Options include
OpenColorIO OpenColorIO_<YOURFACILITY> etc."
FORCE)
endif(NOT OCIO_NAMESPACE)

What is not working for you?
Can you nuke your build dir and try again 'fresh'?

-- Jeremy

On Wed, Oct 27, 2010 at 11:10 PM, Malcolm Humphreys
<malcolmh...@mac.com> wrote:
I think your missing a set() line in the CMakeLists.txt eg.
..
set(OCIO_VERSION
"${OCIO_VERSION_MAJOR}.${OCIO_VERSION_MINOR}.${OCIO_VERSION_PATCH}")
set(OCIO_NAMESPACE OpenColorIO)
..
Other than that it LGTM.
.malcolm
On 27/10/2010, at 9:16 AM, Jeremy Selan wrote:

OCIO namespace #define is now configured using the CMAKE
configure_file mojo.  This makes namespace errors far less likely, as
it's baked into the header that's a part of make_install.

commits:
d00581c9373806b85416115a58488d57a12be04a


Re: Review: OCIO namespace update

Malcolm Humphreys <malcolmh...@...>
 

I think your missing a set() line in the CMakeLists.txt eg.
..
set(OCIO_VERSION "${OCIO_VERSION_MAJOR}.${OCIO_VERSION_MINOR}.${OCIO_VERSION_PATCH}")
set(OCIO_NAMESPACE OpenColorIO)
..

Other than that it LGTM.

.malcolm

On 27/10/2010, at 9:16 AM, Jeremy Selan wrote:

OCIO namespace #define is now configured using the CMAKE
configure_file mojo.  This makes namespace errors far less likely, as
it's baked into the header that's a part of make_install.

commits:
d00581c9373806b85416115a58488d57a12be04a


Re: Review: Updated cmake_minimum_required to 2.8

Malcolm Humphreys <malcolmh...@...>
 

LGTM

On 27/10/2010, at 9:14 AM, Jeremy Selan wrote:

We already required cmake 2.8 (for ExternalProject usage), now this is explicit.

commits:
949855cca45431a6e813ac3b6f3688de0799f379


Re: Review: nuke plugin crash fix

Malcolm Humphreys <malcolmh...@...>
 

LGTM

On 27/10/2010, at 9:14 AM, Jeremy Selan wrote:

Nuke plugins wont crash if the specified $OCIO is invalid.

This issue is related to calling the nuke IOP::error method during
construction, but in the meantime we can at least prevent a crash by
not calling the function.

-- Jeremy

commits:
ecb3b0e41e0bbf5973cf16bf4d39ca0de557155b


Re: Review: Inital pass at searchpath impl

Malcolm Humphreys <malcolmh...@...>
 

We've just started testing the current version of OCIO at Imageworks,
and already we've run into some major confusion regarding lut paths.
This past week's experiences (with Joseph playing the kind role of
guinea pig) illuminates this discussion, and makes me think that some
backtracking may be in order on this topic.
Can you elaborate a little on what was confusing.

* An OCIO profile is not just a single configuration file in isolation
- it's a config AND a set of associated luts. Keeping these together
all times (and conceptually thinking of them as inseparable) is
probably the only way to avoid ambiguity and errors. An OCIO config
is not useful if it gets separated from its luts, and vice-versa. In
fact, if it's possible to separate the two, it WILL happen, and only
bad will come of it. It's hit us once this week, I'd like to prevent
anyone else from ever having to track down this type of issue.

* I'd like for an OCIO profile to be able to be distributed, and used,
either as a single self contained file or as a working directory.
+1 to a self contained file

* Consider, what would the OCIO world look like if we 'locked down' a
fixed directory layout that all profiles had to conform to?

Fixed OCIO profile (in directory form)

rootdir/
config.txt
filetransforms/
a.lut, b.lut, etc.

Point $OCIO at the root directory, (not the config,txt file), and
everything "just works". All search paths, resource paths, go away. A
bit inconvenient? Perhaps. But unambiguous and simple? Definitely.
What about per shot balance grades and look / creative grades, I would cry if I needed to create a zip ocio profile per shot to do this. Then re-syncing these profiles would be a nightmare.

* With this model, the "single file" profile + luts representation
becomes trivial: we would just support pointing $OCIO at a compressed
version of the .ocio directory layout (zip, tgz, etc).
Let me describe how I would like to see OCIO setup on a show.

* central show OCIO profile describing
- working/reference space
- display devices
- colorspace definitions
- luts (relative to this profile)

* show/seq/shot (cdl) balance grades as separate xml on disk

* show/seq/shot (cdl/lut/spline) look / creative grades as separate files on disk

I could see this setup being forked and lock at different stages of production (prepro/onset, trailer, theatrical).

Onset when tech and human resources are limited, being able to setup this up with minimal hassle would be ideal.

For simplicity sake you had some cdl balance grades layout like this.
/job/config/ocio/balance_approved.xml
/job/myseq/config/ocio/balance_approved.xml
/job/myseq/someshot/config/ocio/balance_approved.xml
/job/myseq/othershot/config/ocio/balance_approved.xml

Your search path would be in the central config "/job/$SEQ/$SHOT/config/ocio:/job/$SEQ/config/ocio:/job/config/ocio"

Changing your $SEQ and $SHOT would allow switching between grades.

This is not to say that you might merge this into a more involved system when in house, maybe without using env vars. eg. a Transform plugin which picks up the approved grade from a database.

I think it's important to support both ways of working.

But you do want to make it possible to lock down which files are loaded relative to the profile and which use the searchpath.

I agree this could causes issues.

I would look at having some kind of prefix to filenames to mark them as 'only look in the resource path' this could be by prefixing the paths with an '@' eg. !<FileTransform> {src: @/lg10.spi1d} this would resolve to only paths in the resource path anything without an '@' would look through the search path (in order).

* resourcepath - is relative to the profile, either embedded or on disk
* searchpath - is a ':' ordered list of directories to search for file references
* file references - are absolute paths / '@' in the resourcepath / or somewhere in the searchpath

Want to know what's inside your .ocio.zip config? Easy, just unzip it
using the normal os tools. You can also unzip a profile, drag and
drop a new lut internally, and then re-zip it for distribution. Super
easy, and no lut transcoding needed.

But what would the API look like if we went with this approach? It
would be more directory / file based, and less stream centric.
Would the "write" call write a directory instead? (and copy all
referenced luts into a fixed local lut dir?) Probably.

As foreign as this idea sounds, putting the OCIO configuration on
rails and locking down a fixed directory layout may really help to
minimize errors and confusion going forward.
-1 for fixed directory layout, I think it's important that this is configurable. I can't say how different places will want to setup their pipe. Configurable decision points should be left configurable ( with sensible defaults and examples ;) ).

I think it's important for a process to validate the packaging of a profile. I was hoping for something like:

Package up a profile
$> ociopacakge source.ocio packaged.ocio

This would package up all the absolute and resourcepaths into a packaged ocio profile.

Package up a shot profile
$> ociopackage --resolve-searchpath source.ocio packaged.ocio

This would resolve the searchpath and package up any found files and these would be given '@' references in the packaged.ocio

Unpack a profile
$> ociopackage -x packaged.ocio ~/tmp/

I'm a lot more in favour of a single file with embedded ascii or binary blobs at the bottom. It's quite easy for someone unzip a dir remove a lut and re-zip it and circumvent any validation process.

I also I think people will be checking these into version control systems (aka easy setup publish system) being able to open profiles in a text editor / web browser and reading the header would be really nice rather than having to unzip to check stuff out.

I'm happy to code up a prototype of this in a branch if people are keen to see that idea.

On a slighly different topic, I think it will be preferable when
possible to minimize the use of envvars. Consider the case where the
'global config' (created with $OCIO) is not used. (where config
objects are instead manually initialized). Any options specified with
envvars, such as search paths, will by definition be 'global' and will
have to be worked around (unset) in the the other profiles.
Can you elaborate on this? I don't completely get what you mean, does the '@' in file reference help distinguish between local and global?

.malcolm


-- Jeremy


---------- Forwarded message ----------
From: Malcolm Humphreys <malcolmh...@mac.com>
Date: Mon, Oct 25, 2010 at 3:29 AM
Subject: Re: [ocio-dev] Review: Inital pass at searchpath impl
To: ocio...@googlegroups.com


- fixed a bug with abs searchpath entries
- empty '::' searchpaths now resolve to the profile cwd

http://github.com/malcolmhumphreys/OpenColorIO/commit/5d922362259e86073592481d428926de1054414d

.malcolm

On 25/10/2010, at 6:59 PM, Malcolm Humphreys wrote:

- removed the EnvExpand recusion limits as this didn't work in the production env which
has more than 30 env vars. might want to add limits in later if this becomes a problem.

http://github.com/malcolmhumphreys/OpenColorIO/commit/a172426e59ddebc4ccd0691b796bfe493677ec9f

.malcolm

On 25/10/2010, at 6:17 PM, Malcolm Humphreys wrote:

Inital pass at searchpath impl
- added environment variable string expansion code in PathUtils.h (GetEnvMap() & EnvExpand())
- added FileExists() function to PathUtils.h
- added searchpath functionality into Config:: class (setSearchPath(path), getSearchPath(expand), findFile(filename)) this hasn't be plugged into anything yet.
- added ocio_core_tests.sh.in so we can pass in some env vars for the unit tests

http://github.com/malcolmhumphreys/OpenColorIO/commit/80bfd194bd7fd3d787e7a8795ad63be6050702c6

.malcolm


Re: Reference !<Colorspace>

Malcolm Humphreys <malcolmh...@...>
 


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)?
 
Mostly I see this is for notation, right now profiles infer that all to_reference and from_reference entires go to/from the same reference space.

But I don't need a reference space in 'roles:' or even in 'colorspaces:' for ocio to work. This really isn't a problem if all your reference spaces are the same for all profiles across jobs.

It gets just a little murky when you open the possibilities of different connection spaces in different profiles.

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.
 
Well thats another option, enforce scene_linear as the reference space for all profiles (I would recommend using that as the working space anyhow).

I'm just not sure if that will make it tricker for uptake at smaller shops which would be mostly working in some type of display linear pipe.

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 would remove it till it is needed.

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?
 
Thats not so good if people are sending around profiles with out docs.. 'hmm this profile seems funky but I don't know why, oh and the docs are out of date..' moments.

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).
 
I agree I think having it as a normal colorspace is good, just if there was a specific tag at the top of the profile which told which colorspace was the references space. We could also barf when that colorspace isn't defined in the 'colorspaces:' section.

The use case I keep thinking about is dealing with two profiles with different reference spaces, but maybe this is just over complicating things for where we are right now.

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
 
This was actually: reference:to:Transform()

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.
 
Depending on your thoughts about the reference space we might want some other naming. I was wondering could we rename the <GroupTransform> children param to something like 'items', 'transforms'. (maybe I'm too pedantic parent -> children relationships look like a trees while lists, items etc have an order)

.malcolm


Re: Reference !<Colorspace>

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

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


Re: Reference !<Colorspace>

Rod Bogart <bog...@...>
 

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

On Mon, Oct 25, 2010 at 10:17 PM, Jeremy Selan <jeremy...@gmail.com> wrote:
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


Review: OCIO namespace update

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

OCIO namespace #define is now configured using the CMAKE
configure_file mojo. This makes namespace errors far less likely, as
it's baked into the header that's a part of make_install.

commits:
d00581c9373806b85416115a58488d57a12be04a


Review: Updated cmake_minimum_required to 2.8

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

We already required cmake 2.8 (for ExternalProject usage), now this is explicit.

commits:
949855cca45431a6e813ac3b6f3688de0799f379

1961 - 1980 of 2190