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

I'd like to propose that we define standard directories on each platform where OCIO configurations might live. Nuke has taken a step in this direction now that they are shipping with OCIO. They have

https://github.com/imageworks/OpenColorIO/pull/258 https://github.com/imageworks/OpenColorIO/issues/19

Yes, sounds good to me. All the device code for a given kernel has to ultimately end up in a single compilation unit somehow. You can still keep the code in separate files, but you have to #include

Sure, it's no problem for OCIO to make device allocations. Attaching them to the Processor makes sense -- that way the user of the library can easily control when device memory is freed. -- Nathan

Hi Jeremy, Sent a pull request just now. One additional thing i noticed is that there is a duplicate of pystring.cpp used in the ociobakelut

Hi Jeremy, Sure thing, ill make a fork and do a pull request. Re: what config i was using: I tried a couple of ways of creating the ICC, first without a config (i noticed in the sourcecode that when

You can wrap CUDA memory objects around OpenGL textures, FWIW. Same with OpenCL images. It might make some sense to make the transfer operations "just in time" so the bits get transferred to the

One implementation detail I just thought of... Some of the Ops (such as the ones that use LUTs) will require explicit allocations on the device side. Is it is ok for OCIO to make these allocations

Thanks for looking into CUDA more. This could be really cool. Excellent. Is there a C++ wrapped handle to GPU memory in CUDA? If so, would it be possible to define a custom CUDAImageDesc, which