DEV Community

yue xing
yue xing

Posted on

The screenshot got blurry because of how it was shrunk, not because of the compressor

Assignment portals love a file size cap. Mine is 2 MB per attachment, and the habit I picked up was simple: drag the screenshot into whatever viewer is open, halve the dimensions, save as JPG, done. It passes every time. What finally made me look closer was someone asking me to resend a screenshot because the terminal output in it was unreadable. Zooming in, the red command-line text had smeared together and the edges of the small labels were fuzzy. My first guess was that the compressor was bad. It was not. The blur came from the resize, which happens before any compressor gets involved.

I rebuilt the test with a sample I could share. It is a fake "course assignment portal" page I rendered myself, all invented content, 1280x800, 94.0 KB as PNG.

Path one, the habit: scale to 50%, save JPG at quality 80. That gives 20.1 KB, which is 21% of the original, and a PSNR of 27.0 against the source. PSNR here just means comparing the two images pixel by pixel and reporting how far apart they are, higher being closer to the original; anything above 40 is usually indistinguishable.

Path two: leave the pixel dimensions completely alone and only reduce the number of colors. That gives 37.6 KB, 60% smaller, at PSNR 60.7, and the glyphs are essentially pixel-identical.

Three ways of compressing the same 1280x800 UI screenshot: the 94.0 KB original, 37.6 KB after quantizing to 208 colors, and 20.1 KB after scaling to 50% and saving JPG, with the boxed region magnified 3x underneath. Sample: a self-built UI screenshot with invented content; quantization by the imging web app, scaling and JPG by local Pillow

Two separate losses stack up in path one. The resize resamples two neighbouring pixels into one, and in a UI screenshot a stroke is often only one or two pixels wide, so that detail is simply gone before encoding starts. Then JPEG quantizes in small blocks and leaves low-frequency residue exactly where dark text meets a light background, which is the grey haze you see around the letters. Photographs barely notice either step because they are continuous gradients. Screenshots carry almost all of their information in those hard edges, so they take the full hit.

Color quantization works on screenshots for the opposite reason: a UI uses very few distinct colors. White background, grey rules, two or three text colors, a button. Quantizing builds a limited palette and stores an index per pixel, so nothing moves and letter shapes survive. I ran the screenshot through the image compression tool on imging at its default setting and got a 208-color indexed PNG at 37.6 KB, PSNR 60.7 and SSIM 1.000. Locally, Pillow down to 256 colors landed at 37.3 KB, so the win comes from the image type, not from one clever implementation. Going to WebP at quality 80 gives 31.6 KB, but that is back on a lossy path.

What I now do, by image type:

Image What to use Measured on my samples
Screenshots, flat icons, line art Keep the size, quantize to an indexed PNG 94.0 KB to 37.6 KB, 60% off, PSNR 60.7
Photographs WebP or JPEG, pick quality for a target size At about 150 KB: JPEG q23 PSNR 33.7, WebP q65 37.6, AVIF q59 38.9
Anything with transparency Export to WebP or AVIF 35.2 KB badge to 20.2 KB WebP, 255 alpha levels kept; AVIF 2.4 KB

The photo sample is a CC0 image from Wikimedia Commons shot on an iPhone 6, not one of mine, scaled to 2048x1536. The transparent badge with a drop shadow is something I drew for the test. Saving that badge as JPEG destroys it outright, since JPEG has no alpha channel at all and the transparent area becomes a solid block; composited over a light background it scored PSNR 1.2. I have not checked how AVIF behaves on older devices or browsers, so for anything I hand to someone else I still pick WebP.

On tooling I have low standards: no signup, nothing to install, and let me choose the output format. imging runs in the browser tab, and for image compression and format conversion the file stays local rather than being uploaded, though the first use of some formats downloads a decoder, which is a download and not an upload. Two limits worth knowing. It will not shrink everything: a gradient background I threw at it came out larger, so it fell back and returned the original file with the interface saying the source was already the smallest. And photos at the default setting barely move, 638.7 KB down to 578.0 KB, about 10%, so you have to lower the quality yourself.

The check that takes five seconds: before attaching, zoom the image to 300% and look at the smallest line of text. If it is still crisp and you never touched the dimensions, send it. https://imging.ai/

Top comments (0)