AcademySoftwareFoundation / OpenImageIO

Reading, writing, and processing images in a wide variety of file formats, using a format-agnostic API, aimed at VFX applications.

Home Page:https://openimageio.readthedocs.org

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

[BUG] Problems loading DWA-B EXR files by default -- too soon to default to openexr:core?

jessey-git opened this issue · comments

Describe the bug
Blender this week made the switch to the 2.5.x series and soon after hit rendering issues when displaying DWA-B files. We're currently using the latest version of OpenEXR at the time of filing: v3.2.1

It might be related to AcademySoftwareFoundation/openexr#1591

In any case, perhaps the default of using the Core library is a bit too soon right now?

To Reproduce
Steps to reproduce the behavior:

  1. Attempt to display the attached forest.exr file in the .zip provided
  2. Notice that things are broken when using the "openexr:core" attribute set to 1 (the default)
  3. Change the attribute to 0 and things should look normal

Evidence
When using openexr:core == 1
image

When using openexr:core == 0
image

forest.zip

Platform information:

  • OIIO branch/version: 2.5.6 release + patch for 4044
  • OpenEXR version: 3.2.1 latest release as of 2023-12-25
  • OS: Windows
  • C++ compiler: MSVC

This is most likely a bug in OpenEXR. Definitely file an issue there.

I would recommend that you, of course, turn the core option off for Blender.

Do you think we should switch the default back to off for OpenImageIO? Or should we see if we can get the OpenEXR side fixed ASAP? It would kind of be a silly dance to disable on the OIIO side, make a release (there would normally be one on Jan 1), then within days a fix in OpenEXR, then we have to switch it back on for OIIO.

I'm pretty sure it's fixed with the above referenced commit against OpenEXR but don't have an easy way to test atm. They've had the fix for 6 weeks but I'll try poking their slack and seeing when they're thinking of a release.

There might also be a ZIPS problem with core as well: https://academysoftwarefdn.slack.com/archives/CMLRW4N73/p1699948840458629

As for OIIO, we currently check for just OpenEXR 3.1.10+ when enabling core so maybe we'd have to change that, but there's nothing to change it to without a release on their end.

"They" is us. I'm on the OpenEXR TSC. We can ask for a 3.2.2 release as soon as possible after the new year.

If you think that core is still too bug-riddled to be relied on by default, we can certainly change that default on the OIIO side.

I think this has been fixed on the OpenEXR side, closing.