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

I'm fleshing out support for additional lut formats, and have a question on 3d. There's a 1D shaper lut at the top of the file, and the 3D component further on, all of which use integer types.

An additional clarification... There does need need to be some end-user ui for image display. (I didnt want to imply no UI was necessary). You just dont need lut- directory / browser / setup

We've now got an ftp site setup at spi for large file posting. If you want to post files > 10MB email me and I'll send you the login info.

Exactly. Clients apps will automatically have support for all lut formats. (It's about time!) To an end user, this should feel pretty automated. Apps shouldn't need ebd user options / dialogs,

Neat. So just to clarify, the big idea is that any app that uses your color library properly will, by extension, understand ALL of these luts (whichever happens to be available/used at the facility

Blake was kind enough to a google doc spreadsheet of lut formats: http://spreadsheets.google.com/ccc?key=0Avn2cZhY9jaYdF9qTHYteU1MUDYtdnFkSDJQdHpaU1E&hl=en I'll try to edit it to keep it up to date.

Thanks! I do have the houdini docs, but if you could send me known good examples luts that would be helpful as well. If the files are small (under 10 MB) just post them to this as files to this

I can send the specs for the Houdini .lut (ASCII) and .blut (bin) formats, if you need that. They're also in the HDK documentation, if you have access to that.

Ah, there is a 10MB per-file limit to uploads on google groups. Let me whip up an alternative... wrote:

80 Megs or so of data seems to have confused Google. Anyother way? b -- Bruno Nicoletti

Hi Jeremy, these are the ones we support in Nuke... .vf Nuke native vector field vfz gzip compressed .vf files .cub(e) Truelight 1D or 3D LUT .cube Iridas LUT .csp Cinespace LUT .3dl