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

LGTM

LGTM

Can you elaborate a little on what was confusing. +1 to a self contained file What about per shot balance grades and look / creative grades, I would cry if I needed to create a zip ocio profile per

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

Rod, Answering your short email with a long essay... (just had a coffee) I understand your concern. If we wanted to solve this today -- leveraging OCIO -- the simplest approach would be to use

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: