Install¶
Linux¶
The OpenEXR library is available for download and installation inbinary form via package managers on many Linux distributions.
Beware that some distributions are out of date and only providedistributions of outdated releases OpenEXR. We recommend against usingOpenEXR v2, and westrongly recommend against using OpenEXR v1.
Refer to the current version of OpenEXR on various major Linux distros atrepology.org:
To install viayum on RHEL/CentOS:
%sudoyummakecache%sudoyuminstallOpenEXR
To install viaapt-get on Ubuntu:
%sudoapt-getupdate%sudoapt-getinstallopenexr
macOS¶
On macOS, install viaHomebrew:
%brewinstallopenexr
Alternatively, you can install on macOS viaMacPorts:
%portinstallopenexr
Windows¶
Install viavcpkg:
%.\vcpkginstallopenexr
Build from Source¶
OpenEXR builds on Linux, macOS, Microsoft Windows via CMake, and iscross-compilable on other systems.
Download the source from theGitHub releases pagepage, or clone therepo.
If cloning the repo, check out therelease branch:
%gitcheckoutrelease
Therelease branch of the repo always points to the most advanced stablerelease. Other branches may contain compatible updates to older releases.
The defaultmain branch may contain experimental features which could change in futureversions. It should only be used for testing, or for developers contributing tothe OpenEXR project.
Prerequisites¶
Make sure these are installed on your system before building OpenEXR:
OpenEXR requires CMake version 3.14 or newer
C++ compiler that supports C++17
Imath(auto-fetched by CMake if not found) (https://github.com/AcademySoftwareFoundation/Imath)libdeflate(internal copy used by CMake if not found forv3.4+; auto-fetched in v3.3 and before) (https://github.com/ebiggers/libdeflate)openjph(auto-fetched by CMake if not found; new in v3.4) (https://github.com/aous72/OpenJPH)(optional) Intel’s Thread Building Blocks library (TBB)
The instructions that follow describe building OpenEXR with CMake.
Note that as of OpenEXR 3, the Gnu autoconf bootstrap/configure buildsystem is no longer supported.
OpenEXR/Imath Version Compatibility¶
In most circumstances, follow this best practice:
When building OpenEXR v3.4+, use Imath v3.2
When building OpenEXR v3.3 or before, use Imath v3.1.
OpenEXR v3.X isfunctionally compatible with any v3.Y release ofImath. Therefore, if you have control over how OpenEXR and Imath arebuilt in your application or facility, any combination of OpenEXR v3.Xand Imath v3.Y can be built successfully from source.
However, an OpenEXR v3.X distibution (i.e. compiledlibOpenEXRlibrary) built against a specific v3.Y minor release of Imathrequires that minor Imath release as both a build-time and run-timedependency. Furthermore, application code compilation units that usea specific OpenEXR v3.X distibution must be built using the associatedImath release.
OpenEXR uses Imath symbols in its public API, and both Imath andOpenEXR use suffixed namespaces that embed the minor releaseversion. For example, theV3fAttribute class in a distribution ofOpenEXR v3.4 built against Imath v3.2 is a template instantiation ofImf_3_4::TypedAttribute<Imath_3_2::Vec3<float>>, while thecorresponding class for a distribution of OpenEXR v3.4 built againstImath v3.1 will beImf_3_4::TypedAttribute<Imath_3_1::Vec3<float>>, a differentsymbol.
This means thatit is insufficient to identify a distribution ofOpenEXR by its ``major.minor`` release numbers alone. Youmustfurther identify the distribution of Imath that it was built against,e.g. “OpenEXR v3.4 w/Imath v3.2”.
It is problematic for a single application to use, for example,OpenEXR v3.4 compiled against Imath v3.2, while simultaneously using adistribution of OpenEXR v3.4 built against Imath v3.1. Both sets ofOpenEXR symbols would reside in a single namespace(i.e.Imf_3_4::), but the Imath types would differ between the two(i.e.Imath_3_2:: vsImath_3_1::). It is also problematic forapplication compilation units to use Imath classes directly,independent of OpenEXR, if they also include OpenEXR headers from adistribution built with a different Imath version.
Linux/macOS¶
To build via CMake, you need to first identify three directories:
The source directory, i.e. the top-level directory of thedownloaded source archive or cloned repo, referred to below as
$srcdirA temporary directory to hold the build artifacts, referred to below as
$builddirA destination directory into which to install thelibraries and headers, referred to below as
$installdir.
To build:
% cd $builddir% cmake $srcdir --install-prefix $installdir% cmake --build $builddir --target install --config Release
Note that the CMake configuration prefers to apply an out-of-treebuild process, since there may be multiple build configurations(i.e. debug and release), one per folder, all pointing at once sourcetree, hence the$builddir noted above, referred to in CMakeparlance as thebuild directory. You can place this directorywherever you like.
See the CMake Configuration Options section below for the most commonconfiguration options especially the install directory. Note that withno arguments, as above,makeinstall installs the header files in/usr/local/include, the object libraries in/usr/local/lib, and theexecutable programs in/usr/local/bin.
Windows¶
Under Windows, if you are using a command line-based setup, such ascygwin, you can of course follow the above. For Visual Studio, cmakegenerators are “multiple configuration”, so you don’t even have to setthe build type, although you will most likely need to specify theinstall location. Install Directory By default,makeinstallinstalls the headers, libraries, and programs into/usr/local, but youcan specify a local install directory to cmake via theCMAKE_INSTALL_PREFIX variable:
% cmake .. -DCMAKE_INSTALL_PREFIX=$openexr_install_directory
Library Names¶
By default, libraries are installed with the following names/symlinks:
libOpenEXR.so -> libOpenEXR.so.31libOpenEXR.so.$SOVERSION -> libOpenEXR.so.$SOVERSION.$RELEASElibOpenEXR.so.$SOVERSION.$RELEASE (the shared object file)
TheSOVERSION number identifies the ABI version. Each OpenEXRrelease that changes the ABI in backwards-incompatible ways increasesthis number. By policy, this changes only for major and minorreleases, never for patch releases.RELEASE is theMAJOR.MINOR.PATCH release name. For example, the resulting sharedlibrary filename islibOpenEXR.so.31.3.2.0 for OpenEXR releasev3.2.0. This naming scheme reinforces the correspondence between thereal filename of the.so and the release it corresponds to.
Library Suffix¶
TheOPENEXR_LIB_SUFFIX CMake option designates a suffix for thelibrary and appears between the library base name and the.so. This defaults to encode the major and minor version, as in-3_1:
libOpenEXR.so->libOpenEXR-3_1.solibOpenEXR-3_1.so->libOpenEXR-3_1.so.30libOpenEXR-3_1.so.30->libOpenEXR-3_1.so.30.3.2.0libOpenEXR-3_1.so.30.3.2.0(thesharedobjectfile)
Imath Dependency¶
OpenEXR depends onImath. If a suitableinstallation of Imath cannot be found, CMake will automaticallydownload it at configuration time. To link against an existinginstallation of Imath, add the Imath directory to theCMAKE_PREFIX_PATH setting:
% mkdir $build_directory% cd $build_directory% cmake -DCMAKE_PREFIX_PATH=$imath_install_directory \ -DCMAKE_INSTALL_PREFIX=$openexr_install_destination \ $openexr_source_directory% cmake --build . --target install --config Release
Alternatively, you can specify theImath_DIR variable:
% mkdir $build_directory% cd $build_directory% cmake -DImath_DIR=$imath_config_directory \ -DCMAKE_INSTALL_PREFIX=$openexr_install_destination \ $openexr_source_directory% cmake --build . --target install --config Release
Note thatImath_DIR should point to the directory that includestheImathConfig.cmake file, which is typically thelib/cmake/Imath folder of the root install directory where Imathis installed.
See below for other customization options.
Porting Applications from OpenEXR v2 to v3¶
See theOpenEXR/Imath 2.x to 3.x Porting Guide for details about differences from previousreleases and how to address them. Also refer to the porting guide fordetails about changes to Imath.
Building the Website¶
Thehttps://openexr.com website is generatedviaSphinx with theBreathe extension, using thesphinx-press-theme, and is hosted byreadthedocs. The websitesource is inrestructured textin thewebsite directory.
To build the website locally from the source.rst files, set theCMake optionBUILD_WEBSITE=ON. This adds thewebsite CMaketarget. Generation is off by default.
Building the website requires thatsphinx,breathe, anddoxygen are installed. It further requires thesphinx-press-theme. Complete dependenciesare described in therequirements.txtfile.
On Debian/Ubuntu Linux:
%apt-getinstalldoxygenpython3-sphinx%pip3installbreathe%pip3installsphinx_press_theme%mkdir_build%cd_build%cmake..-DBUILD_WEBSITE=ON%cmake--build.--targetwebsite
CMake Build-time Configuration Options¶
The default CMake configuration options are stored incmake/OpenEXRSetup.cmake. To see a complete set of optionvariables, run:
% cmake -LAH $openexr_source_directory
You can customize these options three ways:
Modify the
.cmakefiles in place.Use the UI
cmake-guiorccmake.Specify them as command-line arguments when you invoke cmake.
Uninstall¶
If you did a binary install of OpenEXR via a package manager(apt-get,yum,port,brew, etc), use the package manager touninstall.
If you have installed from source,and you still have the buildtree from which you installed, you can uninstall via:
% cmake --build $builddir --target uninstall
or if usingmake:
%makeuninstall
Theuninstall relies on CMake’sinstall_manifest.txt for the recordof what was installed.
Library Naming Options¶
OPENEXR_LIB_SUFFIXAppend the given string to the end of all the OpenEXRlibraries. Default is
-<major>_<minor>version string. Pleasesee the section on library names
Imath Dependency¶
CMAKE_PREFIX_PATHThe standard CMake path in which to search for dependencies, Imathin particular. A comma-separated path. Add the root directory whereImath is installed.
Imath_DIRThe config directory where Imath is installed. An alternative tousing
CMAKE_PREFIX_PATH. Note thatImath_DIRshouldbe set to the directory that includes theImathConfig.cmakefile, which is typically thelib/cmake/Imathfolder of the rootinstall directory.OPENEXR_IMATH_REPOandOPENEXR_IMATH_TAGThe github Imath repo to auto-fetch if an installed library cannotbe found, and the tag to sync it to. The default repo is
https://github.com/AcademySoftwareFoundation/Imath.gitand thetag is specific to the OpenEXR release. The internal build isconfigured as a CMake subproject.OPENEXR_FORCE_INTERNAL_IMATHIf set to
ON, force auto-fetching and internal building of ImathusingOPENEXR_IMATH_REPOandOPENEXR_IMATH_TAG. This meansdonot use any existing installation of Imath.
libdeflate Dependency¶
As of OpenEXR release v3.2, OpenEXR depends onlibdeflate forDEFLATE-based compression. Previous OpenEXR releases relied onzlib.
As of OpenEXR release v3.4, OpenEXR ships with an internal “vendored”copy of thelibdeflate compression code. At configuration time, ifCMake finds an external installation oflibdeflate, it will useit. If it fails to find an installation, it will use the internalcopy. To force use of the internal copy, configure with-DOPENEXR_USE_INTERNAL_DEFLATE=ON.
OpenEXR release v3.2 and v3.3 auto-fetch thelibdeflate source andbuild it internally if cmake does not find an externalinstallation. The internal build is linked statically, so no extrashared object is produced. Configuration options are:
OPENEXR_DEFLATE_REPOandOPENEXR_DEFLATE_TAGThe GitHub
libdeflaterepo to auto-fetch if an installed library cannotbe found, and the tag to sync it to. The default repo ishttps://github.com/ebiggers/libdeflate.gitand the tag isv1.18. The internal build is configured as a CMake subproject.OPENEXR_FORCE_INTERNAL_DEFLATEIf set to
ON, force auto-fetching and internal building oflibdeflateusingOPENEXR_DEFLATE_REPOandOPENEXR_DEFLATE_TAG. This means donot use any existinginstallation oflibdeflate.
TBB Dependency¶
OpenEXR can optionally use the TBB library as the default globalthread pool as a thread provider. This allows applications which alsouse TBB for other purposes to lower the number of active threads. Withhigh core count machines more prevalent, this can significantly lowerthe number of active threads and so the improve available resourcesespecially when compiling with a static library and using pluginswhich use OpenEXR.
This is disabled by default, but when turned on, assumes the OneAPIversion of TBB which provides cmake modules. This ONLY changes theglobal thread pool as otherwise this can cause mutex deadlocks if youcreate other ThreadPools thinking that they are separate threads (i.e.the previous use case), but TBB shares actual threads and uses anarena to control thread usage.
To enable this, set the flag during config:
cmake-DOPENEXR_USE_TBB=ON...
Namespace Options¶
OPENEXR_IMF_NAMESPACEPublic namespace alias for OpenEXR. Default is
Imf.OPENEXR_INTERNAL_IMF_NAMESPACEReal namespace for OpenEXR that will end up in compiledsymbols. Default is
Imf_<major>_<minor>.OPENEXR_NAMESPACE_CUSTOMWhether the namespace has been customized (so external users know)
IEX_NAMESPACEPublic namespace alias for Iex. Default is
Iex.IEX_INTERNAL_NAMESPACEReal namespace for Iex that will end up in compiled symbols. Defaultis
Iex_<major>_<minor>.IEX_NAMESPACE_CUSTOMWhether the namespace has been customized (so external users know)
ILMTHREAD_NAMESPACEPublic namespace alias for IlmThread. Default is
IlmThread.ILMTHREAD_INTERNAL_NAMESPACEReal namespace for IlmThread that will end up in compiledsymbols. Default is
IlmThread_<major>_<minor>.ILMTHREAD_NAMESPACE_CUSTOMWhether the namespace has been customized (so external users know)
Component Options¶
BUILD_TESTINGBuild the testing tree. Default is
ON. Note thatthis causes the test suite to be compiled, but it is notexecuted. To execute the suite, run “make test”.OPENEXR_RUN_FUZZ_TESTSControls whether to include the fuzz tests (very slow). Default is
OFF.OPENEXR_BUILD_TOOLSBuild the binary programs (exrheader, exrinfo,exrmakepreview, etc). Default is
ON.OPENEXR_INSTALL_TOOLSInstall the binary programs (exrheader, exrinfo,exrmakepreview, etc). Default is
ON.OPENEXR_INSTALL_DEVELOPER_TOOLSInstall the binary programs useful for developingand/or debugging OpenEXR itself (e.g. exrcheck).Default is
OFF.OPENEXR_BUILD_EXAMPLESBuild the example code. Default is
ON.
Additional CMake Options¶
See the CMake documentation for more information (https://cmake.org/cmake/help/v3.12/).
CMAKE_BUILD_TYPEFor builds when not using a multi-configuration generator. Availablevalues:
Debug,Release,RelWithDebInfo,MinSizeRelBUILD_SHARED_LIBSThis is the primary control whether to build static libraries orshared libraries / dlls (side note: technically a convention, hencenot an official
CMAKE_variable, it is defined within cmake andused everywhere to control this static / shared behavior)OPENEXR_CXX_STANDARDC++ standard to compile against. This obeys the global
CMAKE_CXX_STANDARDbut doesn’t force the global setting toenable sub-project inclusion. Default is17.CMAKE_CXX_COMPILERThe C++ compiler.
CMAKE_C_COMPILERThe C compiler.
CMAKE_INSTALL_RPATHFor non-standard install locations where you don’t want to have toset
LD_LIBRARY_PATHto use themCMAKE_EXPORT_COMPILE_COMMANDSEnable/Disable output of compile commands during generation. Defaultis
OFF.CMAKE_VERBOSE_MAKEFILEEcho all compile commands during make. Default is
OFF.
Cross Compiling / Specifying Specific Compilers¶
When trying to either cross-compile for a different platform, or fortasks such as specifying a compiler set to match theVFX referenceplatform, cmake provides the idea of atoolchain which may be useful instead of having to remember a chain ofconfiguration options. It also means that platform-specific compilernames and options are out of the main cmake file, providing betterisolation.
A toolchain file is simply just a cmake script that sets all thecompiler and related flags and is run very early in the configurationstep to be able to set all the compiler options and such for thediscovery that cmake performs automatically. These options can be seton the command line still if that is clearer, but a theoreticaltoolchain file for compiling for VFX Platform 2015 is provided in thesource tree atcmake/Toolchain-Linux-VFX_Platform15.cmake whichwill hopefully provide a guide how this might work.
For cross-compiling for additional platforms, there is also anincluded sample script incmake/Toolchain-mingw.cmake which showshow cross compiling from Linux for Windows may work. The compilernames and paths may need to be changed for your environment.
More documentation:
Ninja¶
If you haveNinja installed, it is fasterthan make. You can generate ninja files using cmake when doing theinitial generation:
% cmake -G “Ninja” ..
