Proposal: Extended Channel Pixel Types for OpenEXR

[ssh4net]

1. Objective

Extend OpenEXR channel typing from the current limited set to a general scalar type system, while preserving three guarantees:

1. Existing EXR files remain fully readable.
2. New EXR files with new scalar types are encoded so conforming older decoders reject them rather than silently misread them.
3. Updated libraries can provide explicit compatibility conversion for legacy applications, but only inside updated libraries that understand the new format revision.

This is not a proposal to redefine EXR as a generic image container. It is a proposal to extend the numeric storage model in a controlled way.

2. Proposed Channel Types

Instead of adding only a few isolated types, define a coherent scalar family:

• UINT8
• UINT16
• UINT32 (existing UINT)
• INT8
• INT16
• INT32
• HALF
• FLOAT
• DOUBLE

This is materially cleaner than an unsigned-only extension. Once 8-bit and 16-bit integers exist, signed integer support should be designed in immediately, otherwise the type system becomes asymmetric and the implementation work will be repeated later.

3. Non-Goals

This proposal does not define that integer channels are:

• normalized
• color-managed
• display-ready
• gamma-encoded
• raw-camera-interpreted
• video-range or full-range by default

The scalar type defines binary representation only. Interpretation remains separate.

4. Most Critical Requirement: Safe Behavior with Older Decoders

This is the central compatibility rule:

A decoder that does not understand the new scalar-type extension must fail deterministically before it allocates pixel buffers or attempts decode or transcode.

That must be guaranteed by the file format, not left to implementation quality.

4.1 Mandatory New File-Version Feature Flag

Introduce a new file-version feature bit for extended scalar channel types.

A file containing any of:

• UINT8
• UINT16
• INT8
• INT16
• INT32
• DOUBLE

must set this flag.

Recommended rule: the flag may also be set for future scalar-type extensions so the guard remains format-level, not enum-level.

This follows an existing OpenEXR compatibility pattern: version-field flags are already used to prevent older readers from misinterpreting files they cannot fully understand, for example the long-name extension.

4.2 Failure Behavior of Older Readers

Older readers that do not know this flag must reject the file as unsupported file version or unsupported feature, and must not proceed into header parse, channel setup, or pixel decode.

Deeper review of the OpenEXR codebase shows that the reference readers already fail closed in two relevant places:

• unknown version flags are rejected before header parse
• unknown channel pixel types are rejected during header validation rather than silently decoded

The new flag is still essential because it keeps the safety rule at the file-format level, mirrors the existing version-flag compatibility model, and avoids relying on every third-party reader independently validating channel enums correctly.

Without a required feature bit, non-conforming or custom decoders may:

• treat unknown channel type as corrupt header and continue partially
• map unknown type to an existing enum by accident
• compute wrong bytes per sample
• under-allocate or overrun buffers
• miscompute chunk strides
• trigger leaks during partial error unwinding
• decode garbage while appearing successful

This proposal requires that silent fallback by decoders that do not support the extension be forbidden by construction.

5. Decoder Safety Model

5.1 Old Decoders

Old decoders must not attempt compatibility conversion. They do not understand the new types, so the only safe behavior is early rejection.

5.2 Updated Decoders

Only a decoder that explicitly supports the new file-version feature may perform:

• raw decode of new types
• explicit conversion to legacy types for application compatibility

Compatibility conversion is therefore a feature of updated libraries, not of legacy decoders.

6. Library Compatibility for Legacy Applications

A new OpenEXR library may support old applications through explicit compatibility policy.

That means:

• the library understands the new file format
• the application may only understand old destination types
• the library performs requested conversion safely and deliberately

Possible policy modes:

• Error — reject unsupported channel types
• Hide — omit unsupported channels from the exposed image view
• Convert — convert unsupported on-disk channel types to application-supported destination types

The default for a modern low-level API should be Error, not implicit conversion.

The default for legacy convenience APIs may be Convert, but only in APIs already defined as conversion-oriented.

7. API Model: Separate Physical Type from Delivered Type

The API must not blur these concepts.

Each channel should expose at least:

• filePixelType — actual on-disk type
• requestedPixelType — destination type requested by caller, if any
• deliveredPixelType — actual type delivered after conversion

This avoids the dangerous model where the library lies about the stored type. Legacy code can still operate through converted buffers, but modern code can always inspect the true file representation.

8. Mandatory Conversion Specification

If new types are added, conversion semantics must be fully specified in the format and library contract. Otherwise the C path, C++ path, Python bindings, and codec-specific code will drift.

8.1 Integer to Integer

• exact if representable
• otherwise clamp to destination range
• never wrap
• never reinterpret sign bit

Examples:

• INT16 -> UINT8: clamp to [0, 255]
• UINT16 -> INT16: clamp to [0, 32767]
• INT32 -> INT16: clamp to [-32768, 32767]

8.2 Integer to Float

• numeric conversion only
• no implicit normalization
• exact where representable, otherwise nearest representable value

8.3 Float to Integer

• NaN converts to 0
• +inf clamps to destination maximum
• -inf clamps to destination minimum for signed integers, or 0 for unsigned integers
• finite values truncate toward zero
• then clamp to destination range

This preserves existing OpenEXR half/float -> uint conversion behavior for legacy conversion-oriented APIs.

8.4 Float Family Conversions

• HALF, FLOAT, and DOUBLE follow ordinary representational conversion
• NaN is preserved where supported
• infinity is preserved where supported
• overflow follows target format behavior

8.5 No Metadata-Driven Numeric Conversion

Optional metadata such as min and max, offset, or normalization hints must not alter these core conversion rules. That belongs to interpretation and display logic, not decode primitives.

9. Interpretation Metadata

To resolve the question of what integer values mean, keep meaning separate from storage.

Without metadata, integer channels are only integer channels.

Optional metadata may describe intended interpretation, for example:

• sampleInterpretation
  • generic
  • normalized
  • linear
  • nonlinear
  • depth
  • mask
  • label
  • raw_sensor
• valueRangeMin
• valueRangeMax
• offset
• blackLevel
• whiteLevel
• colorSpace
• transferFunction
• activeBits

These attributes are advisory. They never change decode validity.

Because this metadata is advisory rather than decode-critical, it does not need the new scalar-type feature bit. Older readers already preserve unknown attributes opaquely.

10. Implementation Requirements

10.1 Remove All Size Assumptions

The codebase must no longer assume:

• HALF == 2 bytes
• everything else equals 4 bytes

A single authoritative function or table must define byte size for every pixel type:

• UINT8 -> 1
• INT8 -> 1
• UINT16 -> 2
• INT16 -> 2
• HALF -> 2
• UINT32 -> 4
• INT32 -> 4
• FLOAT -> 4
• DOUBLE -> 8

All packing, unpacking, chunk iteration, slice validation, and buffer stride calculations must use that table.

10.2 Replace Trio-Specific Logic with Generic Dispatch

The current implementation often assumes a small hardcoded pixel-type matrix. That must be replaced by:

• centralized type traits
• centralized size lookup
• centralized conversion functions
• codec-independent scalar-type handling where possible

This matters for correctness and for long-term maintainability.

11. Compression Support

Compression support must be explicit per codec.

Before codec rollout, the generic container plumbing has to be generalized. The current C and C++ implementations still hardcode the three-type model in public enums, frame-buffer defaults, chunk sizing, and encode/decode pipeline negotiation. Therefore codec enablement must come after refactoring the common type and size infrastructure, not before it.

11.1 Rule

A codec either:

• supports a scalar type correctly, or
• rejects that scalar type with a clear error

It must never reinterpret a new type through an old path silently.

11.2 Rollout Strategy

The safest plan is staged support.

Phase 1

Allow new scalar types only for codecs validated to be element-size and type safe, for example:

• uncompressed
• RLE
• ZIP
• ZIPS
• possibly PIZ after audit

Phase 2

Add audited support for more specialized codecs:

• PXR24
• HTJ2K
• DWA

These are likely blockers because they often encode assumptions about type class, signedness, or float behavior.

11.3 PXR24 Note

PXR24 may not be sensible for every new scalar type. It is acceptable for the specification or library to reject unsupported type and codec combinations rather than forcing universal support.

12. Deep Data

Deep sample counts remain UINT32.

This should be stated explicitly. The scalar-type extension must not alter the semantics of deep sample count channels.

Deep sample values may be evaluated separately, but sample counts are fixed.

13. Required Safety Behavior During Decode

A robust design should also prescribe decoder behavior, not only file syntax.

13.1 Preflight Validation Before Allocation

Before allocating per-channel decode buffers, the decoder must validate:

• file-version feature bits
• channel type enum validity
• bytes per sample for all channel types
• chunk size consistency
• slice stride and bounds
• codec support for each channel type
• total buffer size overflow

Only after successful validation may allocation and decode proceed.

13.2 Fail Closed on Unsupported Types

If any channel type is unsupported in the current mode:

• low-level API: fail before decode
• compatibility API: fail, hide, or convert according to explicit policy

The decoder must never continue with guessed interpretation.

13.3 Memory Safety

The proposal should also recommend RAII and structured cleanup discipline in all new paths so that early errors in extended-type decode do not leak partially allocated state.

This is implementation guidance, but it is relevant because wrong bytes-per-sample handling is exactly the kind of issue that produces buffer corruption and cleanup bugs.

14. Backward Compatibility Matrix

Existing Files with Old Types

• readable by old libraries
• readable by new libraries

New Files with Extended Scalar Types

• rejected early by conforming old libraries due to the file-version feature bit
• readable by new libraries
• convertible by new libraries for legacy applications if policy allows

Old Applications on Top of a New Library

Possible through explicit compatibility conversion, for example:

• UINT8, UINT16, INT8, INT16, INT32 -> UINT32, FLOAT, or HALF where requested
• DOUBLE -> FLOAT or HALF where requested

But this is a property of the new library, not of old decoders.

15. Recommended Design Position

The strongest technical position is:

OpenEXR should generalize scalar channel typing rather than add isolated special cases. The extension should include signed integers from the beginning, because once 8-bit and 16-bit integer storage is admitted, signed and unsigned integer support belongs to the same architectural change. However, backward safety is more important than type breadth. Therefore, the format must introduce a mandatory new file-version feature flag that forces conforming older decoders to reject extended-type files before decode begins. Compatibility conversion is allowed only in updated libraries that understand the extension and can apply explicit policy safely.

16. Compatibility Limits for Historical Readers

The requirement for older readers to reject extended-type files must be understood as a format-level compatibility rule, not as a claim that already-shipped binaries can be fixed retroactively.

If a historical OpenEXR library is already deployed and the user has no access to its source code, its behavior cannot be changed. Therefore, the proposal cannot guarantee safe rejection for every old binary ever shipped. It can only guarantee that extended-type files are encoded in a way that conforming older readers are expected to reject before decode.

This means:

• files using extended scalar types must set a mandatory file-version feature flag
• the flag must live in an extension point that readers check before channel-type-dependent allocation or decode
• updated readers must reject files that use extended scalar types without this flag
• compatibility with closed-source or non-conforming historical binaries is necessarily best-effort only

In practice, historical readers fall into three categories:

1. Readers that validate unknown required file-version features early. These will reject extended-type files safely.
2. Readers that reject such files during early version or header validation, even if the error message is generic. This is still acceptable if failure occurs before channel decode.
3. Readers that ignore unknown required features or proceed far enough to mis-handle new channel types. These cannot be made safe without changing the binary.

The OpenEXR reference implementation is in categories 1 and 2 here, not category 3: current and historical releases already reject unknown required version flags, and the reference readers also reject invalid channel pixel types during header validation.

Accordingly, the proposal should make the following narrower and technically accurate claim:

“Files using extended scalar channel types must set a mandatory file-version feature flag that conforming readers check before decoding. Readers that do not support this feature must reject the file. This guarantees safe failure for conforming older implementations, but cannot retroactively correct historical binaries that ignore required feature flags or otherwise violate forward-compatibility rules.”

A direct consequence is that extended scalar types must not be introduced merely as additional pixelType enum values inside an otherwise old-format file. They must be guarded by a top-level required feature indicator encountered before channel parsing, allocation, and decode logic.

17. Concise RFC-Style Conclusion

OpenEXR is extended to support a generalized scalar channel type system consisting of unsigned integers, signed integers, and floating-point types, including UINT8, UINT16, INT8, INT16, INT32, and DOUBLE, in addition to existing UINT, HALF, and FLOAT. Files using any extended scalar type must set a new file-version feature flag so that decoders lacking support reject such files deterministically and before pixel decode in conforming implementations. Updated libraries may provide explicit compatibility conversion for legacy applications, but only after validating the new file feature and actual on-disk channel types. Scalar type defines numeric storage only; interpretation such as normalization, display intent, raw-sensor semantics, or color meaning remains optional metadata and is not implied by the type itself. Compatibility with non-conforming historical binaries remains best-effort only.

[cary-ilm]

Thanks for the detailed writeup. I'll respond in more detail as soon as I get a chance to read it more thoroughly. @peterhillman will have thoughts as well, he's suggested an approach to this extension in the past.

Some pseudo-code would be helpful to clarify the specifics.

Our concern in the past has been with improperly-written application code, especially use of the PixelType enum that fails to do the proper error checking. Such code would compile and run but introduce subtle bugs that would be hard to diagnose. Something like this, which implicitly encodes an assumption of only 3 pixel types:

        switch (type)
        {
            case UINT: xStride = sizeof (uint32_t); break;
            case HALF: xStride = sizeof (uint16_t); break;
            case FLOAT: xStride = sizeof (float); break;
            case NUM_PIXELTYPES:
                THROW (IEX_NAMESPACE::ArgExc, "Invalid pixel type.");
        }

Such code works now but would fail if NUM_PIXELTYPES is not 3. This code is incorrect but possibly widespread.

Again, the concern is not within the OpenEXR library, where we can fix the issues. The concern is existing user code in the wild that we have no control over. How much risk to stability are we willing to accept?

[ssh4net]

@cary-ilm
how about this:

2. Change the API section so it freezes the old enum

The proposal should explicitly say that the existing PixelType enum remains
the legacy contract:

enum PixelType
{
    UINT  = 0,
    HALF  = 1,
    FLOAT = 2,
    NUM_PIXELTYPES
};

New channel types should not be added by appending values to this enum in
place.

Instead, the updated API should use a separate extensible type, for example:

enum class ChannelSampleType : uint32_t
{
    UINT,
    HALF,
    FLOAT,
    UINT8,
    UINT16,
    INT8,
    INT16,
    INT32,
    DOUBLE
};

Legacy path:

LegacyInputFile openLegacy (const char* path)
{
    Header h = readHeader (path);

    if (h.hasFeature (EXTENDED_PIXEL_TYPES_FLAG))
    {
        throw InputExc (
            "File uses extended channel pixel types; "
            "use the extended API or an explicit compatibility mode.");
    }

    return LegacyInputFile (h);
}

Extended path:

ExtendedInputFile openExtended (const char* path, CompatibilityMode mode)
{
    Header h = readHeader (path);
    validateRequiredFeatures (h);

    for (auto& ch : h.channels ())
    {
        ChannelInfo info;
        info.filePixelType = readChannelSampleType (ch);

        if (!codecSupports (h.compression (), info.filePixelType))
            throw InputExc ("Unsupported compression/type combination.");

        if (mode == CompatibilityMode::Error &&
            !isLegacyPixelType (info.filePixelType))
            throw InputExc ("Extended channel type requires explicit conversion.");

        if (mode == CompatibilityMode::Convert)
        {
            info.requestedPixelType = chooseLegacyDestinationType (info);
            info.deliveredPixelType = info.requestedPixelType;
        }
    }

    return ExtendedInputFile (h, mode);
}

• extended-type files require a new feature bit
• conforming older readers reject them early
• the old PixelType enum stays frozen
• extended channel types are exposed through a new API, not by appending values
  to PixelType

[1div0]

INT64 and UINT64?

In order to match RISC-V Vector Extension Vector Element Types.?

[KevinJW]

For the record so my and other's slack messages don't get lost.

I asked if bfloat16 would be in or out of scope. I have no preference, I just observed it exists in C++23 and that there is hardware with native support for it.

I'll note that Peter hillman previously (Jan 2024) observed that PXR24 is kind of "bfloat24"

[1div0]

In order to make an extension future proof, let's learn from the past and define arbitrary sample size in bits as in Verilog.

just:// check:// https://github.com/1div0/Riscy-SoC

[cary-ilm]

We discussed this in several forums, including the last technical steering committee meeting. There are several concerns beyond backwards compatibility.

The writeup doesn’t really describe the proposed new workflow with these channel types. Exactly what problem are you solving? How would this data be used in practice? What workflow does this replace, and how much better would this be? Are there other simpler solutions that could accomplish the same objectives? If we make such a fundamental and potentially disruptive change in the format, we should be crystal clear on exactly why this puts the industry in a better place.

One concern is the roll-out process. Some pseudo-code would help, but from reading the proposal, it would likely force application developers to do a lot of work to fully support the new channel types. Backwards compatibility means existing applications will compile fine as is, which is good, except without substantial work on the part of application maintainers/developers, an application doesn’t pick up the new features. For the community at large, this likely means a landscape where some applications support the new types and others don’t. This places a burden not just us as maintainers of the library but on every application developer.

Note that this is much more significant than adding a new compression type. For example, we introduced the htj2k codec in OpenEXR v3.4. You can tell if an application supports the new codec simply by what OpenEXR version it’s built against: if built against v3.4+, it supports htj2k, otherwise it doesn’t. With new channel types, an application would support the new data if it’s built against the new version and the application code has been upgraded.

This is not necessarily a deal-breaker, but it needs to be weighed against the benefits.

And regarding bfloat16, I asked around a while ago and couldn't find anyone with a specific use case for this. bfloat16 may be popular in ML applications, but does anyone have a specific need for images with bfloat16 pixel data? I'm not categorically opposed to such extensions, but given the role that OpenEXR currently serves in the industry, we place a high value on stability, and we should only cause disruption when there's a really good case for the benefit it brings.

[ssh4net]

My idea to have a modern file format (and container) that can cover all VFX/CG/Research use cases. And instead of multiply, including legacy file formats, has a single file format that support modern encoders.

VFX industry is not alone, it consume a data from 3D/4D scanning, photography, etc. And capture studios might be a big part of production, that need to deal with VFX/3DCG requirements but work with scientific and survey applications where fixed precision data types are often be a preferred.

At the end of production full float vector or scalar textures are fine, but to make and work with them fixed precision uint textures and data for them can be more verbose.

OpenEXR already support uint32 and half. So adding uint16 and uint8 is not against fixed precision support. And already available compressions allow to remove PNG from artist pipelines.

Double type, are questionable but such data can be happen from scientific applications. And it can't be count as a rare data type.

As for bfloat16 that's a question. Yes it used a lot in Ai researches but how often it used for 2D data structures?

[lgritz]

Devil's advocate from me. I'm not yet saying I endorse any of these.

The main case for expanding data types is to reduce the number of image container types in a studio, and to reduce user errors resulting from the fact that no container format supports the full cross-product of data types -- for example, if you want uint16, you must write a tiff (say), but half can go in exr. Moving from one container to another might force a data type change, maybe even a change that takes more room needlessly or that loses precision inadvertently. In practice, I deal quite frequently with errors of incorrect container choice by users who don't understand the fine points of which file formats are most appropriate for which use cases of images, and the pros and cons of moving data from one format to another.

It's unrealistic to say "always use floating point data", some things come to you as uint8 or uint16 or some applications demand it. OpenEXR has a lot of properties that are nicer than other image container formats, such as arbitrary name/value metadata, named channels, etc., so the desire is very understandable to say "why can't I use OpenEXR for all my images?"

(Aside: I don't support ALL unification of container types. There is a point of diminishing returns. For example, I do not advocate a single container type for 2D images and videos. But if we had virtually no need for TIFF files at SPI and I could tell people to use exr for those cases without a big downside, I would be very happy.)

The case against is also something I agree with: Keeping OpenEXR narrowly focused, easy to maintain, don't let it be a "kitchen sink" kind of mess like TIFF that tries to be everything to everyone.

There's also a faction with a philosophical view (that I'm neutral on myself, but to some people it's a very strong preference) that it's called "exr" because it's extended range HDR data, so allowing LDR normalized value types is counter to the always-HDR workflow that openexr was trying to promote by existing.

(Note to Vlad: openexr has uint32, but it's not meant or ever used for intensity values; it is exclusively for ID tokens that, for example, identify which object is in each pixel.)

Now then, I've spent 18 years now developing OIIO, whose original purpose was to hide from the apps/developers the fact that you are juggling different file formats with different overlapping subsets of capability, and provide a single API that decouples the app-side data type from what can be stored in any particular file format. So in a sense I've already solved this problem. (But with my studio hat on, I return to how much simpler things would be for us if we could use one container type for all our files.)

OIIO needs to handle quite a few pixel data types, but in practice I've found that the only ones that are encountered with regularity are uint8, uint16, half, and float. Most places in OIIO will merely convert the other types to and from these at the per-file-format handling level (with float always available as a lingua franca) and rarely do the internals directly support more rare types like (signed) int16 for OIIO's image processing functionality, for example. I don't recall every getting a serious request for bfloat16.

Maybe if we add other pixel type to OpenEXR, I would recommend a similar incremental approach where we add the one or two that people really need now and see if more are ever needed, rather than try to implement the full complexity of everything up front.

I am not convinced that the compatibility issue is difficult. Here's how I would do it:

File format + library

• For the file format itself, we can make a new thing in the header that will let old readers recognize it's not a file it can open (like we did when we introduced new concepts like "parts", "deep", "long channel names", etc). So old versions of the library are fine, they will only write old style files and only read old style files.
• Just like those other features we added in the past, new libraries can write "old style" files when the new feature (data types) aren't being used, so it's "forward compatible" as long as they use the old data types.

App + API

• The app reads scanlines or tiles by passing a "Slice" describing their buffer, and that already has a data type in it (HALF, FLOAT, UINT) and I believe that the OpenEXR library automatically converts to and from the buffer data type if the data type in the file differs. Right? So that will continue to work. Old apps requesting or presenting only one of the 3 data types they know about can simply have the new data types converted to them without their ever needing to know.
• Newly modified apps can change the Slice they pass to request sending or receiving new data types as well. If they even care. If not, they get the automatic translation to/from the old types they already know about.

What am I missing? Why is it not this straightforward?

[peterhillman]

I'm strongly against adding support for integer types any time soon, most particularly due to color management concerns. Currently, there is no widespread reliable method for encoding what colorspace an OpenEXR image is in, which is a minor problem: at least you can assume images are scene linear, so the only unknown is the chromaticities. In many cases, images can be processed correctly without knowing the chromaticities. With non-linear data, the transfer function ("gamma") is also unknown, which is far more problematic. Adding integer support now will cause a lot of badly encoded images, broken results, and ad hoc metadata approaches, causing headaches for developers and confusion for users, because there's no common approach to colorspace encoding.

The Color Interop Forum OpenEXR Management attribute would go a long way to creating a standard for OpenEXR images, as well as an expectation that writers will tag colorspaces and readers will interpret the attribute and color manage accordingly. Only when that is widely adopted for existing linear OpenEXRs would it be safe to consider supporting pixel types which will be used to encode non-linear data, because there would be some guarantee that the metadata will accurately reflect the encoding and be interpreted correctly by the reader. (And it may also be the Color Interop attribute would be a sensible single alternative to the proposed set of attributes for describing data encoding of integer image channels)

Even then, I don't think it's wise to add integer types. To me, the OpenEXR standard's single greatest feature is that it does not support integer encoded images. All image data is float encoded, supporting values below 0 and above 1, and the standard says image data is scene-linear. It does that one thing really well (there are a bunch of ways of encoding images, but all color data is scene-linear floating point). And because it only does that thing, it's much easier to understand what OpenEXR images are for, and why and where to use them.
Adding integer types, with banding and clipping and all the other defects of integer images, is going to make things very hard for users, as well as application developers, even if the images are color managed correctly. Users will need to understand which pixel type is most appropriate, what types are supported by which tools, and what will happen to their data downstream.

I'm still struggling to understand exactly why integer types would be useful: I understand that hypothetically if you absolutely need to encode integer data it would be nice to store it in an OpenEXR, but some more detailed examples of where it would be necessary to use integer data over float/half float would help to make a case for the format - or metrics about performance/storage gains by using a integer instead of half float.

I generally haven't run into the problem that I need integer data and can't store it in OpenEXR, much more likely the opposite problem: I can't use linear data because OpenEXR isn't supported by the software reading the image. That means I have to use a different file format, therefore I need to use integer data. Adding integer types to OpenEXR won't solve any problems there. (Indeed, this just came up today: a tool which could easily handle HDR data internally actually can't because it only supports integer file formats)

@lgritz I agree that code that always reads images as HALF or FLOAT buffers will continue to work safely.
The problem is likely in code that always reads images in its native type, either because it is going to write a channel back out again unchanged, or because it has special handling of different types. That code could well have patterns like Cary's example, where the unhandled enum value causes data to be written to a buffer which isn't large enough, or to an uninitialized pointer.

Another pattern I've used is to allocate 4*width*height*numChannels bytes of memory, then set up an Imf::Slice with the input type as the channel type, and an x stride of four bytes. (This allows lazy in-place casting of half to float and back) With double precision types possible, that would read the final four bytes of the OpenEXR beyond the end of allocated memory, which could result in arbitrary code execution vulnerabilties. That's a particularly worrying possibility, so something that should be considered even if it is an unusual case.

[ssh4net]

half/float can be gamma or log encoded.
uint32 even if it was designed for IDs do not disabled for arbitrary inputs, so I can send someone uint32 exr image from MV sensor.

[peterhillman]

The OpenEXR standard says that data is scene linear: each value is linear relative to the amount of light in the depicted scene so you cannot store log encoded values in standard OpenEXR images.

Of course the library doesn't stop you storing log data, or images in uint32 type: it can't. You can also store 1 second of audio in a two channel 48,000 x 1 pixel OpenEXR. Both are non-standard OpenEXR files. If you do either of those things you cannot expect anything else to interpret your files correctly.
If you do send somebody a file where the image data is stored in uint32, don't be surprised if they can't open it as you want - it's "your fault" for not following the standard, not "their fault" for failing to anticipate you might have taken a nonstandard approach.

Right now we are in a position where the bulk of images are in scene linear, and the uint32 type is used only (and rarely) for encoding object IDs and similar information, not images.

I still don't have a clear understanding of why it would be advantageous to store log images in OpenEXR at all. I've seen cases where that happened due to misunderstandings or user errors. "Make it easier for people to do things badly" doesn't seem a compelling reason to extend the standard to non-linear images and encoding schemes, given the complexity and confusion it would create for everyone.

[ssh4net]

When I open image folder in viewer app I also think this will be my vacation photos. When I open project folder, I will think it will be project files in desired encodings and desired color spaces. When I open arbitrary folder I might think anything I want, but reality can be different.
When OpenEXR was adopted internally only in a couple of big VFX studios, designed that format, everything was simple. They even was not needed any meta information about images, because everything was in their control.
Now when OpenEXR have a thousands ways to appears (even some 360 cameras plugins can generate OpenEXR), meta information becomes critical. Because DATA can be arbitrary. SDR saved as uint32, Color Graded, gamma encoded imagery... sound... if someone wish.

OpenEXR using far beyond VFX and 3DCG. For new users OpenEXR common and fast versatile image file format.

Btw, storing image in half precision similar to storing gamma encoded integers. So idea about "linearness" was fair. And storing gamma encoded images in half is a direct way to gift a posterization or bandings.