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. You can merge this Pull Request by running: git pull https://github.com/lgritz/oiio lg-overscan Or you can view, comment on it, or merge it online at: https://github.com/OpenImageIO/oiio/pull/222 -- Commit Summary -- * oiiotool enhancements: --pop, --dup, --select, --origin * Fix bug with parse_wrapmodes. * testtex: add --wrap to let you select wrap mode. * Change set_full to have default NULL value for bordercolor. * supports("origin") and supports("negativeorigin") * maketx and TextureSystem modified to handle textures with "overscan" (smaller "full/display" window than data window). -- File Changes -- M src/CMakeLists.txt (3) M src/doc/imageoutput.tex (7) M src/include/imagebuf.h (2) M src/include/imageio.h (4) M src/include/texture.h (8) M src/libtexture/imagecache.cpp (23) M src/libtexture/imagecache_pvt.h (7) M src/libtexture/texture3d.cpp (19) M src/libtexture/texture_pvt.h (22) M src/libtexture/texturesys.cpp (99) M src/maketx/maketx.cpp (249) M src/oiiotool/imagerec.cpp (14) M src/oiiotool/oiiotool.cpp (106) M src/oiiotool/oiiotool.h (33) M src/openexr.imageio/exrinput.cpp (23) M src/openexr.imageio/exroutput.cpp (4) M src/testtex/testtex.cpp (17) M src/tiff.imageio/tiffoutput.cpp (3) A testsuite/texture-overscan/ref/out.exr (0) A testsuite/texture-overscan/run.py (28) -- Patch Links -- https://github.com/OpenImageIO/oiio/pull/222.patch https://github.com/OpenImageIO/oiio/pull/222.diff --- Reply to this email directly or view it on GitHub: https://github.com/OpenImageIO/oiio/pull/222 _______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
