DEV Community: Denny Guide

The palettegen GIF Trick Made My Files Bigger, Not Smaller — I Benchmarked What Actually Shrinks GIFs

Denny Guide — Fri, 30 Oct 2026 08:44:13 +0000

Every "how to make a GIF with FFmpeg" answer on the internet contains the same
two-pass incantation: run your video through palettegen, then pipe it back
in with paletteuse. The comments under those answers say things like
"smaller file, better colors."

So when I needed to shrink some demo GIFs this week, I ran the trick — and
my files got bigger. Not slightly bigger. Up to 117% bigger, at identical
resolution and frame rate. So I benchmarked it properly, because either my
FFmpeg was broken or the folk wisdom was.

Spoiler: the folk wisdom conflates two different claims. The palette trick
buys you quality. It does not buy you size. And once you know that, the
actual size levers become obvious — they're just not the ones the
copy-pasted answers emphasize.

The setup

Three synthetic 10-second clips, 1280×720, 30 fps, so everything is
reproducible and nothing depends on a specific camera's noise profile:

# screen-recording-like motion (sliders, bars, text)
ffmpeg -f lavfi -i testsrc2=size=1280x720:rate=30:duration=10 \
       -c:v libx264 -pix_fmt yuv420p -crf 20 screen.mp4

# smooth color gradients, slowly zooming (worst case for a 256-color format)
ffmpeg -f lavfi -i mandelbrot=size=1280x720:rate=30 -t 10 \
       -c:v libx264 -pix_fmt yuv420p -crf 20 gradient.mp4

# hard edges, few colors (cellular automaton — the "flat UI animation" profile)
ffmpeg -f lavfi -i life=size=1280x720:rate=30 -t 10 \
       -c:v libx264 -pix_fmt yuv420p -crf 20 blocks.mp4

FFmpeg 8.0 on macOS. Five conversion recipes per clip:

	Recipe
A	the naive one-liner: `fps=15,scale=640:-1`, no palette pass
B	the famous trick: two-pass `palettegen=stats_mode=diff` + `paletteuse=dither=sierra2_4a`, same `fps=15,scale=640:-1`
C	B, but `fps=10`
D	B, but `scale=480:-1`
E	B at native 1280×720, 30 fps (the "just convert it" ceiling)

For the record, the two commands behind B:

ffmpeg -i in.mp4 -vf "fps=15,scale=640:-1:flags=lanczos,palettegen=stats_mode=diff" pal.png
ffmpeg -i in.mp4 -i pal.png -lavfi "fps=15,scale=640:-1:flags=lanczos [x];[x][1:v] paletteuse=dither=sierra2_4a" out.gif

Finding 1: the palette trick is a quality feature, not a compression feature

All three clips, same filters, the only difference is the palette pass:

Clip	A (naive)	B (palette)	B vs A
screen	2.05 MB	3.37 MB	+64%
gradient	10.95 MB	17.56 MB	+60%
blocks	5.87 MB	12.72 MB	+117%

The palette version is bigger. Every time. Why? Two reasons, both measurable.

Reason one: dither noise. sierra2_4a is an error-diffusion dither. It
sprays high-frequency noise across every pixel that isn't exactly
representable in the 256-color palette — and GIF's LZW compression despises
high-frequency noise. Switching the same palette pass to ordered dithering
(dither=bayer:bayer_scale=5) claws some of it back (3.37 → 3.03 MB on the
screen clip) but never gets close to the naive path.

Reason two: the naive path quietly throws colors away. Count the
distinct colors in the first frame of each output:

Clip	A (naive)	B (palette)
screen	184	236
gradient	174	255
blocks	18	221

That blocks row is the whole story in miniature. The cellular-automaton
clip is mostly flat white and black with a handful of accent colors — and
the default quantizer crushes it down to 18 effective colors, which LZW then
compresses beautifully. The content-aware palette preserves 221 of them,
which looks better and compresses worse.

So this is not a bug and I'm not dunking on the technique. If your source
has gradients — screen recordings with soft shadows, anything photographic —
the naive path will band into ugly stair-steps and the palette pass genuinely
fixes that. But if you're reaching for palettegen "to make the file
smaller," you've been mislabeled by the comments section. It's a
quality-for-size trade, priced at roughly +60–117%.

Finding 2: the levers that actually move size are fps and width

Same palette recipe (B), one knob at a time:

Clip	B (640px, 15fps)	fps→10	width→480
screen	3.37 MB	2.32 MB (−31%)	2.30 MB (−32%)
gradient	17.56 MB	11.92 MB (−32%)	10.19 MB (−42%)
blocks	12.72 MB	8.85 MB (−30%)	8.43 MB (−34%)

Dropping from 15 to 10 fps costs you a third of the size across the board,
and for a UI demo or a loading animation, 10–12 fps is usually plenty —
cursor trails get slightly choppier, nothing else changes. Width is the
sharper lever on gradient-heavy content (−42%), because GIF stores every
pixel of every frame; fewer pixels per frame compounds over 300 frames.

Stack both (10 fps, 480px) and the gradient clip lands under 8 MB from a
17.6 MB starting point — a bigger win than any palette-vs-no-palette choice,
with zero quality debate.

Finding 3: know when GIF is simply the wrong format

Recipe E converts at native 1280×720, 30 fps, full palette. The gradient
clip — 10 seconds, remember — comes out at 128.6 MB. The MP4 it was made
from is 9.7 MB. That's 13× the size for objectively worse color (256 colors
dithered vs. the original).

(Small honesty note: on the noisy blocks clip the native-res GIF was 17.8
MB against a 40.8 MB CRF-20 MP4 — GIF can "win" against a high-bitrate
noisy source. But that's the exception profile: flat colors, zero gradients.
If your content looks like a photograph or has any smooth shading, it is not
that profile.)

Modern answer for "a GIF but sane": MP4 or WebM in a <video> tag, or an
animated WebP/AVIF if you need a single self-contained image file. Reserve
actual GIF for the places that force it — README badges, Slack, email,
that one legacy portal. And when it is forced, that's exactly when the
fps/width discipline above earns its keep.

Recipes, by what your clip looks like

Screen recording / UI demo (flat colors): naive path, no palette — fps=12,scale=640:-1. Smallest file, and flat content survives the default quantizer just fine (184 colors on my test clip, no visible loss).
Anything with gradients or photographic content: palette pass with dither=bayer:bayer_scale=5, then claw size back with fps=10 and 480–640px width. Accept that quality costs bytes here.
Both kinds, and you need it under a hard limit (say an email attachment or a 10 MB upload cap): drop to fps=10, scale=480:-1 and trim the clip to the 3–5 seconds that matter. Cutting duration is the one lever stronger than every other lever.

One more practical note: if the clip is a screen demo, check what's in it
before uploading it to any converter — cursor paths and notifications leak
context. The converter I keep bookmarked for this
(iLoveConvert's MP4 to GIF page)
auto-deletes uploads within 24 hours and doesn't demand an account, which is
the baseline I hold any such tool to, but "deleted" doesn't help with a
screenshot of a customer record that's now in a GIF you pasted into a public
issue thread.

Takeaway

The two-pass palette recipe is good FFmpeg advice with a bad reputation. It
makes GIFs look better and weigh more. When your problem is weight, the
cheap wins are boring: fewer frames, fewer pixels, fewer seconds. Measure
instead of trusting the comments — it's two commands and a table like the
one above.

I benchmark file-format tooling and write up the numbers — previously:
500-image PNG→JPG conversion benchmarks, batch audio extraction from video,
and five ways to turn PDF pages into images, all with reproducible scripts.

5 Ways to Turn PDF Pages Into PNG Images — I Benchmarked Them on a 20-Page Document

Denny Guide — Mon, 26 Oct 2026 07:44:47 +0000

Every few weeks someone asks a variant of the same question: "how do I get these PDF pages
into PNG images?" — for slides thumbnails, for embedding pages in docs, for feeding pages
into an OCR model. There are a lot of answers, and most of them are slower than they need
to be.

I generated a synthetic 20-page PDF (US Letter, text + vector shapes) and ran the
contenders at 150 DPI on the same machine. Here's what I found.

The benchmark

Method	20 pages @150 DPI	Throughput
macOS Preview / Acrobat (manual export)	~2 min of clicking	—
`pdftoppm` (poppler)	4.1 s	4.8 pages/s
Ghostscript one-liner	0.9 s	21.2 pages/s
PyMuPDF (Python)	0.7 s	29.4 pages/s
Web converter	upload-bound	—

The spread surprised me: the "standard" poppler route is 6× slower than PyMuPDF on the
same document.

1. Preview / Acrobat — for one or two pages

Fine for a single page. Painful for 20. If you're exporting more than a handful of pages,
anything scripted below wins immediately.

2. `pdftoppm` — the default answer

pdftoppm -png -r 150 input.pdf page
# -> page-01.png, page-02.png, ...

Preinstalled almost everywhere, dead simple, and slow — 4.1 s for 20 pages here. It's also
what the popular pdf2image Python package shells out to under the hood, so that package
inherits the same speed.

3. Ghostscript — the quiet workhorse

gs -q -dNOPAUSE -dBATCH -sDEVICE=png16m -r150 \
   -sOutputFile=page-%02d.png input.pdf

One process renders every page (the %02d pattern handles numbering), at 21 pages/s.
Already installed on most servers.

4. PyMuPDF — the speed winner

import pymupdf

doc = pymupdf.open("input.pdf")
for i, page in enumerate(doc):
    pix = page.get_pixmap(matrix=pymupdf.Matrix(150 / 72, 150 / 72))  # 150 DPI
    pix.save(f"page-{i+1:02d}.png")

29 pages/s, no subprocess overhead, and you control the DPI with a zoom matrix
(150/72 ≈ 2.08× — a 612×792 pt page becomes 1275×1650 px, ~187 KB per page here).
If you're doing anything programmatic — thumbnails, OCR preprocessing, page previews —
this is the one to pick.

5. A web converter — when you can't install anything

Locked-down work laptop, one-off task, or the PDF lives on your phone? Then a browser
tool is the pragmatic choice; I've used
iloveconvert.com's PDF to PNG converter
for exactly this — it bundles multi-page output and saves you the local setup entirely.

Takeaways

For scripting: PyMuPDF, ~6× faster than the poppler default.
For a server you already SSH into: the Ghostscript one-liner is already there.
Save yourself the manual Preview export — anything past 2 pages isn't worth the clicks.

I Extracted the Audio From 20 Video Files in 2.2 Seconds — Here's the Batch Pipeline

Denny Guide — Mon, 19 Oct 2026 01:23:34 +0000

I help maintain a small archive of recorded meetings and talks. The videos are useful, but
nobody re-watches a 40-minute recording to find one decision. What people actually want is
the audio — to listen on the go, or to feed into a transcription tool.

So I built a tiny batch pipeline that rips the audio track out of every video in a folder
and throws the video away. Here's what surprised me: for pure audio extraction, the whole
job is I/O-bound on your disk, not CPU-bound on your codec.

The one-liner that does all the work

for f in *.mp4; do
  ffmpeg -y -i "$f" -vn -c:a libmp3lame -q:a 4 "out/${f%.mp4}.mp3"
done

Two flags matter more than they look:

-vn — drop the video stream entirely. FFmpeg skips decoding most of the video, which is where the speed comes from.
-c:a libmp3lame -q:a 4 — re-encode to MP3 at VBR quality 4 (~165 kbps, transparent for speech). If your source audio is already AAC and you don't need MP3 specifically, use -c:a copy and it's even faster.

Real numbers from my machine

I generated 20 test videos (30 s each, 720p H.264 + AAC, 240.8 MB total) and ran the loop
on an M-series MacBook with FFmpeg 8.0:

Metric	Result
20 files, sequential loop	2.2 s total
Throughput	~9.3 files/s
Size before	240.8 MB
Size after (MP3 q=4)	2.4 MB

That's a 99% size reduction. The MP3s are what you actually want to keep around long
term; the video only matters if someone asks for the slides.

Wrapping it in Python (for the pipeline part)

A shell loop is fine for one folder. If this runs on a schedule — new recordings land in
inbox/, processed files move to done/ — a thin Python wrapper keeps the state machine
honest:

from pathlib import Path
import subprocess, shutil

INBOX, DONE, OUT = Path("inbox"), Path("done"), Path("mp3")

for src in INBOX.glob("*.mp4"):
    dst = OUT / f"{src.stem}.mp3"
    subprocess.run(
        ["ffmpeg", "-y", "-i", str(src), "-vn",
         "-c:a", "libmp3lame", "-q:a", "4", str(dst)],
        check=True, capture_output=True,
    )
    shutil.move(str(src), DONE / src.name)
    print(f"{src.name} -> {dst} ({dst.stat().st_size // 1024} KB)")

check=True means a corrupt file stops the batch instead of silently producing an empty
MP3 — which matters when the next stage is a transcription API billing you by the minute.

When I don't reach for FFmpeg at all

FFmpeg is the right answer for anything recurring. But for one-off files — someone sends
you a single recording and you just need the MP3 to drop into a notes app — installing a
codec stack is overkill. For those cases I use a web converter instead, e.g.
iloveconvert.com's MP4 to MP3 tool,
which handles the common formats without any local setup.

Takeaways

-vn is the speed lever. Don't decode video you're going to discard.
Sequential is fine: at 9 files/s, parallelism adds complexity for no felt gain.
Keep the extracted audio, archive or delete the video — 99% of the bytes were pixels you'll never miss.

Batch-Converting 500 PNGs to JPG: I Timed My Pillow Script Against the Alternatives

Denny Guide — Sat, 17 Oct 2026 02:56:53 +0000

Every few months I get the same folder: a few hundred PNGs exported from a design tool, all needing to be JPG before they can go into a CMS that has a hard 25 MB per-image cap. PNGs of screenshots and photos are heavy, and nobody on the content team is going to open an image editor 500 times.

So I have a script for this. But the last time I posted it, someone asked the obvious question: "is that actually faster than just using an online converter?" Fair. Let's measure it.

The task

500 PNG files, 800×600
About 20% have an alpha channel (logos/icons), the rest are opaque
Target: JPG, quality 85, white background where alpha gets flattened
Don't touch the source files

The script

import os
from PIL import Image

SRC, DST = "src", "out"
os.makedirs(DST, exist_ok=True)

for name in sorted(os.listdir(SRC)):
    if not name.lower().endswith(".png"):
        continue

    img = Image.open(os.path.join(SRC, name))

    # Gotcha 1: JPEG has no alpha channel. RGBA/LA/P images must be
    # flattened onto a background first, or Pillow raises
    # "cannot write mode RGBA as JPEG".
    if img.mode in ("RGBA", "LA", "P"):
        rgba = img.convert("RGBA")
        bg = Image.new("RGB", rgba.size, (255, 255, 255))
        bg.paste(rgba, mask=rgba.split()[-1])  # alpha as the mask
        img = bg
    elif img.mode != "RGB":
        img = img.convert("RGB")

    # Gotcha 2: write to a different directory, never in place.
    # A buggy quality setting shouldn't be able to destroy originals.
    img.save(
        os.path.join(DST, os.path.splitext(name)[0] + ".jpg"),
        "JPEG",
        quality=85,
        optimize=True,  # ~5-10% smaller, costs a bit of CPU
    )

The three gotchas, because they always bite someone

1. Alpha flattening. The naive img.convert("RGB") on an RGBA image doesn't composite onto a background — it just drops the alpha channel. Transparent areas turn black, and you find out after the batch finished. The paste with the alpha band as mask is the fix; white is usually what you want for web, but for dark sites use a dark background.

2. Palette mode (P). GIF-style indexed PNGs show up in the wild more than you'd think, and they're in the same "can't save directly as JPEG" bucket. The mode check above catches them.

3. Never convert in place. Same input/output directory plus a glob that matches both .png and .jpg is how people destroy their originals. Separate out/ folder, always.

The numbers

Ran on my M-series MacBook, Python 3.13, Pillow 12.2:

Metric	Result
Files	500
Wall time	6.7 s
Throughput	~75 images/s
Input total	744.7 MB
Output total	171.7 MB (23% of input)

Worst-case input, by the way: these were noise images, which PNG compresses terribly. With real screenshots and photos the ratio is usually closer to 60–70%, because PNG is even more hopeless on photographic content than on noise.

CPU during the run: one core pegged, the rest idle. You could parallelize with a ProcessPoolExecutor and probably hit 4–6× that, but at 6.7 seconds for 500 images, why would you.

Update: per-file p50/p95, because a reader rightly pushed back

A commenter noted my batch average answers "is the whole folder fast" but not "will this file be fast," and predicted the tails would live in the alpha branch — compositing cost scales with pixel count in a way plain conversion doesn't. Half right, and the half that was wrong turned out to be the interesting part.

Re-ran with per-file timing: same machine, noise images, n=60 per cell, four size buckets, alpha and opaque separated:

Bucket	MP	Alpha?	p50	p95
16×16	0.0003	yes	0.2 ms	0.7 ms
16×16	0.0003	no	0.15 ms	0.5 ms
240×240	0.058	yes	2.2 ms	2.5 ms
240×240	0.058	no	1.9 ms	2.2 ms
800×600	0.48	yes	14.3 ms	16.0 ms
800×600	0.48	no	12.3 ms	15.9 ms
4000×3000	12	yes	305 ms	330 ms
4000×3000	12	no	296 ms	307 ms

What the table actually says:

Megapixels, not alpha, own the tail. Per-file time spans 0.2 ms → 305 ms (~1500×) across buckets; within a bucket, alpha vs opaque differs by 3–16%. Your p95 is decided by "how big is your biggest file."
The alpha tax shrinks as files grow. +15–16% at icon sizes, where the extra paste-onto-white is proportionally large, but only +3% at 12 MP, where JPEG encode dominates everything else. "Alpha files are slow" is only true for files that are fast anyway.
Within-bucket variance is tight — p95 ≈ 1.1× p50 everywhere except the 16px bucket, where the absolute numbers are sub-millisecond noise. The spread in my original 6.7 s figure came from the file mix, not flaky per-file behavior.
For sizing your own batch on comparable hardware: budget ~25–40 ms per megapixel, and treat alpha as a rounding error unless everything you own is tiny icons.

Updated Oct 2026: added per-file p50/p95 by alpha channel and size bucket after feedback in the comments.

When the script is the wrong tool

Honesty time — "I have a script" is not always the right answer:

You're on someone else's machine. Installing Python to convert one folder is using a cannon to kill a mosquito.
It's a one-off. If you'll do this twice a year, writing and debugging a script is slower than the task itself, even the first time.
A non-technical teammate needs it. "Run my Python script" is not a deliverable. "Open this page, drop the folder" is.

For those cases I keep a browser bookmark around — recently I've been using iLoveConvert's PNG to JPG tool for exactly this shape of problem: no signup, files auto-deleted after 24 hours, and it takes a whole folder in one drop. It's obviously not beating 75 images/s on my own hardware, but it doesn't need to — it just needs to work on any machine in ten seconds.

Rule of thumb

Recurring batch + your own machine → script. It's faster, free, offline, and you control the quality settings.
One-off, foreign machine, or handing to someone else → online tool. The 30 seconds you save by not fiddling matters more than raw throughput.

The script above is deliberately boring. Boring is good: it's the version that still runs in three years when Pillow has renamed something else.

DEV Community: Denny Guide

The palettegen GIF Trick Made My Files Bigger, Not Smaller — I Benchmarked What Actually Shrinks GIFs

The setup

Finding 1: the palette trick is a quality feature, not a compression feature

Finding 2: the levers that actually move size are fps and width

Finding 3: know when GIF is simply the wrong format

Recipes, by what your clip looks like

Takeaway

5 Ways to Turn PDF Pages Into PNG Images — I Benchmarked Them on a 20-Page Document

The benchmark

1. Preview / Acrobat — for one or two pages

2. pdftoppm — the default answer

3. Ghostscript — the quiet workhorse

4. PyMuPDF — the speed winner

5. A web converter — when you can't install anything

Takeaways

I Extracted the Audio From 20 Video Files in 2.2 Seconds — Here's the Batch Pipeline

The one-liner that does all the work

Real numbers from my machine

Wrapping it in Python (for the pipeline part)

When I don't reach for FFmpeg at all

Takeaways

Batch-Converting 500 PNGs to JPG: I Timed My Pillow Script Against the Alternatives

The task

The script

The three gotchas, because they always bite someone

The numbers

Update: per-file p50/p95, because a reader rightly pushed back

When the script is the wrong tool

Rule of thumb

2. `pdftoppm` — the default answer