Convert RAF to TIFF

Almost every digital sensor puts a Bayer filter over the photosites: a repeating 2 by 2 tile of red, green, green and blue. Demosaicing algorithms have been refined against that arrangement for twenty-five years and they are extremely good. Fujifilm’s X-Trans sensors use a 6 by 6 pattern instead, designed to break up the regularity that produces moiré and to let the camera do without an anti-aliasing filter.

The consequence is that reconstructing colour from an X-Trans file needs different maths, and converters that approximated it produced the smearing and worm-like texture in foliage that Fujifilm forums have argued about for a decade. Support is much better now than it was, but the point stands for this page: the rendering inside the RAF was made by the processor that was designed around that array. On any other make, extracting the preview is a compromise. On a Fujifilm file it is a defensible choice.

Whatever simulation was selected is applied before the preview is written: Provia, Velvia, Astia, Classic Chrome, Classic Negative, Eterna, Acros or Monochrome, along with the grain, colour chrome and tone curve settings that go with them. The TIFF holds the result exactly.

For a photographer who set the camera up deliberately, that is the whole point — the file you hand to the lab looks like what you saw on the back of the camera, with no risk of a raw developer applying a neutral profile and losing the look. It is also irreversible: there is no undo, and a frame shot in Acros will not give its colour back, because the colour is in the sensor data and the sensor data is not what was extracted. Shoot the simulation you mean if this is the route you intend to use.

An RAF opens with the ASCII string "FUJIFILM", followed by Fujifilm’s own arrangement of offsets and blocks. It is not built on TIFF the way CR2, NEF, ARW, ORF and DNG are, and it is not an ISO base media container the way CR3 is. It is its own thing.

That is exactly why this converter works by scanning the file for embedded JPEGs and keeping the largest one above 640 by 480, rather than by walking a directory of tags. A format-aware parser would need three separate implementations to cover the seven raw formats here; a scan covers all of them with one, and an implementation that handles every format is worth more than one that is elegant about five.

Uncompressed at four bytes a pixel. A 26-megapixel X-T3, X-T4, X-S20 or X-Pro3 frame at 6,240 by 4,160 comes to about 104 MB. A 40-megapixel X-T5 or X-H2 at 7,728 by 5,152 comes to about 159 MB. A 102-megapixel GFX 100 series frame at 11,648 by 8,736 comes to roughly 407 MB.

That last figure is worth treating as a warning rather than a statistic. A 407 MB single image is beyond most upload forms, awkward in most email systems, and slow in any program that loads the whole file into memory. Setting a maximum width during the conversion is the only lever available, because there is no compression setting to reach for — halving the width quarters the file.

TIFF is unusual among image formats in what it permits: multiple pages in one file, layers, tiles, several compression schemes, colour models including CMYK and Lab, and up to 32 bits per channel. It is genuinely a filing system for images rather than an image format.

What is written here uses almost none of that. One image, one strip, eight bits per sample, RGB, no compression, and a Software tag naming the library that produced it. That plainness is deliberate — the readers that ask for TIFF are the ones least likely to agree about the optional parts — but it means a recipient expecting a layered working file will be disappointed. If the brief said "layered TIFF", this is not that, and it never can be from a single flattened source.

The sensor records 14 bits per channel and the camera reduces that to eight when it writes the preview, so the TIFF holds eight. TIFF allows 16, which is what a lab or a retoucher would normally expect from a raw source.

Where the shortfall shows is in editing rather than in printing. Eight bits is entirely sufficient to reproduce the picture; it is thin if somebody is going to grade it, recover a sky, or push shadows a stop or more, because there are not enough levels left to redistribute without banding. If the file is going to a retoucher for real work, the correct delivery is a 16-bit export from a raw developer, or the RAF itself.

The TIFF is written without an ICC profile, so whatever opens it assumes sRGB. Fujifilm bodies have a colour space menu offering sRGB and Adobe RGB, and if the camera is set to Adobe RGB the preview carries Adobe RGB numbers that will be read as sRGB ones.

On a make chosen for its colour rendering, that is a particularly annoying way to lose the thing you were trying to preserve: the film simulation survives the conversion perfectly and then gets flattened by a missing profile. Check the menu before a delivery, or convert the file in colour-managed software when the colour is the reason the picture exists.

None of the metadata crosses. Lens and focal length, aperture, shutter speed, ISO, capture time, the film simulation in use and any GPS coordinate supplied by a paired phone are all absent from the output, despite TIFF having a defined place for each of them.

The film simulation record is the one Fujifilm shooters miss most, because it is genuinely useful — being able to look up what produced a rendering you liked is half of how people learn the system. It stays in the RAF, so keep the originals if you care about it, and note the simulation in the file name or the delivery sheet if the recipient needs to know.

Three cases. If the picture needs real tonal work, the eight-bit preview is the wrong starting point. If the frame was underexposed or the white balance was wrong, the correction lives in the sensor data. And if the lab has asked for a specific profile at 16 bits, this route cannot supply either.

Modern raw software handles X-Trans far better than the software that gave the sensor its reputation, so the old argument for avoiding third-party development has weakened considerably. What has not changed is the practical case for this page: a compliant TIFF in a few seconds, on any machine, with the look the camera gave the picture already applied.

The whole job runs in the tab. The RAF is read from disk, scanned for its preview, decoded and written out as a TIFF, with no request carrying the picture — verifiable in the network tab and provable by disconnecting the machine first.

Input files are accepted up to 100 MB, which covers every X-series RAF and most GFX files comfortably. Whole selections can be dropped at once and taken as a ZIP, which is the sensible way to move a set of hundred-megabyte files anywhere at all.