Hydra fails opening textures using OIIO, when asserts are enabled in OIIO

[sirpalee]

Package versions

OIIO: 1.6.11 (same thing is present in 1.5.8 too)

Steps to Reproduce

1. Just try to assign a uv texture to any hydra shader.

Explanation. When hydra (glf) opens a texture, it's trying to figure out the actual mipmap levels for any texture. That's done in GlfUVTextureData::_GetNumMipLevelsValid . The main method for this is just trying to open images until the GlfImage returns a nullptr signaling that the given subimage can't be opened, and setting up the mip map count to the highest subimage that still can be opened.

The whole code ends up in Glf_OIIOImage::_OpenForReading , which is returning the validity of the image like this

return _imagebuf.init_spec(_filename, subimage, /*mipmap*/0) and
        (_imagebuf.nsubimages() > subimage);

The previous code means calling the init_spec with the queried subimage. Which triggers an assert this line imagecache_pvt.h:268 . The init spec is creating an image_cache if there is no image_cache passed to the image_buf's constructor.

The simplest workaround is to init the spec over the first subimage, check for the number of subimages, then try to init the requested subimage.

return _imagebuf.init_spec(_filename, /*subimage*/0, /*mipmap*/0) and
        (_imagebuf.nsubimages() > subimage) and
        _imagebuf.init_spec(_filename, subimage, /*mipmap*/0);

I tried accessing the subimage info directly, using the shared imagecache's get_image_info, but for some reason, it was not working for me. Maybe something due to my build, not sure.

Even though this doesn't lead to an actual error, using the init_spec this way still triggers an assert and reads incorrectly from an std::vector. I think both of them should be avoided independently of the OIIO build type.

[jtran56]

Filed as internal issue #139553.

[sunyab]

Per @meshula in #204, newer versions of OIIO fail gracefully rather than asserting in this case. We may still want to consider this fix so that we're compatible with older versions, however. See AcademySoftwareFoundation/OpenImageIO#1670

[sunyab]

I believe this is no longer an issue, as the refactoring done in dc0140c makes Glf_OIIOImage::_OpenForReading use an ImageInput object and call seek_subimage which I believe should fail gracefully if the subimage is invalid. Marking this as pending release.

[sunyab]

This should be fixed in 19.11. Closing, thanks!