RAW files are routinely described as “digital negatives,” which is accurate as far as it goes — but the analogy quietly implies one exposure, one frame, one image. Open certain RAW files in a hex editor, or just notice how your camera behaves when you shoot in bracket mode, and that assumption starts to look shaky. A single file carrying two, three, or even a dozen distinct image records isn’t a bug or a curiosity; it’s an intentional consequence of how modern capture formats are structured.
Why RAW Files Are Containers, Not Simple Images
Most people picture a RAW file the way they picture a JPEG: one image record, a header, some metadata, done. The difference is structural. A JPEG encodes a single compressed image in a defined byte sequence; the format was designed around that assumption from the start. RAW formats, by contrast, are almost universally container formats — they wrap multiple data blocks, and nothing in the specification limits those blocks to a single rendered image.
Canon’s CR3 format, for example, uses the ISO Base Media File Format (ISOBMFF) — the same container backbone that underpins MP4 and HEIF. Within one CR3, you’ll routinely find a full-resolution sensor data block, a smaller embedded JPEG preview at roughly display resolution, and sometimes a secondary smaller thumbnail. Those are three discrete image records in a single file. Nikon’s NEF is built on a TIFF-like structure, which is itself a multi-image container spec; the IFD (Image File Directory) chain can point to multiple image sub-files. Sony ARW and Fujifilm RAF use similar multi-block layouts.
The preview image isn’t incidental. It exists because software needs something renderable while it decodes the sensor data, and because operating systems need a thumbnail without running a full RAW decode pipeline. Strip it out and file browsers go blank on import — which is one reason you occasionally see a “thumbnail mismatch” where the initial preview in an import dialog looks subtly different from what the RAW engine produces once it fully processes the file.
Bracketing, HDR, and Burst: When Extra Frames Live in One Container
Preview images are almost invisible to the shooter. The more surprising case is when multiple distinct exposures end up in a single file — something several camera systems now do deliberately.
Fujifilm’s in-camera HDR shooting mode, available on a number of current bodies, can write three bracketed exposures into a single RAF file. The camera fires the bracket sequence and then packages the frames together rather than writing three separate files to the card. From the file system’s perspective, you dropped one file; from the container’s perspective, there are three full-resolution image records inside it.
Some camera manufacturers implement similar behavior for bracketed focus stacking, storing each focal plane as a separate image block so that in-camera or desktop stacking software can find them without requiring a multi-file import operation. Whether a given body does this, and which RAF, CR3, NEF, or ARW variant it produces, depends on firmware and model — the container format permits it, but not every camera exploits the capability.
What this means practically:
- Importing with software that only reads the first image block will silently discard the others. Not every RAW importer iterates all IFDs or all ISOBMFF boxes.
- File size alone will tell you something is different — a single HDR bracket set in one file is proportionally larger than a single exposure in the same format.
- Batch renaming or culling tools that read basic metadata without parsing the full container may report incorrect frame counts.
DNG’s Multi-Image Provisions
Adobe’s DNG specification, now considerably more than a decade old, explicitly describes provisions for multi-image and dual-pixel data. DNG can carry a full-size “original raw image,” a separate “enhanced image” generated in-camera, and various proxy or preview sizes — all co-resident in the same file.
The dual-pixel use case is worth understanding separately. Phase-detection autofocus systems on many sensors read two sub-aperture images from split photodiodes on each pixel. Some DNG implementations preserve both sub-aperture images — a left-view and a right-view pixel array — in the same file. This is what enables depth estimation or computational refocus after capture on certain devices. The format doesn’t store “two photographs” in the narrative sense, but it stores two complete image planes derived from the same exposure, and those planes can be decoded and compared independently.
For shooters interested in where DNG sits as a standardization effort, our article on After Over 20 Years, DNG Becomes the Official RAW Standard covers the spec’s evolution and what the formalization of the standard means for long-term archival.
What Software Actually Does With Multiple Image Records
The behavior varies, and not in obvious ways.
Lightroom and Camera Raw read the primary sensor data block and ignore the embedded JPEG preview entirely for rendering purposes — they use their own demosaic pipeline. But they do read the embedded preview to speed up initial display before processing finishes. If the embedded preview was generated in-camera with a different color profile than Lightroom’s default, you’ll see a visible “pop” when Lightroom’s render replaces it. This is normal; it’s not a calibration failure.
Capture One handles the preview similarly. Some free viewers and OS-level thumbnail generators read only the embedded JPEG and never decode the raw sensor data at all, which means they’ll display whatever the camera’s own JPEG engine decided — not your preferred profile.
For multi-exposure containers (like the Fujifilm HDR case), import behavior breaks down sharply. A DAM (digital asset manager) that iterates IFD chains correctly may import three separate virtual copies; one that reads only the first IFD will show you one frame and no indication that two others exist. There is no universal signal in the file system that flags “this container has more than one frame.”
This isn’t a new problem — TIFF has supported multi-page images since the 1980s, and software fragmentation around multi-image TIFF handling has been documented for decades.
Checking What’s Actually Inside
If you suspect a file contains more than one image record, a few approaches give you concrete answers:
- ExifTool (
exiftool -v3 filename.raf) will print every IFD and embedded image block it finds, with byte offsets and dimensions for each. This is the fastest way to confirm whether your specific camera model is writing multiple frames. - dcraw (
dcraw -i -v) reports the primary image geometry and can reveal whether dual-pixel data is present in supported DNG variants. - Hex inspection of a TIFF-derived RAW (NEF, ARW) will show IFD chain pointers; each IFD that resolves to a distinct set of image dimensions is a distinct image record.
- File size comparison between a known single-frame and a supposed HDR file is the bluntest check — not definitive, but a good first flag.
The RAW vs JPEG: Compression Cost in Professional Workflows article covers the broader trade-offs of staying in RAW through an editing pipeline, which is worth reading alongside this if the multi-image container behavior is prompting a workflow review.
The practical next step here is concrete: pull one RAW file from your current camera system and run ExifTool with verbose output. If you’ve never done it, the output is clarifying in a way that format documentation rarely is — you’ll see the actual embedded dimensions, the byte ranges each image record occupies, and whether your camera writes one image block or three. That’s a more reliable way to understand your specific files than trusting the format name alone.