This set of changes works toward fully supporting OpenEXR 2.0. There are two
new features in OpenEXR 2.0: (1) multi-part EXR (a limited implementation of
multiple images in one file), and (2) deep data (arbitrary numbers of data
samples per pixel, and varying numbers of them with each pixel). This first
review corresponds to (1).
Unfortunately, OpenEXR's library requires that the multi-part files declare the
headers for all the parts upon opening the file. This is in contradiction to
the way TIFF works, and therefore the way I had organized OIIO's APIs, to allow
additional subimages to simply be appended one by one. So to accommodate this,
I had to add a new API call to ImageOutput:
bool open (const std::string &name, int subimages, const ImageSpec *specs);
This lets you open with full information about the number and specification of
subimages that you will be writing. A new supports("appendsubimage"), which
returns true for TIFF, is used to indicate a format that can be output with the
old appending method instead of requiring pre-declaration of the subimages.
I also changed oiiotool to use this new call in the appropriate way, and
verified that all this stuff is working by adding a test that uses oiiotool to
copy all the subimages of one of the new OpenEXR 2.0 test images. In the
process, I changed the convention of the exr test images being stored in
../openexr-images-1.5.0 (which seems like a bad idea to have a specific
version) to ../openexr-images. So beware that you may need to make a link on
your end to ensure that the testsuite runs properly.
It was a much bigger pain to modify 'iconvert' to write multi-part OpenEXR
files (or, more properly, to restructure it to use the new pre-declare flavor
of the API), so I didn't do that at this time. That means that for now, please
use oiiotool rather than iconvert if you anticipate needing to write multi-part
OpenEXRs. I'm not sure if that's a serious limitation, if it is I can try to
fix it, otherwise I'll get to it when I have a chance.
With this patch, OIIO will build with both OpenEXR 2.x as well as 1.x. Of
course, if only 1.x is found at build time, the multi-part support won't be
enabled. Also I've added top-level-Makefile OPENEXR_HOME=... and
ILMBASE_HOME=... variables that let you override the location of those
libraries.
I have one more set of changes coming after this one is approved and merged,
which will add support for "deep" images, which I hope will be the last public
API change before issuing a 1.2 release.
You can merge this Pull Request by running:
git pull https://github.com/lgritz/oiio lg-openexr2
Or view, comment on, or merge it at:
https://github.com/OpenImageIO/oiio/pull/435
Commit Summary
Add ImageOutput::open(name,subimages,subimagespecs[])
Change oiiotool to use the new "open with subimages specified" API call
Support for OpenEXR 2.x "multi-part" files (and build support for Ope…
testsuite/openexr-v2 tests OpenEXR 2.x features, also change OpenEXR
File Changes
M Makefile (9)
M src/CMakeLists.txt (4)
M src/cmake/externalpackages.cmake (18)
M src/doc/imageoutput.tex (271)
M src/doc/openimageio.tex (6)
M src/include/imagecache.h (2)
M src/include/imageio.h (33)
M src/include/version.h.in (3)
M src/oiiotool/oiiotool.cpp (31)
M src/openexr.imageio/exrinput.cpp (352)
M src/openexr.imageio/exroutput.cpp (494)
M src/tiff.imageio/tiffoutput.cpp (2)
M testsuite/openexr-chroma/ref/out.txt (6)
M testsuite/openexr-chroma/run.py (8)
M testsuite/openexr-multires/ref/out.txt (78)
M testsuite/openexr-multires/run.py (4)
M testsuite/openexr-suite/ref/out.txt (108)
M testsuite/openexr-suite/run.py (16)
A testsuite/openexr-v2/ref/out.txt (62)
A testsuite/openexr-v2/run.py (7)
M testsuite/runtest.py (10)
Patch Links
https://github.com/OpenImageIO/oiio/pull/435.patch
https://github.com/OpenImageIO/oiio/pull/435.diff
—
Reply to this email directly or view it on GitHub.
--
Larry Gritz
[email protected]
_______________________________________________
Oiio-dev mailing list
[email protected]
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
