Transloadit

What is JPEG XT?

JPEG XT, standardized as ISO/IEC 18477, extends base JPEG with higher precision, HDR, floating-point, lossless, and alpha-channel coding. Its streams retain a base image for older JPEG decoders.

Base JPEG plus extension boxes
JPEG XT decoder
HDR, high-bit-depth, lossless, or alpha result
A legacy decoder stops at the base image; a JPEG XT decoder also reads the extension data.

How JPEG XT works

JPEG XT is layered on top of legacy JPEG. A file holds an ordinary JPEG image, the base layer, plus extension data that an XT decoder combines with the decoded base to reconstruct the richer picture. The thorfdbg/libjpeg codec, which the JPEG committee lists among JPEG XT implementations, carries that extension data as boxes inside APP11 application marker segments, and the JPEG standard reserves application segments for application use, which is how existing decoders can read the file without understanding the extension. For HDR content the base is a low-dynamic-range rendering: that encoder tone-maps the HDR input by default and, for some profiles, accepts a separately supplied image. The standard is split into parts. Part 1 restates the JPEG core as it is commonly used, Part 2 codes HDR images with a legacy text-based encoding for its metadata, Part 3 defines the box-based file format, Part 6 adds 9- to 16-bit integer samples, Part 7 floating-point HDR samples, Part 8 lossless and near-lossless coding, and Part 9 alpha channels. Support therefore has to be stated per part, and for Part 7 per profile, not as a single yes-or-no flag.

Key facts

  1. A file that opens in an ordinary viewer proves only that the base JPEG is intact. The HDR, higher-precision, lossless, or alpha data travels in application marker segments (APP11 in the thorfdbg/libjpeg codec) that a legacy decoder does not interpret, so confirm it with a decoder for the relevant JPEG XT part.
  2. JPEG XT support is not one capability. Part 6 covers 9- to 16-bit integer samples, Part 7 floating-point HDR samples, Part 8 lossless and near-lossless coding, and Part 9 alpha channels, while Part 1 only restates the JPEG core in common use. Part 7 is not the only HDR part: Part 2 is also an HDR part, with a legacy text-based encoding for its metadata. Ask which parts, and for Part 7 which profile, a tool reads and writes: the JPEG committee’s own software list includes one codec compliant only with Part 7 Profile B and another only with Part 2.
  3. Rewriting a file with JPEG-only tooling can drop the extension data without an error. libjpeg-turbo’s jpegtran, for example, by default copies only comment markers and discards other metadata; -copy all is needed to keep all extra markers. Keeping the markers does not prove the extension still decodes: thorfdbg/libjpeg stores a checksum of the base JPEG stream when it writes JPEG XT files and rejects extension data whose dimensions differ from the base image, so compare XT-decoded output before and after any rewrite. A decode and re-encode through a legacy codec starts from the base image alone.
  4. JPEG XT is not JPEG XL. JPEG XT (ISO/IEC 18477) keeps the file readable by legacy JPEG decoders. JPEG XL (ISO/IEC 18181) is a separate coding system whose bridge to legacy JPEG is lossless transcoding of an existing JPEG file to JPEG XL and back to the identical JPEG file.

When JPEG XT matters

JPEG XT matters when one file has to open in ordinary JPEG software and also carry HDR, higher-bit-depth, lossless, or alpha data for XT-aware software. Legacy decoders show only the base image, so the extra data has to be checked with a decoder that implements the relevant part of the standard.

Sources

Turn media knowledge into a working pipeline

Connect uploads, processing, AI, storage, and delivery through one declarative API — with the encoding stack, scaling, and format churn handled for you.

Try Transloadit for free