Hey Jeremy, The build completes successfully commenting out that line. If things are as Est mentioned, then I think this is a good idea. It would be preferable to use the distribution's supplied

I had the same problem. It happens when you link to the dynamic version of boost's test libraries. You need to build / install boost test as static libraries and point CMake to them. Est.

shared_ptr is part of C++0x (in TR1, I think). So another approach is to rig it so that sufficiently new compilers don't need the boost dependency, and only the old compilers will need to pull it in

Would anyone be against us copying the shared_ptr implementation internally into OCIO? That would let us make the OCIO boost dependency optional, which would let it compile on a plain-vanilla

Trivial addition, exposed ROLE_DEFAULT to python. commit 82dd5a4666f7c5456361e9ec7d78107742e5b427 -- Jeremy

I haven't seen that issue before, but it looks like it's related to the testing framework (which relies on boost). I'll try to get an Ubuntu machine up in the next few days for testing. But... in

We're starting to get some actual OCIO users, so it's time to start a new mailing list: http://groups.google.com/group/ocio-users This will focus on issues related to color profile development,

Hey everyone, I've encountered a linker issue on Ubuntu 10.10 with ocio-0.7.0. I was wondering if anyone could shed some light on whats going on? Linking CXX executable

Color profiles suitable for OCIO 0.7 have been posted, along with basic documentation. See https://sites.google.com/site/opencolorio/profiles for additional information. Note 1: Thanks to Joseph

Rod, This is my partial follow-up to Jeremy's response. A reference space is a useful concept and Imageworks will use them for AMPAS IIF implementation. The colorimetry will match the

There's a lot of good ideas here, it's taken me a bit of time to think through the implications. I'm going to be out of town for the remainder of the week, perhaps we could try an internet call early

Excellent, thanks. <malcolmh...@...> wrote:

Sorry I never noticed that section in the main CMakelists file, it all looks good. "Jeremy Selan" <jeremy...@...> wrote: -- Sent from my phone.

Can you be more specific? Which CMakeLists file, the root one or the one in src/core? The main CMake file has this chunk, # Set the default namespace if(NOT OCIO_NAMESPACE) set(OCIO_NAMESPACE

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