PicaJet

Reference Formats

RAW

An umbrella term for minimally processed sensor data a digital camera captures before demosaicing and color rendering, saved in dozens of mutually incompatible manufacturer-specific formats.

Extension

.raw

Full name

Camera RAW (generic term for minimally processed sensor image data)

Introduced

the concept dates to the earliest digital sensors of the 1990s; Adobe launched DNG as a standardization attempt on September 27, 2004

Vendor

no single vendor — every camera manufacturer defines its own proprietary variant; Adobe introduced DNG as an attempted open, unifying standard

What is inside the container

Nearly every RAW dialect stores the raw mosaic sensor readout (in whatever Bayer, X-Trans, or other color-filter-array pattern that camera uses), an embedded JPEG preview for fast thumbnailing, and a maker-notes metadata block of camera-specific settings — but there is no single specification behind "RAW." Formats like CR2, NEF, ARW, and ORF are TIFF/EP-derived, while newer ones like Canon's CR3 use an entirely different ISO-base-media container, so software support for "RAW" really means a long list of separately maintained, per-format and often per-camera-model parsers.

How to open it

Cross-vendor commercial Adobe Camera Raw / Lightroom Classic, updated per-camera as new models ship
Cross-vendor commercial Capture One supports a wide range of manufacturer RAW formats
Open source RawTherapee and darktable decode most camera RAW formats using open libraries
Underlying decode libraries dcraw and its actively maintained fork LibRaw are what many third-party raw tools build their decoding on

For archives

For long-term DAM archival, convert RAW masters to Adobe DNG (or retain the vendor RAW alongside a DNG copy). DNG is openly documented and ISO-standardized, and it embeds the same sensor data plus a full-size preview, which future-proofs the asset against a manufacturer eventually dropping support for an old proprietary format or discontinued camera model.

“RAW” is not a file format so much as a category: it describes any file that preserves a camera sensor’s near-unprocessed output rather than the demosaiced, white-balanced, gamma-corrected pixels a JPEG contains. Because demosaicing and color rendering are proprietary, competitively significant algorithms, every major manufacturer built its own container and its own maker-notes metadata scheme rather than adopting a shared one — Canon has CR2 and CR3, Nikon has NEF, Sony has ARW, Olympus/OM System has ORF, and Fujifilm, Panasonic, and others each have their own again. Adobe tried to address the resulting fragmentation by launching DNG (Digital Negative) in September 2004 as an open, TIFF/EP-based format that any camera or software vendor could adopt; some manufacturers, notably Leica, Pentax, and Ricoh, offer native DNG capture, but the large volume manufacturers have kept their own formats as the default.

This fragmentation is one of the most persistent headaches in DAM practice. A digital asset management system that wants to preview or search RAW files cannot rely on a single decoder — it needs a rendering engine (commercial SDKs, or open libraries like LibRaw) that tracks every manufacturer’s format and, critically, every new camera model, since maker-notes and sensor layouts change release to release. Most DAM platforms cannot natively preview RAW at all without such an engine bolted on, which is why many fall back to whatever small embedded JPEG preview the RAW file happens to carry — a workable stopgap for thumbnails, but not a substitute for actually being able to process the sensor data. The other recurring risk is longevity: a proprietary RAW format from a camera model discontinued a decade ago may eventually stop getting decoder updates, which is the core argument for normalizing archival masters to DNG.

Frequently asked

Is there a single RAW format a DAM can build one parser for?

No. RAW is an umbrella term; every camera manufacturer defines its own proprietary variant, so software support really means a long list of separately maintained, per-format and often per-camera-model parsers.

What should a DAM do to future-proof RAW archival masters?

Convert them to Adobe DNG, or retain the vendor RAW alongside a DNG copy; DNG is openly documented and ISO-standardized, which future-proofs the asset against a manufacturer eventually dropping support for an old proprietary format or camera model.

What does nearly every RAW file contain regardless of vendor?

Regardless of manufacturer, nearly every RAW file bundles three things: the raw mosaic sensor readout in the camera's color-filter-array pattern (Bayer, X-Trans, or similar), an embedded JPEG preview generated in-camera for quick viewing, and manufacturer-specific maker-notes metadata covering lens, exposure, and camera settings. This shared structure exists even though RAW has no single standardized container — Canon, Nikon, Sony, and others each define proprietary variants — so a DAM can lean on these common elements for consistent handling across vendors.

Are all RAW formats structurally similar?

No. Formats like CR2, NEF, ARW, and ORF are TIFF/EP-derived, while newer ones like Canon's CR3 use an entirely different ISO-base-media container, so they are not interchangeable at the container level.

What lets a DAM generate a fast thumbnail from a RAW file without a full decode?

Most RAW dialects embed a baseline JPEG preview that the camera renders at capture time, sized anywhere from a small thumbnail to a near-full-resolution image. A DAM can extract this embedded JPEG directly from the file container instead of running the raw color-filter-array data through demosaicing and color-matrix reconstruction, which is computationally expensive. That shortcut is what makes it practical to generate thumbnails and previews quickly across a library of thousands of RAW files without decoding each one from scratch.

What underlying libraries do many third-party RAW decoders build on?

Many third-party RAW decoders trace back to dcraw, an open-source command-line utility originally written to decode proprietary RAW structures across a wide range of camera vendors. Its actively maintained fork, LibRaw, turns that codebase into a library meant for embedding directly into other software — raw converters, photo editors, and DAM tools — rather than running as a standalone program. Building on dcraw/LibRaw lets a DAM support many camera-specific RAW variants without writing a separate parser for each one.

When did camera manufacturers start producing RAW files?

RAW capture goes back to the earliest digital sensor cameras of the 1990s — Kodak's DCS 100, released in 1991 as one of the first commercial digital SLRs, used an early proprietary raw format for unprocessed sensor data. Every manufacturer that followed defined its own variant rather than sharing a standard. Adobe tried to unify things in September 2004 with DNG, an open, ISO-standardized format, but most camera makers still ship proprietary RAW by default today.

What data does RAW capture that a JPEG from the same shot does not?

RAW preserves the minimally processed sensor data captured before the camera applies demosaicing, white balance, and color rendering — typically 12 to 14 bits of tonal information per pixel straight off the sensor's color-filter array. A JPEG from the same shot has already been demosaiced, color-corrected, compressed, and baked down to 8 bits, discarding that extra headroom permanently. That preserved data is what lets an editor recover blown highlights, shift white balance, or push exposure after the fact — adjustments a baked-in JPEG can't support.

Sources