Convert RAF to WebP

The purpose of a proofing gallery is to get a decision. The client looks at four hundred frames, marks thirty, and everything else is deleted. Nothing in that gallery will be printed, framed or kept, which means the qualities that matter are speed of loading, consistency across the set, and a rendering the client recognises — not absolute fidelity.

That reframes the usual argument about extracting a camera preview instead of developing the raw. On a delivery, the preview is a compromise. On a proof it is the correct file: it exists to be looked at once, by somebody deciding which pictures they like, and the thirty that survive will be developed properly from the RAF afterwards.

Developing a raw file means demosaicing it — reconstructing full colour from a grid where each photosite recorded one channel — then applying white balance, a tone curve and a profile, then encoding the result. That is real computation, and on four hundred frames it is a job you set going and come back to.

This does none of it. Every Fujifilm body writes a finished, full-resolution JPEG inside the RAF at capture, and the converter scans the file for it and re-encodes it at the size you asked for. There is no raw decoder in the path at all, which is why a whole shoot goes through in a fraction of the time an export would take, on a laptop rather than on a workstation.

A client who watched you shoot has already seen these pictures — on the back of the camera, over your shoulder, in the frames you showed them during the day. Those images carried whatever simulation the camera was set to: Classic Chrome for a documentary look, Astia for portraits, Provia as the default, Acros for anything intentionally monochrome.

Proofs extracted from the RAF carry exactly the same rendering, so the gallery looks like the day rather than like a neutral raw import. That removes a conversation nobody wants to have about why the proofs look flat, and it sets the expectation correctly: the finished pictures will be better than these, not different in kind. The one thing to watch is Acros — a frame proofed in monochrome will be understood as a monochrome picture, so decide before you shoot rather than after.

Set the maximum width to somewhere between 1,200 and 1,600. That is enough for a client to judge whether an eye is sharp and whether the expression is the one they want, on a laptop or a tablet, which is what proofing is for. A 26-megapixel X-T4 frame is 6,240 pixels wide and a 40-megapixel X-T5 frame is 7,728, so this is a reduction of about eighty per cent in each direction.

It is also a deliberate ceiling on what a downloaded proof is good for. A 1,400-pixel WebP makes a poor print and a poor social post at full width, which is not a security measure but is a reasonable friction. Apply one width to the entire set: a gallery where some pictures are noticeably sharper than others makes the client wonder about the ones that are not.

A proofing gallery is one of the heaviest pages a photographer ever publishes — hundreds of images, loaded as the client scrolls, often over a domestic connection on a laptop that is doing other things. At the same visible quality WebP is typically a quarter to a third smaller than JPEG, and every current browser reads it.

The effect is felt in scrolling rather than in first load, because gallery platforms load images lazily. A set that is a third lighter keeps up with a client flicking through it, and one that is not produces the grey placeholders that make people stop and start again. Check that your gallery platform accepts WebP uploads before converting the shoot; most do, and the ones that do not will say so in their file requirements.

Convert the whole shoot in one pass with one width and one quality setting. Proofs are looked at as a sequence, and the eye picks up inconsistency between neighbouring pictures far more readily than it judges any of them on their own — a frame converted at a different setting reads as a worse photograph rather than as a differently processed file.

The same argument applies to the source. Convert from the RAF files every time rather than from an earlier export, so every proof has had the same two lossy passes: the camera’s and this one. Mixing files that came from different routes is how a set ends up with three frames that look subtly wrong and no obvious reason why.

No metadata reaches the output. Lens, focal length, aperture, shutter speed, ISO, capture time, the film simulation in use and any GPS coordinate from a paired phone are all absent, because the picture is decoded and re-encoded and nothing carries the block across.

The capture time is the one that matters operationally, since proofs are usually presented in shooting order and a gallery platform that sorts by EXIF date will have nothing to sort on. The file name is what carries the order — Fujifilm’s sequential naming survives the conversion, so DSCF4821.RAF becomes DSCF4821.webp — and sorting by name gives the right sequence as long as the counter did not roll over mid-shoot. Check that before you upload four hundred files in the wrong order.

This conversion does not add a watermark and has no setting to. If your gallery platform applies one at upload, use that. If it does not, watermarking is a separate batch step in an image editor or a script, run on the WebP files after they are produced.

A good many photographers skip it for client proofs and rely on the size instead, which is a defensible position: a 1,400-pixel image is of limited use for anything the client would otherwise be ordering, and a visible watermark across every frame makes selection genuinely harder. For a public gallery, or for commercial work where the pictures have value before delivery, that reasoning does not hold and a watermark is worth the extra step.

A wedding before the couple have seen it, a commercial shoot before the campaign launches, a portrait session of somebody’s children — none of that should be passing through a converter you have not assessed. Here the RAF files are read from disk by the page, scanned, decoded and re-encoded locally, and no request carries an image.

It is checkable in a minute: open the developer tools, watch the network tab while a file converts, and see that nothing goes out, or disconnect the machine and convert anyway. Contracts for commercial work increasingly say something about where the images may be processed, and being able to answer that question precisely is worth more than the convenience of any web service.

The thirty selected frames deserve the other path. Open the RAF files in Lightroom, Capture One, darktable or Fujifilm’s own software, develop them with the exposure and white balance you actually want, and deliver from there. Everything that makes raw worth shooting — the highlight headroom, the shadow latitude, the freedom to change the white balance without penalty — is in the 14-bit sensor data and not in a proof.

That two-stage shape is the whole argument for this page. The fast path handles the four hundred frames nobody will ever look at again, and the careful path handles the thirty that matter. Doing both jobs with the same tool would mean either proofing too slowly or delivering something that was only ever meant to be chosen from.