Hi, Thanks for the ticket. I could indeed implement a callback for the OCIO colorspace nodes. I already have some code that sets the context variables of the OCIO ColorSpace node. The problem is then

This was discussed a while ago in "[ocio-dev] FileTransform interface changes", https://groups.google.com/forum/#!searchin/ocio-dev/parameter/ocio-dev/dv9ZC28lq_c/D1QxOPPj__wJ ..and would become a

Belated reply, but, those warnings can (hopefully) be ignored if you are just building OCIO The problem is because "Config::getNumEnvironmentVars" returns an "int", when it should probably return an

Made a ticket about this, https://github.com/imageworks/OpenColorIO/issues/364 As an alternative, could you do something with Python in Nuke? Maybe a menu item or addOnUserCreate callback which

Unfortunately the current version of OCIO only uses context variables when resolving file paths. Context variables are only used in search paths and the src parameter for a FileTransform.

Looking at the code OCIO implements Matrix*RGBA (column vector). In matrix operations RGBA*transpose(matrix) = matrix*RGBA. If you feel you are getting the wrong multiplication order then try using

Hi, I did post this question to OCIO-users and did not get any reaction, so I'm trying here as it might be a question related to development. Anyway I'm sorry if this is against posting rules. I've

My name is Joshua Jackson. I'm writing a custom configuration with ocio and have a quick question: Can I apply Matrix Transforms in a different order than RGB x MTX x etc... ? For Chromatic

If I have a config with displays "a", "b", "c" and an active_display list of "a" there is no way to get to displays "b" and "c". In fact reading in a config file and writing it back out will only

Success! Now to make sure I have the same version on linux (in case anything else changed from 1.0.9), then build for Windows (fingers crossed that there's no glitches there!), and I'm ready to start

Thanks!

If you do another pull the cmake file should use the internal lcms by default.

Yeah, I'm working at getting a universal version compiled now. Thanks!

> ld: warning: in /opt/local/lib/liblcms2.dylib, file was built for unsupported file format which is not the architecture being linked (i386) Your liblcms2 is not a universal library. I guess it came

Curses... google ate my reply! A summary of what I wrote: 1. Doing some more testing with yesterday's version, I noticed that changing the order of x86_64 and i386 changed the architecture that the

It is fun to getting quoting rules right in cmake. Please pull the git repo again and test again.

Trying this method, and not using the flag -DCMAKE_OSX_ARCHITECTURES=x86_64;i386 compiled (etc) with no errors, however, when I look at the .a and .dylib files using lipo -info, I get: Non-fat

It didn't work, same error message. :(

Thanks! I'll give this a try!

I have created a new CMakeLists.txt file but I currently do not have a way to test it. If someone could please test the CMakeOSXArch branch on the rminsk/OpenColorIO repository (git clone -b