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.

Looks much more Python'y \o/ Would be good to have more helpful method signatures for __init__ - would make this feature more discoverable - currently it just says: ... | __init__(...) |

Hi, My top few right now - Bit depth support in the API - !<Look> concept fleshed out a little - Transform / Op Plugin API - Static Link working - Update to the latest yaml-cpp from trunk, it has some

Team Coco, OpenColorIO is rapidly approaching stability, so the time is ripe to lock off on our next stable API version. If you have any short-term additions or requests that will break API binary

Ben, So if you're still interested in implementing this feel free to take a stab. What you'll probably want to do is to copy the code from the specified link, add it to an anonymous namespace in the

Commit: http://github.com/jeremyselan/OpenColorIO/commit/05354bc1aad4325eca4cdbef64b4edaade8f16dc $OCIO, ociocheck, and other programs that end up calling Config::CreateFromFile(...), can now specify

Commit: http://github.com/jeremyselan/OpenColorIO/commit/8be4a3ba174c69438cf151802f829696cb7b6555 ociocheck now does much better error checking. It will test each colorspace and see which conversions

Commits: http://github.com/jeremyselan/OpenColorIO/commit/a764a5f7fb151d13be93107697262a670ba34392 This add kwarg support to most of the transform constructors in python. Makes it way more