Thanks for the bug report.
I've put that on github as issue #92.
What you suggest as a workaround is the expected use of the API:
unfortunately the sanity checks do not enforce that the type
attribute is present when creating one part using the
MultiPartOutputFile API.
I'm in two minds whether to inject a type attribute of
"scanlineimage" into all parts of multipart output files that are
missing them, or whether to change the sanity check.
On 18/02/14 11:47, Alexandre Thibodeau
wrote:
Hi,
I'm am developing a tool using OpenEXR. I use the
MultiPartOutputFile API because I will eventually support
multi-part files. As an initial test, I tried writing a single
part file with the multi-part API. I didn't want to implement
two different interfaces, so I didn't use the single-part API.
In the function
GenericOutputFile::writeMagicNumberAndVersionField, called by
the constructor of MultiPartOutputFile, a special check is
made for (parts == 1). If it's the case (it was for me),
headers[0].type() is called. Unlike the other types of files,
MultiPartOutputFile does not set the file type to
SCANLINEIMAGE. As a result, the attribute is not set, and
causes a crash.
A workaround consists of manually calling
SetType(SCANLINEIMAGE) after creating the header. However, to
avoid that someone get into the same issue, I suggest that
MultiPartOutputFile should be set to SCANLINEIMAGE by default,
like it's the case for the other API.
Thanks
_______________________________________________
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
