Squeeze

Why bother making files smaller?

A single photo from a modern phone camera has about 12 million pixels. Each pixel needs 3 bytes (one each for red, green and blue). That's 36 million bytes (36 MB) for one photo, before compression. If every photo stayed that size, a 128 GB phone would fill up after roughly 3,500 photos, and sending one to a friend on a slow connection would take minutes.

In practice that same photo saved as a JPEG is usually 3 to 5 MB. Compression is why you can stream a movie, send voice messages and keep thousands of songs on your phone.

Compression saves four things:

A quick refresher on units

A bit is a single 0 or 1. A byte is 8 bits. From there we go up in thousands:

Encoding and decoding

Compression always has two halves. An encoder squeezes the data down. A decoder turns it back into something you can see or hear. Together they're called a codec (coder-decoder). MP3, JPEG and H.264 are all codecs. Both ends must agree on the rules, which is why an old phone sometimes can't play a video made with a newer codec.

Measuring how well it worked

The compression ratio compares the original size to the compressed size:

compression ratio = original size ÷ compressed size

A 10 MB file compressed to 2 MB has a ratio of 10 ÷ 2 = 5:1 ("five to one"). You can also express it as a percentage saving:

saving = (1 − compressed ÷ original) × 100%

For the same file: (1 − 2 ÷ 10) × 100% = 80% smaller. Make sure both sizes are in the same unit before you divide.

Lossless: nothing is lost

Lossless compression shrinks a file so that when it's decoded you get back exactly the original, bit for bit. It works by finding redundancy: patterns and repetition that can be written more efficiently.

Think of the sentence "the cat sat on the mat and the cat sat on the rug". Instead of writing "the cat sat on the" twice, you could write it once and say "repeat that here". Nothing is lost; you've just found a shorter way to describe it.

Lossless is essential when every bit matters: text documents, program code, spreadsheets, databases, and medical scans. Imagine a bank statement where "compression" changed $1,000 to $1,001. Formats: ZIP, PNG, GIF, FLAC, ALAC.

Lossy: throw away what you won't notice

Lossy compression permanently removes some data. It targets irrelevance: detail that humans can't see or hear, or won't notice. Your eyes are much better at seeing changes in brightness than changes in colour; your ears can't hear a quiet sound right next to a loud one. Lossy codecs exploit these limits.

Because it can discard data, lossy compression gets far smaller files, often 10 to 100 times smaller. The trade-off: once data is thrown away it can never be recovered. Formats: JPEG, MP3, AAC, H.264, WebP (which can do both).

So which is better?

Neither. It depends on what the data is and what it's for. Ask yourself:

• Would changing a single bit cause a problem? If yes, lossless.
• Is a human going to look at it or listen to it? If yes, lossy is usually fine.
• Will it be edited again later? Keep a lossless master.
• Is bandwidth or storage very limited? Lossy, with the quality set as high as the budget allows.

Technique 1: Run-length encoding

A run is a sequence of the same value repeated. RLE replaces each run with a count and the value. This row of pixels (W = white, B = black):

W W W W W W B B B W W W W

becomes 6W 3B 4W. Thirteen values have become three pairs.

RLE is brilliant for images with big areas of flat colour: icons, simple logos, fax pages, old-school game sprites. It's terrible for photos or noisy data, where neighbouring values are rarely identical. Then every "run" is a length of 1, and storing a count as well as the value makes the file bigger.

Technique 2: Dictionary compression

Instead of runs of one value, dictionary methods look for repeated sequences: whole words, phrases or byte patterns. Each repeat is swapped for a short code, and a dictionary records what each code means.

The famous LZ family of algorithms (named after Abraham Lempel and Jacob Ziv, 1977) does this cleverly: instead of a separate dictionary, it points back to text it has already seen, like "copy the 12 characters that appeared 40 characters ago". ZIP files and PNG images both use a method called DEFLATE, which combines an LZ-style dictionary with Huffman coding.

Technique 3: Huffman coding

Normal text uses a fixed-length code: every character takes 8 bits, whether it's a common "e" or a rare "z". David Huffman, a student at MIT in 1952, realised it's smarter to use a variable-length code: give common characters short codes and rare characters long ones. Morse code uses the same idea (E is a single dot).

How to build a Huffman code:

1. Count how often each character appears (its frequency).
2. Treat each character as a little tree with one node. Take the two with the lowest frequencies and join them under a new parent whose frequency is their total.
3. Repeat until everything is joined into one tree.
4. Label every left branch 0 and every right branch 1. A character's code is the path from the top of the tree down to it.

Because every character sits at the end of a branch, no code is the start of another code. This is called the prefix property, and it means the decoder never gets confused about where one character ends and the next begins, even with no gaps between codes.

From wave to numbers

Sound is a wave of air pressure. A microphone turns it into a smoothly changing voltage. To store it digitally, an analogue-to-digital converter measures that voltage thousands of times per second. Each measurement is a sample.

Two settings decide the quality and the size:

Why 44.1 kHz? Humans hear roughly 20 Hz to 20,000 Hz. The Nyquist theorem says you need to sample at at least twice the highest frequency you want to capture. Twice 20 kHz is 40 kHz, plus a little safety margin.

If you sample too slowly, there aren't enough measurements to describe a fast wave, and the samples end up matching a slower wave just as well. When the computer plays them back it produces that slower wave instead, so a high note is recorded as a lower note that was never there. This error is called aliasing, and you can hear it for yourself in the next activity.

How big is raw audio?

Uncompressed audio (a WAV file, for example) is easy to calculate:

size in bits = sample rate × bit depth × channels × seconds

Divide by 8 for bytes. A 3-minute song at CD quality: 44,100 × 16 × 2 × 180 = 254,016,000 bits = 31,752,000 bytes ≈ 31.75 MB. That's why nobody streams raw CD audio.

The number of bits per second is the bitrate. For CD audio it's 44,100 × 16 × 2 = 1,411,200 bits per second, or about 1,411 kbps.

Lossless audio: FLAC

FLAC (Free Lossless Audio Codec) predicts each sample from the ones before it, then stores only the small difference between the prediction and the real value. Small numbers need fewer bits. Music typically shrinks to around 50 to 60% of its WAV size, with zero loss. Musicians and audiophiles use it for archiving.

Lossy audio: MP3, AAC and Opus

Lossy audio codecs rely on psychoacoustics: the science of how we actually perceive sound. They split the sound into many frequency bands, then use a psychoacoustic model to decide which parts you won't notice missing. Main tricks:

• Cutting what's out of range. Very high frequencies (above about 16 to 18 kHz) are hard for most people to hear, especially as they get older. At low bitrates they're simply removed.
• Frequency masking. A loud sound hides quieter sounds at nearby frequencies. If a cymbal crashes, the codec doesn't waste bits on a soft sound right next to it in pitch.
• Temporal masking. A loud sound also hides quiet sounds that happen a few milliseconds before or after it.
• Joint stereo. Left and right channels are often nearly identical, so the codec stores what they share once, plus the small differences.
• Huffman coding packs whatever's left, losslessly. Your Part 3 skills show up again.

The quality setting is the bitrate. 128 kbps MP3 is about 11 times smaller than CD audio; 320 kbps sounds essentially identical to the original for most listeners. Newer codecs like AAC (used by Apple) and Opus (used by many voice and video apps) get better quality than MP3 at the same bitrate.

Images are grids of numbers

A bitmap image is a grid of pixels. The resolution is its width × height in pixels. The colour depth is how many bits store each pixel's colour:

size in bits = width × height × colour depth

A 1920 × 1080 screenshot in 24-bit colour: 1920 × 1080 × 24 = 49,766,400 bits ÷ 8 = 6,220,800 bytes ≈ 6.2 MB.

Lossless images: PNG and GIF

PNG first applies a "filter" that stores each pixel as its difference from its neighbours (in smooth areas those differences are small and repetitive), then compresses the result with DEFLATE, the same LZ + Huffman combination used in ZIP. GIF limits the image to a palette of 256 colours and uses a dictionary method called LZW.

Lossless formats are perfect for logos, diagrams, icons, screenshots and text: sharp edges and flat colour, where lossy artefacts would be obvious. They are poor for photos, where no two neighbouring pixels are quite the same.

Lossy images: how JPEG works

JPEG is designed for photographs. It uses two facts about human vision: we notice brightness detail far more than colour detail, and we notice gradual changes more than tiny, fine detail. Here's the recipe:

1. Change colour space. Convert RGB into Y (brightness, called luma) plus Cb and Cr (two colour channels, called chroma). Lossless on its own.
2. Chroma subsampling. Store colour at a lower resolution, often a quarter of the pixels, while keeping full brightness detail. Lossy.
3. Split into 8×8 blocks. Each block of 64 pixels is processed separately.
4. Discrete cosine transform (DCT). Rewrite each block as a mix of 64 standard patterns, from smooth (top-left) to very fine stripes (bottom-right). Lossless on its own: it's just a different way to describe the same block.
5. Quantisation. Divide each pattern's amount by a number and round it. The fine-detail patterns are divided heavily and often round to zero. This is the main lossy step, and the "quality" slider controls how harsh it is. Lossy.
6. Pack it up. Read the values in a zigzag so the zeros bunch together, then use RLE and Huffman coding. Lossless. Parts 3 and 5 meet!

Why video needs compression the most

Video is a sequence of still images called frames, shown quickly enough to look like motion. The frame rate is frames per second (fps): 24 fps for films, 30 or 60 fps for TV, games and phone video.

size in bits = width × height × colour depth × frame rate × seconds

One second of 1080p at 30 fps in 24-bit colour: 1920 × 1080 × 24 × 30 = 1,492,992,000 bits, about 1.5 gigabits every second. A typical home connection can't come close to that, yet streaming services deliver good-looking 1080p at around 5 Mbps. That's a ratio of roughly 300:1.

Two kinds of video compression

Spatial compression (also called intra-frame) squeezes each frame on its own, much like a JPEG. It removes redundancy within one picture.

Temporal compression (inter-frame) removes redundancy between frames. In most video, very little changes from one frame to the next: a person talking in front of a still background might only move their mouth and eyes. So why store the whole background 30 times per second?

Streaming video usually uses a bitrate budget: a limit on how many bits per second can be sent. When a scene has lots of unpredictable change, like snow, confetti, water spray or a crowd jumping, the P-frames suddenly need far more data. If the budget can't grow, the encoder has to throw away more detail, and the picture turns into a blocky smear. That's the reason behind the Tom Scott video below.

Codecs and containers

A video file like holiday.mp4 is a container: a box holding a compressed video stream, a compressed audio stream, subtitles and information to keep them in sync. MP4, MOV, MKV and WebM are containers. The codec is how each stream inside was compressed.

Streaming services also use adaptive bitrate streaming. Each video is encoded several times at different resolutions and bitrates, chopped into short chunks. Your player measures your connection and switches between versions chunk by chunk. That's why a video sometimes goes blurry for a few seconds and then sharpens again.

This practical has three stations. Every result you get is saved on this page and goes into your practical report at the bottom. Your files never leave your computer: all the compression happens inside your browser, and nothing is uploaded anywhere.

No files of your own? Every station has sample files you can use instead. Using some of your own as well will give you more interesting results.

gzip uses DEFLATE, the same LZ-dictionary-plus-Huffman method inside ZIP files and PNG images. It works on any file. Your job: find out which kinds of file it can shrink, and prove that nothing is lost.

Now you'll save one photo at several JPEG quality settings (and as PNG and WebP) and measure exactly what's lost. The difference map shows where the compressed image differs from the original: black means identical, bright means a big difference (made 8 times brighter so you can see it).

First, find out how compressed an audio file you already have is by comparing it with the raw PCM data inside it. Then re-encode 8 seconds of it at three bitrates and listen for the difference. Headphones help.

This task has four parts. Parts A, B and C are marked automatically when you lock them in, and you can only lock them in once, so check carefully. Part D is written and marked by your teacher against the rubric at the bottom. When you're finished, download your PDF and submit it to your teacher.

Your answers are saved in this browser as you go, but save your PDF before closing the page on a shared computer.