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...@...>
Date: Mon, Oct 25, 2010 at 3:29 AM
Subject: Re: [ocio-dev] Review: Inital pass at searchpath impl
To: ocio...@...


- 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