Data Compression

Paying Per Bit

Every file costs storage, and every transfer costs time and bandwidth: a raw phone photo is ~36 MB of pixel numbers, a minute of raw audio ~10 MB, and raw video is a firehose. Yet photos send in a second and video streams smoothly. The gap between raw size and real size is compression: re-encoding data so the same information takes fewer bits.

The deep idea: real data is full of patterns and redundancy — repeated values, predictable neighbours, detail nobody perceives. Compression is pattern recognition weaponised: find the pattern, store the pattern's description instead of the raw repetition.

Lossless: Perfect Reconstruction

Lossless compression makes files smaller with a hard guarantee: decompressing returns the original bit for bit. Nothing is lost — the data is just written more cleverly.

The classic beginner example is run-length encoding (RLE). A simple image row often contains long runs of identical pixels:

WWWWWWWWWWBBBWWWW    (17 characters)
10W 3B 4W            (three tokens)

Store "10 whites, 3 blacks, 4 whites" instead of 17 separate values. Fully reversible; dramatically smaller — when the data has runs. (On data with no repetition, RLE can even make things bigger. No compressor shrinks everything: truly random data has no pattern to exploit.)

Real-world lossless tools (ZIP files, PNG images) use cleverer pattern-hunting — spotting repeated phrases anywhere in the data, and giving the most common symbols the shortest codes (the same instinct as Morse code giving "E" a single dot). The guarantee stays the same: perfect reconstruction.

Lossless is mandatory where every bit is meaning: text ("Pay £100" vs "Pay £900" is one character), spreadsheets, and above all programs — machine code with one flipped bit is a crash waiting to happen.

Lossy: Smaller, by Throwing Things Away

For photos, music, and video there is a bolder option. Human senses have limits — we cannot see 16.7 million colours' finest gradations or hear every frequency. Lossy compression exploits that redundancy: it permanently discards detail people are unlikely to notice, and shrinks files far beyond what lossless can achieve.

• JPEG (photos) smooths fine colour detail your eye glosses over: 36 MB → 3 MB, visually near-identical
• MP3/AAC (audio) drops sounds outside hearing range and sounds masked by louder ones: 50 MB → 5 MB
• Video codecs add a masterstroke: most frames barely differ from the previous one, so store only the changes between frames

The price is in the name: lossy. The discarded detail is gone forever — no decompression recovers it. Push the quality slider too far and artefacts appear: blocky JPEG skies, swirling smears in fast video. And each re-save discards afresh, which is why a meme screenshotted and reposted a hundred times looks like soup: generation loss, the photocopy of a photocopy.

Choosing: One Question

The whole decision compresses (sorry) to one question — can the data survive approximation?

Data	Tolerates loss?	Choose
Text, code, spreadsheets	No — every bit is meaning	Lossless (ZIP, PNG for diagrams)
Photos for sharing	Yes — eyes forgive	Lossy (JPEG)
Music for listening	Yes — ears forgive	Lossy (MP3/AAC)
Originals you will edit again	Prefer not	Lossless masters, export lossy copies

Every image and song that crosses the internet rides this machinery — compressed at the sender, split into packets, decompressed at your end, in milliseconds, invisibly. Streaming a film over an ordinary connection is only possible because ~99% of the raw data never needs to travel.

Try It Yourself

1. Run-length encode AAAABBBAACCCCCC. What is the compression ratio?
2. Invent a string RLE makes worse.
3. Your band records an album. In which format do you archive the masters, and which do you upload for streaming — and why?

Worked Example — Compressing a Simple Image Row

Picture one row of a simple logo image, stored as colour codes per pixel: RRRRRRRRGGGGGGBBBBRRRRR (23 pixels: 8 red, 6 green, 4 blue, 5 red). Run-length encoding turns this into 8R 6G 4B 5R — four tokens instead of 23 individual values, and every single pixel can be perfectly reconstructed by "unrolling" each token back into its repeats. This is exactly why simple graphics (logos, icons, cartoon-style images with big flat colour areas) compress extremely well with lossless methods: they are full of long runs. Compare that with a photograph of a forest, where neighbouring pixels constantly shift in subtle ways — there are far fewer long runs to exploit, which is one reason photographs lean on lossy compression instead, trading a little invisible detail for a much bigger size reduction than RLE could offer.

Compression and Encryption Are Not the Same Thing

It is worth being precise about a distinction that is easy to blur: compression makes data smaller; encryption makes data unreadable without a key. A ZIP file can do either, or both — some ZIP tools offer password protection, which encrypts the compressed contents. But compressing a file does not make it secure: anyone can unzip an ordinary ZIP file and read what's inside, because there is no secret involved, only a shorter encoding. If a file must be kept both small and private — an archived database backup, for instance — both transformations are typically applied, usually compression first (squeezing out redundancy) and encryption second (scrambling what's left), because encrypted data looks close to random and compresses poorly if the order is reversed.

Key Words

• Compression — re-encoding data into fewer bits
• Lossless — fully reversible; the original is reconstructed exactly
• Lossy — discards imperceptible detail permanently for much smaller files
• Run-length encoding — storing repeated values as count + symbol
• Artefacts / generation loss — visible damage from aggressive or repeated lossy saves