In EXR speak, "zip" is the usual deflate/zip compression in blocks of 16 scanlines, and "zips" is the same compression method, but applied to each scanline individually. Both are supported by OIIO.
The compression/decompression is handled on the OpenEXR library side, not by the OIIO code itself, so in theory anything should be fine with either one. Though I do see a comment in my code indicating that only "zips" has been found to be reliable for deep files. Can you give more detail about what's going wrong? You're rendering out an exr with "zips"? Writing it with OIIO? Then it's "borken" when you "process" them... in what way is it broken, how processed, in what program does it appear broken? (Is that when also reading with OIIO, or some other app?) Which versions of OIIO and OpenEXR are you using? Can you either send me one of these broken files to inspect, or else give a recipe for how to create one (ideally using only OIIO components)? > On Jan 4, 2017, at 2:28 PM, Zachary Bauer <[email protected]> wrote: > > Hello, > A question about OIIO compression support: > > I am having redshift output Multi-Part EXRs and their headers say their > compression is "zips". Typically what I see is "zip" compression for my EXRs > from other renderers (PRMAN). Processing these redshift images using Open > Image IO is resulting in broken images, but if I convert them to "zip" > compression using oiiotool first, everything seems to work ok. > > Is "zips" compression different than "zip"? > Does OIIO support "zips"? > > Thanks, > Zachary Bauer > Senior Software Engineer (Tools) > Blizzard Entertainment > > _______________________________________________ > 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
