Cool. Get's closer, but another build error. I've created this issue: https://github.com/imageworks/OpenColorIO/issues/261 so we can take the remainder of the CUDA build discussion off-list. For

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

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?

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

I tried it with 4.0 this morning and got the same error. It does seem to be a bug in nvcc, but I was able to work around it. I just pushed the fix to my repo.

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

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

i'll try to get 4.1 installed. Let's wait and see if that fixes things. -- Jeremy

Hmmm... I didn't run into anything like that. It looks like the error is coming from an intermediate file that nvcc generates and passes off to gcc. I've seen that kind of thing in the past when

Awesome! Haven't looked very far into the code yet, but tried to build it and having some issues. Does this error ring any bells? I have to admit my CUDA experience is

This is done now. My code is on GitHub: https://github.com/nweston/OpenColorIO/tree/cuda I worked out a little differently than I had planned. I ended up with a parallel class hierarchy of CudaOps.

Has anyone on this list built OCIO for Windows, and NOT used boost_ptr? If so, we'd love to hear from you. (If we don't hear back, that will be an implied LGTM)... ;) -- Jeremy

Doesn't the boost package use tr1 underneath when it detects a compiler that's known to support it? So that would be equivalent, IIRC. -- Larry Gritz l...@...

https://github.com/imageworks/OpenColorIO/pull/260

I think it would be best to package boost smart pointer headers with ocio and use it all the time over tr1 on all platforms. LaszloSebo <laszl...@...> wrote:

Hi there, When building OpenColorIO on windows, one of the things i had to change to make things properly build in my environment was enabling boost in the config, by setting the OCIO_USE_BOOST_PTR

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

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

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:

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