ID 472724 - Reading in large highly compressed EXR files cause crashes on import within Nuke

Problem summary

It has been discovered that when you Read in an EXR file that is in excess of ~545,000,000 pixels (roughly 30000x18000 resolution), Nuke will crash when importing the file.

This appears to occur more commonly with highly compressed zip algorithms such as PIZ, Zip16, DWAA, DWAB, B44 and B44A and occurs only in Nuke 12.0v1 releases and later.

This does not appear to be related to specific resolutions and more determinate to pixel count, and only when reading in the file, not rendering.

Customer reported version:

Nuke 12.2v6

Customer reported platform:

CentOS 7

Steps to reproduce:

1) Open a new Nuke session and create a Checkerboard node in the Node Graph.

2) Set the Checkerboard node's format to a new preset at '30000x18000'.

3) Create a Write node, setting the output file to .exr, set to RGBA, and selecting the PIZ compression format.

4) Render a single frame to a local directory.

5) Read in the rendered .exr file into the current Nuke session and observe Nuke's performance.

Expected behavior:

Nuke should remain stable when importing a large .exr file, as it does not exceed the 4,294,967,296 pixel limit within Nuke's viewer.

https://learn.foundry.com/nuke/13.0/content/getting_started/managing_scripts/loading_image_sequences.html

Actual behavior:

Nuke will crash when importing this large .exr file, or any similarly sized .exr utilizing PIZ, Zip16, DWAA, DWAB, B44 or B44A compression types

Workaround:

We would suggest ensuring that your total pixels used does not exceed ~545 million. Alternatively, if required to use .exr at this resolution, consider using the None, Zip1 and RLE compression formats.

Reproduced by Support in:

Nuke 14.0v3 - Windows 10, CentOS 7 

Nuke 13.0v3 - Windows 10, CentOS 7

Nuke 13.0v1 - Windows 10

Nuke 12.2v1 - Windows 10

Nuke 12.1v1 - Windows 10

Nuke 12.0v1 - Windows 10, macOS 10.15.6, CentOS 7 - Regression

Unable to reproduce bug in:

Nuke 11.3v6 - Windows 10, macOS 10.15.6, CentOS 7

Earliest version tested

Nuke 11.3v6 - This issue doesn't appear in this version and has regressed