How AI Actually "Sees" Your Images (Not What You'd Think)

I've spent the last few weeks getting an AI model to QA feature images for this blog — catching a misspelt "Database," spotting a duplicate label ghosting behind the real one, checking whether a hex colour genuinely matched across seven different generated graphics. It's useful. It's also made me curious about something most people using these tools never actually ask: what is it doing when it looks at an image?

Not "how do I get better prompts out of it." The actual mechanism. Here's what I found out, and where it still falls over.

It's Not Looking at a Description

The first assumption worth killing: the model isn't reading a caption someone else wrote, and it isn't running old-school image recognition that spits out labels like "server, cyan, text." It gets the actual pixel data, and processes it directly alongside whatever text you send with it.

What actually happens to your image

The image is resized to a working resolution, then carved into a grid of small square patches—typically 14×14 or 16×16 pixels each. A 1,000-pixel-wide image becomes a few thousand patches.

Each patch is then flattened into a list of raw pixel values and pushed through a learned linear projection, turning it into a single vector—a few thousand numbers that encode what the patch contains. That vector lives in the same mathematical space as the model's text embeddings. This is the part that matters: a patch of your diagram and the word "diagram" end up as the same kind of object, sitting in the same coordinate system.

Because a bag of patches would lose all spatial information, each one also gets a positional encoding — the model's record of where in the grid that patch sat. That's what lets it reason about above, behind, and overlapping, rather than just present.

Those patch vectors are then interleaved with your text tokens and run through the same attention layers. When you ask "does the cyan in this graphic match #00B2EE," the words in your question and the image patches attend to each other directly, in one pass.

How this differs from the older approach

The systems most people have in their heads work fundamentally differently, and the difference is a bottleneck.

Classic image classifiers — the ResNet-era models behind "this photo contains a cat" — take an image and output a probability distribution over a fixed, closed list of categories. Ask one about a hex code, and there's no mechanism for the question to exist. It answers one question, decided at training time.

Image captioning systems went a step further: an encoder compressed the image into a fixed-length representation, and a separate decoder generated a sentence from it. Better, but everything downstream then reasoned over the sentence. If the caption said "a diagram with blue boxes and labels," the misspelling inside one of those labels was already gone. The detail didn't survive the compression into text.

And OCR was a third, separate pipeline entirely — bolted on, run independently, with no awareness of what the rest of the image looked like or what you'd actually asked.

The patch-embedding approach removes the text bottleneck in the middle. Nothing gets summarised into a sentence before the model reasons about it. That's why it can read small embedded text, compare a swatch against a hex code you supplied, and notice that one label overlaps another — all in the same request, without three separate tools.

Worth being precise about what that does and doesn't buy you, though. Removing the text bottleneck doesn't mean removing all compression. The resize step and the patch projection are both lossy, and that's exactly where the failure modes below come from. The bottleneck moved; it didn't disappear.

Where This Held Up, In Practice

A few concrete examples from actually doing this on real posts, not a demo:

• Catching an embedded typo. One of my AI-generated feature images had "Database Query Cache" misspelt as "Databsse Query Cache" inside the graphic itself. That's not something you'd catch from a filename or a prompt — it required reading the actual rendered text inside the image.
• Spotting a duplicate label. Another image had a garbled second copy of a label sitting behind the correct one — "Perrendered HTML" ghosting behind "Pre-Rendered HTML." Catching that meant noticing two overlapping text shapes, not just one.
• Checking style consistency across a set. Across seven separate images, it could tell me which one didn't match the established isometric-diagram, dark-navy-and-cyan look of the others — a compositional judgement, not a text one.
• Flagging pseudo-text in generated diagrams. Image generators love producing things that have the shape of text without being text — plausible-looking character strokes that resolve into nonsense when you actually read them. At thumbnail size, it passes completely. Asking the model to transcribe every string in a graphic and tell me which ones aren't real words catches it in seconds, and it's now a standing check on anything generated.
• Testing legibility at the size people actually see it. The feature image on a post is displayed at a fraction of its native resolution, and smaller still in a card on a phone. Downscaling an image before showing it to the model and asking what it can still make out is a reasonable proxy for whether a label is doing any work at all in the size it ships at. If the model can't read it at 400px wide, a reader on a train probably can't either.

None of that is exotic. But it's a genuinely different thing from "AI can look at pictures now," which is the vague version most people have in their head.

Where It Still Breaks

The honest part, since a testing-first blog shouldn't dodge the failure modes: it's not infallible, and the ways it fails are worth knowing before you rely on it for anything that matters.

Small or blurry text is genuinely hit-or-miss. If a label in an image is tiny or slightly out of focus, the model can misread it with real confidence — not a hedge, a wrong answer stated plainly. I've had this happen with faint overlapping text before, and I only caught it because I zoomed in myself afterwards.

Why counting is a weak spot

This one has a mechanical explanation, and it's more interesting than "models are bad at maths."

Attention is a soft, content-based lookup. It's extremely good at asking "is there something like X in this image," because that's a similarity question — it pools together everything that resembles X. But pooling is the opposite of counting. Counting requires treating each instance as a distinct item and keeping a running tally.

Identical repeated elements are the worst case here, because they produce near-identical patch embeddings. The seventh icon in a row of identical icons looks, mathematically, almost exactly like the fourth. Positional encoding gives the model some ability to tell them apart. Still, nothing in the architecture individuates them the way a person pointing a finger at each one in turn does.

There's also no loop. A forward pass through the network has a fixed number of layers, whether you asked it to count three things or forty. There's no register that increments, no iteration that runs until it reaches the end of the row. Whatever number comes out has to be produced in one shot.

And the training signal is thin. Captions on the open web say "a grid of icons," not "a grid of seventeen icons." The model has seen enormous evidence for what things are and very little for exactly how many. What it learns instead is approximate numerosity — reliable for small quantities, degrading into estimation beyond that. Which is roughly how human glance-counting works too, except we know to stop and count properly.

Why fine colour distinctions slip

Same underlying cause, different symptom: patch projection is lossy compression optimised for meaning, not measurement.

By the time a patch becomes a vector, it has already been resized, resampled, and squeezed into a representation trained to capture what this region is — a dark background, a glowing edge, a boundary between two shapes. Nothing in that objective rewards preserving an exact RGB triplet. Colour survives roughly as a category, the way a person would say "navy," not as a number.

So when you ask whether something is exactly #0A2647 , the model isn't reading a value. It's inferring a colour name from a compressed representation and reasoning about whether that name is consistent with the hex you gave it. That's a genuinely different operation from what a colour picker does: it looks up one pixel's stored value and reports it exactly.

Add that the file has usually been through lossy compression before the model ever sees it, that colour profiles aren't part of the picture at all, and that "is this the right navy" is a question the pipeline was never built to answer precisely. It'll catch an obviously wrong colour. It will not replace an eyedropper.

Dos and Don'ts for Reviewing Your Own Visual Work

The short version, if you want to use this on your own images:

Do:

• Ask it to transcribe every piece of text in the image, verbatim, before asking anything else. Typos and pseudo-text surface immediately.
• Please include the intended spec in the prompt—the brand colours, the layout, and what the graphic is meant to communicate—so it has something concrete to check against rather than a vague sense of "does this look right?"
• Use it for comparison across a set. Consistency judgements across several images are where it's strongest and where your own eye is weakest, because you've been looking at them all week.
• Downscale the image and re-ask to test whether it still works at the size readers actually see.
• Ask it what the image communicates without telling it your intent first. If the answer doesn't match what you meant, that's a design problem, not a model problem.

Don't:

• Don't trust exact counts of repeated elements. Count them yourself; it takes ten seconds.
• Don't use it as a colour picker. Use an actual colour picker.
• Don't accept a confident reading of small or low-contrast text without zooming in yourself.
• Don't ask leading questions. "Is the text spelt correctly?" invites agreement; "transcribe the text" produces evidence.
• Don't treat a clean pass as sign-off. It's one check in the pipeline, not the gate.

The Practical Takeaway

If you're using AI to check visual work — feature images, screenshots, diagrams — treat it the way you'd treat a junior reviewer with genuinely good eyes but no accountability for being wrong: useful for a first pass, good at catching things you'd otherwise skim past, but not a replacement for actually looking yourself before something ships. I still zoom into every image myself before it goes live on this blog. The AI catches things faster; it doesn't catch everything.

That's not a knock on the technology. It's just the same rule that applies to any test you didn't write yourself: know what it actually checks, and don't assume coverage you haven't verified.