openexr 3.4.0

[BrewTestBot]

Created by brew bump

---

Created with brew bump-formula-pr.

release notes

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.


:warning: 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.


:warning: 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:


:sparkles: New colorInteropID standard attribute


The ID string endorsed by the Color Interop Forum to communicate the color space of RGB images in an interoperable manner.


The contents of the string is described in the specification An ID for Color Interop.


Guidance to application developers is provided in Identifying the Color Space of OpenEXR Files




:sparkles: 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.




:wrench: 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.



:wrench: 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:

:bug: Using openexr via cmake add_subdirectory now works properly.

Changes to the OpenEXR Python module:

:snake: :bug: The Python module now allows an empty part name for a single-part file
:snake: :bug: The header_only option for Python module's OpenEXR.File now works properly.
:snake: :package: :warning: pypi distributions now add support for Python 3.13 and drop support for Python 3.7.

View the full release notes at https://github.com/AcademySoftwareFoundation/openexr/releases/tag/v3.4.0.

---

[chenrui333]

  CMake Error at /home/linuxbrew/.linuxbrew/Homebrew/Library/Homebrew/cmake/trap_fetchcontent_provider.cmake:12 (message):
    Refusing to populate dependency 'openjph' with FetchContent while building
    in Homebrew, please use a formula dependency or add a resource to the
    formula.
  Call Stack (most recent call first):
    /home/linuxbrew/.linuxbrew/opt/cmake/share/cmake/Modules/FetchContent.cmake:2468:EVAL:1 (trap_fetchcontent_provider)
    /home/linuxbrew/.linuxbrew/opt/cmake/share/cmake/Modules/FetchContent.cmake:2468 (cmake_language)
    /home/linuxbrew/.linuxbrew/opt/cmake/share/cmake/Modules/FetchContent.cmake:2314 (__FetchContent_MakeAvailable_eval_code)
    cmake/OpenEXRSetup.cmake:302 (FetchContent_MakeAvailable)
    CMakeLists.txt:62 (include)