9.3 — Compression: Lossy vs Lossless

Start with what the pixels cost. You already know from 9.2 that a colour is a Color32 — four bytes, one each for R, G, B and A. So one pixel costs four bytes, and a picture's raw size is nothing more than width × height × 4. Here are three real files from your own Assets/Artwork/ folder, with what the file costs on disk — fill the Raw column yourself before you read on:

The gap between those two size columns is the whole lesson. The spike's file is 19.9 times smaller than its pixels and the big level sheet's is 25.6 times smaller than its pixels — and nothing was thrown away to get either number. That is lossless compression.

Lossless: every bit comes back. PNG, ZIP, GIF. The file shrinks because the format found repetition and wrote it down more cleverly, not because it decided any part of the picture was unimportant. Unzip a project and you get the same bytes back, which is why ZIP is what you send somebody when the files matter.

The simplest lossless trick is run-length encoding, RLE: a run of identical values becomes a single (count, value) pair. Two sixteen-symbol rows, one flat and one not:

Raw row (16 symbols):  A A A A A A A A B B B B B B B B
RLE (4 symbols):       8A 8B          8 A's, then 8 B's

Raw row (16 symbols):  1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0
RLE (4 symbols):       (7,1)(9,0)     7 ones, then 9 zeros

Sixteen symbols become four. Now feed RLE the wrong picture — a checkerboard, 1 0 1 0 1 0 ... — and every run is one symbol long, so the file comes out bigger than it went in. A compression scheme is a bet on repetition, and pure noise is the bet lost. Hold on to that: it comes back in Step 3.

Lossy: smaller, and forever changed. The original is not recoverable, because the compressed file is the file now. JPEG images, MP3 audio and streaming video work this way. The trick is to throw away what your eyes and ears barely notice — colour detail in a photograph, quiet sounds underneath loud ones — and keep what they do.

Step 1 — compress by hand. Invent a 16 × 1 "sprite row" (letters or 0/1) and write it out raw, then RLE it. Compute the ratio for a few rows of your own: repetitive rows shrink wildly, and noisy rows RLE can explode. Why does a checkerboard defeat RLE — and what defeats even a clever format? Pure noise, which is why a photograph is the one thing a lossless format cannot rescue.

Step 2 — price your own artwork. Open Assets/Artwork/ and sort by size. The biggest picture in the project is Platformer/OriginalFiles/mainlevbuild.png: 2048 × 2048, 654,657 bytes. Raw it would be 2048 × 2048 × 4 = 16,777,216 bytes, exactly 16 MiB — so that PNG is 25.6 times smaller than the pixels it stores. Do the same arithmetic on two more before you move on: Character/Player/Axe1.png (1152 × 2112) and Top_Down/OriginalFiles/Spike.png (64 × 64). Then find the picture the project ships twice: MainLev2.0.png is 589,301 bytes, and the same 589,301 bytes sit in both OriginalFiles/ and Sliced/.

Step 3 — watch lossless run out of room. Lossless compression does not make everything smaller. It makes uncompressed things smaller. The biggest file in your Assets/ folder is not a picture at all — it is _Scenes/Overworld.unity, 2,377,344 bytes of scene text. Compress it (right-click → Compress, or Send to → Compressed folder) and it collapses to roughly 65,000 bytes: about 36 times smaller, and it still opens as exactly the same scene. Now compress Top_Down/OriginalFiles/Spike.png the same way and it comes out bigger than you started — around 858 bytes against 825.

Those two results are one law, not two quirks. The scene is text that had never been compressed, so there was repetition left to find. The PNG had already been through exactly this, so there was nothing left to find. Compressing a file that is already compressed buys you nothing — which is why zipping a folder of PNGs saves you almost nothing, while zipping a folder of text saves you a great deal.

Step 4 — feel the quality knob, on a file that has one. PNG has no quality setting, because there is nothing to trade. JPEG does. Export one of your sprites as a JPEG at quality 80, then 50, then 20 (Preview, GIMP, or any converter), then zoom to 400% and look at the outline. The halos you can see are the "lossy" in action — a decision about what the eye will forgive, taken before the player ever sees it. At which quality would you stop noticing mid-fight? That threshold, and not zero, is what a streaming service is chasing.