Thanks for catching that. I'll try to get the fix validated and we'll push out a 1.0.7-1 today. -- Jeremy

> 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

I think currently, using boost is the most convenient way to get this working on windows. Maybe when VS2010 gets more usage out there that would change... but then, so can the default in OCIO :-)

Once quick note. It looks like we're installing real libraries in the python site-packages directory. In looking at what I already have in there, none of them have sonames/soversions but the project

This release is a duesy. OCIO 1.0.7 is ABI and source compatible with all 1.X versions (of course), but has a lot of features / fixes: Version 1.0.7 (April 17 2012): * IRIDAS .look support *

Correct. You're only going to define a single colorspace (i.e., the same you have now), but for each colorspace you will explicitly define 2 sets of transforms, specifying each direction explicitly

nice ... so I presume that the utility functions for returning the number of color spaces will take this into account and not show me 'double' entries? Also, given the set up below, is it sufficient

I would like to do both. Ideally, for each forward lattice we would have an on disk representation of the inverse. However, in the cases that an inverse is not present I would like to be able to

I may have misunderstood you question upon a second read. Are you hoping to compute the inverse 3dluts dynamically as needed at runtime? Or is this a precomputation step? -- Jeremy

We do something similar internally. (Indeed, we probably use the same inverse code you do. CTL's scattered data point interpolation, anyone?) :) In any OCIO::ColorSpace, you can define the

Hi, I have a library that wraps color processing engines including OCIO. This library has a call to inverse. Whilst I am able to generate the inverse of a 3d lut (with all the usual caveats and edge

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