I'd like to propose that we define standard directories on each
platform where OCIO configurations might live. Nuke has taken a step
in this direction now that they are shipping with OCIO. They have some
users who launch it with a regular double-click after all, so they let
you store configurations in plug-in path directories and they'll show
up in a user-friendly pop-up menu under the viewer preferences. If we
define a standard directory, then all applications could operate this
way, pointing to the same set of configs.

In the After Effects plug-in, I'm currently storing the .ocio path,
but this ends up being fragile if you move the project or open it on
another platform. If I could just store the name of the configuration
and look for it in a standard location, that would make projects much
more portable. ICC profiles currently work this way.

I don't think this has to get any programming support in the OCIO
library. It would be left up to application developers to scan the
directory, build the menu, and pass a path to
OCIO::Config::CreateFromFile().

My path suggestions:
Mac: /Library/Application Support/OpenColorIO
Windows: C:\Program Files\Common Files\OpenColorIO
Linux: /usr/share/OpenColorIO


Brendan

On Thu, Apr 12, 2012 at 3:51 PM, Brendan Bolles <bre...@...> wrote:

My path suggestions:
Mac: /Library/Application Support/OpenColorIO
Windows: C:\Program Files\Common Files\OpenColorIO
Linux: /usr/share/OpenColorIO

Is this configuration data static or is it expected to change over
time? If it may change then it should go somewhere in /var such as
/var/lib/OpenColorIO/...

Richard

On Thu, Apr 12, 2012 at 1:51 PM, Brendan Bolles <bre...@...> wrote:
> My path suggestions:
> Mac: /Library/Application Support/OpenColorIO
> Windows: C:\Program Files\Common Files\OpenColorIO
> Linux: /usr/share/OpenColorIO


The only thing i would add to this is the windows folder location. The "program files" folders tend to be admin only access, so a better place could be maybe to use the common "app data" folders.

There are a couple of ways to get to it in a version / language agnostic way, the most reliable being:

#include "shlobj.h"

TCHAR szPath[MAX_PATH];
SHGetFolderPath(NULL, CSIDL_COMMON_APPDATA, NULL, 0, szPath);
wprintf(L"%s\n", szPath);

returning:
on win7: c:\ProgramData
on XP:  c:\Documents and Settings\All Users\Application Data

Other option is to use env variables, but thats not as good (you will see why):

%appdata%  :  local user's app data should go here
%allusersprofile%   :   shared user data   <-- this is probably preferred

on win7 these are:
appdata = c:\Users\<username>\AppData\Roaming
allusersprofile = c:\ProgramData    <-- matches what the winapi function returns

on XP these are:
appdata = c:\Documents and Settings\<username>\Application Data
allusersprofile = c:\Documents and Settings\All Users   <-- does not match the winapi function...

You might notice that on XP, the allusersprofile does not return an Application Data subfolder, but the root profile folder instead. The subfolder name is language dependent, so you cant even hardcode an additional "Application Data" in the name :\


Anyhow, the "common files" folder might be good as well, just probably would be non-editable in most cases.


cheers,
laszlo

On Apr 12, 2012, at 2:09 PM, Richard Shaw wrote:

Is this configuration data static or is it expected to change over
time? If it may change then it should go somewhere in /var such as
/var/lib/OpenColorIO/...

Well, people may add configurations from time to time, but it won't be changing as often as the stuff that normally goes in /var, like logs and temp files. Apparently Gimp looks for ICC profiles in /usr/share/color/icc, so that's why I suggested /usr/share/OpenColorIO. It seems to fit the description of /usr/share having "architecture-independent data". Interesting standards document on the subject here:

http://www.pathname.com/fhs/



Brendan

On Thu, Apr 12, 2012 at 7:20 PM, Brendan Bolles <bre...@...> wrote:

On Apr 12, 2012, at 2:09 PM, Richard Shaw wrote:

Is this configuration data static or is it expected to change over
time? If it may change then it should go somewhere in /var such as
/var/lib/OpenColorIO/...

Well, people may add configurations from time to time, but it won't be changing as often as the stuff that normally goes in /var, like logs and temp files.  Apparently Gimp looks for ICC profiles in /usr/share/color/icc, so that's why I suggested /usr/share/OpenColorIO.  It seems to fit the description of /usr/share having "architecture-independent data".  Interesting standards document on the subject here:

Then I think there's really 3 paths to worry about then.

1. Since users should never manually put anything in /usr/share (or
/usr for that matter) I would put stuff that comes packaged into
/usr/share/OpenColorIO.

2. Configurations that are not user specific but also not packaged can
go in /usr/local/share/OpenColorIO.

3. Personal configurations can go in a ~/.OpenColorIO or ~/.ocio type
directory (or whatever path already exists?).

There might also need to be a little priority logic for conflict
resolution. I would say 3 should override 2 and 2 should override 1.

Thanks,
Richard

On Apr 12, 2012, at 2:51 PM, László Sebő wrote:

TCHAR szPath[MAX_PATH];
SHGetFolderPath(NULL, CSIDL_COMMON_APPDATA, NULL, 0, szPath);
wprintf(L"%s\n", szPath);

returning:
on win7: c:\ProgramData
on XP: c:\Documents and Settings\All Users\Application Data

Hmmm, since people will be often be installing these manually, we might not want to get too complicated. There's something to be said for a hard-coded path.

But then this does avoid the problem of using Program Files vs. Program Files (x86). I notice that Adobe actually puts ICC profiles in (x86) and has the 64-bit programs get them from there as well.


Brendan

As long as these can all be overridden by an environment variable and
these are some fall back location I would not object, however without
the ability to define a specific location we would never be able to
use it. I was just recently considering dynamically generating
versioned configs per TASK per USER in a VFX environment (a little
extreme perhaps but I certainly need many more than 1 config :-)

Kevin

On Apr 17, 2012, at 3:01 AM, Kevin Wheatley wrote:

As long as these can all be overridden by an environment variable and
these are some fall back location I would not object, however without
the ability to define a specific location we would never be able to
use it.

Do you mean the environment variable to set the OCIO configuration, or a variable for the directory of configurations?

I've been updating the After Effects plug-in to better support the $OCIO variable. But I think most users of AE (even those in studios) won't be running it with that kind of managed environment, so it's important that OCIO have a user-friendly alternate workflow.

I'm currently letting the user choose between three types of paths to store as the configuration location:

1. $OCIO (get the config from the variable)
2. "spi-vfx" (find the named config in a standard directory)
3. "/Users/me/OCIO/nuke-default/config.ocio" (explicit path)

But the way I currently have it, if the user starts with an explicit path and then adds an $OCIO variable later, the old path won't just stop being used. They'd have to say they were using the $OCIO variable from the start.


Brendan

Do these plans include a provision for handling two (or more) different 3rd party apps, each with OCIO embedded, that may want to install mutually-incompatible OCIO default color space definitions? If there is a single preferred location for color configurations, will they clobber each other in troublesome ways?

-- lg


On Apr 17, 2012, at 3:01 AM, Kevin Wheatley wrote:

As long as these can all be overridden by an environment variable and
these are some fall back location I would not object, however without
the ability to define a specific location we would never be able to
use it. I was just recently considering dynamically generating
versioned configs per TASK per USER in a VFX environment (a little
extreme perhaps but I certainly need many more than 1 config :-)

Kevin

--
Larry Gritz
l...@...

On Apr 17, 2012, at 9:41 AM, Larry Gritz wrote:

Do these plans include a provision for handling two (or more) different 3rd party apps, each with OCIO embedded, that may want to install mutually-incompatible OCIO default color space definitions? If there is a single preferred location for color configurations, will they clobber each other in troublesome ways?

Nuke already stores OCIO configurations in its own application-specific directories. Since it has multiple plug-in directories, it should already have some logic for what to do if two configurations with the same name appear in different places. If they recognized the shared location, presumably it would get lower priority to the application-specific ones.

I'm trying to address what I see to be the common case for "regular" users: wanting multiple applications to share the same OCIO configurations. I think most people will not have two configurations that are named the same but behave differently. The simple way to handle that in a shared directory would be to name the other configuration "spi-vfx-v2" or whatever.

For those here who want to juggle multiple configurations, versions, etc., then the $OCIO environment variable method you've been using is what you'll probably want to stick with.


Brendan

> Hmmm, since people will be often be installing these manually, we might not want to get too complicated.  There's something to be said for a hard-coded path.

The main reason i am against hardcoded paths (at least on windows) is that microsoft tends to change its standard directory structure every couple years. So it might require the least amount of code maintenance if we just asked the OS where to put things as the default 'common application data' location (not talking about the additional configs / overrides one might have or has set up optionally).
Putting dynamic configs in "Program Files" became a no-no since vista, you also have the x86 folder for 32bit stuff, unless you are on 32bit windows, when you only have the pure 'program files' folder,... it just gets messy.
We actually have most of our production software installed outside of program files, to allow easier configuration management.

Either way, take this as my 2 cents :) Im cool rolling with whatever decision is made.

Personally I think something like this might be good:

1. $OCIO (get the config from the variable)
2. relative search path starting at so/dll folder: OCIOConfigs/configs/<appname>-default (to follow nuke's arbitrary standard)
3. "<user folder>/OCIO/default/config.ocio" (ex: on win7: c:/Users/me/OCIO/default/config.ocio", on linux: ~/.OCIO/default/config.ocio)
4. "<common appdata>/OCIO/default/config.ocio"  (ex: on win7: c:/ProgramData/OCIO/default/config.ocio", on linux: /etc/OCIO/default/config.ocio)


>  I notice that Adobe actually puts ICC profiles in (x86) and has the 64-bit programs get them from there as well.

Yeah, then there is also the magical c:\windows\System32\spool\drivers\color folder for system ICCs.

On Apr 18, 2012, at 11:06 AM, László Sebő wrote:

1. $OCIO (get the config from the variable)
2. relative search path starting at so/dll folder: OCIOConfigs/configs/<appname>-default (to follow nuke's arbitrary standard)
3. "<user folder>/OCIO/default/config.ocio" (ex: on win7: c:/Users/me/OCIO/default/config.ocio", on linux: ~/.OCIO/default/config.ocio)
4. "<common appdata>/OCIO/default/config.ocio" (ex: on win7: c:/ProgramData/OCIO/default/config.ocio", on linux: /etc/OCIO/default/config.ocio)

Right. I've already got the <common appdata> thing going per your suggestion. I'd like to hear other people's opinions on the others. If this list gets expansive, maybe some official code should be added for getting an array of available configurations.

I'm currently doing <common appdata>/OpenColorIO, not <common appdata>/OCIO. Which do people think would be better?


Brendan

On 4/18/2012 1:35 PM, Brendan Bolles wrote:

On Apr 18, 2012, at 11:06 AM, László Sebő wrote:

1. $OCIO (get the config from the variable)
2. relative search path starting at so/dll folder: OCIOConfigs/configs/<appname>-default (to follow nuke's arbitrary standard)
3. "<user folder>/OCIO/default/config.ocio" (ex: on win7: c:/Users/me/OCIO/default/config.ocio", on linux: ~/.OCIO/default/config.ocio)
4. "<common appdata>/OCIO/default/config.ocio" (ex: on win7: c:/ProgramData/OCIO/default/config.ocio", on linux: /etc/OCIO/default/config.ocio)

Right. I've already got the<common appdata> thing going per your suggestion. I'd like to hear other people's opinions on the others. If this list gets expansive, maybe some official code should be added for getting an array of available configurations.

I'm currently doing<common appdata>/OpenColorIO, not<common appdata>/OCIO. Which do people think would be better?

I like It spelled out OpenColorIO.

How about an additional env var: OCIO_CONFIGS, which can be set to a ;-separated list of paths. The default would be the ones you've been talking about.

Have paths closer to the front of the list override ones further back (so I can stick my own hacked copy of nuke-default in my home directory if I want to).