I've recently been looking into automating various simple image processing tasks using OpenImageIO via the Python bindings. E.g. format conversion, resizing, normalizing display/data windows, color space conversion, contact sheet generation, "over" comps, tile stitching...
I've found the ImageBuf and ImageBufAlgo classes very convenient for expressing these operations clearly and concisely. But things got a messier when I wanted to work with multi-layer images (to use Nuke terminology). In particular, these are multi-subimage files where all the images are the same (display) resolution, but may have different numbers of channels or bit depths. It's common to get these out of a renderer now: the subimages might be stereo views, or AOVs (depth channels, mattes etc.) or a combination of both. I found myself often wanting to treat these as a single conceptual image, similar to the way most Nuke nodes can be set to apply to all layers. But ImageBuf requires you to specify a subimage to read. So the code complexity is increased as you need to cycle through each subimage process them separately, keep track of their names, bundle them all back together etc. As yet I haven't tried to implement anything along these lines for multi-layer images but we're considering doing it soon. I was wondering if there are any tricks to (optionally) hiding away the multi-subimage nature of images when working with ImageBufs and ImageBufAlgo operations, similar to the way many of these operations work independent of the number/name/type of channels. Or if not, do you think he API could be extended in an elegant way to allow that? This isn't so much a "can it be done?" question, as I'm sure the capability is there. It's more, can it be done succinctly? This could help us using the OIIO python bindings to do implement small automated image processing events in the pipeline in a low-overhead way. One small disclaimer, I'm working with a local branch of OIIO which is - for now - a year or so out of date, but I have been referring to the latest public documentation. Cheers Steve
_______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
