You are right, ImageBuf alone only handles a "single" image, like just one
subimage or MIP level.
This comes up with oiiotool, which does a lot of the things you mention.
Internal to oiiotool, there is something called an ImageRec which encapsulates
everything in an image file, which is conceptually a collection of subimages,
and for each subimage either one image or all the MIP layers, each of which is
an ImageBuf. So a lot of oiiotool ops are implemented rather like this:
ImageRecRef A = ot.curimg;
for (int s = 0; s < A->subimages(); ++s) {
for (int m = 0; m < A->miplevels(s); ++m) {
ImageSpec *spec = &(*A)(s,m).specmod();
// Do stuff with ImageBuf (*A)(s,m)...
}
}
So one obvious question is, are you doing things the hard way in Python merely
to reproduce what oiiotool can do for you succinctly already, and handling all
the subimages?
Of course, you could make such a loop in Python, as well, with some more
housekeeping of the ImageBuf's. But if it's important that dealing with these
multi-image files be done in Python or C++ and it's just too clunky, then
perhaps we should consider taking ImageRec (or something like it, possibly with
a better choice of name), decoupling it from oiiotool, and exposing it more
widely. There's no real magic there, it's just a convenient wrapper for all the
subimages (each an ImageBuf) that are in a file.
I think that would pretty neatly solve the problems you have with layers,
stereo, and so on. You mentioned in a thread on another mail list also wanting
to work with video files. That may be another set of issues entirely.
Maybe the best way to proceed is for you to give 3 or 4 concrete examples of
things you want to do, and we can think about how it would most easily be done
today with the various APIs we have, and that might lead naturally to
discovering where the holes are that need to be addressed.
-- lg
> On Mar 15, 2016, at 9:44 PM, Steve Agland <[email protected]> wrote:
>
> 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
--
Larry Gritz
[email protected]
_______________________________________________
Oiio-dev mailing list
[email protected]
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
