I don't think this is a bug.
The code you are quoting is in variety of open() that is passed the specs for
all anticipated subimages. If you look early in that function (line 450 in the
current master), you'll see that for the case of a non-deep, single-subimage
file, it takes an early out by calling the ordinary "open with a single spec"
variety, which is the old code path we've used for years.
The specific test of "if (subimages > 1 || deep)" is not wrong, however it is
superfluous because it will always be true by the time it gets to that point in
the code.
We've been using this code for some time for all our renderer output, which is
consumed by Nuke (among other things), so I'm fairly sure we would have noticed
if we were outputting invalid OpenEXR files.
What application is having trouble reading these files, and can you send me an
example OpenEXR file that can't be read? (Privately, if you prefer.)
Alternate hypothesis: is it possible that despite writing a single-part,
non-deep image, you are doing something else that is triggering the underlying
libIlmImf to output an OpenEXR 2.0 file? (Example: using attribute names that
are longer than the unfortunately short limit of EXR 1.) And then your "other
application" is still linked against libIlmImf 1.x, which doesn't recognize it
as a valid file?
-- lg
On Nov 18, 2013, at 5:24 AM, Michel Lerenard <[email protected]> wrote:
> Hi,
>
>
> while trying to understand why some of our EXR files could not be correctly
> opened by other application, i had a look in the OpenEXROutput::open function
> and there's something I don't get: we do not seem to be setting the type of
> the image if we have 1 subimage and no deep image.
>
>
> Here's the bit of code (L457)
> std::string filetype;//L457
> if (specs[0].deep)
> filetype = specs[0].tile_width ? "tiledimage" : "deepscanlineimage";
> else
> filetype = specs[0].tile_width ? "tiledimage" : "scanlineimage"; //L460
> bool deep = false;
> for (int s = 0; s < subimages; ++s) {
> if (! spec_to_header (m_subimagespecs[s], m_headers[s]))
> return false;
> deep |= m_subimagespecs[s].deep;
> if (m_subimagespecs[s].deep != m_subimagespecs[0].deep) {
> error ("OpenEXR does not support mixed deep/nondeep multi-part
> image files");
> return false;
> }
> if (subimages > 1 || deep) {//L470
> bool tiled = m_subimagespecs[s].tile_width;
> m_headers[s].setType (deep ? (tiled ? Imf::DEEPTILE :
> Imf::DEEPSCANLINE)
> : (tiled ? Imf::TILEDIMAGE :
> Imf::SCANLINEIMAGE));
> }
> }
>
> filetype does not seem to be used, and the values that we put into it are
> exactly the ones defined by the Imf constants.
>
> As far as I can see, we can remove L456->460, and remove the test L470.
>
> Any thoughts ?
>
>
>
> Michel
>
> _______________________________________________
> 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
