Malcolm,

I wish I had known you were thinking about writing this particular
piece of code; I probably would have asked you to hold off on it for a
little while... (This is my mistake, I do realize that this task was
listed in the OCIO TODO file).

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.

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

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

* 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).

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.

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.

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