OpenEXR is a high dynamic-range (HDR) image file format developed by
Industrial Light & Magic for use in computer imaging applications.
OpenEXR is used by ILM on all motion pictures currently in production.
The first movies to employ OpenEXR were Harry Potter and the Sorcerers Stone,
Men in Black II, Gangs of New York, and Signs. Since then, OpenEXR has become
ILM's main image file format.
OpenEXR's features include:
* Higher dynamic range and color precision than existing 8- and 10-bit
image file formats.
* Support for 16-bit floating-point, 32-bit floating-point, and 32-bit
integer pixels. The 16-bit floating-point format, called "half", is compatible
with the half data type in NVIDIA's Cg graphics language and is supported
natively on their new GeForce FX and Quadro FX 3D graphics solutions.
* Multiple lossless image compression algorithms. Some of the included codecs
can achieve 2:1 lossless compression ratios on images with film grain.
* Extensibility. New compression codecs and image types can easily be added
by extending the C++ classes included in the OpenEXR software distribution.
New image attributes (strings, vectors, integers, etc.) can be added to
OpenEXR image headers without affecting backward compatibility with existing
OpenEXR applications.
===> The following configuration options are available for openexr-3.4.16:
DOCS=on: Build and/or install documentation
EXAMPLES=on: Build and/or install examples
===> Use 'make config' to modify these settings
graphics/openexr*: security fix update to v3.4.15
"v3.4.15 fixes two memory issues when parsing IDManifests. Corrupt
or maliciously formed OpenEXR images could trigger excessive memory
allocation, but only in code which decodes the idmanifest attribute.
Other code is unaffected, even when handling files with idmanifest
attributes [...] CVEs have been requested for these issues."
<https://github.com/AcademySoftwareFoundation/openexr/releases/tag/v3.4.15>
CVEs are not yet communicated.
Changelog: https://github.com/AcademySoftwareFoundation/openexr/blob/v3.4.15/CHANGES.md#version-3415-august-21-2026
Pull request: https://github.com/freebsd/freebsd-ports/pull/594
MFH: 2026Q3
PR: 297717
graphics/openexr*: Security update to v3.4.5 and i386 fix
"Patch release that fixes an incorrect size check in
istream_nonparallel_read that could lead to a buffer overflow on invalid
input data."
Also fix i386 self-tests by adding -msse2: i386 builds require SSE2, but
the upstream cmake stuff does not enable this, so use CFLAGS_i386.
To prevent people seeing SIGILL crashes down late at run-time,
check if the CPU is sse2-capable by querying the clang compiler from
the pre-install script (pkg-plist's @preexec). Suggested by diizzy@.
Other than that we could use the cpuid or the lscpu port instead, but
let's for now assume everything that wants to run OpenEXR also has a
working cc that is clang and has -march=native and gives us CPU details).
(GCC also gives us this but will use a different output format.)
While here, make failed tests verbose through ctest's environment so we
can see what's up from the build log already. (We need to go through
this indirection because our cmake.mk's :testing feature wants to go
through the test target instead of calling ctest directly.)
Changelog: https://github.com/AcademySoftwareFoundation/openexr/releases/tag/v3.4.5
Security: 716d25a6-0fdc-11f1-bfdf-ff9355aecb00
MFH: 2026Q1
graphics/openexr: fix build on Sandy Bridge CPUs
OpenEXR attempts to use F16C intrinsics when AVX available and
at least one of these is true: F16C available, GCC used, or clang used.
Intel Sandy Bridge processors do have AVX extensions,
but no F16C instruction set extension, so compilers (clang 19, 20, gcc 14)
complain:
work/openexr-3.4.4/src/lib/OpenEXRCore/unpack.c:37:18:
error: always_inline function '_mm256_cvtph_ps' requires target feature
'f16c',
but would be inlined into function 'half_to_float_buffer'
that is compiled without support for 'f16c'
37 | out, _mm256_cvtph_ps (_mm_loadu_si128 ((const __m128i*)
in)));
| ^
Not bumping PORTREVISION because this is not a supported configuration.
https://github.com/AcademySoftwareFoundation/openexr/issues/2231
Reported by: "UnitedMarsupials"
MFH: 2025Q4
graphics/openexr*: update to v3.4.0
Adds lossless compression with High Throughput JPEG-2000 (HTJ2K)
encoding, which adds an OpenJPH dependency.
The OneAPI TBB option isn't provided because it massively increases
self-test time on FreeBSD 14.3-amd64 and I don't see how production
use would be different. This is with an AMD Ryzen processor.
ChangeLog: https://github.com/AcademySoftwareFoundation/openexr/releases/tag/v3.4.0
math/Imath: update to v3.2.0 bugfix release
ChangeLog:
https://github.com/AcademySoftwareFoundation/Imath/releases/tag/v3.2.0
Note this changes the .so versioning again, so I'll again need to
do additional cleanups because people don't just depend on Imath.
This is unneeded extra work except in the situation of OpenEXR
which is co-developed with Imath by the upstream maintainer,
Academy Software Foundation (ASWF).
I have no intentions of MFH'ing this due to the .so versioning change.
graphics/openexr-website-docs: unbreak and update to 3.3.2
And while here, decouple our PORTVERSION from the openexr version so we
don't break builds.
v3.3.2 seems to have a regression and causes a warning around Latest
News inserts on one site, so add -DSPHINX_OPTS= to override the default
of -W which means "treat warnings as errors", as of 3.3.2, I see one
warning.
graphics/openexr*: upgrade to 3.3.0
This changes the ABI (but not the API) and .so file name,
so we will need to bump all PORTREVISIONs of users, and we'll also fix
graphics/ctl and multimedia/olive.
This is not going to be MFHd to 2024Q4 due to API change, and therefore
has also waited for 2024Q4 to branch before we committed this to main,
so as to avoid 2024Q4 breakage.
ChangeLog: https://github.com/AcademySoftwareFoundation/openexr/releases/tag/v3.3.0
PR: 281859
graphics/openexr: Only build test suite when requested
In order to avoid ctest performance regressions, we also required
commit cbee39bcd1a2472b8f3e24754f5bb3a3429b79a0 from PR 278533.
PR: 278500
graphics/openexr-website-docs: fix build with v3.2.4 changes
- share the distfiles directory and the NO_WRKSUBDIR
- update patch for updated upstream CMakeLists.txt infrastructure
graphics/openexr: fix post-extract to move testimages into place
...and avoid downloading in the configure phase.
Reported by: Tatsuki Makino
While here, revert TESTING_UNSAFE, which does not reproduce,
neither under WITH_TESTING=yes in make.conf in poudriere after "make
distclean".
Bump PORTREVISION.
graphics/openexr: update to 3.2.0
- Also install manual pages (generated through help2man)
- The website (formerly known "DOCS" build) requires the "convert(1)"
tool, which is part of ImageMagick, which itself depends on OpenEXR.
To break the loop, split out the offline website build to a new
package, graphics/openexr-website-docs
graphics/openexr: Fix ARMv7 build
OpenEXR 3.1.6 introduced several NEON-based optimizations
that implied Aarch64. Add patched, either picked from
upstream, or written by mandree@, to enable those
NEON features that also require Aarch64 only there.
PR-1366 is cherry-picked from upstream, and patch-lib/patch-test files
are my work but build upon said PR.
Also cherry-pick PR1354 that adds a missing check for AVX,
which is why I am bumping PORTREVISION because it might change
code (I have not checked).
https://github.com/AcademySoftwareFoundation/openexr/issues/1365
PR: 270348
Reported by: fuz@ (Robert Clausecker)
Remove WWW entries moved into port Makefiles
Commit b7f05445c00f has added WWW entries to port Makefiles based on
WWW: lines in pkg-descr files.
This commit removes the WWW: lines of moved-over URLs from these
pkg-descr files.
Approved by: portmgr (tcberner)
Add WWW entries to port Makefiles
It has been common practice to have one or more URLs at the end of the
ports' pkg-descr files, one per line and prefixed with "WWW:". These
URLs should point at a project website or other relevant resources.
Access to these URLs required processing of the pkg-descr files, and
they have often become stale over time. If more than one such URL was
present in a pkg-descr file, only the first one was tarnsfered into
the port INDEX, but for many ports only the last line did contain the
port specific URL to further information.
There have been several proposals to make a project URL available as
a macro in the ports' Makefiles, over time.
(Only the first 15 lines of the commit message are shown above )
graphics: remove 'Created by' lines
A big Thank You to the original contributors of these ports:
* "Waitman Gobble" <uzimac@da3m0n8t3r.com>
* Aaron Dalton <aaron@FreeBSD.org>
* Abel Chow <ozsanh45vds001@sneakemail.com>
* Adam Weinberger <adamw@FreeBSD.org>
* Ade Lovett <ade@FreeBSD.org>
* Ade Lovett <ade@lovett.com>
* Akinori MUSHA aka knu <knu@idaemons.org>
* Aldis Berjoza <aldis@bsdroot.lv>
* Alex Hayward <xelah@xelah.com>
* Alex Ivasyuv <siegerstein@pochta.ru>
* Alex Samorukov <samm@os2.kiev.ua>
(Only the first 15 lines of the commit message are shown above )
graphics/openexr: bugfix update to 3.1.5
* Add backwards-compatibilty flags to the core library to match
original behavior of the the c++ library. Fixes reading of certain
files by the new core.
* Documentation refers to primary branch as "main"
* Update the CI workflow matrix to VFX-CY2022
Specific OSS-fuzz issues addressed:
* OSS-fuzz 46309 Heap-buffer-overflow in Imf_3_1::memstream_read
* OSS-fuzz 46083 Out-of-memory in openexr_exrcheck_fuzzer
* OSS-fuzz 45899 Integer-overflow in internal_exr_compute_chunk_offset_size
* OSS-fuzz 44084 Out-of-memory in openexr_exrcheck_fuzzer
MFH: 2022Q2
graphics/openexr: security update to 3.1.4
* Several bug fixes to properly reject invalid input upon read
* Miscellaneous documentation improvements
This addresses one public security vulnerability:
* CVE-2021-45942 Heap-buffer-overflow in Imf_3_1::LineCompositeTask::execute
Changelog:
https://github.com/AcademySoftwareFoundation/openexr/blob/v3.1.4/CHANGES.md#version-314-january-26-2022
Security: CVE-2021-45942
MFH: 2022Q1
graphics/openexr: Update to 3.0.4
Patch release that corrects a problem with the release version numbers
in v3.0.2/v3.0.3, and with the referenced Imath release.
graphics/openexr: math/Imath: update to v3.0.3
Only upstream change is an install-fix that had previously been
cherry-picked by the FreeBSD port already.
Besides the version no., no impact on Imath or OpenEXR code, so
no PORTREVISION bumps of our users this time.
graphics/openexr: C++14->C++11, overflow fix
Cherry-pick an upstream fix to relax users to C++11, only the
OpenEXR code itself requires C++14.
Cherry-pick an upstream fix to prevent overflow in
getScanlineChunkOffsetTableSize.
While here, rename MAJORVER to _MAJORVER as portclippy cleanup.
graphics/openexr: really commit v2.5.4 update.
Unfortunately, this was missed with the ilmbase update, and
causes yet another PORTREVISION bump on all dependent ports.
repeating ilmbase's commit log here:
"Patch release with various bug/sanitizer/security fixes, primarily related to
reading corrupted input files."
<https://github.com/AcademySoftwareFoundation/openexr/releases/tag/v2.5.4>
Cherry-pick upstream commit for GCC 11 compatibility:
<https://github.com/AcademySoftwareFoundation/openexr/commit/a40a6151c4e746eb8f93c7c06992d0ec11289fdc>
Since this changes the patchlevel of the solibs, bump PORTREVISION of dependent
ports just to be sure.
(graphics/py-openshadinglanguage is unaltered and .includes the revision bump
from .../openshadinglanguage.)
MFH: 2021Q1 (this requires discussion by ports-secteam@!)
Reported by: VVD (IRC, #bsdports)
graphics/ilmbase, graphics/openexr: security update to v2.5.3
ChangeLog:
https://github.com/AcademySoftwareFoundation/openexr/releases/tag/v2.5.3
"Patch release with various bug/security fixes and build/install fixes, plus a
performance optimization:
* Various sanitizer/fuzz-identified issues related to handling of invalid input
* Fixes to misc compiler warnings [...]
* Read performance optimization (#782)
* Fix for building on non-glibc (#798)
* Fixes to tests"
The full name of shared libraries changed from *.25.0.1 to *.25.0.2
=> PORTREVISION bumps for all ports that use either ilmbase or openexr
coming up in separate commit to ease MFH.
All test builds of direct users succeeded on 12.1 amd64.
MFH: 2020Q3 (patchlevel update w/ security fixes)
Security: b1d6b383-dd51-11ea-a688-7b12871ef3ad
graphics/openexr: fix build on powerpc head
USE_GCC=yes breaks build on head, because powerpc now uses libc++. On stable/11
and stable/12, it's redundant because there already is USES=compiler:c++14-lang.
graphics/ilmbase: graphics/openexr: update to upstream release 2.5.1
Upstream release notes:
* A patch release that corrects the SO version for the v2.5 release,
which missed getting bumped in v2.5.0.
* This release also fixes an improper failure in IlmImfTest
when running on ARMv7 and AAarch64.
Bump PORTREVISION of all port directly requiring ilmbase or openexr
that are not marked BROKEN (shlib/.so file version bump).
Test build of all port directly depending on ilmbase or openexr
succeeded in poudriere in a 12.1-RELEASE amd64 jail.
graphics/ilmbase: graphics/openexr: update to v2.5.0
ChangeLog:
- https://github.com/AcademySoftwareFoundation/openexr/releases/tag/v2.5.0
* Bump PORTREVISION of all consumers except py-openimageio (BROKEN).
* cad/PrusaSlicer:
LIB_DEPENDS: remove version from libHalf.so
BUILD_DEPENDS+=qt5-buildtools as package (needed on bare metal builds)
USE_GL+=gl
USES+=pkgconfig (needed to find libHalf)
graphics/openexr: fix plist in -EXAMPLES config, remove LARGE_STACK
With the EXAMPLES option unset, the plist was mismatched.
Fix all found combinations of DOCS/EXAMPLES dis-/enabled.
While here, LARGE_STACK is apparently an ilmbase-only option as
reported by cmake, remove it.
Reported by: Matthias Fechner
ilmbase, openexr: Update to upstream release v2.4.1 (bugfixes)
Changelog
<https://github.com/AcademySoftwareFoundation/openexr/releases/tag/v2.4.1>:
Patch release with minor bug fixes.
Quoting Cary Phillips:
Various fixes for memory leaks and invalid memory accesses
Various fixes for integer overflow with large images.
Various cmake fixes for build/install of python modules.
ImfMisc.h is no longer installed, since it's a private header.
MFH: 2020Q1 (patchlevel/bugfixes but beware one private .h file removed)
Port ilmbase build fixes including WITH_DEBUG=yes builds.
- under WITH_DEBUG=yes builds, avoid renaming the libraries with _d suffix.
(else it breaks packaging, and we don't want separate lib names) [1]
- while here, avoid creating symlinks from cmake, this causes staging
violations due to cmake bug #17340, (poudriere testport)
see https://gitlab.kitware.com/cmake/cmake/issues/17340
- while here, fix "make test" target - it is a left over from 2.3's
gmake build. Use ctest instead. Removes TEST_TARGET.
No PORTREVISION bump necessary because each and every fixed bug would
cause a broken build and no install.
PR: 243274 [1]
Reported by: Marcin Cieslak [1] against graphics/ilmbase
graphics/ilmbase, graphics/openexr: upgrade to upstream v2.4.0
graphics/gstreamer1-plugins-openexr: switch from C++98 to C++11 to
match new OpenEXR headers and unbreak compilation.
Bump PORTREVISION of all ports depending directly on either, based
on assessing INDEX-12 (bump_portrevision.pl -l (shallow) used).
Release Notes:
https://github.com/AcademySoftwareFoundation/openexr/releases/tag/v2.4.0
The update was deliberately deferred until after 2020Q1, and should
not be MFH'd back to it.
Bump PORTREVISION for ports depending on the canonical version of GCC
as defined in Mk/bsd.default-versions.mk which has moved from GCC 8.3
to GCC 9.1 under most circumstances now after revision 507371.
This includes ports
- with USE_GCC=yes or USE_GCC=any,
- with USES=fortran,
- using Mk/bsd.octave.mk which in turn features USES=fortran, and
- with USES=compiler specifying openmp, nestedfct, c11, c++0x, c++11-lang,
c++11-lib, c++14-lang, c++17-lang, or gcc-c++11-lib
plus, everything INDEX-11 shows with a dependency on lang/gcc9 now.
PR: 238330
Bump PORTREVISION for ports depending on the canonical version of GCC
defined via Mk/bsd.default-versions.mk which has moved from GCC 7.4 t
GCC 8.2 under most circumstances.
This includes ports
- with USE_GCC=yes or USE_GCC=any,
- with USES=fortran,
- using Mk/bsd.octave.mk which in turn features USES=fortran, and
- with USES=compiler specifying openmp, nestedfct, c11, c++0x, c++11-lang,
c++11-lib, c++14-lang, c++17-lang, or gcc-c++11-lib
plus, as a double check, everything INDEX-11 showed depending on lang/gcc7.
PR: 231590
Update ilmbase and openexr to 2.3.0, rename OpenEXR to openexr.
Release notes: <https://github.com/openexr/openexr/releases/tag/v2.3.0>
Adjust LIB_DEPENDS of all ports that require ilmbase or openexr to chase
the new lower-case spelling of the name, and to omit the version from the
library name to ease future maintenance.
Bump PORTREVISION of all ports that depend on ilmbase or openexr directly,
so that they all get rebuilt on upgrades.
Add patches to graphics/ampasCTL to keep it alive, with (a) ilmbase now
that its Iex::BaseExc class is no longer derived from std::string,
details were given upstream through https://github.com/ampas/CTL/issues/71
and (b) to unwind semicolon/;-lists in cmake that stem from openexr/
ilmbase pkg-config variables.
(Note ampasCTL is unmaintained as FreeBSD port, and upstream,
and I cannot run-time test it.)
Poudriere build tests on 11.2-RELEASE-p1 amd64 of ALL ports depending
directly or indirectly on ilmbase and/or openexr have passed without
regressions. Thus invoking due diligence, I believe I have done the
equivalent of an -exp run, and do not require approval for the dependency
chases to third-party ports.
