heydeer/pngdeer

A promising choice if you regularly shrink PNGs and don't want to tune quality settings, especially on UI screenshots and illustrations. Treat the head-to-head numbers as the author's benchmark until you reproduce them.

The problem

You have a folder of PNG assets—app screenshots, icons, illustrations—and need them smaller without visibly changing them. The usual workflow is to open a tool, move a quality slider, compare the result, and repeat until the image stops looking wrong; with TinyPNG the quality target is chosen for you but the tool is a web service. pngdeer replaces the slider with an automatic search: it tries palette sizes from 2 to 256 colors, with and without dithering, scores each candidate with a perceptual metric, and keeps the smallest file that clears the quality bar. You get one command or one browser visit and a file that is smaller without a judgment call.

What's different

The mechanism is exhaustive search over palette and dithering combinations, scored in-process with SSIMULACRA2, where 90 is treated as visually indistinguishable at 1:1 (SSIMULACRA2). That matters because the quality decision is made per image rather than by a global setting, so mixed batches of icons and photos don't need separate presets. A fixed target is still available via --target 85 if you want predictable output.

The trade-off is compute: the search is the product, so it is slower than a compressor that applies one fixed palette, and large images are searched on a downscaled preview before being checked at full size. The author reports that at TinyPNG's quality the median file is 12% smaller on a held-out set and 8% on a tuning set, and the README is candid that parameters were tuned on 109 images while 71 were collected afterwards (benchmark and methodology). Those are the maintainer's measurements, not independent verification; the benchmark rerun only covers 155 of the 180 images because some website screenshots can't be shared. The same Rust code runs on the CLI and as WebAssembly in the browser, so the browser path is not a reduced demo.

Who should try it

Good fit: a developer or designer who compresses PNG UI assets and illustrations in batches and would rather trust a quality metric than eyeball each file. Good fit too if you want the same result on a laptop and in a browser without uploading images—the web app runs locally. Poor fit: someone who needs lossless PNG output, or who needs to guarantee a precise byte size or quality value beyond the single target flag; this is a lossy, palette-based compressor aimed at perceived quality. If your pipeline already depends on a specific quantizer's output or on exact reproducibility across versions, verify that the automatic choice matches expectations first.

Requirements and limitations

The README documents macOS and Linux support for the CLI via Homebrew, with cargo build --release as the source path (project instructions); Windows is not listed, so check before planning a cross-platform build step. The browser version handles up to 40 megapixels, with more allowed on the command line—relevant if you routinely compress large renders. Building the web app from source requires a Wasm toolchain, documented in web/build.sh, rather than a simple static file.

Ongoing care is about version drift: the automatic quality choice is the core behavior, so a future release could change output for the same input. The research notes in experiments/palette-feedback trace how defaults were chosen, which is the place to look when a file comes out unexpectedly soft or banded. Because the format is lossy palette reduction, images with fine photographic gradients are the hardest case, and transparent pixels are judged over light and dark backgrounds by the scorer.

HotRepo's take

HotRepo has one dated observation: on 2026-10-26 the project appeared on the NEW-REPOSITORY board for Rust at #12 with 126 total stars, which is a snapshot of a one-day-old repository, not a daily growth series. There is no comparable daily-board history, so persistence of interest cannot yet be judged. Before adopting, verify the benchmark methodology against your own asset mix rather than relying on the 8–12% figure alone.