The OpenEXR project provides the specification and reference implementation of the EXR file format, the professional-grade image storage format of the motion picture industry.

Overview

License CII Best Practices Build Status Analysis Status Quality Gate Status

OpenEXR

OpenEXR provides the specification and reference implementation of the EXR file format, the professional-grade image storage format of the motion picture industry.

The purpose of EXR format is to accurately and efficiently represent high-dynamic-range scene-linear image data and associated metadata, with strong support for multi-part, multi-channel use cases.

OpenEXR is widely used in host application software where accuracy is critical, such as photorealistic rendering, texture access, image compositing, deep compositing, and DI.

About OpenEXR

OpenEXR is a project of the Academy Software Foundation. The format and library were originally developed by Industrial Light & Magic and first released in 2003. Weta Digital, Walt Disney Animation Studios, Sony Pictures Imageworks, Pixar Animation Studios, DreamWorks, and other studios, companies, and individuals have made contributions to the code base.

OpenEXR is included in the VFX Reference Platform.

OpenEXR Features

  • High dynamic range and color precision.
  • Support for 16-bit floating-point, 32-bit floating-point, and 32-bit integer pixels.
  • Multiple image compression algorithms, both lossless and lossy. Some of the included codecs can achieve 2:1 lossless compression ratios on images with film grain. The lossy codecs have been tuned for visual quality and decoding performance.
  • 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.
  • Support for stereoscopic image workflows and a generalization to multi-views.
  • Flexible support for deep data: pixels can store a variable-length list of samples and, thus, it is possible to store multiple values at different depths for each pixel. Hard surfaces and volumetric data representations are accommodated.
  • Multipart: ability to encode separate, but related, images in one file. This allows for access to individual parts without the need to read other parts in the file.
  • Versioning: OpenEXR source allows for user configurable C++ namespaces to provide protection when using multiple versions of the library in the same process space.

OpenEXR and Imath Version 3

With the release of OpenEXR 3, the Imath library formerly distributed via the IlmBase component of OpenEXR is now an independent library dependency, available for download from https:://github.com/AcademySoftwareFoundation/Imath. You can choose to build OpenEXR against an external installation of Imath, or the default CMake configuration will download and build it automatically during the OpenEXR build process. Note that the half 16-bit floating point data type is included in Imath.

See the porting guide for details about differences from previous releases and how to address them. Also refer to the porting guide for details about changes to Imath.

New Features in OpenEXR v3.1

The 3.1 release of OpenEXR introduces a new library, OpenEXRCore, which is the result of a significant re-thinking of how OpenEXR manages file I/O and provides access to image data. It begins to address long-standing scalability issues with multithreaded image reading and writing.

The OpenEXRCore library provides thread-safe, non-blocking access to files, which was not possible with the current API, where the framebuffer management is separate from read requests. It is written entirely in C and provides a new C-language API alongside the existing C++ API. This new low-level API allows applications to do custom unpacking of EXR data, such as on the GPU, while still benefiting from efficient I/O, file validation, and other semantics. It provides efficient direct access to EXR files in texturing applications. This C library also introduces an easier path to implementing OpenEXR bindings in other languages, such as Rust.

The 3.1 release represents a technology preview for upcoming releases. The initial release is incremental; the existing API and underlying behavior has not changed. The new API is available now for performance validation testing, and then in future OpenEXR releases, the C++ API will migrate to use the new core in stages. It is not the intention to entirely deprecate the C++ API, nor must all applications re-implement EXR I/O in terms of the C library. The C API does not, and will not, provide the rich set of utility classes that exist in the C++ layer. The 3.1 release of the OpenEXRCore library simply offers new functionality for specialty applications seeking the highest possible performance. In the future, the ABI will evolve, but the API will remain consistent, or only have additions.

See Reading and Writing OpenEXR Image Files with the C-language API for more information.

Supported Platforms

OpenEXR builds on Linux, macOS, Microsoft Windows, and is cross-compilable on other systems.

OpenEXR Project Mission

The goal of the OpenEXR project is to keep the EXR format reliable and modern and to maintain its place as the preferred image format for entertainment content creation.

Major revisions are infrequent, and new features will be carefully weighed against increased complexity. The principal priorities of the project are:

  • Robustness, reliability, security
  • Backwards compatibility, data longevity
  • Performance - read/write/compression/decompression time
  • Simplicity, ease of use, maintainability
  • Wide adoption, multi-platform support - Linux, Windows, macOS, and others

OpenEXR is intended solely for 2D data. It is not appropriate for storage of volumetric data, cached or lit 3D scenes, or more complex 3D data such as light fields.

The goals of the IlmBase project are simplicity, ease of use, correctness and verifiability, and breadth of adoption. IlmBase is not intended to be a comprehensive linear algebra or numerical analysis package.

OpenEXR Project Governance

OpenEXR is hosted by the Academy Software Foundation. See GOVERNANCE for more information about how the project operates.

The OpenEXR project is dedicated to promoting a harassment-free community. Read our code of conduct.

Developer Quick Start

See INSTALL for instructions on downloading and building OpenEXR from source.

Resources

Getting Help

There are several ways to connect with the OpenEXR project:

  • The [email protected] mail list: This is a development focused mail list with a deep history of technical conversations and decisions that have shaped the project. Subscribe at [email protected].

  • ASWF Slack channel: #openexr

  • GitHub Issues: GitHub issues are used both to track bugs and to discuss feature requests.

See CONTRIBUTING for more information.

Getting Involved

OpenEXR welcomes contributions to the project. See CONTRIBUTING for more information about contributing to OpenEXR.

License

OpenEXR is released under the BSD-3-Clause license. See PATENTS for license information about portions of OpenEXR that are provided under a different license.

Frequently Asked Questions

  • "pip install openexr doesn't work."

    The OpenEXR project provides python bindings for the Imath vector/matrix classes, but it does not provide python bindings for reading, writing, or editing .exr files. The openexrpython module is not affiliated with the OpenEXR project or the ASWF. Please direct questions there.

    Alternatively, OpenImageIO also includes python bindings for OpenEXR.


aswf

Comments
  • Serious problem: openexr not fully installing

    Serious problem: openexr not fully installing

    I'm seeing builds of OpenEXR (from the current master, and when it automatically builds Imath) fail to fully install. It installs the imath part, but the openexr headers and config files are not showing up in the install.

    This only recently started happening. I've never seen it happen for v3.0.1, but OIIO CI started failing several days ago (actually, the CI itself didn't fail; the install of master openexr was broken, and my CI fell back to a syste install of OpenEXR 2.3, so it took me a while to discover the problem).

    I can reproduce it by hand. Some bisecting indicates that it may have been introduced (or at least become symptomatic) specifically with the merge of #1008, but I don't understand why that would be the case, and so I'm not 100% certain.

    Below is a transcript of me doing this right now on my Mac, at the commit that corresponds to #1008. (I can't seem to reproduce it with earlier commits.) Look particularly at the lines that begin with -- Installing: (for what's missing) as well as the ls -R at the end that shows that it really is missing.

    This is on Mac, but I've seen it on OIIO CI on Linux. Here's an example:

    [email protected] ~/code/openexr (broken) $ rm -rf build dist 
    [email protected] ~/code/openexr (broken) $ cmake -B build -S . -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=$PWD/dist -DOPENEXR_INSTALL_EXAMPLES=0 -DBUILD_TESTING=0 -DOPENEXR_BUILD_UTILS=0
    -- The C compiler identification is AppleClang 12.0.0.12000032
    -- The CXX compiler identification is AppleClang 12.0.0.12000032
    -- Detecting C compiler ABI info
    -- Detecting C compiler ABI info - done
    -- Check for working C compiler: /usr/local/opt/ccache/libexec/cc - skipped
    -- Detecting C compile features
    -- Detecting C compile features - done
    -- Detecting CXX compiler ABI info
    -- Detecting CXX compiler ABI info - done
    -- Check for working CXX compiler: /usr/local/opt/ccache/libexec/c++ - skipped
    -- Detecting CXX compile features
    -- Detecting CXX compile features - done
    -- Configure OpenEXR Version: 3.0.2-dev Lib API: 28.0.0
    -- Looking for pthread.h
    -- Looking for pthread.h - found
    -- Performing Test CMAKE_HAVE_LIBC_PTHREAD
    -- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Success
    -- Found Threads: TRUE
    -- Imath was not found, installing from https://github.com/AcademySoftwareFoundation/Imath.git (master)
    -- Configure Imath Version: 3.0.2-dev Lib API: 28.0.0
    -- Imath is configuring as a cmake sub project
    -- Performing Test OPENEXR_IMF_HAVE_SYSCONF_NPROCESSORS_ONLN
    -- Performing Test OPENEXR_IMF_HAVE_SYSCONF_NPROCESSORS_ONLN - Success
    -- Performing Test OPENEXR_IMF_HAVE_GCC_INLINE_ASM_AVX
    -- Performing Test OPENEXR_IMF_HAVE_GCC_INLINE_ASM_AVX - Success
    -- Looking for include file ucontext.h
    -- Looking for include file ucontext.h - not found
    -- clang-format found: /usr/local/bin/clang-format
    -- Configuring done
    -- Generating done
    -- Build files have been written to: /Users/lg/code/openexr/build
    [email protected] ~/code/openexr (broken) $ cmake --build build --target install
    [  1%] Building CXX object src/lib/Iex/CMakeFiles/Iex.dir/IexThrowErrnoExc.cpp.o
    [  3%] Building CXX object src/lib/Iex/CMakeFiles/Iex.dir/IexBaseExc.cpp.o
    [  3%] Building CXX object _deps/imath-build/src/Imath/CMakeFiles/Imath.dir/ImathColorAlgo.cpp.o
    [  3%] Building CXX object _deps/imath-build/src/Imath/CMakeFiles/Imath.dir/ImathMatrixAlgo.cpp.o
    [  3%] Building CXX object _deps/imath-build/src/Imath/CMakeFiles/Imath.dir/ImathRandom.cpp.o
    [  5%] Building CXX object src/lib/Iex/CMakeFiles/Iex.dir/IexMathFpu.cpp.o
    [  5%] Building CXX object _deps/imath-build/src/Imath/CMakeFiles/Imath.dir/ImathFun.cpp.o
    [  6%] Building CXX object src/lib/Iex/CMakeFiles/Iex.dir/IexMathFloatExc.cpp.o
    [  7%] Building CXX object _deps/imath-build/src/Imath/CMakeFiles/Imath.dir/half.cpp.o
    [  7%] Linking CXX shared library libIex-3_0.dylib
    [  7%] Linking CXX shared library libImath-3_0.dylib
    [  7%] Built target Imath
    [  7%] Built target Iex
    [  8%] Building CXX object src/lib/IlmThread/CMakeFiles/IlmThread.dir/IlmThreadSemaphorePosixCompat.cpp.o
    [  9%] Building CXX object src/lib/IlmThread/CMakeFiles/IlmThread.dir/IlmThread.cpp.o
    [ 10%] Building CXX object src/lib/IlmThread/CMakeFiles/IlmThread.dir/IlmThreadPool.cpp.o
    [ 11%] Building CXX object src/lib/IlmThread/CMakeFiles/IlmThread.dir/IlmThreadSemaphore.cpp.o
    [ 12%] Building CXX object src/lib/IlmThread/CMakeFiles/IlmThread.dir/IlmThreadSemaphoreOSX.cpp.o
    [ 12%] Building CXX object src/lib/IlmThread/CMakeFiles/IlmThread.dir/IlmThreadSemaphorePosix.cpp.o
    [ 13%] Building CXX object src/lib/IlmThread/CMakeFiles/IlmThread.dir/IlmThreadSemaphoreWin32.cpp.o
    [ 14%] Linking CXX shared library libIlmThread-3_0.dylib
    [ 14%] Built target IlmThread
    [ 17%] Building CXX object src/lib/OpenEXR/CMakeFiles/OpenEXR.dir/ImfChannelList.cpp.o
    [ 18%] Building CXX object src/lib/OpenEXR/CMakeFiles/OpenEXR.dir/ImfCRgbaFile.cpp.o
    [ 18%] Building CXX object src/lib/OpenEXR/CMakeFiles/OpenEXR.dir/ImfAttribute.cpp.o
    [ 18%] Building CXX object src/lib/OpenEXR/CMakeFiles/OpenEXR.dir/ImfChannelListAttribute.cpp.o
    [ 18%] Building CXX object src/lib/OpenEXR/CMakeFiles/OpenEXR.dir/ImfFloatAttribute.cpp.o
    [ 19%] Building CXX object src/lib/OpenEXR/CMakeFiles/OpenEXR.dir/ImfBoxAttribute.cpp.o
    [ 20%] Building CXX object src/lib/OpenEXR/CMakeFiles/OpenEXR.dir/ImfHeader.cpp.o
    [ 21%] Building CXX object src/lib/OpenEXR/CMakeFiles/OpenEXR.dir/ImfFrameBuffer.cpp.o
    [ 22%] Building CXX object src/lib/OpenEXR/CMakeFiles/OpenEXR.dir/ImfIO.cpp.o
    [ 22%] Building CXX object src/lib/OpenEXR/CMakeFiles/OpenEXR.dir/ImfInputFile.cpp.o
    [ 23%] Building CXX object src/lib/OpenEXR/CMakeFiles/OpenEXR.dir/ImfIntAttribute.cpp.o
    [ 24%] Building CXX object src/lib/OpenEXR/CMakeFiles/OpenEXR.dir/ImfLineOrderAttribute.cpp.o
    [ 25%] Building CXX object src/lib/OpenEXR/CMakeFiles/OpenEXR.dir/ImfMatrixAttribute.cpp.o
    [ 25%] Building CXX object src/lib/OpenEXR/CMakeFiles/OpenEXR.dir/ImfOpaqueAttribute.cpp.o
    [ 26%] Building CXX object src/lib/OpenEXR/CMakeFiles/OpenEXR.dir/ImfOutputFile.cpp.o
    [ 27%] Building CXX object src/lib/OpenEXR/CMakeFiles/OpenEXR.dir/ImfRgbaFile.cpp.o
    [ 29%] Building CXX object src/lib/OpenEXR/CMakeFiles/OpenEXR.dir/ImfVecAttribute.cpp.o
    [ 29%] Building CXX object src/lib/OpenEXR/CMakeFiles/OpenEXR.dir/ImfStringAttribute.cpp.o
    [ 31%] Building CXX object src/lib/OpenEXR/CMakeFiles/OpenEXR.dir/ImfHuf.cpp.o
    [ 31%] Building CXX object src/lib/OpenEXR/CMakeFiles/OpenEXR.dir/ImfWav.cpp.o
    [ 31%] Building CXX object src/lib/OpenEXR/CMakeFiles/OpenEXR.dir/ImfThreading.cpp.o
    [ 32%] Building CXX object src/lib/OpenEXR/CMakeFiles/OpenEXR.dir/ImfLut.cpp.o
    [ 33%] Building CXX object src/lib/OpenEXR/CMakeFiles/OpenEXR.dir/ImfCompressor.cpp.o
    [ 33%] Building CXX object src/lib/OpenEXR/CMakeFiles/OpenEXR.dir/ImfRleCompressor.cpp.o
    [ 34%] Building CXX object src/lib/OpenEXR/CMakeFiles/OpenEXR.dir/ImfZipCompressor.cpp.o
    [ 35%] Building CXX object src/lib/OpenEXR/CMakeFiles/OpenEXR.dir/ImfPizCompressor.cpp.o
    [ 36%] Building CXX object src/lib/OpenEXR/CMakeFiles/OpenEXR.dir/ImfB44Compressor.cpp.o
    [ 37%] Building CXX object src/lib/OpenEXR/CMakeFiles/OpenEXR.dir/ImfDwaCompressor.cpp.o
    [ 37%] Building CXX object src/lib/OpenEXR/CMakeFiles/OpenEXR.dir/ImfMisc.cpp.o
    [ 38%] Building CXX object src/lib/OpenEXR/CMakeFiles/OpenEXR.dir/ImfCompressionAttribute.cpp.o
    [ 39%] Building CXX object src/lib/OpenEXR/CMakeFiles/OpenEXR.dir/ImfDoubleAttribute.cpp.o
    [ 40%] Building CXX object src/lib/OpenEXR/CMakeFiles/OpenEXR.dir/ImfConvert.cpp.o
    [ 40%] Building CXX object src/lib/OpenEXR/CMakeFiles/OpenEXR.dir/ImfPreviewImage.cpp.o
    [ 41%] Building CXX object src/lib/OpenEXR/CMakeFiles/OpenEXR.dir/ImfPreviewImageAttribute.cpp.o
    [ 43%] Building CXX object src/lib/OpenEXR/CMakeFiles/OpenEXR.dir/ImfVersion.cpp.o
    [ 43%] Building CXX object src/lib/OpenEXR/CMakeFiles/OpenEXR.dir/ImfChromaticities.cpp.o
    [ 44%] Building CXX object src/lib/OpenEXR/CMakeFiles/OpenEXR.dir/ImfChromaticitiesAttribute.cpp.o
    [ 44%] Building CXX object src/lib/OpenEXR/CMakeFiles/OpenEXR.dir/ImfKeyCode.cpp.o
    [ 45%] Building CXX object src/lib/OpenEXR/CMakeFiles/OpenEXR.dir/ImfKeyCodeAttribute.cpp.o
    [ 46%] Building CXX object src/lib/OpenEXR/CMakeFiles/OpenEXR.dir/ImfTimeCode.cpp.o
    [ 47%] Building CXX object src/lib/OpenEXR/CMakeFiles/OpenEXR.dir/ImfTimeCodeAttribute.cpp.o
    [ 48%] Building CXX object src/lib/OpenEXR/CMakeFiles/OpenEXR.dir/ImfRational.cpp.o
    [ 48%] Building CXX object src/lib/OpenEXR/CMakeFiles/OpenEXR.dir/ImfRationalAttribute.cpp.o
    [ 49%] Building CXX object src/lib/OpenEXR/CMakeFiles/OpenEXR.dir/ImfFramesPerSecond.cpp.o
    [ 50%] Building CXX object src/lib/OpenEXR/CMakeFiles/OpenEXR.dir/ImfStdIO.cpp.o
    [ 51%] Building CXX object src/lib/OpenEXR/CMakeFiles/OpenEXR.dir/ImfStandardAttributes.cpp.o
    [ 51%] Building CXX object src/lib/OpenEXR/CMakeFiles/OpenEXR.dir/ImfEnvmap.cpp.o
    [ 52%] Building CXX object src/lib/OpenEXR/CMakeFiles/OpenEXR.dir/ImfEnvmapAttribute.cpp.o
    [ 53%] Building CXX object src/lib/OpenEXR/CMakeFiles/OpenEXR.dir/ImfScanLineInputFile.cpp.o
    [ 54%] Building CXX object src/lib/OpenEXR/CMakeFiles/OpenEXR.dir/ImfTiledInputFile.cpp.o
    [ 55%] Building CXX object src/lib/OpenEXR/CMakeFiles/OpenEXR.dir/ImfTiledMisc.cpp.o
    [ 55%] Building CXX object src/lib/OpenEXR/CMakeFiles/OpenEXR.dir/ImfTiledOutputFile.cpp.o
    [ 56%] Building CXX object src/lib/OpenEXR/CMakeFiles/OpenEXR.dir/ImfTiledRgbaFile.cpp.o
    [ 57%] Building CXX object src/lib/OpenEXR/CMakeFiles/OpenEXR.dir/ImfTileDescriptionAttribute.cpp.o
    [ 58%] Building CXX object src/lib/OpenEXR/CMakeFiles/OpenEXR.dir/ImfTileOffsets.cpp.o
    [ 59%] Building CXX object src/lib/OpenEXR/CMakeFiles/OpenEXR.dir/ImfRgbaYca.cpp.o
    [ 59%] Building CXX object src/lib/OpenEXR/CMakeFiles/OpenEXR.dir/ImfPxr24Compressor.cpp.o
    [ 60%] Building CXX object src/lib/OpenEXR/CMakeFiles/OpenEXR.dir/ImfTestFile.cpp.o
    [ 61%] Building CXX object src/lib/OpenEXR/CMakeFiles/OpenEXR.dir/ImfStringVectorAttribute.cpp.o
    [ 62%] Building CXX object src/lib/OpenEXR/CMakeFiles/OpenEXR.dir/ImfMultiView.cpp.o
    [ 62%] Building CXX object src/lib/OpenEXR/CMakeFiles/OpenEXR.dir/ImfAcesFile.cpp.o
    [ 64%] Building CXX object src/lib/OpenEXR/CMakeFiles/OpenEXR.dir/ImfMultiPartOutputFile.cpp.o
    [ 64%] Building CXX object src/lib/OpenEXR/CMakeFiles/OpenEXR.dir/ImfGenericOutputFile.cpp.o
    [ 65%] Building CXX object src/lib/OpenEXR/CMakeFiles/OpenEXR.dir/ImfOutputPartData.cpp.o
    [ 65%] Building CXX object src/lib/OpenEXR/CMakeFiles/OpenEXR.dir/ImfGenericInputFile.cpp.o
    [ 66%] Building CXX object src/lib/OpenEXR/CMakeFiles/OpenEXR.dir/ImfMultiPartInputFile.cpp.o
    [ 67%] Building CXX object src/lib/OpenEXR/CMakeFiles/OpenEXR.dir/ImfPartType.cpp.o
    [ 68%] Building CXX object src/lib/OpenEXR/CMakeFiles/OpenEXR.dir/ImfInputPartData.cpp.o
    [ 69%] Building CXX object src/lib/OpenEXR/CMakeFiles/OpenEXR.dir/ImfTiledOutputPart.cpp.o
    [ 70%] Building CXX object src/lib/OpenEXR/CMakeFiles/OpenEXR.dir/ImfOutputPart.cpp.o
    [ 70%] Building CXX object src/lib/OpenEXR/CMakeFiles/OpenEXR.dir/ImfInputPart.cpp.o
    [ 71%] Building CXX object src/lib/OpenEXR/CMakeFiles/OpenEXR.dir/ImfTiledInputPart.cpp.o
    [ 72%] Building CXX object src/lib/OpenEXR/CMakeFiles/OpenEXR.dir/ImfDeepScanLineInputPart.cpp.o
    [ 72%] Building CXX object src/lib/OpenEXR/CMakeFiles/OpenEXR.dir/ImfDeepScanLineOutputFile.cpp.o
    [ 74%] Building CXX object src/lib/OpenEXR/CMakeFiles/OpenEXR.dir/ImfDeepScanLineInputFile.cpp.o
    [ 74%] Building CXX object src/lib/OpenEXR/CMakeFiles/OpenEXR.dir/ImfDeepScanLineOutputPart.cpp.o
    [ 75%] Building CXX object src/lib/OpenEXR/CMakeFiles/OpenEXR.dir/ImfDeepTiledInputPart.cpp.o
    [ 76%] Building CXX object src/lib/OpenEXR/CMakeFiles/OpenEXR.dir/ImfDeepTiledOutputPart.cpp.o
    [ 77%] Building CXX object src/lib/OpenEXR/CMakeFiles/OpenEXR.dir/ImfDeepTiledInputFile.cpp.o
    [ 77%] Building CXX object src/lib/OpenEXR/CMakeFiles/OpenEXR.dir/ImfDeepTiledOutputFile.cpp.o
    [ 78%] Building CXX object src/lib/OpenEXR/CMakeFiles/OpenEXR.dir/ImfDeepFrameBuffer.cpp.o
    [ 79%] Building CXX object src/lib/OpenEXR/CMakeFiles/OpenEXR.dir/ImfDeepCompositing.cpp.o
    [ 80%] Building CXX object src/lib/OpenEXR/CMakeFiles/OpenEXR.dir/ImfCompositeDeepScanLine.cpp.o
    [ 82%] Building CXX object src/lib/OpenEXR/CMakeFiles/OpenEXR.dir/ImfFastHuf.cpp.o
    [ 82%] Building CXX object src/lib/OpenEXR/CMakeFiles/OpenEXR.dir/ImfFloatVectorAttribute.cpp.o
    [ 82%] Building CXX object src/lib/OpenEXR/CMakeFiles/OpenEXR.dir/ImfDeepImageStateAttribute.cpp.o
    [ 83%] Building CXX object src/lib/OpenEXR/CMakeFiles/OpenEXR.dir/ImfRle.cpp.o
    [ 84%] Building CXX object src/lib/OpenEXR/CMakeFiles/OpenEXR.dir/ImfSystemSpecific.cpp.o
    [ 85%] Building CXX object src/lib/OpenEXR/CMakeFiles/OpenEXR.dir/ImfZip.cpp.o
    [ 85%] Building CXX object src/lib/OpenEXR/CMakeFiles/OpenEXR.dir/ImfIDManifest.cpp.o
    [ 86%] Building CXX object src/lib/OpenEXR/CMakeFiles/OpenEXR.dir/ImfIDManifestAttribute.cpp.o
    [ 87%] Linking CXX shared library libOpenEXR-3_0.dylib
    [ 87%] Built target OpenEXR
    [ 88%] Building CXX object src/lib/OpenEXRUtil/CMakeFiles/OpenEXRUtil.dir/ImfFlatImageChannel.cpp.o
    [ 90%] Building CXX object src/lib/OpenEXRUtil/CMakeFiles/OpenEXRUtil.dir/ImfDeepImageChannel.cpp.o
    [ 90%] Building CXX object src/lib/OpenEXRUtil/CMakeFiles/OpenEXRUtil.dir/ImfSampleCountChannel.cpp.o
    [ 90%] Building CXX object src/lib/OpenEXRUtil/CMakeFiles/OpenEXRUtil.dir/ImfImageChannel.cpp.o
    [ 93%] Building CXX object src/lib/OpenEXRUtil/CMakeFiles/OpenEXRUtil.dir/ImfImageLevel.cpp.o
    [ 93%] Building CXX object src/lib/OpenEXRUtil/CMakeFiles/OpenEXRUtil.dir/ImfFlatImageLevel.cpp.o
    [ 93%] Building CXX object src/lib/OpenEXRUtil/CMakeFiles/OpenEXRUtil.dir/ImfImage.cpp.o
    [ 93%] Building CXX object src/lib/OpenEXRUtil/CMakeFiles/OpenEXRUtil.dir/ImfDeepImageLevel.cpp.o
    [ 95%] Building CXX object src/lib/OpenEXRUtil/CMakeFiles/OpenEXRUtil.dir/ImfFlatImage.cpp.o
    [ 95%] Building CXX object src/lib/OpenEXRUtil/CMakeFiles/OpenEXRUtil.dir/ImfDeepImage.cpp.o
    [ 96%] Building CXX object src/lib/OpenEXRUtil/CMakeFiles/OpenEXRUtil.dir/ImfImageIO.cpp.o
    [ 96%] Building CXX object src/lib/OpenEXRUtil/CMakeFiles/OpenEXRUtil.dir/ImfFlatImageIO.cpp.o
    [ 98%] Building CXX object src/lib/OpenEXRUtil/CMakeFiles/OpenEXRUtil.dir/ImfCheckFile.cpp.o
    [ 98%] Building CXX object src/lib/OpenEXRUtil/CMakeFiles/OpenEXRUtil.dir/ImfDeepImageIO.cpp.o
    [ 99%] Building CXX object src/lib/OpenEXRUtil/CMakeFiles/OpenEXRUtil.dir/ImfImageDataWindow.cpp.o
    [100%] Linking CXX shared library libOpenEXRUtil-3_0.dylib
    [100%] Built target OpenEXRUtil
    Install the project...
    -- Install configuration: "Release"
    -- Installing: /Users/lg/code/openexr/dist/include/Imath/ImathConfig.h
    -- Installing: /Users/lg/code/openexr/dist/lib/pkgconfig/Imath.pc
    -- Installing: /Users/lg/code/openexr/dist/lib/cmake/Imath/ImathConfig.cmake
    -- Installing: /Users/lg/code/openexr/dist/lib/cmake/Imath/ImathConfigVersion.cmake
    -- Installing: /Users/lg/code/openexr/dist/lib/cmake/Imath/ImathTargets.cmake
    -- Installing: /Users/lg/code/openexr/dist/lib/cmake/Imath/ImathTargets-release.cmake
    -- Installing: /Users/lg/code/openexr/dist/lib/libImath-3_0.28.0.0.dylib
    -- Installing: /Users/lg/code/openexr/dist/lib/libImath-3_0.28.dylib
    -- Installing: /Users/lg/code/openexr/dist/lib/libImath-3_0.dylib
    -- Installing: /Users/lg/code/openexr/dist/include/Imath/ImathBoxAlgo.h
    -- Installing: /Users/lg/code/openexr/dist/include/Imath/ImathBox.h
    -- Installing: /Users/lg/code/openexr/dist/include/Imath/ImathColorAlgo.h
    -- Installing: /Users/lg/code/openexr/dist/include/Imath/ImathColor.h
    -- Installing: /Users/lg/code/openexr/dist/include/Imath/ImathEuler.h
    -- Installing: /Users/lg/code/openexr/dist/include/Imath/ImathExport.h
    -- Installing: /Users/lg/code/openexr/dist/include/Imath/ImathForward.h
    -- Installing: /Users/lg/code/openexr/dist/include/Imath/ImathFrame.h
    -- Installing: /Users/lg/code/openexr/dist/include/Imath/ImathFrustum.h
    -- Installing: /Users/lg/code/openexr/dist/include/Imath/ImathFrustumTest.h
    -- Installing: /Users/lg/code/openexr/dist/include/Imath/ImathFun.h
    -- Installing: /Users/lg/code/openexr/dist/include/Imath/ImathGL.h
    -- Installing: /Users/lg/code/openexr/dist/include/Imath/ImathGLU.h
    -- Installing: /Users/lg/code/openexr/dist/include/Imath/ImathInt64.h
    -- Installing: /Users/lg/code/openexr/dist/include/Imath/ImathInterval.h
    -- Installing: /Users/lg/code/openexr/dist/include/Imath/ImathLineAlgo.h
    -- Installing: /Users/lg/code/openexr/dist/include/Imath/ImathLine.h
    -- Installing: /Users/lg/code/openexr/dist/include/Imath/ImathMath.h
    -- Installing: /Users/lg/code/openexr/dist/include/Imath/ImathMatrixAlgo.h
    -- Installing: /Users/lg/code/openexr/dist/include/Imath/ImathMatrix.h
    -- Installing: /Users/lg/code/openexr/dist/include/Imath/ImathNamespace.h
    -- Installing: /Users/lg/code/openexr/dist/include/Imath/ImathPlane.h
    -- Installing: /Users/lg/code/openexr/dist/include/Imath/ImathPlatform.h
    -- Installing: /Users/lg/code/openexr/dist/include/Imath/ImathQuat.h
    -- Installing: /Users/lg/code/openexr/dist/include/Imath/ImathRandom.h
    -- Installing: /Users/lg/code/openexr/dist/include/Imath/ImathRoots.h
    -- Installing: /Users/lg/code/openexr/dist/include/Imath/ImathShear.h
    -- Installing: /Users/lg/code/openexr/dist/include/Imath/ImathSphere.h
    -- Installing: /Users/lg/code/openexr/dist/include/Imath/ImathTypeTraits.h
    -- Installing: /Users/lg/code/openexr/dist/include/Imath/ImathVecAlgo.h
    -- Installing: /Users/lg/code/openexr/dist/include/Imath/ImathVec.h
    -- Installing: /Users/lg/code/openexr/dist/include/Imath/half.h
    -- Installing: /Users/lg/code/openexr/dist/include/Imath/halfFunction.h
    -- Installing: /Users/lg/code/openexr/dist/include/Imath/halfLimits.h
    -- Creating symlink in /Users/lg/code/openexr/dist/lib libImath.dylib -> libImath-3_0.dylib
    -- Installing: /Users/lg/code/openexr/dist/lib/pkgconfig/OpenEXR.pc
    -- Creating symlink in /Users/lg/code/openexr/dist/lib libIex.dylib -> libIex-3_0.dylib
    -- Creating symlink in /Users/lg/code/openexr/dist/lib libIlmThread.dylib -> libIlmThread-3_0.dylib
    -- Creating symlink in /Users/lg/code/openexr/dist/lib libOpenEXR.dylib -> libOpenEXR-3_0.dylib
    -- Creating symlink in /Users/lg/code/openexr/dist/lib libOpenEXRUtil.dylib -> libOpenEXRUtil-3_0.dylib
    
    [email protected] ~/code/openexr (broken) $ ls -R dist
    dist:
    include/  lib/
    
    dist/include:
    Imath/
    
    dist/include/Imath:
    ImathBox.h        ImathFrustum.h      ImathMath.h        ImathShear.h
    ImathBoxAlgo.h    ImathFrustumTest.h  ImathMatrix.h      ImathSphere.h
    ImathColor.h      ImathFun.h          ImathMatrixAlgo.h  ImathTypeTraits.h
    ImathColorAlgo.h  ImathGL.h           ImathNamespace.h   ImathVec.h
    ImathConfig.h     ImathGLU.h          ImathPlane.h       ImathVecAlgo.h
    ImathEuler.h      ImathInt64.h        ImathPlatform.h    half.h
    ImathExport.h     ImathInterval.h     ImathQuat.h        halfFunction.h
    ImathForward.h    ImathLine.h         ImathRandom.h      halfLimits.h
    ImathFrame.h      ImathLineAlgo.h     ImathRoots.h
    
    dist/lib:
    cmake/                      [email protected]  [email protected]
    [email protected]               [email protected]     pkgconfig/
    [email protected]         [email protected]
    libImath-3_0.28.0.0.dylib*  [email protected]
    
    dist/lib/cmake:
    Imath/
    
    dist/lib/cmake/Imath:
    ImathConfig.cmake         ImathTargets-release.cmake
    ImathConfigVersion.cmake  ImathTargets.cmake
    
    dist/lib/pkgconfig:
    Imath.pc  OpenEXR.pc
    

    You can see that the libOpenEXR made it, but not the headers, nor the lib/cmake/OpenEXR area.

    Can somebody else please try this all on their own and see if you can reproduce?

    I haven't yet tried the top of 2.4 and 2.5, but we better make sure those are not broken before we do any releases.

    opened by lgritz 26
  • DWA compression slow for tiles larger than 64

    DWA compression slow for tiles larger than 64

    I noticed something strange (and showstoppingly critical for my application) with the run time behavior of compressing a tiled OpenEXR with DWAB compression: If I use exrmaketiled to recode a 100MP scanline file into a tiled file, the run time increases significantly if I increase the tile size. Here are a few measurements:

    tile size -> run time 64x64 -> 14s 128x128 -> 30s 256x256 -> 42s

    This seems completely counter intuitive, since the smaller the tiles are, the more restarts and tile header generations, etc. are necessary. DWAA behaves the same. As a reference: when doing the same sequence with PIZ, I get the following timings: 8s, 4s, 3s. Which is what I would expect.

    Before I start digging in an unknown code base, does anyone have an idea why the library behaves like that and whether or not this can be fixed (easily)?

    Bug 
    opened by axxel 24
  • Support for pthreads under mingw-w64.

    Support for pthreads under mingw-w64.

    This PR does two things:

    1. It checks for and uses pthreads if available, when compiling for mingw-w64.
    2. It adds logic that checks for the presence of the generated headers (toFloat.h, eLut.h, b44ExpLogTable.h and dwaLookups.h) before trying to build them. Additionally, it streamlines the workflow somewhat by allowing the user to point to a previous (native) build when cross-compiling; so if CMake detects that it's cross-compiling, it can use previously built native executables to generate those headers.

    P.S. I'm really sorry about the whitespace diffs, I swear I really tried  😅

    Needs Discussion 
    opened by Lord-Kamina 23
  • ilmbase 2.3.0 fails to build in FreeBSD 11.2

    ilmbase 2.3.0 fails to build in FreeBSD 11.2

    Greetings,

    I was trying to upgrade the ilmbase and OpenEXR ports in FreeBSD to v2.3.0 - but it appears that there are too many Linux/i386 issues such that I consider the effort unviable. It looks like we need to skip v2.3.0 on FreeBSD and stick to v2.2.1, which is unfortunate.

    With ilmbase, I find that:

    • the cmake build is now totally broken (no matter if using ninja or make) because most variables aren't defined, and I need to set on the command line several variables listed in https://github.com/openexr/openexr/blob/master/README.md#building-with-cmake - these would not appear in ccmake.
    • "SOVERSION" appears verbatim in the file names (this is with FreeBSD 11.2 and cmake 3.11.2), rather than 24.
    • under cmake, no libraries are built unless I define, among others, -DOPENEXR_BUILD_STATIC=bool:true
    • the GNU configure script is bash-specific and does not work with a plain POSIX /bin/sh and fails.

    So, if I use the GNU configure stuff and use bash for the configure shell, I can get past these issues at least, and now for the real regressions in the code:

    • ilmbase 2.3.0 now uses many Linux-specific or obsolete sigaction() features, FreeBSD does not have asm/sigcontext.h, so we get several errors from IexMathFpu.cpp around _fpstate and fpregs, and sa_restorer isn't exposed in FreeBSD (but ilmbase tampers with it - Linux's manpage clearly states "Not intended for application use"). I can't seem to find the required FPE struct elements with "grep -r SOMEFEATURE /usr/include" on FreeBSD. This appears to be a major regression since v2.2.1.
    • ilmbase 2.3.0 uses SA_NOMASK, which isn't defined on FreeBSD (SA_NODEFER is, however).
    • I haven't gotten around to try to build OpenEXR 2.3.0, it doesn't work with ilmbase v2.2.1 (which doesn't surprise me though).

    We have always needed some local patches to get OpenEXR to compile on FreeBSD, but with 2.3.0, I am at a loss about IexMathFpu.*.

    opened by mandree 23
  • Use GNUInstallDirs and add missing .pc files for cmake build

    Use GNUInstallDirs and add missing .pc files for cmake build

    Use GNUInstallDirs to allow a standard convention in install variable naming.

    Add missing OpenEXR.pc, OpenEXR_Viewers.pc, and PyIlmBase.pc files: The Autotools build system installs a .pc file, but CMake doesn't. This adds the missing file but makes use of GNUInstallDirs for the paths. It is now modeled after the Autotools version. Based on: PR #138 but corrected to link to the correct libraries.

    Changed the .pc files to be external templates like autotools.

    Signed-off by: Jonathan Scruggs ([email protected])

    Build 
    opened by dracwyrm 21
  • CMake build custom command for generating b44ExpLogTable exe fails on Linux and OS X

    CMake build custom command for generating b44ExpLogTable exe fails on Linux and OS X

    As an addition to Issue 61, based off the CMake-fixes branch, on Linux and OS X (10.6.8) with CMake only, I don't think the custom command for generating the b44ExpLogTable.h is working:

    previously, I was tarring up the already built versions of IlmBase and OpenEXR that I'd built as tests for the CMake-fixes stuff, and copying them to the project I'm using them in, and that worked, but that seems to be because the 1.1 MB b44ExpLogTable.h was included in that.

    If I remove that file, which seems to be generated as a custom command in OpenEXR/IlmImf, then on Linux the file gets generated, but in the OpenEXR directory, which then can't find the header as it's actually looking for it in the OpenEXR/IlmImf directory as that's where the .cpp is.

    I tried moving the generation step to build it actually in the OpenEXR/IlmImf directory, but that then can't actually build the b44ExpLogTable executable program, as it has link issues.

    This is with the latest CMake-fixes brach, with minor changes to some of the CMakeLists.txt files for the OpenEXR component in order to append "-2_0" to some of the libraries in IlmBase things link against (which coincidently is a change needed to use OpenEXR with CMake on both Linux and OS X).

    On OS X, generation of b44ExpLogTable fails completely, as for some reason it can't find libHalf.10.dylib to link against - the target lib's there, so maybe a missing LINK_DIRECTORIES() command to specify the library search path? I can't work out why it does build on Linux and not on OS X, as there doesn't seem to be any platform-specific stuff, but I haven't really got the time to look into it properly I'm afraid:

    To fix this issue locally for my own usage, I've just removed that custom command generation and running, and included the 1.1 MB generated file in the .tar.bz2 I'm using as the OpenEXR sourcedrop which then gets around the issue.

    opened by ppearson 21
  • Missing C++11 type traits for half

    Missing C++11 type traits for half

    half.h lacks the bits of code necessary for certain C++11 type traits. Users should expect that std::is_floating_point::value is true, as should be std::is_arithmetic::value. (Currently, they default to false, which can screw up your clever metaprogramming when using half. There may be others we should set as well.

    (Question above my C++ pay grade: should vector & matrix types also have arithmetic and floating point traits?)

    In retrospect, I can see that this was mentioned in #253, and we closed that tickets without fully addressing it.

    opened by lgritz 19
  • Switch default Zip compression level from 6 to 4

    Switch default Zip compression level from 6 to 4

    Kinda related to #1002 but this one does not add any new libraries or compressors. After #1149 added controllable zip compression levels, this makes the default zip level change; from 6 to 4.

    In my test of 18 various exr files (total raw data size 1057MB):

    • zip 6: 2.452x ratio, 206MB/s compression
    • zip 4: 2.421x ratio, 437MB/s compression

    So a tiny drop of compression ratio, but compression is more than 2x faster. This makes writing zip faster than writing uncompressed (386MB/s). Decompression speed unaffected.

    A longer writeup of all this, with data graphs: https://aras-p.info/blog/2021/08/05/EXR-Zip-compression-levels/

    Screenshot 2021-08-05 at 09 24 57 v3.1.3 
    opened by aras-p 17
  • Initial rename of OpenEXR and IlmBase directories and seperation of Test

    Initial rename of OpenEXR and IlmBase directories and seperation of Test

    This PR effectively:

    Restructures the repo's source file directory including:

    Moving into a tree starting from src/ Moves all tests in these two old directories to a new separate directory tests/ Allows for building with this new configuration using CMake

    PyIlmBase/ has not been touched as it could potentially be removed altogether, the only thing it contains now are pyIex and pyIexTest. This PR by default will not build PyIlmBase, but it remains as source.

    After this PR:

    PyIlmBase/ can be removed or relocated depending on feedback. Cmake can be further optimized as there is some redundancy

    This is a big change so if there are objections that is understandable. I want to get feedback before getting too far into things.

    v3.0.0-beta 
    opened by oxt3479 17
  • ZLIB_LIBRARY ZLIB_INCLUDE_DIR being ignored (LNK2019 errors) in OpenEXR\IlmImf\IlmImf.vcxproj

    ZLIB_LIBRARY ZLIB_INCLUDE_DIR being ignored (LNK2019 errors) in OpenEXR\IlmImf\IlmImf.vcxproj

    In windows 10 x64; using VS2017; using cmake 3.13.14 and a powershell script.

    I have multiple LNK2019 error, despite a correct configuration:

    ImfDwaCompressor.obj : error LNK2019: unresolved external symbol compress2 referenced in function "private: int __cdecl
     Imf_2_3::DwaCompressor::compress(char const *,int,class Imath_2_3::Box<class Imath_2_3::Vec2<int> >,char const * &)" (
    [email protected]@[email protected]@[email protected][email protected]@[email protected]@@[email protected]@[email protected]) [I:\lib\master-openexr\bu
    ild\OpenEXR\IlmImf\IlmImf.vcxproj]
    ImfDwaCompressor.obj : error LNK2019: unresolved external symbol compressBound referenced in function "private: int __c
    decl Imf_2_3::DwaCompressor::compress(char const *,int,class Imath_2_3::Box<class Imath_2_3::Vec2<int> >,char const * &
    )" ([email protected]@[email protected]@[email protected][email protected]@[email protected]@@[email protected]@[email protected]) [I:\lib\master-openex
    r\build\OpenEXR\IlmImf\IlmImf.vcxproj]
    ImfDwaCompressor.obj : error LNK2019: unresolved external symbol uncompress referenced in function "private: int __cdec
    l Imf_2_3::DwaCompressor::uncompress(char const *,int,class Imath_2_3::Box<class Imath_2_3::Vec2<int> >,char const * &)
    " ([email protected]@[email protected]@[email protected][email protected]@[email protected]@@[email protected]@[email protected]) [I:\lib\master-opene
    xr\build\OpenEXR\IlmImf\IlmImf.vcxproj]
    ImfPxr24Compressor.obj : error LNK2001: unresolved external symbol uncompress [I:\lib\master-openexr\build\OpenEXR\IlmI
    mf\IlmImf.vcxproj]
    ImfZip.obj : error LNK2001: unresolved external symbol uncompress [I:\lib\master-openexr\build\OpenEXR\IlmImf\IlmImf.vc
    xproj]
    ImfPxr24Compressor.obj : error LNK2019: unresolved external symbol compress referenced in function "private: int __cdec
    l Imf_2_3::Pxr24Compressor::compress(char const *,int,class Imath_2_3::Box<class Imath_2_3::Vec2<int> >,char const * &)
    " ([email protected]@[email protected]@[email protected][email protected]@[email protected]@@[email protected]@[email protected]) [I:\lib\master-opene
    xr\build\OpenEXR\IlmImf\IlmImf.vcxproj]
    ImfZip.obj : error LNK2001: unresolved external symbol compress [I:\lib\master-openexr\build\OpenEXR\IlmImf\IlmImf.vcxp
    roj]
    I:\lib\master-openexr\build\OpenEXR\IlmImf\Release\IlmImf-2_3.dll : fatal error LNK1120: 4 unresolved externals [I:\lib
    \master-openexr\build\OpenEXR\IlmImf\IlmImf.vcxproj]
    

    Repro: using zlib 1.2.11, compiled in Win64 at I:\lib\zlib

    I configure and build openexr with this script:

    $target = "Visual Studio 15 2017 Win64"
    $zlib_prefix = "I:\lib\zlib"
    
    function configure {
    	cmake.exe -G $target -T v141, host=x64 -j8 `
    		-DZLIB_LIBRARY="${zlib_prefix}\lib" -DZLIB_INCLUDE_DIR="${zlib_prefix}\include" `
    		-DOPENEXR_BUILD_PYTHON_LIBS=0 -DCMAKE_INSTALL_PREFIX="I:\lib\openexr" `
    		..
    }
    
    function build {
    	"build openexr debug"
    	MSBuild.exe OpenEXR.sln /verbosity:m /m
    	"build openexr release"
    	MSBuild.exe OpenEXR.sln /p:Configuration=Release /verbosity:m /m
    }
    
    function install {
    	"install openexr debug"
    	MSBuild.exe INSTALL.vcxproj /verbosity:m /m
    	"install openexr release"
    	MSBuild.exe INSTALL.vcxproj /p:Configuration=Release /verbosity:m /m
    }
    
    if (!(test-path build)) {
    	New-Item -ItemType Directory build
    }
    Set-Location build
    configure
    build
    #install
    Set-Location ..
    

    Proof: hand-edit IlmImf.vcxproj to use the zlib.lib and zlibd.lib provided works.

    Needs Discussion 
    opened by mprevot 17
  • Release OpenEXR as NuGet

    Release OpenEXR as NuGet

    These scripts compile OpenEXR as a NuGet Package. Use with Visual Studio or MSBuild. Prepared for continuous integration services.

    https://www.nuget.org/packages/openexr-msvc14-x86/ https://www.nuget.org/packages/openexr-msvc14-x64/

    opened by ghost 17
  • CII gold badge: build_reproducible

    CII gold badge: build_reproducible

    The project MUST have a reproducible build. If no building occurs (e.g., scripting languages where the source code is used directly instead of being compiled), select "not applicable" (N/A). (URL required)

    A reproducible build means that multiple parties can independently redo the process of generating information from source files and get exactly the same bit-for-bit result. In some cases, this can be resolved by forcing some sort order. JavaScript developers may consider using npm shrinkwrap and webpack OccurenceOrderPlugin. GCC and clang users may find the -frandom-seed option useful. The build environment (including the toolset) can often be defined for external parties by specifying the cryptographic hash of a specific container or virtual machine that they can use for rebuilding. The reproducible builds project has documentation on how to do this.

    opened by cary-ilm 0
  • CII gold badge: hardened_site

    CII gold badge: hardened_site

    The project website, repository (if accessible via the web), and download site (if separate) MUST include key hardening headers with nonpermissive values. (URL required)

    Note that GitHub and GitLab are known to meet this. Sites such as https://securityheaders.com/ can quickly check this. The key hardening headers are: Content Security Policy (CSP), HTTP Strict Transport Security (HSTS), X-Content-Type-Options (as "nosniff"), and X-Frame-Options. Fully static web sites with no ability to log in via the web pages could omit some hardening headers with less risk, but there's no reliable way to detect such sites, so we require these headers even if they are fully static sites.

    opened by cary-ilm 0
  • CII gold badge: security_review

    CII gold badge: security_review

    The project MUST have performed a security review within the last 5 years. This review MUST consider the security requirements and security boundary.

    This MAY be done by the project members and/or an independent evaluation. This evaluation MAY be supported by static and dynamic analysis tools, but there also must be human review to identify problems (particularly in design) that tools cannot detect. Security review justification

    opened by cary-ilm 0
  • CII silver badge: assurance_case

    CII silver badge: assurance_case

    The project MUST provide an assurance case that justifies why its security requirements are met. The assurance case MUST include: a description of the threat model, clear identification of trust boundaries, an argument that secure design principles have been applied, and an argument that common implementation security weaknesses have been countered. (URL required)

    An assurance case is "a documented body of evidence that provides a convincing and valid argument that a specified set of critical claims regarding a system’s properties are adequately justified for a given application in a given environment" ("Software Assurance Using Structured Assurance Case Models", Thomas Rhodes et al, NIST Interagency Report 7608). Trust boundaries are boundaries where data or execution changes its level of trust, e.g., a server's boundaries in a typical web application. It's common to list secure design principles (such as Saltzer and Schroeer) and common implementation security weaknesses (such as the OWASP top 10 or CWE/SANS top 25), and show how each are countered. The BadgeApp assurance case may be a useful example. This is related to documentation_security, documentation_architecture, and implement_secure_design.

    opened by cary-ilm 0
  • CII silver badge: version_tags_signed

    CII silver badge: version_tags_signed

    It is SUGGESTED that in the version control system, each important version tag (a tag that is part of a major release, minor release, or fixes publicly noted vulnerabilities) be cryptographically signed and verifiable as described in signed_releases.

    opened by cary-ilm 0
Releases(v3.1.5)
  • v3.1.5(Apr 11, 2022)

    Patch release that address various bug/build/doc issues:

    • 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.
    • Fix build failures on MSVC14 and MSVC 2022
    • Fix build failure on latest 64-bit Ubuntu
    • Documentation refers to primary branch as "main"
    • Update the CI workflow matrix to VFX-CY2022
    • Update auto-fetch Imath version to v3.1.5

    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
    Source code(tar.gz)
    Source code(zip)
  • v2.5.8(Mar 19, 2022)

    Patch release that backports two fixes:

    • Fix MinGW build by dropping export on defaulted KeyCode::~KeyCode
    • Use CMAKE_INSTALL_FULL_LIBDIR/INCLUDEDIR in pkgconfig
    Source code(tar.gz)
    Source code(zip)
  • v3.1.4(Jan 27, 2022)

    Patch release that addresses various issues:

    • Several bug fixes to properly reject invalid input upon read
    • A check to enable SSE2 when building with Visual Studio
    • A check to fix building with VisualStudio on ARM64
    • Update the automatically-downloaded version of Imath to v3.1.4
    • Miscellaneous documentation improvements

    This addresses one public security vulnerability:

    • CVE-2021-45942 Heap-buffer-overflow in Imf_3_1::LineCompositeTask::execute

    See CHANGES.md for more details.

    Source code(tar.gz)
    Source code(zip)
  • v3.1.3(Oct 27, 2021)

    Patch release with a change to default zip compression level:

    • Default zip compression level is now 4 (instead of 6), which in our tests improves compression times by 2x with only a tiny drop in compression ratio.
    • setDefaultZipCompression() and setDefaultDwaCompression() now set default compression levels for writing.
    • The Header now has zipCompressionLevel() and dwaCompressionLevel() to get/set the levels used for writing.

    Also, various bug fixes, build improvements, and documentation updates. In particular:

    • Fixes a build failure with Imath prior to v3.1
    • Fixes a bug in detecting invalid chromaticity values
    Source code(tar.gz)
    Source code(zip)
  • v3.1.2(Oct 4, 2021)

    Patch release with various bug fixes, build improvements, and documentation updates. In particular:

    • Fixes a test failure on arm7
    • Proper handling of pthread with glibc 2.34+
    • miscellaneous fixes for handling of invalid input by the new OpenEXRCore library

    With this version, the OpenEXR technical documentation formerly distributed exclusively as pdf's is now published online at https://openexr.readthedocs.io, with the document source now maintained as .rst files in the repo's docs subfolder.

    • OSS-fuzz 39196 Stack-buffer-overflow in dispatch_print_error
    • OSS-fuzz 39198 Direct-leak in exr_attr_chlist_add_with_length
    • OSS-fuzz 39206 Direct-leak in extract_attr_string_vector
    • OSS-fuzz 39212 Heap-use-after-free in dispatch_print_error
    • OSS-fuzz 39205 Timeout in openexr_exrcheck_fuzzer
    • OSS-fuzz 38912 Integer-overflow in Imf_3_1::bytesPerDeepLineTable
    • OSS-fuzz 39084 Divide-by-zero in Imf_3_1::RGBtoXYZ
    Source code(tar.gz)
    Source code(zip)
  • v3.1.1(Aug 3, 2021)

  • v3.1.0(Jul 23, 2021)

    Minor release with significant new features:

    The 3.1 release of OpenEXR introduces a new library, OpenEXRCore, which is the result of a significant re-thinking of how OpenEXR manages file I/O and provides access to image data. It begins to address long-standing scalability issues with multithreaded image reading and writing.

    The OpenEXRCore library provides thread-safe, non-blocking access to files, which was not possible with the current API, where the framebuffer management is separate from read requests. It is written entirely in C and provides a new C-language API alongside the existing C++ API. This new low-level API allows applications to do custom unpacking of EXR data, such as on the GPU, while still benefiting from efficient I/O, file validation, and other semantics. It provides efficient direct access to EXR files in texturing applications. This C library also introduces an easier path to implementing OpenEXR bindings in other languages, such as Rust.

    The 3.1 release represents a technology preview for upcoming releases. The initial release is incremental; the existing API and underlying behavior has not changed. The new API is available now for performance validation testing, and then in future OpenEXR releases, the C++ API will migrate to use the new core in stages. It is not the intention to entirely deprecate the C++ API, nor must all applications re-implement EXR I/O in terms of the C library. The C API does not, and will not, provide the rich set of utility classes that exist in the C++ layer. The 3.1 release of the OpenEXRCore library simply offers new functionality for specialty applications seeking the highest possible performance. In the future, the ABI will evolve, but the API will remain consistent, or only have additions.

    See the release notes and the technical documentation for more details.

    Source code(tar.gz)
    Source code(zip)
  • v3.0.5(Jul 2, 2021)

    Patch release that fixes problems with library symlinks and pkg-config, as well as miscellaneous bugs/security issues.

    • 1064 Use CMAKE_INSTALL_FULL_LIBDIR/INCLUDEDIR in pkgconfig for 3.*
    • 1051 Fix non-versioned library symlinks in debug build.
    • 1050 Use CMAKE__POSTFIX for .pc file lib suffix.
    • 1045 The vtable for TiledRgbaInputFile was not properly tagged as export
    • 1038 fix/extend part number validation in MultiPart methods
    • 1037 verify data size in deepscanlines with NO_COMPRESSION
    • 1036 detect buffer overflows in RleUncompress
    • The Imath auto-build version defaults to Imath v3.0.5.
    Source code(tar.gz)
    Source code(zip)
  • v2.5.7(Jun 16, 2021)

    Patch release of 2.5 with security and build fixes:

    • OSS-fuzz 28051 Heap-buffer-overflow in Imf_2_5::copyIntoFrameBuffer
    • OSS-fuzz 28155 Crash in Imf_2_5::PtrIStream::read
    • Fix broken symlink and pkg-config lib suffix for cmake debug builds
    Source code(tar.gz)
    Source code(zip)
  • v3.0.4(Jun 3, 2021)

  • v3.0.3(May 19, 2021)

  • v3.0.2(May 18, 2021)

    Patch release with miscellaneous bug/build fixes, including:

    • Fix TimeCode.frame max value
    • Don't impose C++14 on downstream projects
    • Restore fix to macOS universal 2 build lost from #854

    Specific OSS-fuzz issues:

    • OSS-fuzz 33741 Integer-overflow in Imf_3_0::getScanlineChunkOffsetTableSize
    • OSS-fuzz 32620 Out-of-memory in openexr_exrcheck_fuzzer
    Source code(tar.gz)
    Source code(zip)
  • v2.4.3(May 18, 2021)

    Patch release for v2.4 that addresses the following security vulnerabilities:

    Also:

    • 1013 Fixed regression in Imath::succf() and Imath::predf() when negative values are given
    Source code(tar.gz)
    Source code(zip)
  • v2.5.6(May 18, 2021)

    Patch release for v2.5 that fixes a regression in Imath::succf()/Imath::predf():

    #1013 Fixed regression in Imath::succf() and Imath::predf() when negative values are given

    Source code(tar.gz)
    Source code(zip)
  • v3.0.1(Apr 1, 2021)

    Major release with major build restructuring, security improvements, and new features:

    Restructuring:

    • The IlmBase/PyIlmBase submodules have been separated into the Imath project, now included by OpenEXR via a CMake submodule dependency, fetched automatically via CMake's FetchContent if necessary.
    • The library is now called libOpenEXR (instead of libIlmImf). No header files have been renamed; they retain the Imf prefix.
    • Symbol linkage visibility is limited to specific public symbols. See SymbolVisibility.md for more details.

    Build improvements:

    • No more simultaneous static/shared build option.
    • Community-provided support for bazel.
    • Gnu autoconf/bootstrap/configure build setup has been retired.

    New Features:

    Changes:

    • EXR files with no channels are no longer allowed.
    • Hard limit on the size of deep tile sizes; tiles must be less than 230 pixels.
    • Tiled DWAB files used STATIC_HUFFMAN compression.
    • Int64 and SInt64 types are deprecated in favor of uint64_t and int64_t.
    • Header files have been pruned of extraneous #include's ("Include What You Use"), which may generate compiler errors in application source code from undefined symbols or partially-defined types. These can be resolved by identifying and including the appropriate header.
    • See the porting guide for details about differences from previous releases and how to address them.
    • Also refer to the porting guide for details about changes to Imath.
    Source code(tar.gz)
    Source code(zip)
  • v3.0.1-beta(Mar 29, 2021)

    Beta patch release:

    • OSS-fuzz 32370 Out-of-memory in openexr_exrcheck_fuzzer
    • OSS-fuzz 32067 account for size of pixels when estimating memory

    Merged Pull Requests:

    • 988 Remove deprecated argument to getChunkOffsetTableSize()
    • 987 exrcheck: reduceMemory now checks pixel size and scanline compression mode
    • 983 Reduce warnigns reported in #982
    • 980 Bazel cherry picks
    • 968 Fix typos in Int64/SInt64 deprecation warnings
    • 966 exrcheck: account for size of pixels when estimating memory
    Source code(tar.gz)
    Source code(zip)
  • v3.0.0-beta(Mar 17, 2021)

    Major release with major build restructuring, security improvements, and new features:

    Restructuring:

    • The IlmBase/PyIlmBase submodules have been separated into the Imath project, now included by OpenEXR via a CMake submodule dependency, fetched automatically via CMake's FetchContent if necessary.
    • The library is now called libOpenEXR (instead of libIlmImf). No header files have been renamed; they retain the Imf prefix.
    • Symbol linkage visibility is limited to specific public symbols. See SymbolVisibility.md for more details.

    Build improvements:

    • No more simultaneous static/shared build option.
    • Community-provided support for bazel.
    • Gnu autoconf/bootstrap/configure build setup has been retired.

    New Features:

    Changes:

    • EXR files with no channels are no longer allowed.
    • Hard limit on the size of deep tile sizes; tiles must be less than 230 pixels.
    • Tiled DWAB files used STATIC_HUFFMAN compression.
    • Int64 and SInt64 types are deprecated in favor of uint64_t and int64_t.
    • Header files have been pruned of extraneous #include's ("Include What You Use"), which may generate compiler errors in application source code from undefined symbols or partially-defined types. These can be resolved by identifying and including the appropriate header.
    • See the porting guide for details about differences from previous releases and how to address them.
    • Also refer to the porting guide for details about changes to Imath.
    Source code(tar.gz)
    Source code(zip)
  • v2.5.5(Feb 12, 2021)

    Patch release with various bug/sanitizer/security fixes, primarily related to reading corrupted input files, but also a fix for universal build support on macOS.

    Specific OSS-fuzz issues include:

    • OSS-fuzz #30291 Timeout in openexr_exrcheck_fuzzer
    • OSS-fuzz #29106 Heap-buffer-overflow in Imf_2_5::FastHufDecoder::decode
    • OSS-fuzz #28971 Undefined-shift in Imf_2_5::cachePadding
    • OSS-fuzz #29829 Integer-overflow in Imf_2_5::DwaCompressor::initializeBuffers
    • OSS-fuzz #30121 Out-of-memory in openexr_exrcheck_fuzzer
    Source code(tar.gz)
    Source code(zip)
  • v2.5.4(Dec 31, 2020)

    Patch release with various bug/sanitizer/security fixes, primarily related to reading corrupted input files.

    Specific OSS-fuzz issues include:

    • OSS-fuzz #24854 Segv on unknown address in Imf_2_5::hufUncompress
    • OSS-fuzz #24831 Undefined-shift in Imf_2_5::FastHufDecoder::FastHufDecoder
    • OSS-fuzz #24969 Invalid-enum-value in Imf_2_5::TypedAttribute<Imf_2_5::Envmap>::writeVal ueTo
    • OSS-fuzz #25297 Integer-overflow in Imf_2_5::calculateNumTiles
    • OSS-fuzz #24787 Undefined-shift in Imf_2_5::unpack14
    • OSS-fuzz #25326 Out-of-memory in openexr_scanlines_fuzzer
    • OSS-fuzz #25399 Heap-buffer-overflow in Imf_2_5::FastHufDecoder::FastHufDecoder
    • OSS-fuzz #25415 Abrt in __cxxabiv1::failed_throw
    • OSS-fuzz #25370 Out-of-memory in openexr_exrenvmap_fuzzer
    • OSS-fuzz #25501 Out-of-memory in openexr_scanlines_fuzzer
    • OSS-fuzz #25505 Heap-buffer-overflow in Imf_2_5::copyIntoFrameBuffer
    • OSS-fuzz #25562 Integer-overflow in Imf_2_5::hufUncompress
    • OSS-fuzz #25740 Null-dereference READ in Imf_2_5::Header::operator
    • OSS-fuzz #25743 Null-dereference in Imf_2_5::MultiPartInputFile::header
    • OSS-fuzz #25913 Out-of-memory in openexr_exrenvmap_fuzzer
    • OSS-fuzz #26229 Undefined-shift in Imf_2_5::hufDecode
    • OSS-fuzz #26658 Out-of-memory in openexr_scanlines_fuzzer
    • OSS-fuzz #26956 Heap-buffer-overflow in Imf_2_5::DeepTiledInputFile::readPixelSampleCoun ts
    • OSS-fuzz #27409 Out-of-memory in openexr_exrcheck_fuzzer
    • OSS-fuzz #25892 Divide-by-zero in Imf_2_5::calculateNumTiles
    • OSS-fuzz #25894 Floating-point-exception in Imf_2_5::precalculateTileInfo

    See CHANGES.md for more details.

    Source code(tar.gz)
    Source code(zip)
  • v2.5.3(Aug 12, 2020)

    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
    • Cmake fix for building on arm64 macOS (#772)
    • Read performance optimization (#782)
    • Fix for building on non-glibc (#798)
    • Fixes to tests
    Source code(tar.gz)
    Source code(zip)
    openexr-2.5.3.tar.gz.sig(287 bytes)
  • v2.5.2(Jun 15, 2020)

    Patch release with various bug/security and build/install fixes:

    • Invalid input could cause a heap-use-after-free error in DeepScanLineInputFile::DeepScanLineInputFile()
    • Invalid chunkCount attributes could cause heap buffer overflow in getChunkOffsetTableSize()
    • Invalid tiled input file could cause invalid memory access TiledInputFile::TiledInputFile()
    • OpenEXRConfig.h now correctly sets OPENEXR_PACKAGE_STRING to "OpenEXR" (rather than "IlmBase")
    • Various Windows build fixes
    Source code(tar.gz)
    Source code(zip)
    openexr-2.5.2.tar.gz.sig(287 bytes)
  • v2.4.2(Jun 15, 2020)

    Patch release that backports various recent bug/security fixes:

    • Invalid input could cause a heap-use-after-free error in DeepScanLineInputFile::DeepScanLineInputFile()
    • Invalid chunkCount attributes could cause heap buffer overflow in getChunkOffsetTableSize()
    • Invalid tiled input file could cause invalid memory access TiledInputFile::TiledInputFile()
    • OpenEXRConfig.h now correctly sets OPENEXR_PACKAGE_STRING to "OpenEXR" (rather than "IlmBase)"
    Source code(tar.gz)
    Source code(zip)
    openexr-2.4.2.tar.gz.sig(287 bytes)
  • v2.5.1(May 11, 2020)

  • v2.5.0(May 7, 2020)

    Minor release with miscellaneous bug fixes and small features:

    • No more build-time header generation: toFloat.h, eLut.h, b44ExpLogTable.h, and dwaLookups.h are now ordinary header files, no longer generated on the fly.
    • New StdISSTream class, an "input" stringstream version of StdOSStream
    • New Matrix22 class in Imath
    • Chromaticity comparison operator now includes white (formerly ignored)
    • Various cmake fixes
    • Bug fixes for various memory leaks
    • Bug fixes for various invalid memory accesses
    • New checks to detect damaged input files
    • OpenEXR_Viewers has been deprecated, removed from the top-level cmake build and documentation.

    See CHANGES.md for more details.

    Source code(tar.gz)
    Source code(zip)
    openexr-2.5.0.tar.gz.sig(287 bytes)
  • v2.2.2(Apr 30, 2020)

    This is a patch release that backports fixes for the following CVE's into the 2.2.1 (Nov 30, 2017) release:

    • CVE-2020-11765 There is an off-by-one error in use of the ImfXdr.h read function by DwaCompressor::Classifier::Classifier, leading to an out-of-bounds read.
    • CVE-2020-11764 There is an out-of-bounds write in copyIntoFrameBuffer in ImfMisc.cpp.
    • CVE-2020-11763 There is an std::vector out-of-bounds read and write, as demonstrated by ImfTileOffsets.cpp.
    • CVE-2020-11762 There is an out-of-bounds read and write in DwaCompressor::uncompress in ImfDwaCompressor.cpp when handling the UNKNOWN compression case.
    • CVE-2020-11761 There is an out-of-bounds read during Huffman uncompression, as demonstrated by FastHufDecoder::refill in ImfFastHuf.cpp.
    • CVE-2020-11760 There is an out-of-bounds read during RLE uncompression in rleUncompress in ImfRle.cpp.
    • CVE-2020-11759 Because of integer overflows in CompositeDeepScanLine::Data::handleDeepFrameBuffer and readSampleCountForLineBlock, an attacker can write to an out-of-bounds pointer.
    • CVE-2020-11758 There is an out-of-bounds read in ImfOptimizedPixelReading.h.
    Source code(tar.gz)
    Source code(zip)
    openexr-2.2.2.tar.gz.asc(659 bytes)
    openexr-2.2.2.tar.gz.sig(438 bytes)
  • v2.4.1(Feb 12, 2020)

    Patch release with minor bug fixes.

    Summary:

    • 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.

    This version fixes the following security vulnerabilities:

    • CVE-2020-11765 There is an off-by-one error in use of the ImfXdr.h read function by DwaCompressor::Classifier::ClasGsifier, leading to an out-of-bounds read.
    • CVE-2020-11764 There is an out-of-bounds write in copyIntoFrameBuffer in ImfMisc.cpp.
    • CVE-2020-11763 There is an std::vector out-of-bounds read and write, as demonstrated by ImfTileOffsets.cpp.
    • CVE-2020-11762 There is an out-of-bounds read and write in DwaCompressor::uncompress in ImfDwaCompressor.cpp when handling the UNKNOWN compression case.
    • CVE-2020-11761 There is an out-of-bounds read during Huffman uncompression, as demonstrated by FastHufDecoder::refill in ImfFastHuf.cpp.
    • CVE-2020-11760 There is an out-of-bounds read during RLE uncompression in rleUncompress in ImfRle.cpp.
    • CVE-2020-11759 Because of integer overflows in CompositeDeepScanLine::Data::handleDeepFrameBuffer and readSampleCountForLineBlock, an attacker can write to an out-of-bounds pointer.
    • CVE-2020-11758 There is an out-of-bounds read in ImfOptimizedPixelReading.h.
    Source code(tar.gz)
    Source code(zip)
    v2.4.1.tar.gz.asc(490 bytes)
  • v2.4.0(Sep 19, 2019)

    Version 2.4.0

    Summary of changes:

    • Completely re-written CMake configuration files
    • Improved support for building on Windows, via CMake
    • Improved support for building on macOS, via CMake
    • All code compiles without warnings on gcc, clang, msvc
    • Cleanup of license and copyright notices
    • floating-point exception handling is disabled by default
    • New Slice::Make method to reliably compute base pointer for a slice.
    • Miscellaneous bug fixes

    Security Vulnerabilities

    This version fixes the following security vulnerabilities:

    • CVE-2018-18444 Issue #351 Out of Memory
    • CVE-2018-18443 Issue #350 heap-buffer-overflow
    Source code(tar.gz)
    Source code(zip)
  • v2.4.0-beta.1(Sep 5, 2019)

    Version 2.4.0

    Summary of changes:

    • Completely re-written CMake configuration files
    • Improved support for building on Windows, via CMake
    • Improved support for building on macOS, via CMake
    • All code compiles without warnings on gcc, clang, msvc
    • Cleanup of license and copyright notices
    • floating-point exception handling is disabled by default
    • New Slice::Make method to reliably compute base pointer for a slice.
    • Miscellaneous bug fixes

    Security Vulnerabilities

    This version fixes the following security vulnerabilities:

    • CVE-2018-18444 Issue #351 Out of Memory
    • CVE-2018-18443 Issue #350 heap-buffer-overflow
    Source code(tar.gz)
    Source code(zip)
  • v2.3.0(Aug 10, 2018)

    OpenEXR Release Notes

    Version 2.3.0:

    Features/Improvements:

    • ThreadPool overhead improvements, enable custom thread pool to be registered via ThreadPoolProvider class
    • Fixes to enable custom namespaces for Iex, Imf
    • Improve read performance for deep/zipped data, and SIMD-accelerated uncompress support
    • Added rawPixelDataToBuffer() function for access to compressed scanlines
    • Iex::BaseExc no longer derived from std::string.
    • Imath throw() specifiers removed
    • Initial Support for Python 3

    Bugs:

    • 25+ various bug fixes

    Security Vulnerabilities:

    This release addresses vulnerability CVE-2017-12596.

    Build Fixes:

    • Various fixes to the cmake and autoconf build infrastructures
    • Various changes to support compiling for C++11 / C++14 / C++17 and GCC 6.3.1
    • Various fixes to address Windows build issues
    • 60+ total build-related fixes (see detailed Release Notes for the full list)
    Source code(tar.gz)
    Source code(zip)
    ilmbase-2.3.0.tar.gz(581.53 KB)
    ilmbase-2.3.0.tar.gz.sig(566 bytes)
    openexr-2.3.0.tar.gz(17.55 MB)
    openexr-2.3.0.tar.gz.sig(566 bytes)
    openexr_viewers-2.3.0.tar.gz(519.68 KB)
    openexr_viewers-2.3.0.tar.gz.sig(566 bytes)
    pyilmbase-2.3.0.tar.gz(512.67 KB)
    pyilmbase-2.3.0.tar.gz.sig(566 bytes)
  • v2.2.1(Nov 30, 2017)

    Version 2.2.1

    Summary of changes:

    Maintenance release - security patches for OpenEXR

    The 2.2.1 release addresses the known OpenEXR security vulnerabilities, specifically:

    • CVE-2017-9110
    • CVE-2017-9111
    • CVE-2017-9112
    • CVE-2017-9113
    • CVE-2017-9114
    • CVE-2017-9115
    • CVE-2017-9116
    Source code(tar.gz)
    Source code(zip)
    openexr-2.2.1.tar.gz(17.33 MB)
Owner
Academy Software Foundation
Academy Software Foundation
Spacex Storage is an offchain storage work inspector of Mannheim Network running inside TEE enclave.

Spacex Storage Spacex Storage is an offchain storage work inspector of Mannheim Network running inside TEE enclave. Contribution Thank you for conside

Mannheim Network 10 Oct 21, 2022
A motion-activated LED light strip controller. Supports up to two motion detectors.

A simple standalone motion activated controller for WS2812b LED lights Version 0.30 adds the ability to change settings from a web interface without r

null 4 Mar 12, 2022
C++ implementation for a binary data storage format.

bsmlib- A C++ library for loading and writing binary data to and from files. bsmlib provides functions for loading, modifying, and saving BSM (Binary

Colleen 4 Oct 9, 2022
CQC (Charmed Quark Controller) a commercial grade, full featured, software based automation system. CQC is built on our CIDLib C++ development system, which is also available here on GitHub.

The CQC Automation System What It Is CQC is a commercial quality, software based automation system, suitable for residential or commercial application

Dean Roddey 61 Dec 13, 2022
Implement a program that computes the approximate grade level needed to comprehend some text.

Readability - CS50 Implement a program that computes the approximate grade level needed to comprehend some text. Reading Levels According to Scholasti

Vanessa Bauer 1 Oct 4, 2021
This is the laplight software for enabling flashlight support on a laptop/netbook. For the specification, see: https://github.com/LapLight/

By: Seanpm2001, Et; Al. Top README.md Read this article in a different language Sorted by: A-Z Sorting options unavailable ( af Afrikaans Afrikaans |

Sean P. Myrick V19.1.7.2 3 Oct 25, 2022
A C++ binding for the OpenGL API, generated using the gl.xml specification.

glbinding is a cross-platform C++ binding for the OpenGL API. glbinding leverages C++11 features like enum classes, lambdas, and variadic templates, i

CG Internals 758 Dec 13, 2022
Professional Firmware for the Creality Ender 3 v2 3D Printer

Professional Firmware for the Creality Ender 3 v2 3D Printer Please test this firmware and let us know if it misbehaves in any way. Volunteers are sta

Miguel Risco-Castillo 989 Jan 4, 2023
Professional Firmware for the Creality Ender 3 s1 3D Printer

Professional Firmware for the Creality Ender 3 s1 3D Printer Please test this firmware and let us know if it misbehaves in any way. Volunteers are sta

Miguel Risco-Castillo 28 Dec 18, 2022
Professional Firmware for the Creality Ender 3 V2/S1 Printers

Professional Firmware for the Creality Ender 3 V2/S1 Printers Universal RET6/RCT6 Ender 3 V2/S1 Edition Please test this firmware and let us know if i

Miguel Risco-Castillo 989 Jan 4, 2023
The Leap Motion cross-format, cross-platform declarative serialization library

Introduction to LeapSerial LeapSerial is a cross-format, declarative, serialization and deserialization library written and maintained by Leap Motion.

Leap Motion (Ultraleap) 15 Jan 17, 2022
this project is a function in c to take the next line of a file or a file descriptor. this is a project of 42 school.

Get Next Line of 42. Make with ❤︎ for Luiz Cezario ?? Index What's this Repo? List of Archives Technologies How to Run Find a Bug? Or somenthing need

Luiz lima cezario 7 Nov 28, 2022
Human-friendly HSL, reference implementation

HSLuv - Human-friendly HSL Explanation, demo, ports etc. The reference implementation is written in Haxe. Build system HSLuv uses Nix package manager.

HSLuv Project 1.2k Dec 30, 2022
null 313 Dec 31, 2022
(Simple String Format) is an syntax of format and a library for parse this.

SSFMT (Simple String Format) is an syntax of format and a library for parse this. SSFMT != {fmt} SSFMT is NOT an API/library for parse {fmt} syntax !

null 2 Jan 30, 2022
Quite OK Image (QOI) format encoder/decoder

This project implements encoding and decoding the "Quite OK Image" (QOI) format in the Ć programming language. Ć can be automatically translated to pu

Piotr Fusik 50 Dec 25, 2022
An efficient, small mobile key-value storage framework developed by WeChat. Works on Android, iOS, macOS, Windows, and POSIX.

中文版本请参看这里 MMKV is an efficient, small, easy-to-use mobile key-value storage framework used in the WeChat application. It's currently available on Andr

Tencent 15.4k Jan 8, 2023
Get Next Line is a project at 42. It is a function that reads a file and allows you to read a line ending with a newline character from a file descriptor

Get Next Line is a project at 42. It is a function that reads a file and allows you to read a line ending with a newline character from a file descriptor. When you call the function again on the same file, it grabs the next line

Mhamed Ajjig 5 Nov 15, 2022
Motion planner built upon Tesseract and Trajopt

motion_planner Motion planner built upon Tesseract and Trajopt The abb_example package is similar to the tesseract_ros_examples, but it contain more e

Mohamed Ahmed 8 Jan 18, 2022