Hi Brendan, glad to hear v2 worked for you! The type attribute can actually be one of four values, since an image can be regular or deep, and tiled or scanline. The type info is required in the header of each part for multipart files, even ones with no deep data.
The only case where "type" is extraneous is for single part regular images (which will be the most common type of EXR). For consistency we chose to include it in this case too. Making "type" a string should make for more elegant handling of extra types in the future. Peter Brendan Bolles <bren...@fnordware.com> wrote:I've started experimenting using v2 with my ProEXR plug-ins. So far so good - just swapping in the new library with my old code lets me read the new files with multi-part and deep data handled for me. One thing that strikes me as a little odd is that the way to determine if an image uses deep data is a string attribute called "type". Actually, even old EXRs are now shown to have this attribute even when they clearly do not. Seems a little clumsy to me, shouldn't the type attribute be a more opaque enum-style data type, like tiledesc or lineOrder? BTW, my github fork has Xcode projects all set up to build the EXR libraries and apps like exrdisplay if anyone's interested. Brendan _______________________________________________ Openexr-devel mailing list Openexr-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/openexr-devel
_______________________________________________ Openexr-devel mailing list Openexr-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/openexr-devel
