Why compress?
Raw pictures and sounds are huge. In Topics 5 and 6 you worked out the sizes. Compression makes files smaller, so they take less space and travel faster.
Storage. A phone holds about 10 times more photos and songs.
Bandwidth: faster downloads and streaming. A connection carries a fixed number of bits each second. Fewer bits = less waiting.
Less mobile data and lower cost. Mobile plans charge by the gigabyte. Companies pay for every byte they store and send.
Some things only work compressed. Raw Full HD video at 30 frames a second is about 1.5 gigabits every second. Streaming it raw is impossible for almost every home connection.
By hand: how big is one second of raw HD video?
One Full HD frame: 1920 × 1080 = 2,073,600 pixels.
× 24 bits per pixel = 49,766,400 bits per frame.
× 30 frames a second = 1,492,992,000 bits ≈ 1.5 billion bits per second (1,500 Mbps).
A typical home connection is 50–100 Mbps. Streaming services send HD at about 5 Mbps. That's about 300 times smaller, all thanks to compression.
Lossless vs lossy
There are two families of compression. Lossless rewrites the data more cleverly, and gets back every single bit. Lossy throws away detail for ever, to make the file much smaller.
| Lossless | Lossy | |
|---|---|---|
| What happens | Writes repetition and patterns more cleverly | Removes detail for ever |
| Original back? | Yes, exactly, bit for bit | No: a close copy |
| Size saving | Medium (often 2–3 times smaller) | Large (often 10 times smaller or more) |
| Methods | RLE, Huffman coding, ZIP | JPEG, MP3, AAC, MP4 (H.264) |
| Used for | Text, code, spreadsheets, PNG, ZIP, FLAC | Photos, music, video, streaming |
Text and code. One wrong bit can change a letter, a number or an instruction. "Pay £100" could become "Pay £900". A program with one changed bit may crash.
Also: medical scans (a missing detail could be a tumour), legal documents, bank records, and any file you will edit and save again and again (each lossy save loses more).
By hand: ratio and percentage saved
A 48-bit message is compressed to 9 bits.
Ratio: old ÷ new = 48 ÷ 9 = 5.33. It's 5.33 times smaller. Write it "5.33 : 1".
Fraction left: new ÷ old = 9 ÷ 48 = 0.1875. So 18.75% of the file is left.
Fraction saved: 1 − 0.1875 = 0.8125.
Percentage saved: 0.8125 × 100 = 81.25%.
Shortcut: saved bits ÷ old bits × 100. (48 − 9) ÷ 48 × 100 = 39 ÷ 48 × 100 = 81.25%. Same answer.
Run-length encoding (RLE)
RLE is lossless. A run is the same thing repeated in a row. Instead of writing it out every time, write how many, then what.
Start with AAAABBBCCD (10 characters).
Four A's in a row → 4A.
Three B's → 3B.
Two C's → 2C.
One D → 1D.
Result: 4A3B2C1D. 8 characters instead of 10. Ratio 10 ÷ 8 = 1.25. Saved 2 ÷ 10 = 20%.
ABCD becomes 1A1B1C1D: twice as long. RLE only helps when things repeat next to each other. "BANANA" has three A's but never two in a row, so RLE makes it worse.
Decoding: turn it back
Read 3W2B5W in pairs: (3, W) (2, B) (5, W).
Write each letter that many times: WWW · BB · WWWWW.
Join them: WWWBBWWWWW. Exactly the original: that's what lossless means.
AQA 8525 asks you to RLE-encode data as frequency/data pairs, e.g. 4 A 3 B, or for a bitmap 8 0 3 1. OCR J277 only expects you to know lossy vs lossless and their uses, not RLE or Huffman by name.
RLE on a black-and-white image
Remember 1-bit images from Topic 5: 1 = black, 0 = white. Pictures often have long runs of the same colour. RLE stores each run as a count and a colour.
Paint a row, then compress it
Tap pixels to switch them between white and black. Each run costs 6 bits (5 for the count, 1 for the colour).
Why is RLE good for cartoons and screenshots but bad for photos? Cartoons have big areas of exactly the same colour: long runs. In a photo, neighbouring pixels are almost always slightly different, so most runs are only 1 pixel long.
Huffman coding: build the tree
Huffman coding is lossless. ASCII gives every character 8 bits. Huffman gives common characters short codes and rare ones longer codes. It builds a tree to decide the codes.
Count each letter in BANANA: A = 3, N = 2, B = 1. This is the frequency table.
Sort smallest first: B(1), N(2), A(3).
Join the two smallest: B(1) + N(2) → a new node worth 3. Put it back in the list: A(3), node(3).
Join again: A(3) + node(3) → 6. Only one tree is left, and 6 is the length of the word. Done.
Label branches: left = 0, right = 1.
Read each code by walking from the top to the letter: A = 0, B = 10, N = 11.
Encode: B A N A N A → 10 0 11 0 11 0 → 100110110 = 9 bits. 8-bit ASCII needs 6 × 8 = 48 bits.
How does the decoder know where each code ends? No code is the start of another one (0, 10, 11). This is called a prefix code. Read left to right, and the first code that matches is always right. 1 → not a code yet. 10 → B! Then 0 → A! And so on.
When two totals are equal, you may pick either. Different choices give different codes, but the same total number of bits. Exam mark schemes accept any correct tree.
Build a Huffman tree for any word
Type a word or a short sentence. Step through the merges one at a time, then read the codes off the tree.
Huffman builder
How many bits did Huffman save?
To count the total, you don't need to write out the whole bit string. For each letter: how many times it appears × the length of its code. Add them up.
By hand: from a code table
| Letter | Appears (n) | Code | Length (L) | n × L |
|---|---|---|---|---|
| E | 5 | 0 | 1 | 5 |
| T | 3 | 10 | 2 | 6 |
| A | 2 | 110 | 3 | 6 |
| Z | 1 | 111 | 3 | 3 |
Multiply each row: 5 × 1 = 5, 3 × 2 = 6, 2 × 3 = 6, 1 × 3 = 3.
Add them: 5 + 6 + 6 + 3 = 20 bits with Huffman.
Total letters: 5 + 3 + 2 + 1 = 11. In 8-bit ASCII: 11 × 8 = 88 bits.
Saved: 88 − 20 = 68 bits. Percentage: 68 ÷ 88 × 100 = 77.3%. Ratio: 88 ÷ 20 = 4.4.
Real files must also store the tree (or the code table), so the decoder can rebuild the codes. For a short word that table can cost more than it saves. Huffman pays off on long files. Exam questions usually ignore the table.
AQA 8525 asks you to interpret a Huffman tree, write codes from it, and compare the bits with ASCII (7-bit or 8-bit: check the question). Building a tree from scratch is good practice and helps you understand it.
How lossy decides what to throw away
Lossy compression uses perceptual coding: it studies what human eyes and ears notice, and drops what they don't. The file shrinks a lot, and most people can't tell.
JPEG (photos): eyes see fine detail in brightness much better than fine detail in colour. So JPEG keeps brightness for every pixel, but stores colour once for each small block. It also rounds off tiny, fine changes in each 8 × 8 block.
MP3 (music): it removes sounds too high for most people, and quiet sounds hidden under louder ones at the same moment (called masking).
Video (MP4): most of each frame is the same as the one before. So it stores a full frame now and then, and in between stores only what moved or changed.
Lossy demo: squash a picture
A colourful picture drawn by maths. Choose how much to throw away. The right-hand view shows what was lost, made 4 times brighter so you can see it.
Press "256 levels" and "Every pixel" after squashing hard. You get the original back only because the toy redraws it from the maths. A real JPEG has no maths to redraw from: the lost detail is gone for ever. Saving a JPEG again and again loses a little more each time ("generation loss").
Choosing: lossy or lossless?
Ask one question: would losing a tiny bit of detail matter? If yes, use lossless. If no, lossy gives a much smaller file.
| Job | Choose | Why |
|---|---|---|
| Holiday photos on social media | Lossy (JPEG) | Nobody notices, uploads are fast |
| Streaming music or video | Lossy (AAC, MP4) | Must fit through the connection |
| A Python program sent by email | Lossless (ZIP) | One wrong bit can break it |
| A school report or contract | Lossless | Every word and number must be exact |
| An X-ray or MRI scan | Lossless | A lost detail could be missed by the doctor |
| A logo or screenshot with flat colours | Lossless (PNG) | Lossy makes blurry "fringes"; lossless compresses flat colours well anyway |
| Master recording in a music studio | Lossless (FLAC, WAV) | It will be edited many times |
A ZIP file is lossless. It uses ideas like RLE and Huffman together, plus a trick that replaces repeated phrases with a pointer back to where they first appeared. Text files often shrink to a third of their size.
Common mix-ups
The mistakes nearly everyone makes the first time. Read the left side, then the right.
Compression always makes a file smaller.
Not always. RLE on ABCD doubles it. Zipping a JPEG barely helps: it's already compressed.
Lossless means it doesn't get smaller.
It gets smaller and comes back exactly. It just can't shrink as much as lossy.
You can unzip a JPEG back to the original photo.
Lossy detail is gone for ever. Decompressing gives a close copy, never the original.
In Huffman, the most common letter gets the longest code.
The shortest. It's used most, so short codes save the most bits.
In a Huffman tree you join the two biggest.
Always join the two smallest. Rare letters end up deep in the tree, with long codes.
RLE counts every A in the text, like Huffman.
RLE only counts letters in a row. BANANA has no runs at all.
Ratio and percentage saved are the same number.
48 → 12 bits: ratio = 4 (4 : 1), saved = 75%.
Check yourself
Quick questions first. Then endless practice: a wrong answer shows you the working, step by step.