Thats cool, I'm trying to get all the remaining pieces in place before friday. So I will have a few more things over the next few days. .malcolm

On first glance, this looks great. Thanks! I wont have a chance to do a more thorough review until tomorrow... -- Jeremy

https://github.com/imageworks/OpenColorIO/pull/73 Replacing some pre ocio code for building luts at drd - Added new OCIO::Baker interface and initial pass at houdini lut writing - Added new app

Oh, of course - test data might be.. useful... http://dl.dropbox.com/u/796113/ocio_temp/csp_prelut_testfile.tar.gz - Source image (JPLogLin'd marcie) - a lin_to_rec709.csp test LUT - source image with

Sorry I'm working on some other stuff for the last few days in preparation for wrapping up next week. I'll be back on ocio tomorrow so I'll have a look at it then. .malcolm

Cool, looks good! Would anyone have an example csp file with a prelut suitable for testing? Malcolm? Even though what you've done looks totally reasonable, I'd like to QC it against some known good

Initial attempt at this, and an unrelated commit which prevents empty config sections being seralised: https://github.com/imageworks/OpenColorIO/pull/72

Actually, on further thought let's do both. Very few people get notified of pull requests, and I'd like to keep everyone on this list in the development loop. (that is it's purpose, after all). So

Sounds good. My only concern is that discussion would end up being spread over both the mailing list, and pull request comments - it's kind of nice to have it all in one place ...but that's a

So github's pull request mechanism has gotten a lot better since we started the project. At this point I don't see a compelling reason to submit reviews to this email alias, rather than to just use

Excellent. Thanks for the feedback. Do we know that static linking isn't currently working? I've never tried. Why wouldn't it work already? (just that we dont have cmake create the .a

Sounds good. I'll try to give it a shot. -- Jeremy

Looks good. So for the case you outline below, you'd create a Lut1D op, where from_min = 0.0, from_max = 4.0, and the lut values 0 ... 2.0 would go in the lut. I'd go with a fixed number of samples

I don't mind at all if somebody wants to replace the BOOST_FOREACH in OIIO argparse with regular 'for' statements. -- lg -- Larry Gritz l...@...

Started attempting this, seems to be progressing well - thanks for the tips! To be clear about the resampling. Given a prelut of: 0.0 2.0 4.0 0.0 1.0 2.0 ..the code would linearly-interoplate

Only seems to use BOOST_FOREACH - should be easy enough to replace with an old-fashioned for()

I was looking at oiio argparse but that too seems dependant on boost for something I remember. .malcolm

Agreed about the --inputconfig / $OCIO option. I've added that. I'll see what I can do about remove the boost dependency. I agree that if we can avoid it, we should. -- Jeremy

Ope, that's an embarrassing copy/paste error... fixed! I totally agree that python docstrings are critical. I'll add the task to the git issues list, and try to get to it soon. -- Jeremy

Looks good! Perhaps if --inputconfig flag is not set, it could check $OCIO? Might be a convenient way to verify the env is setup correctly, and may answer many "why doesn't OCIO work!" questions.