Testing, 1 2 3... I've updated our github acct. so all pull requests get cc'd to this list. I really like how OpenImageIO reviews commits in their public dev forum before adding them to the repo,

Branch: refs/heads/master Home: http://github.com/imageworks/OpenColorIO Commit: 77639305a291d929b257bb1b3211462b8c9428ed

Est, A 32x32x32 cube lut is a totally reasonable size, it's what we happen to use internally at Imageworks. Some other popular sizes include 17x17x17 (flame), and 33x33x33 (a few commercial color

Hi All, I recently started using OpenColorIO and I have some questions: In my current code, I'm using a 32x32x32 lut, just for the display, not for processing. Is it a good size? How do you choose a

I think thats fine, the DEBUG/TEST build would build both and the RELEASE wouldn't. .malcolm

Version 0.6.0 (Sept 21 2010): * Start of 0.6, "stable" branch All 0.6.x builds will be ABI compatible (forward only). New features (even experimental ones) will be added to the

Ok, so I just checked in a bunch of changes to the unit testing (spi github repository). These changes may or may not affect the build error you've gotten. I'll check your error on OSX when I get

Hi Jeremy, Ahhh, my bad. In quick reading up on it I'd assumed that they were referring to linking with boost's libraries, rather than the test modules created within the user's code. I did a little

Actually, I dont believe there currently is a link dependency to boost. ldd src/core/libOpenColorIO.so : linux-vdso.so.1 => (0x00007fff63afb000) libstdc++.so.6 =>

Hi Jeremy, shared_ptr is header only and you're already using CMake, so perhaps it'd be worth looking at using CMake's unit testing instead of boost's? This way there's no linking dependencies

Thanks for all the feedback, everyone! It has been very helpful. Having tabulated the results, the winner - by a landslide - is documentation! So this will be the (rough) order of development: 1)

Hmmm, that patch doesnt quite work for us locally at Imageworks. (I think it's probably because we use a namespaced version of boost, and the macro isn't quite right in our context). Let me see if I

Best way to solve a problem? Post on a mailing list asking for help, then you'll find the solution within minutes. Cheers, Alan.

Hi All, For some reason the compilation of the latest trunk is failing on FC13. It's complaining about main not being defined, but from what I've read on the boost unit testing defining

Hello Jeremy, I would like to see OCIO grow into a library that can handle all our color transformations. I can see it being used in the current xml'ized form within our production environment to

Version 0.5.16 (Sept 16 2010): * PyTransforms now use native python class inheritance * OpenColorIO C++ namespace can now be configured at build time (for safe distribution in commercial

Hello Jeremy and all ! I don't have much time to focus on OCIO now but soon or late I will...;) And when that day will come, I'll be happy to find : - Developer API Docs - Color Config Authoring

Hi Jeremy, I'm currently adding OpenColorIO support to my compositor. My list would be: - End User (Artist) Docs - Developer API Docs - Flesh out the existing ocio configs (spi-anim,spi-vfx) for

Hi Jeremy, The top five for me would be as follows. 1) API Documentation (the classes and how the pieces are supposed to work together - I guess that may count as config documentation) 2) LUT

1) Document 'best practice' for each config, provide examples with imagery 2) Flesh out the existing ocio configs (spi-anim,spi-vfx) for real use 3) Add example color config authoring scripts 4) End