Convert ORF to WebP

A server-side converter has to receive the file before it can do anything, and a raw file is the worst possible thing to send over a bad connection. Sixty ORF files at around 20 MB each is 1.2 GB uploaded, and upload is the slow direction on almost every consumer connection — a guesthouse router that downloads acceptably will often upload at a tenth of that.

Here nothing is sent. The card is read by the page, the pictures are extracted and re-encoded on the laptop’s own processor, and the only data that ever crosses the network is the finished set going to your own site — perhaps 20 MB for the same sixty photographs. On a metered tether that is the difference between publishing an entry and deciding not to bother.

Once this page and its converter have loaded, the conversion needs no network. That is a property of running in the browser rather than a feature that was added: the code is on your machine and the files are on your machine, so a train tunnel, an aeroplane or a campsite with no signal makes no difference to it.

The practical shape of that is to open the page while you have a connection, then work through the card whenever you have time — on a bus, in the evening, waiting for a ferry — and publish the finished files when a connection turns up. It is also the cleanest demonstration that nothing is being uploaded, since a conversion that completes with the wifi switched off cannot have sent anything anywhere.

A standard Olympus or OM System frame is 5,184 by 3,888 pixels, about 20 megapixels, in an ORF that usually sits somewhere between 17 and 25 MB. That is a good deal smaller than the raw files a full-frame body produces, which is one of several reasons the system ends up in a rucksack rather than at home.

It is still more than three times as wide as anything a blog displays. A journal entry showing photographs at 1,600 pixels is using less than a tenth of the pixel count the camera recorded, and everything above that is being downloaded by readers and discarded by their browsers. Set the maximum width during the conversion and the saving is taken once, at the point where it costs nothing.

The picture extracted is the JPEG the body wrote when the shutter fired, at full resolution, with the Picture Mode, the white balance and the noise reduction the camera applied. It is the image you reviewed on the rear screen and decided was worth keeping.

That is a reasonable basis for a travel journal and a poor one for a print. The extra latitude in the 12-bit sensor data — the recoverable highlight in a bright sky, the shadow that could be lifted — is not in the extracted picture and cannot be got back from it. Publishing from the preview and developing the good frames properly at home is not a compromise so much as two different jobs, and the ORF files are unchanged by anything this page does.

Look at how wide photographs actually appear in your theme, double it if you want them sharp on a high-density screen, and use that number. For most blog layouts that lands between 1,400 and 1,800. Full-bleed designs justify 2,000; a text-led journal with images at half width does not need more than 1,200.

Apply the same number across the whole card. Consistency matters more than the exact value: a page where one photograph is 2,400 pixels and the next is 1,100 loads unevenly and looks unconsidered on a wide screen. Setting it once at the start of a batch is also one less decision to make at the end of a long day.

At the same visible quality WebP typically comes in a quarter to a third smaller than JPEG, and every current browser reads it. For a journal entry with a dozen photographs in it, that is a meaningful reduction for the reader, who is quite possibly on a phone on a train themselves.

It compounds with the resizing rather than competing with it. Cutting 5,184 pixels to 1,600 removes roughly ninety per cent of the data; WebP then removes a further quarter to a third of what remains. Neither step is visible in the published picture, and together they turn a 20 MB capture into something around 200 KB.

The camera compressed the picture once when it wrote the preview, and this conversion compresses it again as WebP. At the default quality of 82 and at blog dimensions, that second pass is not something a reader will see — the resize does more to the picture than the encoder does.

The habit worth keeping is to convert from the ORF each time rather than from a WebP or a JPEG you made last week. Each conversion from the original is two passes; converting a converted file is three, and it accumulates in exactly the parts of a travel photograph that already struggle, like a hazy sky or an out-of-focus background.

Nothing from the metadata block survives the conversion: no camera or lens, no exposure settings, no capture date, and no GPS coordinate from the body or a paired phone.

For someone publishing while still on the move, that is worth more than it looks. A journal that quietly tells the internet exactly where its author was, at what time, on the day it was posted, is a different disclosure from a journal that describes a place after the fact. If you want the location published, write it in the text where you have chosen it deliberately; if you want the capture dates for your own records, read them from the ORF files before they are archived.

Drop the whole selection, set one maximum width, and take the result as a ZIP. Each file is handled separately with its own progress, so a batch can be left to run while you do something else, and a failure on one file does not lose the rest.

Extraction is cheap — there is no raw decoder to run, only a scan through the file for the embedded JPEG — so this is considerably faster than a raw developer would be on the same machine. That matters on a travel laptop, which is usually chosen for weight rather than for processing photographs, and the free tier’s 100 MB input limit is never reached by an ORF.

Publishing does not consume anything. The ORF keeps the 12-bit sensor data, the full latitude and the complete metadata, and it remains the only file from which a different rendering can be made.

Back the card up before you clear it — two copies, ideally not in the same bag — and treat the WebP set as disposable output that can be regenerated in minutes. The pictures worth printing usually announce themselves weeks later, on a proper screen, and by then the only thing that can serve them is the raw file you did not delete in a guesthouse.