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

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

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

I agree that the system is more about conversion between spaces. OCC? RGB PS - nice try sneaking the "u" into color, Bruno... <bruno.j....@...> wrote:

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 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

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.

Oh I have never used this as it got released by RSR after we implemented the csp format at RSP. Not sure if it's helpful as I haven't spent anytime looking into it so I wouldn't expect it to work out

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

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

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

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

I wouldn't burden OCS with the image-reading functionality. You'll never make everybody happy without supporting a bzillion formats. Why not just allow the lut to be specified as a big array and

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 -

Oh, and for those who geek out on python binding implementations, I'd invite you to check out: src/pyglue/ PyConfig.h PyConfig.cpp I'm curious to see how people feel about this approach. Rather

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

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

Jeremy, The 2D LUT format I describe below is starting to become a bit more standardized in the game industry - it is being used by two major middleware companies (Crytek and Epic - see

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

Hi Jeremy, thanks for the reply. I'm a firm believer in smart pointers, choosing what to expose can be problematic in an API like this when there is no firm standard. #ifndefs is the way around