Rule plus remainder, on your own picture
Part of every image can be painted by a rule.
Take any photograph and divide it in two. One part is smooth: skies, walls, skin, water, shadow, the slow gradients that make up much of the frame. That part follows a rule and can be painted at runtime from a handful of numbers. Whatever the rule does not get is kept exactly, as a remainder. Add them back together and you have the original, byte for byte.
Below, your own image is split that way in front of you, and the sizes are put against PNG so you can see where it stands. Sometimes it beats PNG, often it does not, and that is not the interesting part anyway. The interesting part is how much of a real picture the simplest possible rule already accounts for.
1. The original
What you gave me, scaled to fit.
2. What the rules paint
Each tile gets one flat plane: a starting brightness and two slopes. That is all.
3. What the rules could not paint
The remainder, amplified six times so it is visible at all. Black means the rule was already right.
4. Rules plus difference
The reconstruction. Identical to the original, verified by hash.
Read the PNG number as indicative rather than as a codec benchmark. PNG here encodes four channels including alpha and carries its own container; the split encodes the three colour channels and packs the differences with the browser's gzip. A serious comparison would match those conditions and use a tuned entropy coder on both sides. Losslessness, on the other hand, is exact: panel 4 is hashed against panel 1 every run.
The gain is not the compression. It is that the data never exists.
Comparing against PNG is the wrong scoreboard, and I put it there only because it is the first thing a sceptic asks for. Compression makes a stored thing smaller. This makes a stored thing unnecessary: the fill in panel 2 is not a small file, it is no file at all until something asks for it, and afterwards it is gone again.
That matters because of how much of a data centre is holding things nobody is looking at. Thumbnails and previews at six sizes. Map tiles for every zoom level. Rolled-up aggregates. Rendered reports. Cached variants. Synthetic and augmented training sets. Procedural textures and terrain. All of it derivable, all of it sitting on a disk being paid for by the month, and almost none of it read on any given day.
Measured, and the boundary with it
Against materialising a whole field up front, deriving only the part actually requested was 611× cheaper at 0.02% of the field and 17× at 0.4%. The two approaches break even near 25%. Below that line you should not be storing it; above it you should. Real viewports, real queries and real page views live far below the line, which is the entire argument.
What it costs instead
Compute, and honesty about it. Reproducing a value you already have on local disk is about 4.5× slower than reading it. You are trading storage for CPU, and that trade is only worth making when the stored copy is rarely read, or when the alternative is fetching it across a network, where deriving beat the link by 114×.
A database that holds less
Same principle one level up: keep the source values and the rule that produces the derived ones, rather than keeping every derived table, index projection and rolled-up copy. The derived rows are computed when queried. This is not exotic: it is what a view is, versus a materialised view, and the discipline is deciding which things have earned the right to be stored.
Where it does not apply
A photograph of a real place, a log of what actually happened, a document someone wrote: there is no rule that generates those, so they must be kept, and storing them well is a compression problem rather than a derivation one. The honest claim is about the derivable fraction of the pile, which is large, not about the whole pile.
What the four panels are telling you
Panel 2 costs almost nothing
Every tile in the image is described by three numbers per colour channel: a starting value and how fast it changes across and down. That is a plane, the simplest possible rule. For a 16 pixel tile it replaces 768 bytes of pixels with 9 bytes of rule, and it is generated at runtime rather than stored.
Panel 3 is the remainder
Look at how black it is. Across much of the frame the rule was right to within a shade or two. Every pixel it missed is kept exactly, so nothing is lost, and on a photograph that remainder is most of the cost.
Nothing is approximated
Panel 4 is not close to the original, it is the original, and the page proves it by hashing both and comparing. Every difference, however small, is kept. This is a change of representation rather than a quality trade, which is what separates it from lossy compression.
And the honest part
PNG is very good at exactly this, and on a photograph it normally wins, because it has decades of tuned prediction and entropy coding behind it. What this page shows is not a better compressor. It is how much of a picture one plane per tile already accounts for.
Why it runs in your browser
An idea from one person working alone does not get accepted on assertion, not from someone without an institution behind them. It gets accepted when people can run it themselves and watch what happens. So it runs here, with the measurement that shows where it fails printed next to the part that works.