Colour Glyphs — When a Picture Paints a Thousand Words (Literally)

October 2, 2025 Peter Hughes 5 min read

We've all heard the phrase: a picture paints a thousand words. But what if a picture could literally contain those words and more?

Back in my earlier post, I shared an experiment I'd started called Colour Glyphs — a way of encoding data using coloured blocks instead of black and white squares.

The idea was simple: what if machine-readable codes could be expressive, creative, and compact, not just functional?

Since then, I've taken the concept through an MVP, added framing headers, even tested type-awareness, and now I've reached a natural conclusion point. This post wraps it all up.

From Bytes to Colours

Here's how it works:

  1. Take any file — text, MP3, an ID, even a URL.
  2. Split the bytes into smaller 4-bit units called nibbles.
  3. Map each nibble to one of sixteen colours in a fixed palette.
  4. Arrange them into a square grid with a quiet white border.
  5. Export the result as an image.

The decoder simply reverses the process, reading each colour back into nibbles and reassembling the original file.

In short: data in → colour out.

Painting With Structure: Frame Headers

If we stopped here, the colours alone wouldn't be enough. How would a decoder know where the data starts and ends? What kind of content it is? Whether the data is intact?

That's where frame headers come in. Think of them as the invisible brushstrokes that give the picture its meaning.

Every Colour Glyph begins with a structured header containing:

  • Magic Bytes — Marks this as a Colour Glyph (CG)
  • Version — Which format version is in use
  • Type — What kind of data (text, URL, binary, etc.)
  • Length — Number of bytes in the payload
  • CRC32 — A checksum to ensure integrity
  • Payload — The file's actual data
  • Padding — Extra filler to square the grid

Error Correction: The Next Layer of Paint

Even with structure, a single smudge or blurred square could break decoding. The solution is Reed–Solomon error correction, the same method that keeps CDs, QR codes, and spacecraft signals usable even when damaged.

Adding Reed–Solomon means:

  • Misread squares can be corrected.
  • Missing chunks can be reconstructed.
  • Designers can balance payload size against robustness.

It's like painting backup colours into the glyph so it can heal itself when parts are lost.

Why Does This Matter?

Because once data lives as a picture, new possibilities emerge:

  • Digital passports: colourful stamps for tours or memberships
  • Creative puzzles and games: codes that are both art and information
  • Branding and design: expressive alternatives to black-and-white QR codes
  • Compact data sharing: small, portable messages embedded in posters or print media

Each glyph carries both utility and personality.

Closing Thoughts

The natural next step would be adding full Reed–Solomon error correction so Colour Glyphs can survive smudges, blur, or missing squares — just like QR codes do. That's definitely possible, but it's a bigger leap.

For now though, I'm happy to call this experiment "signed off". It's a neat proof-of-concept that I may revisit in the future, but it's not something I'm actively working on right now.

A picture has always been worth a thousand words. With Colour Glyphs, a picture can be those words — and more.

For me, this was about exploring how far we could push a simple idea: could we take raw data and make it visual, expressive, and portable? The answer is yes. And while I may leave Colour Glyphs here for now, I think the door is open for them — or something like them — to play a role in how we share offline data in the future.