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

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

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

This one will actually build on other people's machines... please see INSTALL file for instructions on how to build the Nuke example (posted here as well): Make a build directory, cd into

Folks, We've made a lot of progress on Open Color Space, and decided to post our first cut. This is first code drop of many; we will try to post the trunk either every week or every 2 weeks. (And

Yes. Agreed. The importer can use the fuzzy greater-than-1/2-max heuristic for guessing the bit-depths of A and B. ...and be correct most of the time. -blake

Cool, thanks for the info. So it sounds like when we want to write a .3dl exporter, we'll need to specify which flavor of .3dl to write. However, on the import side it still sounds like we'll be

Regarding 3dl -- The lore I've been fed is that Mitch Bogdonowicz formerly of Kodak wrote (invented? burped?) the 3dl "specification" when he was at Kodak as a quick and dirty solution of 3D LUT