← Back to all sparks
O

OpenImageIO

DESIGN
Velocity5.0

Library and tools for reading, writing and processing images in visual effects pipelines

Every image reader is now assumed hostile, and the fuzzer proves it monthly

image-iofuzzinghardeningvfxoiiotoolbranch-eol
Current state
OpenImageIO ships on a monthly rhythm, releasing the current 3.1 line and the explicitly obsolete 3.0 line in tandem within minutes of each other. The dominant work is defensive: guarding pnm, jpeg-xl, dicom, cineon, dpx, fits and iff readers against corrupt or hostile files, with a CVE fixed in cineon bit-depth validation and a new limits:resolution attribute capping per-dimension image size against decompression bombs. libFuzzer-based fuzzing infrastructure for format readers landed in August.
Where it's heading
The project is institutionalizing the hardening rather than reacting to individual reports — building fuzzing into the repo, clarifying what qualifies as a vulnerability in its security policy, and adding a global attribute that lets applications set their own limits. Alongside that, oiiotool keeps gaining ergonomics, and genuinely new capability is being gated behind an explicit --experimental flag: the FLIP perceptual difference metric and a standalone GPU texture system prototype that deliberately does not touch the core library.
Prediction
With 3.2 stated as roughly two months out and 3.0 support ending shortly after, expect the next releases to focus on that transition while the fuzzing infrastructure keeps producing reader fixes.

Recent moves

  1. 9d ago

    3.1.16.0 adds fuzzing infrastructure and a decompression-bomb limit

    The clearest statement of the hardening turn: libFuzzer-based fuzzing infrastructure for format readers plus a limits:resolution global attribute capping per-dimension image size against decompression-bomb attacks. Also adds oiiotool thumbnail get/set and an experimental standalone GPU texture system prototype that leaves the core library untouched.

    View source ↗
  2. 9d ago

    3.0.21.0 fixes a cineon CVE and warns the branch is ending

    Backports CVE-2026-63638 — cineon bit depths now validated against libcineon's supported set before the vendored library crashes on them — plus dpx integer overflow guards. The notes state plainly that 3.2 is roughly two months out and 3.0 support will stop soon after.

    View source ↗
  3. 1mo ago

    3.1.15.0 widens deep pixel indices to int64 and hardens cineon

    Deep data handling moves merge_deep_pixels and sort() to int64_t pixel indices, which matters for the large deep images this library exists to handle. Cineon becomes more robust to invalid channel counts and bit depths, fixing a memory leak in init() along the way.

    View source ↗
  4. 1mo ago

    3.0.20.0 converts a recursive FITS reader to a bounded loop

    Fixes a stack overflow from recursive header-block reading on corrupt FITS files by converting it to an iterative loop with a 10000-header safety limit, plus an iff allocation bug on 16-bit RGBA. Textbook examples of the corrupt-file class this project keeps finding.

    View source ↗
  5. 1mo ago

    3.1.14.1 fixes a pystring auto-build break

    A patch that only matters if you rely on auto-building OpenColorIO's pystring dependency, which changed to v1.2.0. The notes explicitly tell unaffected users not to bother upgrading.

    View source ↗
  6. 1mo ago

    3.0.19.1 backports the pystring build fix

    The obsolete-branch twin of 3.1.14.1, carrying the same single auto-build fix and the same advice to skip it if unaffected.

    View source ↗