Skip to content

Releases: AcademySoftwareFoundation/openexr

v3.4.4

19 Nov 21:04
v3.4.4

Choose a tag to compare

Patch release with an optimization to reduce the size of the library.

B44 and DWA compression tables are now initialized at first use rather than being hard-coded in the source code and compiled binary. This reduces the library size at a slight performance cost. Initialization takes under a millisecond, but the size of libOpenEXRCore.so is reduced from around 1Mb to less than half that.

This also fixes a build issue with ILMTHREAD_THREADING_ENABLED which inadvertently enabled threading when it should have been disabled.

This also fixes a bug where importing the python module from a parent directory would fail.

Full changelog: v3.4.3..v3.4.4

v3.4.3

05 Nov 01:39

Choose a tag to compare

Patch release that addresses several bugs, primarily involving properly rejecting corrupt input data.

Specifically:

  • Buffer overflow in PyOpenEXR_old's channels() and channel() in legacy python, reported by Joshua Rogers (GitHub: MegaManSec).
  • Use after free in PyObject_StealAttrString in legacy python, reported by Joshua Rogers (GitHub: MegaManSec).
  • Use of Uninitialized Memory in openexr, reported by Aldo Ristori (GitHub: Kaldreic).
  • Heap-based Buffer Overflow Remote Code Execution Vulnerability, reported by Trend Micro Zero Day Initiative.

Also:

  • OSS-fuzz 456158449 Heap-buffer-overflow in generic_unpack
  • OSS-fuzz 447429458 Heap-buffer-overflow in DwaCompressor_uncompress
  • OSS-fuzz 439237843 Heap-buffer-overflow in internal_exr_undo_ht
  • OSS-fuzz 436037111 Heap-buffer-overflow in generic_unpack
  • OSS-fuzz 435779241 Heap-buffer-overflow in generic_unpack
  • OSS-fuzz 420744464 Abrt in __cxxabiv1::failed_throw

Other fixes:

  • Fix a bug with re-reading a scanline file with a different set of channels.
  • Only populate CMAKE_DEBUG_POSTFIX with _d if it is undefined, which makes it possible to set CMAKE_DEBUG_POSTFIX="".

This version also bumps the auto-fetched version of OpenJPH to 0.24.5. OpenJPH 0.24.5 addresses these OSS-Fuzz issues:

  • OSS-fuzz 456837230 Crash in ojph::local::param_cod::~param_cod
  • OSS-fuzz 456248580 Null-dereference READ in ojph::local::param_cod::~param_cod
  • OSS-fuzz 455374208 Floating-point-exception in ojph::local::tile::pre_alloc
  • OSS-fuzz 444963190 Index-out-of-bounds in ojph::local::param_qcd::read_qcc
  • OSS-fuzz 444889300 Heap-buffer-overflow in ojph::mem_infile::read
  • OSS-fuzz 444878558 Segv on unknown address in ojph::local::param_qcd::~param_qcd
  • OSS-fuzz 444878557 Null-dereference READ in ojph::local::param_qcd::~param_qcd

Full changelog: v3.4.2..v3.4.3

v3.3.6

05 Nov 01:26
027f332

Choose a tag to compare

Patch release that addresses several bugs, primarily involving properly rejecting corrupt input data.

Specifically:

  • Buffer overflow in PyOpenEXR_old's channels() and channel() in legacy python, reported by Joshua Rogers (GitHub: MegaManSec).
  • Use after free in PyObject_StealAttrString in legacy python, reported by Joshua Rogers (GitHub: MegaManSec).
  • Use of Uninitialized Memory in openexr, reported by Aldo Ristori (GitHub: Kaldreic).
  • Heap-based Buffer Overflow Remote Code Execution Vulnerability, reported by Trend Micro Zero Day Initiative.

Full changelog: v3.3.5..v3.3.6

v3.2.5

05 Nov 01:23

Choose a tag to compare

Patch release that addresses bugs in the python module's legacy API.

  • Buffer overflow in PyOpenEXR_old's channels() and channel() in legacy python, reported by Joshua Rogers (GitHub: MegaManSec).
  • Use after free in PyObject_StealAttrString in legacy python, reported by Joshua Rogers (GitHub: MegaManSec).

v3.4.2

16 Oct 14:59

Choose a tag to compare

Patch release that fixes a Windows build issue introduced in v3.4.1.

This version also bumps the auto-fetched Imath version to v3.2.2, which resolves a build problem with newer versions of cmake, involving duplicate library aliases.

No change in functionality.

v3.4.1

08 Oct 19:18
v3.4.1

Choose a tag to compare

Patch release that fixes a build issue: OpenJPH headers are now
included from the openjph folder, as required by OpenJPH 0.23+.

No change in functionality.

v3.4.0

05 Sep 17:36
v3.4.0

Choose a tag to compare

OpenEXR v3.4 introduces a new, additional compression option to the OpenEXR file format for lossless compression with High Throughput JPEG-2000 (HTJ2K) encoding:

  • A new HTJ2K compressor uses the High-Throughput (HT) block coder. It supports the full range of OpenEXR features, including 16-bit and 32-bit floating-point image channels, both scanline and tiled.

  • The HT block coder is standardized in Rec. ITU-T T.814 and ISO/IEC 15444-15. It is royalty-free, widely used in cinema and distribution servicing, and implemented in both commercial and open-source toolkits.

  • In experiments, we've found that HTJ2K produces smaller files, and depending on the nature of the image data, is one of the fastest compression types available in OpenEXR.

  • Integration with OpenEXR uses the OpenJPH open-source library. For ease in managing the dependency, the OpenEXR CMake configuration supports automatically fetching and building OpenJPH internally, or linking against an external installation.

  • OpenEXR supports two new compression types with distinct space/time trade-offs:

    • htj2k256 -- encodes/decodes chunks of 256 scanlines, producing slightly smaller file size than htj2k32.

    • htj2k32 -- encodes/decodes chunks of 32 scanlines, better suited to multi-threading, so it offers significantly faster encoding and decoding (4-6x in some cases) than htj2k256, with a slight increase in file size.

  • All existing OpenEXR compression options remain unchanged. This new feature simply extends the range of compression types available.

  • Software compiled with OpenEXR v3.4 will be able to read HTJ2K compressed OpenEXRs without any code changes. Software that writes files may automatically support the new type, but may need a small update to make the new type available as a user option.

  • ⚠️ This is a backwards-compatible extension to the OpenEXR file format. Files written with OpenEXR v3.4 will be readable by applications built against previous releases, unless they use the new htj2k32 or htj2k256 compression options.

  • ⚠️ This feature was first introduced for evaluation in February, 2025 via the htj2k-beta branch with a single 256 scanlines/chunk compression option, with the 32-scanline option added more recently. Application software written during this evaluation period will need to change IMF_HTJ2K_COMPRESSION to IMF_HTJ2K256_COMPRESSION, although files written with the earlier evaluation version should still read properly.

Other New Features:

  • New colorInteropID standard attribute

  • New bytes attribute type

    • Designed to hold an arbitrary binary blob of metadata.

    • The OpenEXR library forces no interpretations of the attribute contents; it is strictly application-dependent.

    • The attribute also holds a typeHint string which applications can use to suggest the intended interpretation of the contents,
      but it is strictly informational.

  • 🔧 TBB as a global thread provider

    • A new cmake option -DOPENEXR_USE_TBB=ON switches the internals of the thread pool to use TBB by default.
    • Building with this option adds a link dependency on the OneAPI TBB distribution.
  • 🔧 Vendored libdeflate

    • OpenEXR v3.4 now ships with a bundled distribution of the libdeflate library, replacing the previous "auto-fetch" mechanism.
    • By default, building OpenEXR will use a system installation of libdeflate as before, but if none is found, the build will use the internal copy of libdeflate.
    • Use -DOPENEXR_USE_INTERNAL_DEFLATE=ON to force the use of the internal vendored version.

Bug fixes:

  • 🐛 Using openexr via cmake add_subdirectory now works properly.

Changes to the OpenEXR Python module:

  • 🐍 🐛 The Python module now allows an empty part name for a single-part file
  • 🐍 🐛 The header_only option for Python module's OpenEXR.File now works properly.
  • 🐍 📦 ⚠️ pypi distributions now add support for Python 3.13 and drop support for Python 3.7.

v3.3.5

26 Jul 17:55
v3.3.5

Choose a tag to compare

Patch release with a couple bug/performance fixes:

  • 🐛 Fix for DeepScanlineInputFile read memory leak
  • 🚀 OpenEXRCore Deep pixel unpacking optimisation

v3.3.4

09 Jun 01:25
v3.3.4

Choose a tag to compare

Patch release with several bug/build/performance fixes:

  • 🐛 Fix a crash with deep scanline input
  • 🐛 Fix a bug when reading a file with missing tiles
  • 🐛 Fix a crash in exrmetrics
  • 🛠️ Fix a problem with /EHsc and /MP flags that broke CUDA compilation
  • 🛠️ Fix a build failure on MinGW
  • 🚀 Enable vectorisation for ZIP reconstruct stage on Windows

v3.3.3

24 Mar 03:50
v3.3.3

Choose a tag to compare

Patch release with miscellaneous bug/build/documentation fixes:

🐛 Fix a bug involving deep tiled images
🐛 Adjust the clamping on the dwa compression (Issue #1982)
🐛 Address issues with small exr files and header parse (Issue #1984)
🐛 Fix crash if user does not provide memory when filling deep framebuffer
🐛 Fix bad pointer SSE math causing out-of-bounds access
🐛 Fix potential buffer overwrite with zip data
🐛 Fix usage of utf-8 filenames for windows
🐛 Fix regression in reading EXR images on 32bit Windows involving atomic_compare_exchange_strong
🐛 Add checks to avoid using optimizations when inappropriate (Issue #1949)
🐛 Convert dwa encoder to use algorithm quantize (Issue #1915)
🐛 Fix incorrect v3 array size validation
🚀 Add minor huf encode / decode performance optimizations
🛠️ Add numpy dependency to python wrapper (Issue #1919)
🛠️ Remove duplicate cmake dependency from skbuild plugin (Issue #1958)
🛠️ Don't set the library postfix in the cmake cache (Issue #1981)

This version also introduces a new tool, exrmetrics, a utility to help analyize file i/o times and compression ratios. See exrmetrics for details.

This version also officially installs the exrcheck utility, formerly built for internal use but not installed.

This version also publishes the python bindings for arm64 on Ubuntu and macOS.

This version addresses the following security vulnerabilities:

  • CVE-2025-48074 Out-Of-Memory via Unbounded File Header Values
  • CVE-2025-48073 ScanLineProcess::run_fill NULL Pointer Write In "reduceMemory" Mode
  • CVE-2025-48072 Out of Bounds Heap Read due to Bad Pointer Arithmetic in LossyDctDecoder_execute
  • CVE-2025-48071 Heap-Based Buffer Overflow in Deep Scanline Parsing via Forged Unpacked Size