When PNG is the right target for AVIF
AVIF is one of the few formats that is both small and can carry transparency, which is why it is popular for logos, stickers and cut-outs on the web. When one of those arrives as an AVIF and you need it in a program that cannot open AVIF, PNG is the format that keeps the see-through areas. JPG cannot.
PNG is also the right choice when the picture will be edited, because it stores exactly what the AVIF decodes to, with no further loss. For a photo that you only need to look at, AVIF to JPG gives a far smaller file.
Transparency, checked against another decoder
AVIF stores transparency as a separate alpha picture beside the colour picture. We made one with avifenc from a 1024 by 1024 logo with soft edges, about 63,000 of whose pixels are partly transparent, and converted it here. The PNG's alpha channel was identical to the one libavif and dav1d produced: the largest difference was 0.
The colours of partly transparent pixels can differ a little more, since many browser image paths store colour already multiplied by alpha. After multiplying both versions by alpha, so that invisible colour does not count, the average difference was 0.03 of a level, the largest was 3, and the PSNR was 63.9 dB. Fully opaque pixels differed by at most 1 level.
Bit depth, chroma and colour
- 10 and 12 bit. PNG here is 8 bits per colour. A 10 bit AVIF test photo matched the 8 bit output of libavif within two levels.
- Chroma subsampling. Many AVIF files, including the ones this site makes, store colour at half resolution (4:2:0), and a 4:4:4 file keeps more. The PNG stores whatever the decoder gives, so blur in the colour channels is not undone.
- Colour profile. The PNG is written without a colour profile, so programs read its colours as sRGB. An AVIF tagged with a Display P3 profile is converted to sRGB first: against LittleCMS the average difference was 0.16 of a level (largest 5), where leaving the numbers as they were would have been off by 3.3 on average and by up to 39. A file with only colour codes (CICP) and no profile gave the same result.
- Lossless AVIF. A lossless AVIF test file differed from the reference decoder's output by 0.01 of a level on average.
- Rotation and mirroring. An AVIF can store a rotation (irot) and a mirror (imir) as flags instead of turned pixels. We made eight files with every rotation, both mirrors and two combinations, and compared the PNG with the transform libavif documents (rotation anti-clockwise, mirror 0 top to bottom, mirror 1 left to right) applied to libavif's own decode. All eight matched within 1 level, and the turned ones came out 100 by 160 pixels instead of 160 by 100.
- Metadata. An AVIF can carry EXIF, but the Metadata switch copies EXIF only from JPG, PNG and WebP files. A test AVIF with an 85 KB EXIF block gave a PNG with none, even with Keep selected, and the list said that no metadata was kept.
How big the PNG gets
AVIF photos are very compact, and PNG stores every pixel, so the PNG is large: 344 KB became 3.6 MB for a 2048 by 1536 photo, and a 375 KB 10 bit version became 4.0 MB. A 1024 pixel logo with transparency grew from 35 KB to 122 KB.
Flat graphics are the exception. A lossless AVIF of a simple 200 by 200 logo was 18.1 KB, and the PNG made from it was 8.3 KB, because the optimiser stores few-colour pictures compactly. The list shows both sizes for every file.
Most of the difference comes from the optimiser, which is the Make PNG files smaller switch. With it off, the same three test files were 5.4 MB (the photo), 213 KB (the logo with transparency) and 28.3 KB (the flat logo), and all three converted in 0.2 seconds. With it on they were 3.6 MB, 122 KB and 8.3 KB and took 5.7 seconds on a busy laptop. The optimiser is lossless, so it only changes how the pixels are stored: leave it on unless you are in a hurry.