Release -- would 1.2 be ok?  Or do you need a backport to 1.1?

Python... uh... I have no idea, but suspect there is not currently a cmake flag 
for this. It would be a very welcome addition, as would be any and all 
improvements to our poor neglected Python setup. I wish I had the time and 
expertise to keep up with the Python bindings, but I'm afraid that's where my 
finite rubber meets the road. Or something like that. I need some volunteers 
who know Python better than I do (in particular, how to expose C++ libraries to 
Python) and who depend on the OIIO Python bindings themselves so they have good 
incentive to stay on top of the issue. That's my problem -- I use the C++ 
library constantly, but don't do anything challenging with the Python bindings, 
so it's easy for me to unintentionallymodify C++ without realizing that I've 
broken Python or fail to keep them in sync. I am not proud of this, but there 
it is.



On Jul 8, 2013, at 12:25 PM, Andrew Wood wrote:

> if it wouldn't be toooo much trouble, a release version would be great!
> 
> by the way, is there a CMake flag for rpathing the core lib in the python 
> module?  Perhaps I should make a separate thread about that?
> 
> 
> 
> 
> Andrew Wood
> Pipeline Engineer, Digital Domain
> x2914
> 
> 
> On Mon, Jul 8, 2013 at 12:14 PM, Larry Gritz <[email protected]> wrote:
> Great. Are you ok with merging it just into master?  Or do you require a 
> backport to a release branch?
> 
> 
> On Jul 8, 2013, at 12:09 PM, Andrew Wood wrote:
> 
>> this looks fantastic, Larry.  Thanks so much for your help!
>> 
>> best,
>> Andrew
>> 
>> 
>> 
>> Andrew Wood
>> Pipeline Engineer, Digital Domain
>> x2914
>> 
>> 
>> On Fri, Jul 5, 2013 at 11:59 PM, Larry Gritz <[email protected]> wrote:
>> Aha.  I've posted a new version of the patch.  Try now.
>> 
>>      -- lg
>> 
>> 
>> On Jul 5, 2013, at 6:50 PM, Larry Gritz wrote:
>> 
>>> Aha, yes, I can reproduce something weird here.  Stay tuned...
>>> 
>>> 
>>> 
>>> On Jul 5, 2013, at 5:44 PM, Andrew Wood wrote:
>>> 
>>>> Try putting this through autotrim:
>>>> 
>>>> 
>>>> 
>>>> before:
>>>> /var/tmp/flower.exr:
>>>> 
>>>> file format version: 2, flags 0x0
>>>> channels (type chlist):
>>>>     B, 16-bit floating-point, sampling 1 1
>>>>     G, 16-bit floating-point, sampling 1 1
>>>>     R, 16-bit floating-point, sampling 1 1
>>>> compression (type compression): zip, individual scanlines
>>>> dataWindow (type box2i): (0 0) - (1919 1079)
>>>> displayWindow (type box2i): (0 0) - (1919 1079)
>>>> lineOrder (type lineOrder): increasing y
>>>> nuke/input/bitsperchannel (type string): "32-bit float"
>>>> nuke/input/ctime (type string): "2013-07-01 14:11:50"
>>>> nuke/input/filename (type string): "/var/tmp/test.exr"
>>>> nuke/input/filereader (type string): "exr"
>>>> nuke/input/filesize (type int): 2761776
>>>> nuke/input/height (type int): 1080
>>>> nuke/input/mtime (type string): "2013-07-01 14:11:50"
>>>> nuke/input/width (type int): 1920
>>>> nuke/node_hash (type string): "7a4990d4f3aa42ab"
>>>> pixelAspectRatio (type float): 1
>>>> screenWindowCenter (type v2f): (0 0)
>>>> screenWindowWidth (type float): 1
>>>> 
>>>> 
>>>> after:
>>>> 
>>>> 
>>>> /var/tmp/flowerout.exr:
>>>> 
>>>> file format version: 2, flags 0x0
>>>> Exif:ImageHistory (type string): 
>>>> "/dd/tools/cent5_64/package/openimageio/1.2.0-alpha01/bin/oiiotool 
>>>> /var/tmp/flower.exr --autotrim -o /var/tmp/flowerout.exr"
>>>> Software (type string): "OpenImageIO 1.3.0dev : 
>>>> /dd/tools/cent5_64/package/openimageio/1.2.0-alpha01/bin/oiiotool 
>>>> /var/tmp/flower.exr --autotrim -o /var/tmp/flowerout.exr"
>>>> capDate (type string): "2013:07:05 17:42:03"
>>>> channels (type chlist):
>>>>     B, 16-bit floating-point, sampling 1 1
>>>>     G, 16-bit floating-point, sampling 1 1
>>>>     R, 16-bit floating-point, sampling 1 1
>>>> compression (type compression): zip, individual scanlines
>>>> dataWindow (type box2i): (0 0) - (0 0)
>>>> displayWindow (type box2i): (0 0) - (1919 1079)
>>>> lineOrder (type lineOrder): increasing y
>>>> nuke/input/bitsperchannel (type string): "32-bit float"
>>>> nuke/input/ctime (type string): "2013-07-01 14:11:50"
>>>> nuke/input/filename (type string): "/var/tmp/test.exr"
>>>> nuke/input/filereader (type string): "exr"
>>>> nuke/input/filesize (type int): 2761776
>>>> nuke/input/height (type int): 1080
>>>> nuke/input/mtime (type string): "2013-07-01 14:11:50"
>>>> nuke/input/width (type int): 1920
>>>> nuke/node_hash (type string): "7a4990d4f3aa42ab"
>>>> pixelAspectRatio (type float): 1
>>>> screenWindowCenter (type v2f): (0 0)
>>>> screenWindowWidth (type float): 1
>>>> 
>>>> 
>>>> Sorry for the image size, it's a hard problem to reproduce.
>>>> thanks again for your help!
>>>> Andrew
>>>> 
>>>> 
>>>> 
>>>> Andrew Wood
>>>> Pipeline Engineer, Digital Domain
>>>> x2914
>>>> 
>>>> 
>>>> On Fri, Jul 5, 2013 at 4:06 PM, Andrew Wood <[email protected]> wrote:
>>>> ah nuts, you're right.  I'm having problems with it on a larger 
>>>> proprietary image, where it's changing the data window to 0 (as in 
>>>> out.exr)  
>>>> 
>>>> I was trying to reproduce with smaller images.  let me play around some 
>>>> more.
>>>> 
>>>> 
>>>> 
>>>> Andrew Wood
>>>> Pipeline Engineer, Digital Domain
>>>> x2914
>>>> 
>>>> 
>>>> On Fri, Jul 5, 2013 at 3:09 PM, Larry Gritz <[email protected]> wrote:
>>>> Are you absolutely sure that out.exr is the right file?  Your input was 
>>>> RGB, but out.exr was RGBA, that looks suspicious, like maybe you were 
>>>> using a different file as input than you may have thought.
>>>> 
>>>> 
>>>> 
>>>> On Jul 5, 2013, at 3:05 PM, Larry Gritz wrote:
>>>> 
>>>>> Works for me!
>>>>> 
>>>>> Hmmm...
>>>>> 
>>>>> Maybe just to be sure, do a 'make nuke' and then make it from scratch?
>>>>> 
>>>>> Also, maybe try pulling exactly what I have to be sure (like I said in 
>>>>> the earlier email), instead of applying just the patch?  Just in case?
>>>>> 
>>>>> If this still doesn't work, maybe do a 'make test' and let me know if 
>>>>> anything else interesting fails?  (I'm expecting a failure for 'psd', but 
>>>>> everything else should be fine.)
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> On Jul 5, 2013, at 2:45 PM, Andrew Wood wrote:
>>>>> 
>>>>>> Did some simple tests.  My simple colorwheel worked, but a 
>>>>>> nonsymmettrical test didn't.  What do you think?
>>>>>> 
>>>>>> 
>>>>>> /var/tmp/in.exr:
>>>>>> 
>>>>>> file format version: 2, flags 0x0
>>>>>> channels (type chlist):
>>>>>>     B, 16-bit floating-point, sampling 1 1
>>>>>>     G, 16-bit floating-point, sampling 1 1
>>>>>>     R, 16-bit floating-point, sampling 1 1
>>>>>> compression (type compression): zip, individual scanlines
>>>>>> dataWindow (type box2i): (0 0) - (19 19)
>>>>>> displayWindow (type box2i): (0 0) - (19 19)
>>>>>> lineOrder (type lineOrder): increasing y
>>>>>> pixelAspectRatio (type float): 1
>>>>>> screenWindowCenter (type v2f): (0 0)
>>>>>> screenWindowWidth (type float): 1
>>>>>> 
>>>>>> dataWindow is 0,0 and looks like its falling back on an HD formatting 
>>>>>> here...
>>>>>> 
>>>>>> /var/tmp/out.exr:
>>>>>> 
>>>>>> file format version: 2, flags 0x0
>>>>>> Exif:ImageHistory (type string): 
>>>>>> "/dd/tools/cent5_64/package/openimageio/1.2.0-alpha01/bin/oiiotool 
>>>>>> /var/tmp/test.exr --autotrim -o /var/tmp/out.exr"
>>>>>> Software (type string): "OpenImageIO 1.3.0dev : 
>>>>>> /dd/tools/cent5_64/package/openimageio/1.2.0-alpha01/bin/oiiotool 
>>>>>> /var/tmp/test.exr --autotrim -o /var/tmp/out.exr"
>>>>>> capDate (type string): "2013:07:05 14:36:20"
>>>>>> channels (type chlist):
>>>>>>     A, 32-bit floating-point, sampling 1 1
>>>>>>     B, 32-bit floating-point, sampling 1 1
>>>>>>     G, 32-bit floating-point, sampling 1 1
>>>>>>     R, 32-bit floating-point, sampling 1 1
>>>>>> compression (type compression): piz
>>>>>> dataWindow (type box2i): (0 0) - (0 0)
>>>>>> displayWindow (type box2i): (0 0) - (1919 1079)
>>>>>> lineOrder (type lineOrder): increasing y
>>>>>> pixelAspectRatio (type float): 1
>>>>>> screenWindowCenter (type v2f): (0 0)
>>>>>> screenWindowWidth (type float): 1
>>>>>> 
>>>>>> 
>>>>>> this is how nuke spits it out:
>>>>>> 
>>>>>> 
>>>>>> /var/tmp/out2.exr:
>>>>>> 
>>>>>> file format version: 2, flags 0x0
>>>>>> channels (type chlist):
>>>>>>     B, 16-bit floating-point, sampling 1 1
>>>>>>     G, 16-bit floating-point, sampling 1 1
>>>>>>     R, 16-bit floating-point, sampling 1 1
>>>>>> compression (type compression): zip, individual scanlines
>>>>>> dataWindow (type box2i): (5 4) - (15 14)
>>>>>> displayWindow (type box2i): (0 0) - (19 19)
>>>>>> lineOrder (type lineOrder): increasing y
>>>>>> pixelAspectRatio (type float): 1
>>>>>> screenWindowCenter (type v2f): (0 0)
>>>>>> screenWindowWidth (type float): 1
>>>>>> 
>>>>>> thanks so much for your help!
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Andrew Wood
>>>>>> Pipeline Engineer, Digital Domain
>>>>>> x2914
>>>>>> 
>>>>>> 
>>>>>> On Fri, Jul 5, 2013 at 1:17 PM, Larry Gritz <[email protected]> wrote:
>>>>>> Yeah, I'm sure it also works just fine to apply the patch directly.
>>>>>> 
>>>>>> 
>>>>>> On Jul 5, 2013, at 1:14 PM, Andrew Wood wrote:
>>>>>> 
>>>>>>> thanks for the heads up.  I have the master checked out, so I just did
>>>>>>> 
>>>>>>> curl https://github.com/OpenImageIO/oiio/pull/635.patch -k | git am
>>>>>>> 
>>>>>>> I believe that's the same thing, although I'm still learning my way 
>>>>>>> around git.
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> Andrew Wood
>>>>>>> Pipeline Engineer, Digital Domain
>>>>>>> x2914
>>>>>>> 
>>>>>>> 
>>>>>>> On Fri, Jul 5, 2013 at 1:10 PM, Larry Gritz <[email protected]> wrote:
>>>>>>> Just to be clear -- I haven't merged this into master yet, you'll need 
>>>>>>> to pull from the branch mentioned in the pull request, like this:
>>>>>>> 
>>>>>>>         git pull https://github.com/lgritz/oiio lg-trim
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> On Jul 5, 2013, at 11:44 AM, Andrew Wood wrote:
>>>>>>> 
>>>>>>>> sorry, didn't see this.  I'll give it a go!
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Andrew Wood
>>>>>>>> Pipeline Engineer, Digital Domain
>>>>>>>> x2914
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On Thu, Jul 4, 2013 at 11:15 PM, Larry Gritz <[email protected]> 
>>>>>>>> wrote:
>>>>>>>> https://github.com/OpenImageIO/oiio/pull/635
>>>>>>>> 
>>>>>>>> Try the patch in this pull request, see if that does what you expect.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On Jun 28, 2013, at 6:30 PM, Andrew Wood wrote:
>>>>>>>> 
>>>>>>>>> yeah, that's exactly right.  Same size image, just set the data 
>>>>>>>>> window automatically.  If you're familiar with nuke, the Write node 
>>>>>>>>> has an "autocrop" button.
>>>>>>>>> 
>>>>>>>>> would be much appreciated!
>>>>>>>>> 
>>>>>>>>> one of these days, I need to read through all of your docs and start 
>>>>>>>>> helping out!  Thanks for all your amazing work.  it's a fantastic 
>>>>>>>>> toolset.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Andrew Wood
>>>>>>>>> Pipeline Engineer, Digital Domain
>>>>>>>>> x2914
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On Fri, Jun 28, 2013 at 4:02 PM, Larry Gritz <[email protected]> 
>>>>>>>>> wrote:
>>>>>>>>> The "autocrop" feature that it refers to means that oiiotool 
>>>>>>>>> automatically behaves as if they had specified --croptofull, if and 
>>>>>>>>> only if outputting to a file format that doesn't support separate 
>>>>>>>>> data and display windows.  That's the default, and you turn it off 
>>>>>>>>> with --noautocrop.
>>>>>>>>> 
>>>>>>>>> You're looking for something different -- if I understand properly, 
>>>>>>>>> you want to shrink the data window so that it encloses the minimal 
>>>>>>>>> area with non-black pixels, right?
>>>>>>>>> 
>>>>>>>>> There is no such functionality in oiiotool at the moment, but it 
>>>>>>>>> would be easy to add.  I'll try to take a whack at it over the 
>>>>>>>>> weekend.
>>>>>>>>> 
>>>>>>>>>         -- lg
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On Jun 28, 2013, at 11:51 AM, Andrew Wood wrote:
>>>>>>>>> 
>>>>>>>>> > I see this flag:
>>>>>>>>> >
>>>>>>>>> > --noautocrop           Do not automatically crop images whose 
>>>>>>>>> > formats don't support separate pixel data and full/display windows
>>>>>>>>> >
>>>>>>>>> > I'm reading an exr (display window same as data window) and 
>>>>>>>>> > outputting an exr.  I'd love an autocrop behavior to set the 
>>>>>>>>> > bounding box.  I was thinking that is what it would do 
>>>>>>>>> > automatically based on that flag.
>>>>>>>>> >
>>>>>>>>> > But that does not seem to be the case.  Am I missing something 
>>>>>>>>> > obvious? oiio 1.1.9
>>>>>>>>> >
>>>>>>>>> > thanks!
>>>>>>>>> > Andrew
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> > oiiotool input.exr -o /var/tmp/test.exr
>>>>>>>>> >
>>>>>>>>> > channels (type chlist):
>>>>>>>>> >     A, 16-bit floating-point, sampling 1 1
>>>>>>>>> >     B, 16-bit floating-point, sampling 1 1
>>>>>>>>> >     G, 16-bit floating-point, sampling 1 1
>>>>>>>>> >     R, 16-bit floating-point, sampling 1 1
>>>>>>>>> >     fire_color.b, 16-bit floating-point, sampling 1 1
>>>>>>>>> >     fire_color.g, 16-bit floating-point, sampling 1 1
>>>>>>>>> >     fire_color.r, 16-bit floating-point, sampling 1 1
>>>>>>>>> >     fire_mask, 16-bit floating-point, sampling 1 1
>>>>>>>>> >     smoke_color.b, 16-bit floating-point, sampling 1 1
>>>>>>>>> >     smoke_color.g, 16-bit floating-point, sampling 1 1
>>>>>>>>> >     smoke_color.r, 16-bit floating-point, sampling 1 1
>>>>>>>>> >     smoke_mask, 16-bit floating-point, sampling 1 1
>>>>>>>>> > comment (type string): "none"
>>>>>>>>> > compression (type compression): zip, individual scanlines
>>>>>>>>> > dataWindow (type box2i): (0 0) - (2251 967)
>>>>>>>>> > displayWindow (type box2i): (0 0) - (2251 967)
>>>>>>>>> > lineOrder (type lineOrder): increasing y
>>>>>>>>> > pixelAspectRatio (type float): 1
>>>>>>>>> > screenWindowCenter (type v2f): (0 0)
>>>>>>>>> > screenWindowWidth (type float): 1
>>>>>>>>> >
>>>>>>>>> > channels (type chlist):
>>>>>>>>> >     A, 16-bit floating-point, sampling 1 1
>>>>>>>>> >     B, 16-bit floating-point, sampling 1 1
>>>>>>>>> >     G, 16-bit floating-point, sampling 1 1
>>>>>>>>> >     R, 16-bit floating-point, sampling 1 1
>>>>>>>>> >     fire_color.b, 16-bit floating-point, sampling 1 1
>>>>>>>>> >     fire_color.g, 16-bit floating-point, sampling 1 1
>>>>>>>>> >     fire_color.r, 16-bit floating-point, sampling 1 1
>>>>>>>>> >     fire_mask, 16-bit floating-point, sampling 1 1
>>>>>>>>> >     smoke_color.b, 16-bit floating-point, sampling 1 1
>>>>>>>>> >     smoke_color.g, 16-bit floating-point, sampling 1 1
>>>>>>>>> >     smoke_color.r, 16-bit floating-point, sampling 1 1
>>>>>>>>> >     smoke_mask, 16-bit floating-point, sampling 1 1
>>>>>>>>> > comment (type string): "none"
>>>>>>>>> > compression (type compression): zip, multi-scanline blocks
>>>>>>>>> > dataWindow (type box2i): (0 0) - (2251 967)
>>>>>>>>> > displayWindow (type box2i): (0 0) - (2251 967)
>>>>>>>>> > lineOrder (type lineOrder): increasing y
>>>>>>>>> > pixelAspectRatio (type float): 1
>>>>>>>>> > screenWindowCenter (type v2f): (0 0)
>>>>>>>>> > screenWindowWidth (type float): 1
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> > Andrew Wood
>>>>>>>>> > Pipeline Engineer, Digital Domain
>>>>>>>>> > x2914
>>>>>>>>> > _______________________________________________
>>>>>>>>> > Oiio-dev mailing list
>>>>>>>>> > [email protected]
>>>>>>>>> > http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>>>>>>>> 
>>>>>>>>> --
>>>>>>>>> Larry Gritz
>>>>>>>>> [email protected]
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> _______________________________________________
>>>>>>>>> Oiio-dev mailing list
>>>>>>>>> [email protected]
>>>>>>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>>>>>>>> 
>>>>>>>>> _______________________________________________
>>>>>>>>> Oiio-dev mailing list
>>>>>>>>> [email protected]
>>>>>>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>>>>>>> 
>>>>>>>> --
>>>>>>>> Larry Gritz
>>>>>>>> [email protected]
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> _______________________________________________
>>>>>>>> Oiio-dev mailing list
>>>>>>>> [email protected]
>>>>>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>>>>>>> 
>>>>>>>> 
>>>>>>>> _______________________________________________
>>>>>>>> Oiio-dev mailing list
>>>>>>>> [email protected]
>>>>>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>>>>>> 
>>>>>>> --
>>>>>>> Larry Gritz
>>>>>>> [email protected]
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> Oiio-dev mailing list
>>>>>>> [email protected]
>>>>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>>>>>> 
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> Oiio-dev mailing list
>>>>>>> [email protected]
>>>>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>>>>> 
>>>>>> --
>>>>>> Larry Gritz
>>>>>> [email protected]
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> _______________________________________________
>>>>>> Oiio-dev mailing list
>>>>>> [email protected]
>>>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>>>>> 
>>>>>> 
>>>>>> <in.exr><out.exr><out2.exr>_______________________________________________
>>>>>> Oiio-dev mailing list
>>>>>> [email protected]
>>>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>>>> 
>>>>> --
>>>>> Larry Gritz
>>>>> [email protected]
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> Oiio-dev mailing list
>>>>> [email protected]
>>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>>> 
>>>> --
>>>> Larry Gritz
>>>> [email protected]
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> Oiio-dev mailing list
>>>> [email protected]
>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>>> 
>>>> 
>>>> 
>>>> <flower.exr>_______________________________________________
>>>> Oiio-dev mailing list
>>>> [email protected]
>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>> 
>>> --
>>> Larry Gritz
>>> [email protected]
>>> 
>>> 
>>> _______________________________________________
>>> Oiio-dev mailing list
>>> [email protected]
>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>> 
>> --
>> Larry Gritz
>> [email protected]
>> 
>> 
>> 
>> _______________________________________________
>> Oiio-dev mailing list
>> [email protected]
>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>> 
>> 
>> _______________________________________________
>> Oiio-dev mailing list
>> [email protected]
>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
> 
> --
> Larry Gritz
> [email protected]
> 
> 
> 
> _______________________________________________
> Oiio-dev mailing list
> [email protected]
> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
> 
> 
> _______________________________________________
> Oiio-dev mailing list
> [email protected]
> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

--
Larry Gritz
[email protected]


_______________________________________________
Oiio-dev mailing list
[email protected]
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

Reply via email to