Sorry, cmake is brand new to me and I figured it would be quicker to ask... What would be the proper way to tell cmake to build the nuke plugins linking to the versions of libraries (libstdc++ etc) in

Your example looks good to me. Can you test the sub components of your transform? If you skip the ctl nodes, and only try the log2lin portions, does that result in an identity transform? Feel free

Thanks for the quick answer and the explanation :) I tried this afternoon to create my own aceslg2_to_Rec709 LUT but I'm still not sure to understand how it should work. I started to give a quick

Marie, Thanks for catching this! The currently shipping IIF configuration is based on an older specification (I forget the exact version, but it's around 8 months old), so my hope is the versions

Hello all ! I'm having a look at IIF config.ocio and I was wondering how you build the aceslg2_to_Rec709.cube LUT for the rrt_odt_r709 colorspace. I'm asking because when I compare an OCIOColorspace

Friends, We've just officially released version 1.0, now available for download

Yes, that important functionality is under documented. I'll try to update the headers / documentation this week. But in the meantime... The allocation / allocation vars are utilized using during

Could anybody say a little about what ColorSpace::setAllocation() and ColorSpace::setAllocationVars() do? I'm starting to get up and running writing my own luts into the spi1d format for converting

https://github.com/imageworks/OpenColorIO/pull/165 Oh no! Today, in the normal course of production work (debugging why our editorial deliverables didn't match on-set reference), we discovered that

Hi, The shaper interpolation should be what we agreed. Interpolation FileTransform::getShaperInterpolation() const; void FileTransform::setShaperInterpolation(Interpolation interp); bool

Thanks so much...this completely rocks my color-world! Jordan

https://github.com/imageworks/OpenColorIO/pull/163 Added support for --lut command-line argument. Instead of requiring an ocio profile, users can specify a lut (or a chain of luts) to create an icc

Would FileTransform::setOptionString(...) introduce the same complexity? Say you wanted to create the OCIOFileTransform in nuke. In this system, would you expect to see a single knob,

Am 15.09.11, 17:50 -0700 schrieb Jeremy Selan: That looks like cmake output. But littleCMS (alias lcms) uses autotools and is written in C not C++. Did you check with lcms' native build system? Btw.

I leave it up to you to decide what makes it into 1.0. At the end of the day I would just be happy to somehow replace these: FileTransform::getCCCId() FileTransform::setCCCId(const char * id) But I

Hey Jeremy,

Malcolm, Sorry for the delay in responding. First, I agree with you that dynamically defined FileTransform options would have more elegant. (prman is a great example of how such an API can stay

Hey, Just giving my two cents but having ocio support icc transforms would be a killer feature. Would this be too invasive a change to make it into 1.0? Cheers, Andrew On Sep 14, 2011 10:04 AM,

Hi, As we are fast approaching 1.0 I know it's a bit late in the day for some API changes. But I noticed these while doing the JNI wrapping for the android port some things which would be really good

With "mylut.csp", and the following saved as "example.yaml" (http://pastie.org/2523829 incase the formatting is screwed up): ocio_profile_version: 1 # Look in current working dir for