OpenImageIO/oiio — pull request #222 by lgritz (2012-01-30 00:19:52+00:00)
Title: Review: handle textures with "overscan"

This review adds logic to ensure correct handling of "overscanned" texture (in the parlance of OpenEXR, that means a "data window" that extends beyond the "display window" that defines 0-1 texture space). Although I can find no renderer that supports this currently, it is fairly common to use overscan for compositing, and we have had requests to support it in rendering as well.

There is some trickery involved because OpenEXR's design did not seem to fully consider the combination of MIPmaps and non-zero data window origins. In particular, OpenEXR specifies a single data window and a single display window for the entire MIPmap; obviously they only have meaningful coordinates for the highest-res level of the MIPmap, but the weirdness comes home to roost because you still access tiles of the upper levels using coordinates based on the origin of the highest-res level, which makes no sense when you think about it. We use the highest level to determine the relationship between the data window and texture space, then just play along with the insanity for the other levels and it all works out.

At present, even with this backwards overbending, OpenEXR is the only texture format I've found that can support overscan. TIFF is very close, but it all breaks down because the "origin" TIFF tags are unsigned, so your pixel data area cannot start with negative value coordinates, oops.

It really is only meaningful with "black" and "clamp" wrap modes. Trust me, you don't want to work out what the correct or useful behavior of "periodic" or "mirror" ought to be when combined with display and data windows that don't match.

A few other fixes and enhancements were performed along the way of this review, and are included herein (though when I merged, they will look like separate commits). Among them:

* oiiotool additional commands: --pop, --dup, --origin, --selectmip. Useful in constructing my test cases.

* parse_wrapmodes was just plain wrong for the (obsolete) TextureOptions.

* testtex has a new --wrap argument that lets you specify the wrap mode.

* ImageOutput::supports() now takes two new tags: "origin" and "negativeorigin" in case apps want to know whether a format supports nonzero data and/or display origins, and separately, whether they can be negative or only positive.