RAF File Documentation

Summary

A RAF (Fujifilm RAW Image) file is the unprocessed data straight off a Fujifilm camera’s sensor, a digital negative from an X-series or GFX body. It begins with the ASCII marker FUJIFILMCCD-RAW and packs the raw sensor readout together with an embedded JPEG preview and EXIF metadata. Its MIME type is image/x-fuji-raf. On Windows, install the free Raw Image Extension to see thumbnails; edit a .raf in the free RawTherapee or darktable, then export to JPG or archival DNG.

Technical details

FeatureValue
Full nameFujifilm RAW Image (RAF)
File extension.raf
MIME typeimage/x-fuji-raf
Format typeProprietary camera raw (binary; embeds JPEG + TIFF/EXIF)
DeveloperFujifilm
IntroducedEarly 2000s (CCD era); current on X-series and GFX
Byte orderBig-endian (Motorola)
Magic stringFUJIFILMCCD-RAW at offset 0 (16 bytes)
Version field4 ASCII bytes at offset 0x10 (e.g. 0201)
Camera model32-byte string at offset 0x1C
Embedded previewFull-size JPEG (offset+length in the directory)
MetadataTIFF/EXIF: camera, lens, ISO, white balance, film simulation
Sensor dataRaw CFA (Bayer or X-Trans 6×6), typically 14-bit
Colour filter arrayX-Trans on many X-series (non-Bayer, needs X-Trans demosaicing)
Open standardNo (proprietary; undocumented sensor block)
Related extensions.cr2, .cr3, .nef, .arw, .dng, .tiff
SpecificationProprietary (Fujifilm); reverse-engineered by libopenraw/LibRaw
File signature (magic bytes)
46 55 4A 49 46 49 4C 4D 43 43 44 2D 52 41 57

Offset 0, 16 bytes. In ASCII this reads FUJIFILMCCD-RAW (15 characters plus a trailing space or padding byte). It is a unique, reliable identifier: no other common format begins this way. Immediately after it, at offset 0x10, come 4 ASCII bytes giving a format version such as 0201, then an 8-byte field and a 32-byte camera-model string at offset 0x1C. All multi-byte integers in the file that follows are big-endian.

What is a RAF file?

RAF is the raw image format written by Fujifilm digital cameras, from the early CCD-sensor models of the 2000s through today’s X-series and GFX mirrorless bodies. The name comes from “Fujifilm CCD-RAW”, and the file begins with exactly that idea: the ASCII string FUJIFILMCCD-RAW sits at byte 0. A raw file is the unprocessed readout of the camera’s image sensor, a digital negative. Unlike a JPEG, a RAF has not been demosaiced, white-balanced, sharpened or compressed into final pixels in-camera, so it keeps the sensor’s full tonal range and the latitude to recover highlights and shadows and to reset white balance after the shot.

Because RAF is proprietary and undocumented by Fujifilm, its structure is known mainly through reverse-engineering by projects such as libopenraw and LibRaw. What those show is a simple wrapper: a fixed header, a small directory of offsets, and three payloads — an embedded JPEG preview, a block of TIFF/EXIF metadata, and the raw sensor data itself. Everything below walks that layout field by field, then covers the one thing that makes Fujifilm raw different from every other brand: the X-Trans colour filter array.

The header: magic string, version and camera model

A RAF file opens with a fixed-size header that any parser can read without guessing. All multi-byte values in the file are big-endian (Motorola order).

offset  size  field
0x00     16   magic  "FUJIFILMCCD-RAW" (+ padding)
0x10      4   format version, ASCII, e.g. "0201"
0x14      8   camera-ID number, e.g. "FF389501"
0x1C     32   camera model string, null-padded (e.g. "X-T4")
0x3C     ..   directory: offsets/lengths of the sub-blocks

The 16-byte magic at offset 0x00 is the reliable signature. The 4 ASCII bytes at 0x10 are a format version such as 0201; different Fujifilm generations bump this. The 8 bytes at 0x14 are an internal camera-identifier number, and the 32-byte string at 0x1C spells out the model, which is how software can select the correct sensor geometry and colour matrix before it has decoded anything. After the fixed header comes a small directory of 32-bit offset/length pairs that point to the rest of the file.

The directory: locating the JPEG, metadata and raw blocks

Rather than storing its three payloads back to back, a RAF records where each one lives in a table of big-endian 32-bit offsets and lengths. The layout below is what the reverse-engineered format guides describe.

directory entries (each offset/length is 4 bytes, big-endian)
  JPEG image     offset + length   -> embedded full-size preview
  meta container offset + length   -> TIFF/EXIF-style records
  CFA (raw) data offset + length   -> sensor readout, often a TIFF box

Splitting the file this way means a reader can jump straight to whatever it needs. A file browser generating a thumbnail seeks to the JPEG offset and decodes only that; a metadata tool reads only the meta container; a raw developer reads the CFA block and ignores the rest. The meta container is itself a small tagged structure: a 4-byte record count followed by records of a 2-byte tag ID, a 2-byte size and the value, which is how Fujifilm stores white-balance coefficients and sensor parameters alongside the standard EXIF.

The embedded JPEG preview

Every RAF carries a full-resolution JPEG rendering of the shot, produced by the camera’s own processing engine with the selected film simulation baked in. This is the image you see on the rear screen and in the electronic viewfinder during playback, and it is what a thumbnail service extracts when a full raw decode would be too slow. It also carries the standard EXIF block (exposure, aperture, ISO, lens, timestamps, sometimes GPS). Because this preview is a finished, processed image, it is not the same data a raw developer works from: the developer bypasses it and reads the CFA block so it can apply its own demosaicing, white balance and tone curve. That separation is why a RAF thumbnail can look different from the raw once you open it in RawTherapee or Lightroom.

X-Trans: why Fujifilm raw needs special demosaicing

The sensor data in the CFA block is a single-channel mosaic: each photosite records one colour, filtered by a colour filter array, and software must interpolate the missing two channels at every pixel. Most cameras use the Bayer pattern, a 2×2 tile of red, two greens and blue. Many Fujifilm X-series bodies instead use X-Trans, a 6×6 tile with a less regular red/green/blue arrangement.

Colour filter arrayTile sizeNote
Bayer (most brands, Fuji GFX)2×2Regular RGGB; standard demosaicing
X-Trans (many Fuji X)6×6Irregular pattern; suppresses moiré, no OLPF

The 6×6 X-Trans layout scatters the colour sites so that the eye finds no regular grid, which lets Fujifilm omit the optical low-pass (anti-aliasing) filter and keep more detail while reducing colour moiré. The cost is that the mosaic is harder to reconstruct: a demosaicing algorithm written for the 2×2 Bayer grid cannot decode it correctly, and early converters that tried produced smeared, “wormy” foliage detail. This is why up-to-date, X-Trans-aware software (RawTherapee, darktable, Adobe Camera Raw, Capture One or Fujifilm’s own X RAW STUDIO) matters more for Fuji raw than for any other brand. The raw values are typically 14-bit per photosite, and newer bodies can store them losslessly compressed inside the CFA block.

RAF among the raw formats and the DNG question

Every camera maker wraps sensor data its own way: Canon has CR2/CR3, Nikon has NEF, Sony has ARW, and Fujifilm has RAF. They are not interchangeable, because each describes a specific sensor’s geometry and colour response; you cannot convert one brand’s raw into another’s. What they share is the raw idea, and the neutral meeting point is Adobe’s DNG, an openly documented raw container built on TIFF. Converting a RAF to DNG (with the free Adobe DNG Converter) keeps the raw sensor values while shedding Fujifilm’s proprietary wrapper, which is useful for long-term archiving and for software that lacks a RAF decoder. Many photographers keep the original RAF as the master and treat DNG or an exported TIFF/JPG as a derived copy, since raw editing is non-destructive: adjustments are stored as instructions, never written back into the RAF.

Frequently asked questions

Why does my Fuji RAF look smeared or “wormy”?

Because the file uses the X-Trans colour filter array, a 6×6 pattern that generic Bayer demosaicing cannot decode correctly. Older or non-Fuji-aware converters interpolate the wrong neighbours and turn fine foliage into worm-like artefacts. Open the RAF in current software that has X-Trans support (RawTherapee, darktable, Adobe Camera Raw, Capture One) and the detail resolves cleanly.

Why does the thumbnail look different from the opened raw?

The thumbnail is the camera’s embedded JPEG preview, already processed with a film simulation. When you open the RAF in a raw developer it ignores that preview and decodes the sensor data from scratch with its own default settings, so the starting image can look flatter or differently coloured until you develop it.

References