A coworker complained that screenshots on our internal asset site came out with a dirty grey halo around the text. I built that site years ago, and every upload goes through the same JPEG quality 80, screenshots and photos alike. Before touching it I wanted to see how an off-the-shelf compressor handles the two kinds of image, and then check its choices against my own encodes.
The tool I used was the image compressor on ImgIng (https://imging.ai/), run in Chromium 149 on an M4 Mac. My samples: two 1280×800 screenshots I made myself by laying out fake pages in a browser (a Chinese meeting-notes page with 174 distinct colours, and an order table with coloured status tags and 1,402 colours), plus two Wikimedia Commons photos scaled to 1280 wide and saved as lossless PNG ("Lake in Dome Creek" by Jakub Fryš, and a fruit stall in Arequipa by Josep M. Gracia, both CC BY-SA 4.0). Four more images, two portraits at two sizes each, brought the total to eight.
What the tool picked on its own
The text screenshot got the banner "detected icon/line art, defaulting to PNG-8, 256 colours", with dithering off. The result went from 306.6 KB to 114.1 KB as a 174-colour indexed PNG. Since the source only had 174 colours, nothing was thrown away. I compared output and source pixel by pixel and they were identical. The table screenshot also went to PNG-8 and came out at PSNR 52.84, SSIM 0.9999. In PNG-8 mode the quality slider disappears and you get a colour-reduction toggle, a colour count and a dither switch instead.
The lake photo was labelled a photo and defaulted to WebP at quality 75, going from 1.42 MB to 58.1 KB. The UI shows its per-content quality presets right there: photo 75, smooth 72, texture 80, graphics/text 84 for WebP, and 80, 78, 84, 88 when you switch to JPG.
It did misjudge two of the eight. The fruit stall, which is full of tiny bright details, and a 2996×4200 portrait were both labelled "screenshot/UI". The only consequence was quality 84 instead of 75; they stayed WebP rather than being forced into a palette. No screenshot was mistaken for a photo. Eight images are far too few to talk about accuracy, and I can only guess that it looks at things like colour count and edges.
Were those choices right?
I encoded the same four main images with sharp 0.34.5 in Node: JPEG with its default 4:2:0 subsampling, WebP at 80, and a 256-colour palette PNG.
| Image | JPEG q60 | JPEG q80 | WebP q80 | Palette PNG |
|---|---|---|---|---|
| Text screenshot | 123,658 B | 164,265 B | 112,844 B | 116,231 B, pixel-identical |
| Table screenshot | 82,392 B | 111,650 B | 58,254 B | 58,317 B, PSNR 62.14 |
| Lake photo | 69,701 B | 117,320 B | 73,278 B | 447,369 B |
| Fruit stall photo | 139,973 B | 205,125 B | 153,452 B | 518,500 B |
For screenshots the palette PNG beat JPEG on both size and quality. On the table screenshot it was about half the size of JPEG q80, and zoomed in, the JPEG versions had the grey speckle my coworker was talking about, plus a colour fringe around the green "shipped" tag. WebP 80 came very close to the palette PNG: 3% smaller on the text screenshot and only 63 bytes apart on the table. But it is lossy, and the text edges look a little soft.
For photos the palette was the wrong call. Both palette PNGs were 2.5 to 3.8 times the size of JPEG q80. The fruit stall dropped to SSIM 0.9309, below even JPEG q60 at 0.9684. In the lake's sky, dithering off gave visible bands and dithering on gave a fine grain. The misty lower part of the same photo, which is one blue-grey tone, showed no banding at 256 colours, so "palettes always band on photos" is too strong.
One thing that tripped me up when I tried my own split: once the table screenshot had been saved as JPEG, its distinct colour count jumped from 1,402 to 21,500, the same order as a portrait photo at 26,827. Colour count alone stopped working. How concentrated the colours are held up better. In the JPEG'd screenshots the top 16 colours still covered at least 74% of pixels, and at least 74% of pixels matched their right-hand neighbour exactly. For the photos both numbers stayed at or below 26%.
So my asset site is getting two paths. Screenshots try a palette PNG first, photos stay on lossy formats. Before shipping it I'll run the real images from the site through the classifier and look at which ones land on the wrong side.
Top comments (0)