Potential projects for the Google Summer of Code or beyond.

Protobuf-based Fuzz Test

Write a “structure-aware” fuzz test for oss-fuzz using Protocol Buffers, Google’s language-neutral, platform-neutral, extensible mechanism for serializing structured data.

The standard oss-fuzz fuzzer throws random seeds of raw bytes at a program, verifying that it properly rejects invalid and potentially malicious data. However, OpenEXR handles complex, layered image data. Raw bytes often result in "invalid file" errors immediately, never reaching the deep logic of the library. By using Protobuf, a fuzzer can define the "grammar" of an EXR file, and thus ensure it more efficiently generates syntactically correct input that validates the library’s internal code.

You’ll write a .proto file that defines a message that mirrors the EXR header, channels, and attribute types, then serializes it into an in-memory OpenEXR file. In pseudo-code:

#include "openexr_fuzz.pb.h"

#include "libprotobuf-mutator/src/libfuzzer/libfuzzer_macro.h"
#include <ImfInputFile.h>
#include <ImfMemFile.h>

DEFINE_PROTO_FUZZER(const ExrFuzzInput& input) {
    std::string exr_data = SerializeToExrFormat(input);
    try {
        Imf::StdISStream stream;
        stream.str(exr_data);
        Imf::InputFile file(stream);
    } catch (...) {
        // We expect errors, we just don't want crashes (Segfaults, OOMs)
    }
}

You’ll then extend the oss-fuzz build.sh to compile it using protoc and link against libprotobuf-mutator.

Explore Other Compression Schemes.

OpenEXR currently supports lossless compression through zlib, but other more modern compression schemes exist. We would like to explore adding additional options for compressing with other utilities, such was Zstandard. To do this properly, we also need to assemble a standard set of images to use as benchmarks, and also develop some basic performance metrics in order to compare compression/decompression time across different options.

Performance Metric Suite

OpenEXR needs a mechanism for quantifying read/write and compress/decompress times.

A Fast Header Read

Extend the OpenEXR API with a way to read just the header attributes you request, and nothing else, for efficiency when applications need only the header information but no pixel data.

Add a Part Type That is Only Metadata

An image part that holds only metada with no pixel data could be useful for managing metadata in motion picture pipelines.

Add Support for Sorting of Attributes

Currently, attributes are written and read in alphabetical order in the file, and stored alphabetically internally.
But sometimes it would be convenient to organize and present them in the API, or GUI's, in a logical, non-alphabetical order.
The solution needs some investigation, but it might involve changing the internal attribute storage mechanism, or leaving the internal representation alone and adding an "order" attribute to store the preferred order.

Add a New Spectral Attribute Type

Follow up on Alban Fichet's spectral image storage presentation by implementing a custom attribute to hold the spectra: https://hal.inria.fr/hal-03252797