MPO File Documentation

Summary

An MPO (Multi-Picture Object) file is a single container that holds two or more complete JPEG images, most often a left-eye and right-eye pair captured for a stereoscopic 3D photo. It is defined by the CIPA DC-007 Multi-Picture Format standard (2009) and its MIME type is image/mpo. Because the file starts as an ordinary JPEG, most viewers already show the first image; the extra frame is indexed by an MPF marker further inside the file.

Technical details

FeatureValue
Full nameMulti-Picture Object (CIPA Multi-Picture Format)
File extension.mpo
MIME typeimage/mpo
Format typeContainer of two or more concatenated JPEG images (binary)
DeveloperCIPA (Camera & Imaging Products Association)
Introduced2009
StandardCIPA DC-007 (Multi-Picture Format); revised DC-X007:2012
Open standardYes
Base formatJPEG (JFIF/EXIF), one SOI-to-EOI stream per image
Index mechanismAPP2 segment tagged MPF\0 holding an EXIF-style MP Index IFD
Byte orderMP header declares little- or big-endian (like TIFF/EXIF)
Magic numberFF D8 FF (JPEG SOI, identical to a plain JPEG)
Typical imagesLeft-eye + right-eye stereo pair; also multi-angle / panorama sets
MetadataStandard EXIF per image (camera, lens, convergence, sometimes GPS)
Common sourcesNintendo 3DS, Fujifilm FinePix Real 3D, 3D-capable Panasonic/Sony cameras, LG Optimus 3D / HTC EVO 3D
Related extensions.jpg, .jpeg, .jps, .heic
Specificationcipa.jp/std/documents/e/DC-007_E.pdf
File signature (magic bytes)
FF D8 FF E1

Offset 0. An MPO opens with the JPEG Start-of-Image marker FF D8 followed by an application marker (commonly FF E1, the APP1/EXIF segment), so byte-for-byte it is indistinguishable from an ordinary JPEG at the start. What makes the file an MPO is a later FF E2 (APP2) segment whose payload begins with the ASCII tag MPF\0 (4D 50 46 00). That segment carries the MP Index, whose entries point to the byte offset of each additional embedded JPEG. Viewers that ignore the APP2 data simply display the first image.

What is an MPO file?

MPO stands for Multi-Picture Object, the file form of the CIPA Multi-Picture Format defined in the DC-007 standard published in 2009 by Japan’s Camera & Imaging Products Association. The idea is deliberately simple: store several complete JPEG images inside one file, and add a small index that says how many images there are, where each one begins, and what role it plays. The most common role pairing is stereoscopic 3D, where a left-eye image and a right-eye image are packed together so the pair can be shown with depth.

Because the first image is a normal JPEG placed at offset 0, an MPO is a valid JPEG file at its start. Any viewer that reads the leading image and ignores the trailing data shows the first frame and nothing more, which is why a copy renamed to .jpg opens everywhere and why thumbnails appear as usual. The additional image or images live further into the file and are found only through the MP index. The format reached consumers on the Nintendo 3DS camera, Fujifilm FinePix Real 3D cameras, several 3D-capable Panasonic and Sony models, and early 3D phones such as the LG Optimus 3D and HTC EVO 3D around 2010–2013.

Two JPEGs in one file: the concatenated layout

An MPO is not a new binary format wrapped around image data. It is literally two or more independent JPEG streams written back to back in a single file. Each stream is a complete JPEG: it starts with the Start-of-Image marker FF D8 and ends with the End-of-Image marker FF D9, with its own frame header, Huffman tables and entropy-coded scan in between.

FF D8 ...            SOI of image 1 (the "primary" / usually left eye)
  FF E1 ....         APP1  EXIF metadata for image 1
  FF E2 .. MPF\0 ..  APP2  the MP index (only in the primary image)
  ... scan data ...
FF D9                EOI of image 1
FF D8 ...            SOI of image 2 (usually right eye) begins here
  FF E1 ....         APP1  EXIF for image 2
  ... scan data ...
FF D9                EOI of image 2

The byte position where the second FF D8 appears is exactly the offset recorded in the primary image’s MP index. A decoder that supports MPO reads the index, seeks to that offset, and decodes the second stream as an ordinary JPEG. A decoder that does not support MPO stops at the first FF D9 and never sees the rest. Both behaviours are correct JPEG parsing, which is what makes the format backward compatible.

The MPF APP2 segment and the MP header

Everything that distinguishes an MPO from a plain JPEG sits in one APP2 marker segment in the primary image. The segment starts with the two-byte marker FF E2, a two-byte length, and then the format identifier MPF followed by a NUL byte (4D 50 46 00). All byte offsets that follow are measured from the byte immediately after this identifier, a position the specification calls the MP base offset.

Directly after the identifier is the MP Header. Its first field is a 4-byte endianness marker (the same II/MM convention TIFF and EXIF use) that tells the reader whether the numbers that follow are little- or big-endian. The next field is a 4-byte offset to the first Image File Directory (IFD); when the directory follows immediately, this value is 8. The whole index is structured exactly like an EXIF IFD tree, so tools that already parse EXIF can parse the MP index with the same machinery.

The MP Index IFD and the 16-byte MP entries

The primary image carries two directories: an MP Index IFD that describes the whole set, and an MP Attribute IFD that describes the individual image. The Index IFD holds a count of the images in the file and an MP Entry table with one fixed-size record per image.

MP Entry (16 bytes, one per image)
  uint32  Individual Image Attribute   // flags: type of image, dependent/representative
  uint32  Individual Image Size        // length in bytes of this image's JPEG stream
  uint32  Individual Image Data Offset // offset to this image's SOI, from the MP base
  uint16  Dependent Image 1 Entry No.  // index of a linked image (e.g. the other eye)
  uint16  Dependent Image 2 Entry No.  // second dependency, if any

The offset field is the key to locating any frame: add it to the MP base offset and you land on that image’s FF D8. The size field then gives the exact byte range to read. The attribute flags classify each image (for example, whether it is a baseline primary image, a large thumbnail, or one half of a disparity pair), and the two dependency indices let a stereo pair record that its members belong together. For the first entry, the offset is defined as 0, because the primary image is the file itself and needs no seek.

Stereoscopic pairs and disparity

In a 3D MPO the two images are the same scene photographed from two slightly separated viewpoints, mimicking the gap between human eyes. The horizontal shift between corresponding points in the two frames is the disparity, and it is disparity that the brain interprets as depth. Software that renders the 3D effect reads both JPEG streams, aligns them, and produces one of several outputs: a red/cyan anaglyph for cheap coloured glasses, a side-by-side or top/bottom frame for a 3D display, or an interlaced image for a lenticular or polarised screen. The convergence and separation used at capture are often recorded in the EXIF of each frame, which alignment tools can read to auto-correct vertical misregistration.

Not every MPO is stereoscopic. The same container also stores multi-angle sets and “panorama” or “best-shot” groups, where the attribute flags mark the images as a sequence rather than a disparity pair. The container structure is identical; only the per-image attribute bits and the number of entries change.

Locating and extracting a single frame

To pull one image out of an MPO by hand, a tool does exactly what the index describes: read the APP2 MPF segment, walk the MP Entry table, and for each entry copy Individual Image Size bytes starting at Individual Image Data Offset (plus the MP base). Each copied span is already a self-contained JPEG, so it can be written straight to a .jpg file with no re-encoding and no quality loss. The first frame is even simpler: everything from the initial FF D8 up to and including the first FF D9 is a complete JPEG, which is why the “rename a copy to .jpg” trick works — most readers stop at that first FF D9 anyway.

Relationship to JPS, JPEG and newer 3D formats

MPO keeps the two eyes as two full images. A related interchange format, JPS, instead packs both eyes side by side into a single JPEG frame, which more tools accept because it is just one image. Converting MPO to JPS therefore means compositing the two decoded frames into one canvas rather than splitting them apart. For plain sharing, extracting one frame gives an ordinary JPEG that any browser or editor opens. The 3D-camera and 3D-TV market faded after about 2013, and modern depth and multi-image capture has moved to other containers, so most MPO files today are legacy captures that people convert to a single JPEG.

Frequently asked questions

Why does my MPO only show one image?

Most viewers decode the first JPEG stream and stop at its End-of-Image marker, ignoring the APP2 MPF index that points to the second frame. That first stream is a complete, valid JPEG on its own, so the viewer has no reason to look further. A stereo-aware tool reads the MP index and decodes both streams.

Is an MPO really just a JPEG?

The first image in an MPO is a genuine JPEG at offset 0, so yes, at its start it is a JPEG. The difference is the extra concatenated JPEG stream (or streams) after it and the APP2 MPF marker that indexes them. Strip everything after the first FF D9 and you have a normal single-image JPEG.

References