GlideSorter
Smart Card Sorting Machine
Works with MTG, Pokémon, FaB and others

A Simple Example of Card Vectorization

Imagine that each card has only two features — its average visual “redness” and “blueness”. We’ll take a few cards and roughly estimate, by eye, how red and how blue they are, assigning values between 0 and 1. Now each card has its own coordinates, so we can place them on a plane for visualization.

Take a look at the illustration: you’ll see that several reddish cards cluster close together, while a few bluish ones form another group. Somewhere in between, there’s a violet card — a mix of red and blue.

We can easily tell the violet card apart from the others by distance, and we can distinguish the two main clusters from each other. However, within each cluster the distances are too small to be sure of anything.

If we want to tell apart the cards inside these merged clusters, we’ll need to add one more feature, and then another, and another — until all those overlapping cards are finally pulled further apart.

With each new feature, we increase the dimensionality of the space — moving from two dimensions to many. It quickly becomes something the human brain can’t easily grasp. Fortunately, we don’t have to: all we need is to compute the distances between points in this multi-dimensional space, and good old Earth mathematics handles that just fine. ;)

Evaluating Distances Between Vectors

To move forward with development, we first need clear criteria for evaluating the distances between card coordinates in the vector space — in other words, how well we manage to pull them apart.

I thought it would be a good idea to perform augmentation for each card — a procedure that generates several slightly modified versions of the same image. In our case, we don’t need zooming or rotation; shifting the white balance and applying small translations (left-right, up-down) will be enough. These mutations produce 72 augmented variants from a single image.

We’ll then vectorize all of them and look at the cloud of points they form. To make the concept easier to visualize, we can simplify it to a two-dimensional space. The outermost points define a useful parameter: D_aug, the augmentation diameter.

Card Vectorization in Practice

So, the task is to “invent” a transformation that converts the original card images into vectors in such a way that the distances between these vectors remain greater than D_aug.

Ideally, we’d like to keep pushing those vectors further apart while also shrinking D_aug — but in practice, D_aug tends to grow just as fast, meaning most “improvements” turn out to be… well, not that useful. ;)

Only occasionally I managed to find a really good combination of filters, and to make such cases easier to spot, I usually normalized D_aug to 1.0 — it also looks nicer on the charts.

A good indicator of progress can be the ratio Dist_med / D_aug. By comparing this ratio before and after each change, it becomes possible to evaluate how successful the modification actually was.

Preparing for Large-Scale Tests

At last, the time has come to move from small local tests with 100–500 cards to something much larger.

On my RTX 3080 (10 GB), I could process at most about 5000 cards in a single run — and yes, I actually did that — but now it’s time to start filling the database and working directly with it instead.

Vectorizing all 100K+ cards takes roughly 3.5 hours. That’s not exactly blazing fast, and the bottleneck is probably PostgreSQL running inside a Docker container.

Either way, I didn’t dig into it or try to optimize anything — the full vectorization needs to be done only once, and later updates will just add a few dozen new records at a time, which is hardly a problem.

An unbreakable argument! So be it. ;)

First Large-Scale Test

The first large-scale tests revealed several massive clusters — 200–300 cards each — and one gigantic cluster containing 930 cards. That was definitely not what I expected.

It turned out that those 930 cards had no actual images — just placeholder pictures saying “not yet available.” For now, these can be safely removed from the database until real photos appear.

The other clusters, however, turned out to be genuine surprises.

Examples on the screenshot:

• #1, #2 – These cards are hard to recognize because most of the area is plain white with almost no distinct visual features. The small text area doesn’t help either — our vectorizer wasn’t trained to interpret text.
• #3 – These cards share the same illustration — an MTG logo — covering about half of the image, with the rest being text. They genuinely have a lot in common, so it’s understandable that the vectorizer struggled.
• #4 – Visually similar cards with low-contrast, noisy artwork. There were several such groups in different dominant tones — blue, red, and so on.
• #5 – All the illustrations and other useful details are drawn with thin lines, which our vectorizer interpreted as text and simply ignored.

Interim Results of the First Major Test

For the first three groups, recognition without OCR is practically hopeless. So for now, I decided to remove those cards from the database and treat them as unknown during sorting to avoid misclassification.

As for the remaining groups — they clearly needed more work. And yes, that meant running the full 3.5-hour vectorization process several more times… ;) but in the end, it paid off — the fix that solved these groups ended up improving recognition quality across all cards.

Great things are best seen from afar

I really wanted to see the overall distribution of distances across all 100K+ MTG cards — how they relate to each other in the global vector space.

We can load all vectors into VRAM — that takes only about 0.3 GB (100K+ vectors, float16, 1680 dimensions). However, keeping all 5 billion distances in memory would be far beyond what VRAM can handle.

That leaves two choices:

1. Store temporary results on disk — slow but simple.
2. Process distances in batches and accumulate data directly into a histogram.

Automated Processing of Merged Vectors

We can iterate through all vectors in the database and, for each one, find all nearest neighbors within D_aug = 1.0. This makes it possible to detect chains of visually similar cards, which — by linking together — form complete clusters of similar cards.

Once the clusters are formed, we can compare their sorting attributes (name, type_text, color, mana_value, mechanic, and type). Within a single cluster, these values should be identical. If any differences are found, the cluster is considered “dirty”, and the mismatched cards must be excluded and flagged for manual inspection.

This relatively simple procedure should significantly reduce the number of cards that require manual review, while also helping to identify inconsistencies in the database describing sorting attributes.

After processing, we end up with 46 680 single cards that didn’t belong to any cluster — meaning they are either highly unique or were excluded as “dirty”.

The process also identified 18 240 reprints, the largest cluster containing 39 cards. However, it’s worth noting that this card was probably printed many more times — our vectorizer simply didn’t include some versions whose visual appearance differs significantly.

Distribution of Single Vectors

Now we’re ready to analyze the vector distribution again — this time using only single cards, meaning those that have no neighbors within D_aug.

Visually, the plot looks almost the same, but now, from 46,680 single cards, we get “only” 1 billion pairwise distances. What matters most is this: there are now just 1 033 pairs of cards with distances smaller than D_aug.

Since in this test we excluded all cards that had neighbors, we expected to have no pairs at all with a distance smaller than D_aug — and that would mean the vectorizer had done its job and the work was finished.

Taking a Closer Look at the “Dirty” Cards

Let’s write another small helper module to examine these “dirty” cards in more detail. Out of 34 pairs, we actually have 69 unique cards — no problem, that’s expected.

Here are a few examples from the screenshots below, which illustrate the following patterns:

• In most cases, it’s not just a simple reprint — a single-sided card was later released as a double-sided version, which changed its name, mechanics, and even color (from one to two).
• Less often, the mana cost and mechanics change for unclear reasons — it doesn’t look like a misprint, but it’s hard to tell why.
• And in a few rare cases, there are genuine misprints, where a card has nothing in common with its cluster except for the artwork.

Performance Test on Raspberry Pi 5 (8 GB)

After running 200 different card images through the vectorizer, we got a median time of 0.0080 seconds per card — incredibly fast, almost unbelievable.

In the same test, I tried processing the same 200 images in a batch. On a GPU this usually gives a speedup proportional to the batch size, since operations run in parallel — but the Raspberry Pi has no GPU, so everything runs on the CPU. Surprisingly, the result was 0.0053 seconds per card, which means about 1.5× faster — no idea how exactly, but I’ll take it. ;) Batch processing probably won’t be needed in practice anyway — this was mostly a test for academic curiosity.

So, the original goal for the Raspberry Pi 5 (8 GB) was to stay within 0.14 seconds per card, and we achieved 0.008 seconds — which means only one thing: we’ve done far better than even the wildest optimistic expectations.

Ah, here it comes again — that feeling… mmm… somebody stop me! ;)