Page MenuHome

Blender 2.79 is freezing while loading EXR Files as Textures.
Closed, ResolvedPublic


System Information
i5 4460 16gb ram 24 gb Swap

Operating system and graphics card
Linux Mint 17.3 Kernel 4.4.0-97
Asus Nvidia 1050 TI OC Expedition 4GB VRAM

Blender Version
Broken: 2.79 5bd8ac9abfa,
Worked: all versions of 2.78

Short description of error

Blender 2.79 GUI is freezing partly or in total when loading EXR as Texture Files. This problem is reproducable with all EXR Files no Matter of used Compression ( ZIP 1 Line , Zip 16 Lines, PIZ, DWA, RLE)
Also Blender consume the entire workload of the CPU just for loading a single 24mb file.
I added a video to show the problem. the interface freezes like in the video showed.

Exact steps for others to reproduce the error
Based on a (as simple as possible) attached .blend file with minimum amount of steps

Event Timeline

Vuk Gardašević (lijenstina) renamed this task from Blener 2.79 is freezing while loading EXR Files as Textures. to Blender 2.79 is freezing while loading EXR Files as Textures. .Oct 17 2017, 6:46 PM
Vuk Gardašević (lijenstina) updated the task description. (Show Details)
Brecht Van Lommel (brecht) lowered the priority of this task from Needs Triage by Developer to Needs Information from User.Oct 18 2017, 12:26 AM

I can't reproduce the issue here on Linux with the official 2.79 release, loading even 200MB .exrs, compressed or uncompressed, happens in less than a second. OpenEXR using all CPU threads is not a problem in itself, it helps speed up image loading, but it's not supposed to be this slow of course.

In the video it seems the .exr file does not actually get loaded, and the UI just slows down a lot, so perhaps it's failing to load the image into GPU memory or something like that, or an addons is doing weird things.

  • Please try File > Load Factory Settings and then load the image, there may be some settings (color management, image draw method in user preferences) or addons influencing things.
  • Please attach a .exr file that reproduces the issue. Even if it happens for all the ones you tested, we don't know that it's actually all .exr files that have the problem.


So i tried the Factory Default Way, Dont work at all, its slow.

I will not Share any EXR File, just for testing. Dose not make any sense cause the problem is not the file, happens with every EXR file, and the file itself cannot be the problem because:

The EXR files are getting loaded in NUKE in 1 second. Is loaded in Natron in 1 Second, also in Houdini. Also in Blender 2.78 ( all versions : a b c) and also in Fusion without any problem. The EXR file itself is compressed in ZIP 1 Line. i also tested ZIP 16 Lines dont change the problem. also RLE and PIZ Compression dosent make any difference.

I tried to use a uncompressed EXR and this also generates the problem.


The Problem persists in all cases in Blender 2.79 also when using Factory Defaults.

Idea for Solution: Redo all changes in the EXR Code -> all Codelines which are edited within 2.79 compared to 2.78.
I will quit this discussion here, and hope someone find a solution....the developers need to go through the code lines step by step, and compare 2.78 and 2.79 i guess this can lead to finding the error.

Annother Idea could be the Memory load functions of EXR. I dont no the code of blender. But it looks for me like that Blender is not able to decode the EXR Files thats why the CPU is running at 100% and the GUI is freezing.

Question: Why the hack Do someone change the EXR Code? I mean, sorry but its not even EXR 2.0 in Blender, its just 1.x right with a DWAA addition.


Iam out.

We ask for the .exr file not because we think the file itself is broken, but because to investigate this we need a way to reproduce the issue, and so far we don't have that. There can always be something different about .exr files you tested, tile vs. scanline, specific metadata, non-power of two resolution, .. lots of unknowns.

I already checked the code changes in our OpenEXR integration between 2.78c and 2.79, there's nothing significant there. It's almost certainly not the OpenEXR code itself that's the problem, but some interaction with other parts of Blender, and that's very difficult to guess.

This is a smaller Test file which results in the same problem. I cannot share the large File with you without that we make a contract with every involved person, and without money. So its just a test file.

Sorry to say i cannot understand why this stuff works in 2.78 and not in 2.79 this dosent make sense at all...

Where is the problem? Why is Blender everytime just a damn fucking patchwork?! Implement EXR with full functions in industry Standard way like every other developer is doing! The Blender Foundation is earning so much damn fucking money and is not able to implement just the correct EXR thing?really?

Sorry iam now really out of this now. Find the problem or not. Its everytime the same problem with Blender.

2.78c was the last Blender for me. Or like a great Blender Artist told me a week ago: "When they just invent new stuff instead of greating an consolidating all the bugs before they invent new stuff, they will probably have a hard time with 2.80"


BTW i will not recive any further mail or answer, cause i delete my account now, was the last time ,that ive wasted my time with this.

Brecht Van Lommel (brecht) raised the priority of this task from Needs Information from User to Confirmed, Medium.Oct 18 2017, 4:09 AM

Confirmed bug with the file, both Blender 2.78c and 2.79 have the problem here, with this error in the console:

OpenEXR-readPixels: ERROR: Error reading pixel data from image file "dummy". Tried to read scan line outside the image file's data window.

oiiotool shows this file has a different data and display window, so likely it's related to that:

Reading test.exr
test.exr             : 4096 x 4096, 4 channel, half openexr
    channel list: R, G, B, A
    pixel data origin: x=0, y=-631
    full/display size: 5202 x 3465
    full/display origin: 0, 0