Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
jessey-git opened this issue Dec 26, 2023 · 4 comments

Comments

@jessey-git
Copy link
Contributor

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
@lgritz
Copy link
Collaborator

lgritz commented Dec 26, 2023

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.

@jessey-git
Copy link
Contributor Author

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.

@lgritz
Copy link
Collaborator

lgritz commented Dec 27, 2023

"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.

@lgritz
Copy link
Collaborator

lgritz commented Apr 15, 2024

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

@lgritz lgritz closed this as completed Apr 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants