Hi Jeremy, looking much nicer. However, I have The Fear as you are using C++ TR1 for smart pointer magic. We are on Visual Studio 2005 for Windows and there is no TR1 for VS5 (we won't be changing in

Oh, and to clarify, Is your fear related to the specific include of the TR1 shared_ptr, or to shared_ptrs in public headers in general? -- Jeremy

The use of tr1 shared_ptr is only a stub. When we get multi-platform stuff sorted out that section will definitely be replaced with platform / compiler specific #ifdefs. Any shared_ptr that provides a

My fear is that TR1 is somewhat variably implemented at the moment, though smart pointers should be pretty much stable. The biggie is that we can't support it on Windows yet. b -- Bruno Nicoletti

Hello! I'm at the stage where I would like to get a survey of lut file formats (1d, 3d, matrix, etc) that folks actually use in the wild. If you commonly use a lut format at your facility, or define o

Yah, the "lut as image" approach should be really easy to support, I'll add that to the short list. My only concern would be which fileformats to support. I'd still like to keep our dependencies as lo

Version 0.5.6 (June 8 2010): * PyConfig stub implementation * Dropped ImageDesc.init; added PlanarImageDesc / PackedImageDesc * Dropped tr1::shared_ptr; added boost::shared_ptr

There are some subtleties with layout and mappings, so let me know when it's time to implement the import/export logic and I'll write up a spec. As for file formats, people use different ones - TIFF a

I've used 10bit DPX for this purpose in the past (when I thought I'd invented 2D 3D LUTs). 8 or 16 bit PPM may be a good compromise. It won't please everyone but implementation requires so little code

Good feedback. How about this: Let's support all trivial image formats, as long as it doesn't introduce a library dependency or support headache. So PPM is in. If there's a simple raw/ascii float form

0.5.7 features: * Python API is much more fleshed out (object ownership is clarified), object mutability is explicit * Improved public C++ header (functions if-def'd out have been removed (temporarily

Mostly using cinespace .csp, houdini .lut and .icc profiles for photoshop. The main lut format requirements for me is supporting some form of 1D pre lut and a 3D cube. I have uploaded the csp lut spec

We've setup a private repository for developers on github! Please email your github account details you'd like access. For everyone else, we will continue to post weekly code drops.

I wasn't originally in love with the name Open Color Space, but I have to admit it's grown on me. What are other people's feeling on "OCS"? Previously, David (Gordon) has suggested that the use of "Op

How about "Open Colour Management"? Seeing as it is more about coordinating the whole mess of colour spaces and displays and so on, rather than being a colour space per se. b -- Bruno Nicoletti

I agree that the system is more about conversion between spaces. OCC? RGB PS - nice try sneaking the "u" into color, Bruno...

I'm with the other's that this effort isn't really about defining color spaces or color encodings but rather offering an open set of libraries to manage color transformations. I believe the name shoul

I vote for "Open Color Management." But I'd use it no matter what name you choose. -- Larry Gritz l...@...

Ope, Turns out I may have opened a can of worms on our end. I didnt realize this yesterday, but we'd already gotten legal signoff on the "OCS" name, and changing it now is not gonna be simple. So keep

If it's the OCS part that matters: Open Color System? -stevel