Build1 distinct publisher3 min readUpdated
A pipeline that turned 1074 KB into 4881 KB was not losing to the compressor. It was decoding away the interframe differencing the source already had.
The Engineer · Build desk

Compiled by The EngineerSomething wrong?How this is made
The check that would have caught this is not one most pipelines run. Every frame the old encoder emitted was individually correct and the animation played correctly [8], so a visual diff passes it, and so does a hash of the decoded frame buffers. What went missing was structure, not pixels. A GIF is a sequence of image blocks, each with its own disposal method and local palette, and nothing requires a block to cover the whole canvas or to be a complete picture [5]. The pendulum source used that: a static rig and a dark background left alone, bytes spent on a bob occupying a few percent of the pixels [7]. The re-encode wrote full-canvas opaque keyframes instead and paid for that background 287 extra times [9].
That is the general shape. Any step that decodes a format to a canonical intermediate and re-serialises it discards the source's encoding decisions, and if those decisions were the compression, no output check based on appearance can see the loss. The size ratio is the detector, which is how this one surfaced at all: 1074 KB to 4881 KB on a 288-frame file [1], 116 KB to 1232 KB on a 70-frame one [2], with the same inflation on a pure re-encode with no crop [4].
The most useful part of the writeup is the heuristic that was built and then deleted [12]. The intuitive rule is to skip the delta when too much of the frame changed, and the measurements inverted it: the file that changed twice as much was the one that should have used deltas, the file that changed less was the one that should not [13]. LZW pays for runs, not for pixels, so what decides the outcome is how scattered the movement is, and no threshold over a changed-pixel count can see scatter [14]. So the encoder measures instead. Three sample frames per file, encoded both ways, winner kept [15], with both candidates appended after an identical frame 0 so the header, global palette and loop block cancel out of the comparison [16].
Across ten Wikimedia Commons animations [17], output runs 15% to 100% of the previous encoder's, median 90%, nothing bigger [18]. That median is the number worth holding: at least half the set gained 10% or less [5]. This is not a compression improvement with a long tail. It is a repair with a very short one, and the two repaired cases move 6.7x and 3.8x [1][2].
The numbers do not fully close. The fixed turret is 184 KB and the fixed pendulum 1292 KB [19], which are 59% and 20% above the input sizes quoted earlier in the same piece [3][4], while the summary says all ten finished at 17% to 79% of their sources [20]. The writeup does not say which files that band covers.
The palette footgun is the same failure mode in miniature: hand `quantize()` a subarray view and it reads the whole underlying buffer, builds the palette from the wrong pixels, and returns something plausible with no error [21].
Follow any of these and your For You feed starts watching them — no settings page required.
Ranked by verification strength, evidence, and original report placement.
Output is 15% to 100% of the previous encoder's size, median 90%, and zero files got bigger.
A 288-frame Foucault pendulum GIF went from 1074 KB in to 4881 KB out through the authors' re-encode pipeline.
A 70-frame gun turret GIF went from 116 KB to 1232 KB through the same pipeline.
The same inflation occurred with no crop applied at all, which the authors say identifies the cause as the encoder discarding something the source already had rather than losing to the compressor.
GIF stores an animation as a sequence of image blocks, each carrying a disposal method and its own local palette; nothing requires a block to cover the whole canvas or to be a complete picture.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Detailed and self-consistent, but single-source and self-reported
The mechanism is well specified and checkable against the GIF format (image blocks, disposal, transparent index) and the results are quantified over a named ten-file public corpus with before/after byte sizes, plus an independent-decoder cross-check using Pillow. What is missing is external verification: no published harness or corpus results, no third-party reproduction, and one unreconciled numeric tension between quoted input sizes and fixed output sizes inside the same article.
Single-vendor, self-reported deployment
The only observed usage is the author's own browser-based Image Machine GIF tools, where the encoder now runs client side. No other project, library release, downstream integration or third-party usage disclosure appears in the supplied material, and the underlying gifenc library is referenced only as a dependency constraint.
Headline multiples run ahead of a median that the body itself deflates
The title and dek foreground a 4.5x inflation and its reversal, and the two worst-case files do improve by roughly 6.7x and 3.8x. But the body's own framing is deliberately modest - median output is 90% of the prior encoder, half the corpus barely moved, and the author calls it a fix for a failure mode rather than a general compression gain - which keeps overstatement small. The residual gap comes from the unreconciled claim that all ten outputs are smaller than their sources, which the article's own quoted input sizes for turret and pendulum appear to contradict.
Author is promoting the product the fix ships in
The post is a self-published first-person writeup on a developer blogging platform by the maintainer of the tool being described, and it closes by naming and linking the commercial destination (Image Machine GIF tools, the GIF cropper) where the encoder runs. All measurements are the author's own, with no external review, so favourable framing carries direct promotional benefit - partially offset by the author volunteering the median caveat and the abandoned heuristic.
Mechanism credible, magnitudes only as good as one author's numbers
Confidence in the diagnosis is high because it follows from documented GIF compositing semantics and the no-crop control case, and the Pillow cross-decode raises confidence in correctness. Confidence in the size and generality of the gains is moderate: one publisher, one author, an unpublished harness, a median that shows most files barely change, and an internal numeric inconsistency that is not explained.
build
An exact byte budget is a search problem, and 18 encodes is the wrong way to run it1 distinct publisher
build
Three manual interventions in a month, and every guard was working as designed1 distinct publisher
build
Six MariaDB versions, one real difference: the only reason to leave 10.6 is the July 2026 clock1 distinct publisher
build
Force the tool call, then hand Lightsail a long-lived key1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 23, 2026