The --look arg would only make sense with the existing-config options (e.g "--inputspace lg10 --outputspace srgb8 --look di"), so it should be pretty straight forward - just need to make sure the

https://github.com/imageworks/OpenColorIO/pull/267

Sounds good. So let's update the default. -- Jeremy

I'll take a stab, since I need it this week ;)

That's an accidental omission. "ociobakelut --look" totally makes sense. It's not super straightforward to add, unfortunately as ociobakelut currently creates a new temporary color configuration for

I have a bunch of look transforms set up that I would like to bake into luts. ociobakelut doesn't seem to know anything about looks currently so is there another way to do this? Or would it be

I like It spelled out OpenColorIO. How about an additional env var: OCIO_CONFIGS, which can be set to a ;-separated list of paths. The default would be the ones you've been talking about. Have paths

Right. I've already got the <common appdata> thing going per your suggestion. I'd like to hear other people's opinions on the others. If this list gets expansive, maybe some official code should be

I went ahead an did a pull request. Got to keep my github-fu strong(er) :) Also a quick fix on the documentation. Some non-git related hidden files were making their way into the installed

Thanks for catching that. I'll try to get the fix validated and we'll push out a 1.0.7-1 today. -- Jeremy

> Hmmm, since people will be often be installing these manually, we might not want to get too complicated. There's something to be said for a hard-coded path. The main reason i am against hardcoded

I think currently, using boost is the most convenient way to get this working on windows. Maybe when VS2010 gets more usage out there that would change... but then, so can the default in OCIO :-)

Once quick note. It looks like we're installing real libraries in the python site-packages directory. In looking at what I already have in there, none of them have sonames/soversions but the project

This release is a duesy. OCIO 1.0.7 is ABI and source compatible with all 1.X versions (of course), but has a lot of features / fixes: Version 1.0.7 (April 17 2012): * IRIDAS .look support *

Correct. You're only going to define a single colorspace (i.e., the same you have now), but for each colorspace you will explicitly define 2 sets of transforms, specifying each direction explicitly

nice ... so I presume that the utility functions for returning the number of color spaces will take this into account and not show me 'double' entries? Also, given the set up below, is it sufficient

I would like to do both. Ideally, for each forward lattice we would have an on disk representation of the inverse. However, in the cases that an inverse is not present I would like to be able to

I may have misunderstood you question upon a second read. Are you hoping to compute the inverse 3dluts dynamically as needed at runtime? Or is this a precomputation step? -- Jeremy

We do something similar internally. (Indeed, we probably use the same inverse code you do. CTL's scattered data point interpolation, anyone?) :) In any OCIO::ColorSpace, you can define the

Hi, I have a library that wraps color processing engines including OCIO. This library has a call to inverse. Whilst I am able to generate the inverse of a 3d lut (with all the usual caveats and edge