Convert ARW to PNG

PNG stores exact pixel values, so a file written today decodes to the same array as the same file written next month, and re-saving it changes nothing. For anything that measures, compares, hashes or trains on images, that property is worth more than file size — a format that quietly re-compresses on every write turns a reproducibility problem into a mystery.

This conversion is deterministic in the same sense. The same ARW produces the same PNG every time: the preview is located by the same scan, decoded by the same decoder and encoded by the same encoder, with no randomised step anywhere in it.

Camera JPEGs almost always subsample chroma: brightness is stored per pixel, colour at half resolution horizontally and vertically. It works because human vision is far more sensitive to luminance detail than to colour detail, and it is invisible in a photograph looked at by a person.

It is not invisible to an algorithm. Fine coloured detail — a red line on a white background, the boundary between two saturated areas — has been interpolated rather than measured. The PNG will store a full colour value for every pixel, but a quarter of those values were reconstructed by the JPEG decoder rather than recorded by the camera. If your pipeline measures colour edges, that is the limitation to know about, and the only way past it is to demosaic the ARW properly.

An ARW is a TIFF-derived container that Sony has written since the Alpha DSLR-A100 of 2006, holding 12-bit sensor readings on the early bodies and 14-bit on the later ones. Alongside them the camera writes a finished JPEG at the moment of capture, at the full pixel dimensions of the sensor on modern bodies.

The converter scans for that JPEG, keeps the largest above 640 by 480, decodes it and re-encodes it as PNG. The sensor data is never touched, which is why the conversion is fast and why it cannot give you anything the camera did not already render.

Two cases in particular. Photogrammetry and panorama stitching want consistency across a set, and the camera applies auto white balance and its own tone curve per frame; if the camera was on auto anything, the set drifts and the tool has to work harder. Shoot with fixed white balance and a neutral profile, or develop the ARW files in a batch with identical settings.

Anything measuring absolute luminance, doing radiometric work, or relying on a linear response also needs the sensor data. The camera’s tone curve is a deliberately non-linear rendering intended to look right, and it destroys the relationship between pixel value and light that such work depends on.

PNG supports 16 bits per channel and Sony sensors record 14, but the extracted preview is an 8-bit JPEG, so the output is 8-bit. In 8 bits a channel has 256 levels, and any operation that stretches a narrow range — normalising a dark frame, pulling contrast out of a flat one — will band.

If the pipeline does that kind of stretching, this is the wrong source. Develop the ARW in Imaging Edge, Lightroom, Capture One or darktable and export a 16-bit TIFF, which is the standard input for exactly this reason.

The arithmetic is unforgiving at Sony’s higher resolutions. A 24-megapixel A7 III frame is about 72 MB of raw pixels; a 61-megapixel A7R IV frame is about 180 MB. PNG brings a photograph to roughly half or three-quarters of that, so a thousand-image set from an A7R IV can easily exceed a hundred gigabytes.

Setting a maximum width is the lever. Many pipelines resize their input as the first step anyway, and doing it during conversion means you never store the full-size version. Check what the tool actually consumes before generating something it will immediately shrink.

The re-encode drops the EXIF, so there is no lens, no focal length, no exposure data and no GPS coordinate in the PNG. Anything that needs those — a photogrammetry tool reading focal length, a dataset recording capture conditions — has to get them from the ARW separately and carry them in a sidecar or a manifest.

That is usually the better design regardless. A pipeline that reads its parameters from a manifest is reproducible; one that reads them out of whichever derivative file happens to be on disk is not.

Batches work and consistency is the point: drop the whole set, let every file go through the same settings, take the result as a ZIP. Converting in several sittings is how a dataset ends up with two different maximum widths in it and a week lost to finding out why.

Encoding PNG at these pixel counts is genuine work, so a large set takes time — much longer than the JPG route, where the preview is copied out without re-encoding. Input files are accepted up to 100 MB each, which covers compressed and lossless compressed ARW comfortably; an uncompressed 61-megapixel frame at around 120 MB is over the line.

The conversion runs in the browser, so the ARW files are never transmitted. For image data that is confidential, personally identifying, or subject to a research ethics approval, that is not a nice-to-have — uploading a dataset to a converter found in a search result is the kind of step that invalidates the approval.

It is verifiable rather than promised: open the developer tools, watch the network tab through a conversion, and note that nothing carrying the images goes out.