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

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

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

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

I've checked in this patch to the master branch. The code itself looks good; whether we choose to backtrack from that API direction in the upcoming weeks can/should be a separate issue from this

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

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

Thanks, LGTM <malcolmh...@...> wrote:

Looks good to me. I'll commit this after I finish working through the search path checkins (tomorrow, hopefully). -- Jeremy <malcolmh...@...> wrote:

Is it just a role? seems like each colorspace needs it to convert between each other. Roles main purpose is to have abstract names / pointers for colorspaces. The reference space could also be a role

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

No reason was just waiting to get the tick of approval, this is now removed. http://github.com/malcolmhumphreys/OpenColorIO/commit/26aa9bfc1baa74796b355de0b2ec476960b1b481 .malcolm

- converted configs/testing/config.ocio to YAML - added OpenColorIOTest to the ctest run ie 'make test & make test_verbose' - some test output was being written to /mcp changed this to /tmp for

Is there a reason to not remove yaml-cpp-0.2.5* from ext? Other than that, looks good to me. -- Jeremy <malcolmh...@...> wrote:

Looks good to me. (I tested this, as well as all the related post-email updates). -- Jeremy <malcolmh...@...> wrote:

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

- added yaml-cpp r443 which contains the new YAML::Newline emitter manipulator http://stackoverflow.com/questions/3982901/how-to-emit-a-blank-line-using-yaml-cpp - added some 'out << YAML::Newline' to

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

- 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

Inital pass at searchpath impl - added environment variable string expansion code in PathUtils.h (GetEnvMap() & EnvExpand()) - added FileExists() function to PathUtils.h - added searchpath