What is an RAF file?

RAF is a container: a wrapper that holds streams encoded by something else. It stores a grid of pixels, so enlarging it past its own resolution softens it. It is used for photography and editing.

The extension is .raf, and the full name is Fujifilm Raw. Both matter less than what the file can hold, which is what the rest of this page is about.

Fujifilm published it in 2000. It comes out of Fujifilm X-series and GFX bodies bodies.

Age is worth knowing here for one practical reason: the older a format is, the more programs have had time to learn it.

Reading it outside the vendor’s own software depends on work done by other people, usually by inspection rather than by documentation. That mostly works and occasionally does not, which is the reason to convert anything you intend to keep.

RAF stores its content exactly. Saving it again changes nothing, so it can be opened, edited and re-saved as often as you like without accumulating damage — which is what makes it a working format rather than a delivery one.

RAF has nowhere to record transparency. Anything transparent in the source is filled with a solid colour on the way in — white, unless something chooses otherwise.

Up to 14 bits per channel. It can work in RGB.

More than eight bits per channel is what stops a gradient from stepping when it is edited, which is why it matters in a working file and rarely in a finished one.

Adobe Lightroom, Capture One and darktable read it, and so do most programs of the same kind.

If a file will not open, the format is rarely the problem — it is more often that the program predates it. Converting to something older is the reliable way past that, and it is what the rest of this site is for.

No browser reads it.

That is the single most common reason to convert it: not that the format is bad, but that the place you want to show the file cannot read it.

RAF can hold EXIF, XMP and GPS coordinates.

The GPS coordinates are the field worth thinking about before sending a file anywhere: they say where the photograph was taken, and almost nothing warns you that they are still in there.

RAF is meant to be opened and changed. Keep the file in this format for as long as the work is going on, and export from it whenever a finished copy is needed.

The recurring complaints: programs often show an embedded preview rather than the real data and support outside its home ground is uneven.

None of these is a reason to avoid the format. They are the things worth knowing before you are surprised by one, which is a different claim and a more useful one.

RAF is what Fujifilm cameras write in raw — the X series, the GFX medium format bodies, and the older FinePix models. Like every manufacturer raw it holds the sensor readings before any interpretation, and unlike every other manufacturer raw, the sensor underneath is not arranged the way the rest of the industry arranges one.

That is not a marketing distinction. It changes what software has to do with the file, and it is the reason RAF has a reputation for rendering inconsistently across programs when ARW and NEF do not.

Essentially every digital camera uses a Bayer filter: a repeating two-by-two block of red, green, green and blue in front of the sensor. Demosaicing algorithms have been built around that pattern for thirty years and are extremely well optimised for it.

Fujifilm’s X-Trans uses a six-by-six pattern instead, with a more irregular arrangement of the same three colours. The stated goal was to suppress the moiré that the regular Bayer grid produces on fine repeating detail, which let Fujifilm omit the optical low-pass filter that slightly softens most sensors. The trade is that no existing demosaicing code applied, and every program had to write new code for one manufacturer.

For years Fujifilm photographers reported that fine foliage rendered oddly in Adobe software — leaves and grass turning into smeared, painterly blobs at the pixel level, which the community named the watercolour effect. It did not appear in Capture One or in Fujifilm’s own converter.

It was a demosaicing problem, not a sensor problem: Adobe’s handling of the X-Trans pattern was doing badly with high-frequency organic detail. Adobe improved it substantially over successive versions and the complaint has largely receded, but it is why a great many Fujifilm photographers use a different converter out of habit, and why the same RAF can still look meaningfully different between programs.

Because X-Trans demands its own code path, software that reads ARW and NEF competently sometimes handles RAF poorly or not at all. Smaller viewers, older editors and some open-source pipelines either lack support or produce visibly worse results than the same tool gives a Bayer file.

The practical advice follows: if an RAF looks wrong rather than merely unprocessed, try a second program before concluding anything about the file. A rendering difference between converters is normal here in a way it is not for other raw formats.

Fujifilm’s film simulations — Velvia, Astia, Classic Chrome, Acros — are the main reason many people buy these cameras. They are applied when the camera produces a JPG, and they are recorded in the RAF as a setting rather than baked into the sensor data.

So an RAF opened in Fujifilm’s own software or in Capture One shows the simulation you chose; opened in something that ignores the tag it shows a flat, neutral conversion and photographers conclude the file is wrong. It is not — the interpretation simply has not been applied. The embedded preview will show the intended look even when the converter does not.

Recent Fujifilm bodies offer three settings. Uncompressed is the largest and has no advantage beyond compatibility with older software. Lossless compressed produces an identical image at roughly half the size and is the sensible default. Lossy compressed is smaller again and discards data, which is worth avoiding unless card space is the binding constraint.

As with Sony, the newest option tends to be the one older software fails to read, so a file that will not open in an established program while another from the same camera does is usually a compression-setting difference rather than damage.

Every RAF embeds a full-size JPG preview with the film simulation and the camera’s processing applied. It is what a file browser shows as a thumbnail, and it is why the image sometimes appears to change as an editor finishes loading — the preview is replaced by the program’s own conversion.

It is also a genuine escape hatch. If a camera is too new for your software, extracting the embedded JPG gives a usable full-resolution image with the look you chose, while the raw waits for support. It carries none of the editing latitude, but it is a photograph.

Camera model and serial number, lens, focal length, aperture, shutter speed, ISO, the exact date and time, the film simulation, and the dynamic range setting. Location if the camera was paired with a phone.

Little of this survives a conversion to JPG or PNG in the way people expect. The exposure fields usually carry over and the location may or may not depending on the tool, which is worth deciding deliberately before publishing rather than discovering afterwards.

To share or print, convert to JPG at high quality. For further work outside a raw editor, or where every pixel must survive, PNG or TIFF. If the film simulation is the look you want, convert from software that applies it — otherwise the result will be the flat interpretation rather than the photograph you composed.

Keep the RAF regardless. The converted file has the white balance, the tone curve and the simulation baked in permanently, and none of those choices can be revisited afterwards. The raw file is the only version that still holds all of them open.