OpenEXR moved from ILM's lab to open Academy governance

The shot

OpenEXR's own documentation states plainly where it came from: 'The format and library were originally developed at Industrial Light & Magic and first released as open source in 2003,' according to the project's about page. As retrieved on 16 September 2026, the same documentation states that 'OpenEXR is a project of the Academy Software Foundation,' the open-source umbrella body that, per the foundation's own about page, 'was founded in August 2018' by the Academy of Motion Picture Arts and Sciences following research by its Science and Technology Council. OpenEXR's governing repository describes the format's purpose as 'the professional-grade image storage format of the motion picture industry,' built to 'accurately and efficiently represent high-dynamic-range scene-linear image data and associated metadata.'

What the documents show

The documentation draws a line that trade coverage sometimes blurs: 'most image formats store images that are ready for display,' while OpenEXR stores scene-linear data that still needs processing before it looks right on a screen, a distinction that matters for anyone assuming any high-bit-depth file behaves the same way. The repository states OpenEXR is 'widely used in host application software where accuracy is critical, such as photorealistic rendering, texture access, image compositing, deep compositing, and DI,' and lists its priorities as 'robustness, reliability, security,' 'backwards compatibility, data longevity,' and 'performance,' a maintenance mandate consistent with foundation governance rather than one studio. Nothing here describes any video-generation vendor's export format; that claim would need the vendor's own documentation.

The workflow

For a pipeline, OpenEXR is the container a frame typically has to be written into, or converted into, before it can move between a renderer, a compositor, and a color pipeline like ACES without losing dynamic range. A studio decides which OpenEXR features a pipeline uses, such as multipart files, deep data, or a specific compression codec, and that choice is a pipeline-engineering decision, not something the format mandates. A generated frame arriving in a display-ready delivery format has to be brought into that convention deliberately, by the studio, before it fits a plate-based pipeline.

What the tool does not change

OpenEXR is a file format and library, not a rendering or color-science method; it does not decide how an image looks, only how it is stored and read back losslessly. Governance by a foundation does not guarantee every tool claiming EXR support implements every feature the same way, and that remains a compatibility question a supervisor still has to check. This is editorial: 'supports OpenEXR' is a narrower claim than it can sound.

• Which OpenEXR features, such as multipart data or a specific compression codec, does a given tool's export actually implement?
• Is a generated frame arriving in a display-ready format, or the scene-linear form a VFX pipeline expects?
• Does 'EXR support' in a vendor's documentation name a version or feature set, or use the term generically?

OpenEXR's own history, as its documentation tells it, runs from a single studio's internal tool to a foundation-governed standard; that lineage is a fact about image storage, and it says nothing on its own about what any generation tool produces before that storage step.