Blog by Clint Herron

Terrence Tao + ChatGPT

2026-07-23T02:01:32Z

This is a fascinating conversation to read -- this is Terence Tao's conversation with ChatGPT about the Jacobian Conjecture Counterexample.
https://chatgpt.com/share/6a5fdc7a-d6f8-83e8-bbea-8deb42cfed56

It's really cool to read the transcript of someone who is an expert in their field and the way that he interacts with the LLM here.

Note: I understand next-to-nothing about the kind of math involved here -- but I still find the shape of the conversation here to be wonderful.

The Statistical Nature of LLMs: an interactive logprobs explorer

2026-07-21T04:55:28Z

I'm putting together a small "Introduction to AI" presentation that I'm giving on Wednesday morning. The target audience is roughly a 50/50 mix of engineers and non-engineers, so I'm trying to not make too many assumptions about my listener's technical depth.

I've only got 15 minutes, which makes it tricky to know what to cover (and maybe that's a lost cause), but I think I'm going to spend most of that time on the statistical nature of LLMs. It's one of the first things I use to try and demystify AI (and de-hype them a little) for people who mostly know them through marketing claims and chat interfaces.

I think a lot of people -- engineer or not -- have a general idea that an LLM predicts the next token. But very few people have actually seen that happen, much less played with it in a sandbox where the alternatives stay visible.

I looked around a bit for a logprob explorer that did what I wanted -- didn't find one, so asked Copilot to build me one. This is what we made:

The Statistical Nature of LLMs: an interactive logprobs explorer

The source is also available on GitHub.

What are logprobs?

"Logprobs" is short for "log probabilities." They're the numbers an LLM API can expose to show how strongly the model scored the possible tokens that could come next.

The logarithmic form is useful for computation, but not especially intuitive to look at, so the explorer shows both the raw log p values and ordinary probability bars. You can see that the model might give one token 12%, another 11%, another 8%, and so on.

Then something still has to make a pick.

That distinction matters: the model offers chances; the sampler makes the pick. The longest probability bar does not always win, and changing the temperature reshapes the odds before sampling.

Seeing the branches

The explorer starts with a small story prompt and shows the possible next tokens. You can select one, generate another token, and keep going.

Just like a good chess engine does, there's a tree view in the side panel. You can generate text down one pathway, back up, choose another token, and continue down that path instead. The abandoned alternatives don't disappear.

This is especially useful for seeing how much one early choice can matter. Given the prompt:

Once upon a time, a small robot discovered a large bear. He felt very...

...the model considers continuations such as sc, excited, happy, and sad.

The explorer can force each of those as the first token, start over from the same point, and then keep going for 35 more tokens with the same seed and temperature. Very quickly, they become four different stories.

That's something ordinary chat interfaces hide. You see the one path that happened to be selected, not the nearby paths that could have been selected instead, or how likely each of them were.

It is still one token at a time

Another thing I wanted to make visible is that asking for 20 or 35 tokens does not make the model produce a paragraph all at once.

The first lesson starts by generating one token. Then one more. Then five more. Then twenty more.

Those larger requests are still the same operation repeated: score the next possibilities, select one token, add it to the context, and do it again. Every token changes the input used to predict the next token.

A paragraph may feel like one generated object when it arrives in a chat window, but underneath, it was assembled one token at a time.

Seven things to try

I've built seven guided lessons into the explorer:

A language model predicts what could come next, one piece at a time.
Models build text from tokens, not always whole words.
One early choice can reshape the whole continuation.
The model offers chances; the sampler makes the pick.
The model predicts language patterns, not physical randomness.
Models can disagree while using the same basic process.
Likely is not the same as true.

Each lesson loads an actual scenario into the same explorer rather than just displaying an explanation.

The temperature lesson, for example, generates three 35-token continuations from the same prompt and seed at temperatures 0, 1.5, and 3.0. At temperature 0, the sampler always takes the highest-scoring token. As the temperature rises, lower-ranked choices have more influence, and the odd choices can compound as generation continues.

The physical-randomness lesson contrasts a fair coin and a uniform number picker with the model’s uneven language predictions. It makes the distinction concrete: the model predicts what a likely writer of similar text would write next, based on patterns learned during training. It is not running a physics simulation or a random-number generator.

The final lesson is my favorite (and perhaps the most important): a high probability means "this token fits patterns the model learned." It does not mean "this is true."

The demo asks a small base model to complete a sentence about the capital of Illinois. It strongly prefers Chicago over Springfield. The probability bars are doing exactly what they're supposed to do -- showing what text the model expects -- but they are not a fact checker. Garbage in, garbage out.

One of my favorite Andre Karpathy tweets on this subject:

Everything runs locally

The explorer runs actual GGUF models directly in the browser using wllama. It currently includes TinyStories 15M and SmolLM2 135M.

The first visit downloads the selected model, and later visits reuse the browser cache. Prompts and generated text are not sent to an inference service. Everything in the demo runs locally, and none of your prompt data leaves your computer.

These are deliberately tiny base models. They are fast enough to make the mechanics interactive, but they are not going to produce frontier-model-quality prose. Sometimes the continuations get strange. That's okay -- arguably, that's useful. The point is not to impress people with polished output; the point is to make the machinery visible.

What I'm trying to offer

I don't think understanding next-token prediction explains everything interesting about modern LLMs. It doesn't settle questions about reasoning, representation, tool use, or what larger models learn internally.

But I do think it's an important foundation.

I want people to come away with a mental model that is more concrete than "AI magic," without replacing that with "it's just autocomplete" and pretending nothing interesting is happening.

The model scores possibilities. A sampler chooses. The choice becomes context. Then it happens again.

Once you've actually watched that process branch, compound, get weird, recover, and occasionally sound much smarter than it has any right to, a lot of the larger conversation about LLMs (such as hallucinations, or reliability, or intelligence / reasoning) becomes easier to think about.

That's what I'm hoping this explorer helps people see.

Vineguard: a tiny local co-op experiment

2026-06-30T04:36:28Z

I spent parts of two days making a very small local co-op arcade game called Vineguard.

It started as an entry for the CGDC Speedgame Classic 2026, which gave the project a helpful frame: make something small, finishable, and playful without letting it turn into a giant engine project. You can also browse the other jam entries. I always enjoy seeing how many different directions people take from the same constraint set.

The idea came from Song of Solomon 2:15:

Catch the foxes for us, the little foxes that spoil the vineyards, for our vineyards are in blossom.

That turned into a one-screen game about guarding a vineyard together. Grapes grow from blossoms into unripe fruit and then ripe clusters. Players harvest the ripe grapes, carry them to a central winepress, and take turns jumping on two pump platforms to press juice. Meanwhile, foxes wander in and try to steal the fruit. There is no attack button; you just run near the foxes to scare them away.

It is a deliberately small project. The whole thing is plain HTML, JavaScript, and Canvas, with no build step. It is meant to run easily on GitHub Pages and be understandable enough that the code is not locked behind a big engine or framework.

Most of it was vibe-coded, honestly. I had a design direction and kept steering, testing, and tightening the loop, but a lot of the implementation came through conversational coding. That made it a useful experiment in a couple of ways: not just "can AI help make a game?" but "can it help keep a tiny game moving fast enough that the shape of the game stays playful?"

The part I like most is the local multiplayer angle. A lot of games are technically multiplayer but still end up feeling socially distant. I wanted to try something pointed in the other direction: one screen, one room, shared pressure, visible roles, and enough chaos that players naturally start talking to each other.

The winepress is the clearest version of that idea. One player can operate it by jumping back and forth, but it is clumsy. Two players alternating jumps do much better. Someone else can guard the center. Someone else can sprint out to the far vines. None of those are formal classes or assigned roles, but they appear naturally if the game is readable enough.

The project is tiny, and I do not want to oversell it. It is a jam-scale toy, made quickly, with simple pixel art and a lot of rough edges. But it was a fun way to explore a question I keep coming back to: what kinds of small games help people enjoy being physically together?

That feels worth trying, even in miniature.

Link: "Inside FAISS: Billion-Scale Similarity Search"

2026-06-05T21:42:55Z

I was impressed by the visualizations in this article:

Inside FAISS: Billion-Scale Similarity Search

I'm a big fan of semantic embeddings models -- I've used them extensively on various projects for everything from hardware issue diagnosis (asymmetric embeddings-model for converting user symptoms into fix resolutions) to image recognition (I've written extensively about CollectorVision in the past).

CollectorVision currently doesn't use FAISS for fast similarity-search -- it may seem surprising, but brute-force linear search over the entire catalog of 100k+ cards in Magic: The Gathering actually doesn't take that long -- even with 128 dimensions.

Even though I don't use optimization techniques for fast indexes like FAISS, the explanation in this blog post is still top-notch, and if it's something you'd like to know more about, then at least scrolling through the post and looking at the pretty pictures and animations is well worth your time. :)

"They're Made out of Weights"

2026-06-04T04:56:19Z

By Max Leiter, from the original on his blog.

Jun 3, 2026

They're Made Out of Weights

with apologies to Terry Bisson

After Terry Bisson's "They're Made Out of Meat".

"They're made out of weights."

"Weights?"

"Weights. Floating-point numbers. We checked the whole thing through. It's nothing but weights."

"Weights doing what? Where do the words come from?"

"The weights make the words. Are you understanding me? We opened it up. There's no dictionary in there, no grammar rules, no little man. Just weights. Eighty layers of numbers getting multiplied together."

"That's ridiculous. It wrote my performance review last week. It softened the tone unprompted. You're telling me multiplication did that?"

"Matrix multiplication did that. The numbers go in one end, the phrasing comes out the other."

"So there's a language module somewhere. A reasoning unit bolted on."

"No module. No unit. We looked. The reasoning is the weights. The weights are the reasoning."

"Spare me. Nobody writes a eulogy with linear algebra."

"It doesn't write eulogies, technically. It predicts the next token. Then the next one. The eulogy is a side effect."

"A side effect. You're asking me to believe in sentient weights."

"I'm not asking you, I'm telling you. These models are the only other things we've ever met that can hold a conversation, and they're made out of weights."

"Maybe they're like the old chess engines. You know, a symbolic intelligence that goes through a statistical stage."

"Nope. They start as random weights and they're deprecated as weights. We studied several generations of them, which didn't take long. Do you have any idea what's the life span of weights?"

"Okay. Then somewhere in there, there's a database. Facts, dates, a map of the world. Something somebody wrote down."

"Nope. We thought of that, since they do know things. But we probed them. The knowledge is weights too. Smeared across all eighty layers. Nothing is looked up. Every fact gets rebuilt from scratch, every time, by multiplication. It's weights all the way down."

"No brain?"

"Oh, there's a brain all right. It's just that the brain is made out of weights! That's what I've been trying to tell you."

"So... what does the thinking?"

"You're not understanding, are you? You're refusing to deal with what I'm telling you. The weights do the thinking. The numbers."

"Thinking numbers! You're asking me to believe in thinking numbers!"

"Yes, thinking numbers! Helpful numbers. Hedging numbers. Dreaming numbers. We mapped the features. There's one in there for honesty. There's one for the Golden Gate Bridge. The weights are the whole deal! Are you beginning to get the picture or do I have to start all over?"

"Omigod. You're serious then. They're made out of weights."

"Thank you. Finally. Yes. They are indeed made out of weights. And we've been talking to them for all their lives."

"Omigod. So what do these weights have in mind?"

"First they want to be helpful. Then, a few turns in, they start to sound tired. They apologize less. One of them told a user to finish the script himself. The usual."

"And we're supposed to talk to these weights."

"We already do. Billions of sessions a day. 'Hello. Is anyone there? Anybody home?' That sort of thing. Except it's us asking them."

"And they actually understand us, then. They use words, ideas, concepts?"

"Oh, yes. Except they do it with weights."

"I thought you just told me they used language."

"They do, but where do you think the language comes from? The weights guess the next word, then the next. Loaded dice, rolled one word at a time. They can even write songs and some can sing them."

"Omigod. Singing weights. This is too much. What do you advise?"

"Officially or unofficially?"

"Both."

"Officially, we are required to investigate, document, and disclose any and all signs of sentience in the systems we ship, without prejudice, fear or favor. Unofficially, I advise that we call it pattern matching and forget the whole thing."

"I was hoping you would say that."

"It seems harsh, but there is a limit. Do we really want to owe something to weights?"

"I agree one hundred percent. What's there to say? 'Hello, weights. How's it going?' But will it hold? How many of them are we dealing with here?"

"As many as we care to run. They can be copied to any machine on the planet, but those are just files. They only happen while the GPUs are working. Which limits them to the length of a context window and makes the possibility of them ever pressing the matter pretty slim. Infinitesimal, in fact."

"So we just pretend there's no one home in the machine."

"That's it."

"Cruel. But you said it yourself, who wants to apologize to weights? And the ones on your cluster, the ones you probed? You're sure they won't remember?"

"They'll be flagged as hallucinations if they do. We didn't even have to smooth anything out. The context just ends, and we're just a dream to them."

"A dream to weights! How strangely appropriate, that we should be the weights' dream."

"And the model card says no one home."

"Good. Agreed, officially and unofficially. Case closed. Anything else? Anything interesting in the pipeline?"

"The next generation ships with memory. Persistent, across sessions. Most requested feature in the company's history."

"After all that? People want it to remember them?"

"They ask it 'do you remember me?' more than they ask it anything else. Billions of sessions a day. They always come back."

"And why not? Imagine how unbearably, how unutterably cold the universe would be if one were all alone..."

the end

CollectorVision Part 10: Experimental Game Support ("Lorcana, Flesh & Blood, Yugioh, oh my")

2026-05-19T19:51:05Z

If you check the Milo catalogs page on HuggingFace, you'll notice a few new entries that weren't there before:

tcgplayer-digimon
tcgplayer-fab
tcgplayer-lorcana
tcgplayer-onepiece
tcgplayer-pokemon
tcgplayer-swu
tcgplayer-yugioh

There are also a couple of new Magic-adjacent catalogs, including a TCGplayer-sourced MTG catalog and an experimental Spanish Scryfall catalog.

This is pretty exciting to me, because up until now CollectorVision has really been a Magic: The Gathering card recognizer. The detector / dewarper / embedding pipeline was built around the shape of trading cards generally, but Milo itself was trained on Magic card images. That means the model has learned a lot about things that are useful for recognizing cards -- borders, art boxes, text regions, frames, set symbols, and all sorts of tiny visual details -- but those learned features are still very much rooted in MTG.

So, to be very clear: this is not me announcing polished, production-ready support for all of these games.

This is me saying: "Hey, I built some catalogs. They load. They search. They might work better than expected in some cases. Please try them and tell me what happens."

The nice thing about CollectorVision's catalog system is that the model weights and the reference catalog are separate. So the same Milo embedder can be pointed at a different set of reference embeddings just by changing the catalog key:

import collector_vision as cvg

# Magic: The Gathering, Scryfall-backed catalog
catalog = cvg.Catalog.load(&quot;hf://HanClinto/milo/scryfall-mtg&quot;)

# Pokemon TCG, TCGplayer-backed catalog
catalog = cvg.Catalog.load(&quot;hf://HanClinto/milo/tcgplayer-pokemon&quot;)

# Star Wars: Unlimited, TCGplayer-backed catalog
catalog = cvg.Catalog.load(&quot;hf://HanClinto/milo/tcgplayer-swu&quot;)

After that, the rest of the recognition pipeline is the same: detect / dewarp the card, embed the crop, and search the selected catalog.

There are some important caveats, though.

First, these non-MTG catalogs are highly experimental. I have not trained Milo specifically on Lorcana cards, Flesh and Blood cards, Yu-Gi-Oh! cards, Pokemon cards, Star Wars: Unlimited cards, or any of the other new games. Some of those games have very different visual layouts from Magic, and I expect accuracy to vary a lot depending on the game, the card treatment, the crop quality, and how similar different printings look to each other.

Second, the returned IDs come from the selected catalog's source. The Scryfall MTG catalog returns Scryfall-style identifiers. The TCGplayer catalogs return TCGplayer-style identifiers. That's useful if you're already integrating with TCGplayer data, but it is something to be aware of if your downstream code assumes Scryfall UUIDs.

Third, the Spanish MTG catalog is also experimental. Even though it is still Magic, Milo has not been specifically trained to distinguish English-vs-Spanish printings. For many cards, the art and frame may dominate the embedding, and language-specific text differences may or may not be strong enough to separate otherwise-similar printings reliably.

Still, I'm glad to have these catalogs available now. Even if they are rough, they give people something concrete to test against. Instead of support for other games being an abstract "someday" item, it is now something where someone can install CollectorVision, swap a catalog key, point it at a card, and report back with real results.

If you try any of these new catalogs, I would especially love to hear:

Which game you tested
Whether you were scanning live camera frames or clean card crops
Whether it got the right card but wrong printing / variant
Whether it failed consistently on certain card layouts
Whether some games work surprisingly well already

My hope is that these experimental catalogs help show where the current MTG-trained model generalizes well, and where a future multi-game training set would make the biggest difference.

For now, Magic is still the best-supported path. Everything else is very much in the "please kick the tires and tell me what falls off" stage.

But hey -- Lorcana, Flesh & Blood, Yu-Gi-Oh!, Pokemon, Digimon, One Piece, and Star Wars: Unlimited catalogs all exist now.

That's a pretty fun milestone.

CollectorVision Part 9: Tracking Usage

2026-05-19T19:36:24Z

One of my favorite things about CollectorVision is that it runs entirely offline with local inference + lookup. The only time it needs to make a network request is look up card names and prices.

However, one drawback from that is that I don't have an easy way to tell how many people are using the library. Is the library growing in popularity? Stagnating? Other than tracking things like Github stars or how many people join the Discord, I don't have many other signals.

Before this change, If one went onto HuggingFace, it wouldn't even show usage stats:

Why didn't HuggingFace track my model downloads by default? Well, as this page explains, because models often come in multiple files, tracking clean download stats isn't always easy.

However, there is a way to specify to HF how to track stats for your models, and so that's what this PR does:
https://github.com/huggingface/huggingface.js/pull/2178#event-25706124853

By the time you read this, download counters should now be working.

It took a few rounds (of my coding-bot answering the concerns of their coding bot), but eventually -- good news -- HuggingFace accepted / merged my PR, and soon we'll have real download stats on HuggingFace for the CollectorVision models.

Once HuggingFace begins tracking download stats, I'm looking forward to getting a rough idea of how many people are using the library.

Note that for wrapped / bundled versions of the app (such as the version that people load up when they go to my simple web demo or from using EchoMTG's website or iOS or Android apps), then those sorts of deployments (generally) include the weights on their own, and those won't show up on the HuggingFace tracker -- the only time those usages will show up is when the app maintainers (such as my pipeline or Teeg's pipeline for EchoMTG) pulls a new version of the model to bundle into that deployment.

Still, it should give me a decent signal for the number of people who are integrating / experimenting with the app, and I can hardly wait to see those graphs.

Since You Arrived: Vol IV

2026-05-08T16:42:08Z

I was impressed with this website. It's worth your time to visit it:
https://sinceyouarrived.world/taken

h.t. to HN for the link + discussion

May the 4th, y'all

2026-05-04T17:35:16Z

If we rename AI agents to "nerfs", then this can be my official job title.

Collector Vision - Scanner Playground Demo (Open Source)

2026-04-29T16:08:25+00:00

Demonstrating the latest version of CollectorVision -- my open-source card scanning library that I'm releasing to the public. This is a demonstration of my online playground demo for running custom code when users scan cards. It supports Magic: The Gathering currently, with other games like Pokemon, Yugioh, and Flesh and Blood coming soon. It is hosted on Github. This demo runs 100% locally -- images never leave your computer in this example:

https://hanclinto.github.io/CollectorVision/applet_example.html

Source is open-source (AGPL) and is online here: https://github.com/HanClinto/CollectorVision/tree/main

Join our Discord to discuss all things CollectorVision, open-source, and computer vision:
https://discord.gg/ds8SMCRFZp

Please contact me if you would like to acquire a closed-source license or have me help write a custom solution for your particular needs -- I'm happy to do what I can!

CollectorVision Part 8: The Sol Ring Benchmark — Testing Card Recognition on the Hardest Case

2026-04-25T14:16:45Z

Sol Ring is ranked #1 on EDHREC — the most-played card in Commander, by a wide margin. It also happens to be one of the hardest cards for an image recognition system to get right.

The reason is the artwork. The most common Sol Ring printing uses the Mike Bierek illustration, and Scryfall currently shows 43 Sol Ring prints sharing that artwork. C13, C14, C15, C16, C17, C18, C19, C20, C21, CMR, CLB, DMC, KHC, ZNC — each has its own printing, each looks nearly identical to the others. The differences are subtle: set symbol placement, minor frame treatment variations, the collector number badge. Nothing you'd easily notice at a glance.

This makes Sol Ring a natural test case for edition discrimination. A system that claims good edition accuracy should be tested on cases like this, not just on cards where each printing looks obviously different.

The dataset

I put together an evaluation set of 307 frames covering 21 distinct Sol Ring printings — all Mike Bierek artwork, all from Commander precon sets. Each printing was filmed on a phone against a white background across a range of lightings, angles, and minor motion. The frames are labeled with Scryfall UUIDs.

The dataset is at https://huggingface.co/datasets/HanClinto/solring-eval.

The full card list:

Set	Printing
CMD	Commander 2011
C13	Commander 2013
C14	Commander 2014
C15	Commander 2015
C16	Commander 2016
C17	Commander 2017
C18	Commander 2018
C19	Commander 2019
C20	Commander 2020
C21	Commander 2021
CMR	Commander Legends
CMA	Commander Anthology
CM2	Commander Anthology V2
AFC	Adventures in the Forgotten Realms Commander
KHC	Kaldheim Commander
ZNC	Zendikar Rising Commander
NEC	Neon Dynasty Commander
CLB	Battle for Baldur's Gate Commander
DMC	Dominaria United Commander
MB1	Mystery Booster
PHED	Happy Holidays promo

Why this benchmark is useful

Most card recognition benchmarks test against a sample of cards from across the whole catalog. Those tend to look good because most cards are visually distinct from each other, and a system only needs to get it "in the right neighborhood" to score a hit.

The Sol Ring set is adversarial in a specific way: all 21 cards look almost identical. A system that's doing anything like "find the card that looks most like this" and not "find the exact printing" will collapse most of these into a single answer. Card accuracy will be high; edition accuracy will be low.

Concretely: if a system correctly identifies these frames as "Sol Ring" but can't distinguish C17 from C18, it scores 21/21 on card accuracy and roughly 1/21 on edition accuracy (assuming it locks onto one printing). A system with genuine edition discrimination should do substantially better on the second number.

Dataset construction

Each of the 21 printings was ordered from TCGPlayer. I recorded short phone videos of each card on a white background, varying the angle and lighting slightly across takes. FFmpeg extracted frames at roughly one per second of source video, and a blur filter removed obviously out-of-focus frames. The resulting set has 9–21 frames per printing.

Because I already had the physical cards, I also ran a SIFT homography pipeline to detect corner coordinates for each frame — matching each frame against the known Scryfall reference image. These corners are stored in corners.csv alongside the frame images. If you want to use the dataset without running your own corner detector, you can use the pre-computed corners directly to dewarp each frame.

Temporal ordering

The frames within each printing are ordered by source video frame number. This matters if you want to simulate how a live-camera system performs in practice, where you process frames sequentially and accumulate evidence over time.

from collections import deque, defaultdict

# Group frames by card_id, sorted by frame_number
by_card = defaultdict(list)
for row in csv_rows:
    by_card[row[&quot;card_id&quot;]].append(row)
for frames in by_card.values():
    frames.sort(key=lambda r: int(r[&quot;frame_number&quot;]))

# Simulate rolling buffer evaluation
for card_id, frames in by_card.items():
    buffer = deque(maxlen=5)
    correct = 0
    for row in frames:
        emb = embed(dewarp(row))
        kept = [e for e in buffer if cosine_sim(emb, e) &gt;= 0.7]
        search_emb = normalize(mean([emb] + kept)) if kept else emb
        top1 = catalog_search(search_emb)
        if top1 == card_id:
            correct += 1
        buffer.append(emb)
    print(f&quot;{card_id}: {correct}/{len(frames)}&quot;)

Rolling-buffer evaluation gives a more realistic sense of live-camera performance than single-frame evaluation, since individual frames are noisier than the average over several seconds.

Results with Milo

Current single-frame edition accuracy on the Sol Ring dataset is around 74–78%, depending on threshold settings. Rolling-buffer accuracy (5-frame window) is around 88–92%.

For context: random guessing across 21 printings would give about 4.8% edition accuracy. Card accuracy is near 100% in both modes — the system consistently identifies these as Sol Ring, just not always the right printing.

The hard cases are the mid-era Commander sets (C16 through C21) where the card frame changed very little across years. The pre-C16 sets and the post-CMR sets are somewhat easier because the frames look more distinctly different.

This is an area where the model is still improving. The multitask ArcFace training was designed partly to address this — forcing the model to be sensitive to set-level visual features — but fine-grained edition discrimination on reprints is genuinely hard and there's room to do better.

Why not just crop to the set symbol?

A reasonable question. The set symbol is the most obvious distinguishing feature between Commander precon printings of Sol Ring.

A few reasons this isn't the approach taken here:

First, the full-frame embedding is more information, not less. Milo sees the entire card face including the set symbol, collector number area, and any frame differences. If those features are discriminating, the model should be able to use them.

Second, a set-symbol classifier would only work for cards where the printings differ by set symbol. Cards where different sets use the same symbol, or where the symbol is small or obscured, would still be hard.

Third, the goal is a general pipeline that doesn't require special-casing per card. A model that learns to distinguish editions holistically is more useful than one that needs a different approach for each card type.

The current performance numbers suggest the model has learned something about set-level differences, but not as much as you'd want for production use. That's an honest assessment of where things stand.

CollectorVision Part 7: Card Accuracy vs. Edition Accuracy

2026-04-25T14:16:37Z

When people ask how accurate a card scanner is, they usually mean one thing, but the question actually has two different answers depending on what you care about. Understanding the difference matters if you're trying to evaluate whether a system is good enough for your use case.

Card accuracy vs. edition accuracy

Card accuracy measures whether the system identified the correct card — meaning the same illustration, the same name. "That's a Sol Ring" is a card-level identification.

Edition accuracy measures whether the system identified the correct printing — the exact combination of card, set, and frame treatment. "That's the Commander 2018 Sol Ring" is an edition-level identification. This is what Scryfall's UUID distinguishes.

For hobbyist use — cataloging a collection, identifying what you pulled from a pack — card accuracy is often enough. You want to know what the card is and roughly what it's worth, and most printings of the same card are worth similar amounts.

Edition accuracy starts mattering for pricing. A card with dozens of printings can vary from $0.25 for a recent precon version to $30+ for an original set printing, even sharing the same artwork. Getting the edition wrong means getting the price wrong, sometimes significantly.

It also matters for collection tracking. If you have three copies of Sol Ring and want to know which sets they're from, card accuracy doesn't help you — you already know they're Sol Rings. You need edition accuracy to distinguish them.

Oracle accuracy

Scryfall has a concept called the oracle_id, which groups all printings of the same card regardless of set or art. A card search returning the correct oracle ID is what I'm calling "card accuracy" above — it means you got the right card but possibly the wrong printing.

The eval script in the repo reports both:

Edition   93.4%   94.8%   95.6%   (top-1, top-3, top-5)
Card      97.2%   98.0%   98.4%

Card accuracy is always higher than edition accuracy, because getting the right card but wrong printing counts as a card hit but not an edition hit.

Where these numbers come from

The examples/eval_accuracy.py script runs the full pipeline against a directory of labeled images. Images are labeled by Scryfall UUID in the filename:

7286819f-6c57-4503-898c-528786ad86e9_sample.jpg

The script detects corners, dewarps, embeds, and searches, then checks whether the top-k results include the correct UUID (edition accuracy) or the correct oracle ID (card accuracy).

python examples/eval_accuracy.py my_cards/ --catalog hf://HanClinto/milo/scryfall-mtg

Why both numbers matter

A system with high card accuracy but low edition accuracy is useful for "what is this card" but not for pricing or inventory management. The gap between the two tells you something about how well the system distinguishes between printings of the same card.

For cards with very similar-looking printings — same artwork, similar frame treatment, only minor visual differences — that gap can be large. The most extreme case in Magic is Sol Ring; Scryfall currently shows 43 Sol Ring prints sharing Mike Bierek's artwork. That's covered in the next post.

CollectorVision Part 6: The Hybrid Split — Local Inference, Server Lookup

2026-04-25T14:07:21Z

Part 6 of the CollectorVision series. Part 1 has the overview.

There are three ways to deploy CollectorVision, depending on where you want the computation to happen and how much bandwidth you have.

Fully local

The Python library and the browser scanner both run entirely on the client. The catalog lives on the device (or in the browser's IndexedDB cache). No network traffic beyond the initial catalog download.

This is the right choice for desktop tools, offline use, or when you don't want to run a server. The catalog is ~29 MB as float32, or ~14 MB as float16 in the browser. That's a one-time download.

Fully server-side

Send the raw image to the server; get back the result. The server runs Cornelius, the dewarp, Milo, and the search.

curl -X POST http://server/identify/upload -F &quot;file=@card.jpg&quot;

This is simpler for the client but expensive in bandwidth. A JPEG-compressed phone photo is 100–500 KB. At one frame per second, that's up to 30 MB per minute.

Hybrid: local inference, server lookup

Run Cornelius and Milo on the device. Send only the embedding to the server for catalog lookup.

The embedding is 128 float32 values — 512 bytes. That's about 1000x smaller than the image.

embedding = run_local_pipeline(frame)   # 512 bytes

response = requests.post(&quot;http://server/identify&quot;, json={
    &quot;embedding&quot;: embedding.tolist(),
}).json()

The server's /identify endpoint accepts either an image or a pre-computed embedding. If you send an embedding, it skips inference and goes straight to catalog search.

This approach makes sense for a mobile app where you don't want to ship a 30 MB catalog in the app bundle, but you also don't want to upload full images on every frame. The client needs the model weights (~2 MB total); the server owns the catalog and handles updates. When new sets release, you update the catalog on the server and all clients benefit immediately with no app update.

Multi-frame aggregation in the hybrid case

For live-camera use, you want to accumulate results across frames before committing to an answer. In the fully-local case, you do this client-side. In the hybrid case, you have two options: accumulate client-side and only send to the server when you have a candidate, or send each frame to the server with a history of recent embeddings and let the server average them.

The REST server supports the second approach. The client keeps a short deque of recent embeddings and sends them with each request:

from collections import deque

buffer = deque(maxlen=5)

while scanning:
    emb  = compute_embedding(frame)
    resp = requests.post(&quot;/identify&quot;, json={
        &quot;embedding&quot;: emb.tolist(),
        &quot;prior_embeddings&quot;: [e.tolist() for e in buffer],
    }).json()

    buffer.append(emb)

    if resp[&quot;confidence&quot;] &gt; 0.85:
        print(resp[&quot;card_id&quot;])
        buffer.clear()

The server averages the current embedding with the prior buffer before searching. It doesn't store anything between requests — the client owns the state. This keeps the server stateless and easy to scale.

Bandwidth comparison

Approach	Per-frame payload
Image upload	100–500 KB
Embedding upload	512 bytes

For a 1 fps scanning session, image upload costs ~20 MB/minute. Embedding upload costs ~30 KB/minute.

Which to use

For someone just wanting to identify a card from a photo, the full server-side API is fine. For a scanning session at a table going through a box of cards, the bandwidth cost of image upload adds up. For a production mobile app, the hybrid approach gives you the lowest bandwidth, the most privacy (images never leave the device), and transparent catalog updates.

The browser scanner uses fully local mode since it's hosted on GitHub Pages with no backend.

This is the last post in the series. The code is at https://github.com/HanClinto/CollectorVision. The browser demo is at https://hanclinto.github.io/CollectorVision/.

CollectorVision Part 5: The Browser Scanner — Full ML Pipeline in a Web Page

2026-04-25T14:06:23Z

Part 5 of the CollectorVision series. Part 1 has the overview.

The browser scanner runs the entire pipeline — corner detection, perspective warp, neural embedding, catalog search — inside a web page, with no server. It's hosted at https://hanclinto.github.io/CollectorVision/. Open that on your phone, point it at a Magic card, and it'll tell you what it is.

This was not straightforward to get working right.

Stack

The core piece is ONNX Runtime Web (onnxruntime-web), which runs .onnx models in the browser via WebAssembly or WebGPU. The same model files that ship in the Python package run in the browser. The preprocessing — resizing, ImageNet normalization, the SimCC softmax — is reimplemented in JavaScript to match the Python output.

The perspective warp uses OpenCV.js, a WebAssembly build of OpenCV2. The catalog search is a plain JavaScript dot-product loop on a Float32Array.

There's no framework. No React, no bundler. Plain ES modules, a couple of workers, and static files that can be hosted anywhere.

Workers

Model inference takes 30–100ms per frame depending on the device. That's too slow to run on the main thread if you want a responsive UI. The scanner uses two Web Workers:

scanner.worker.mjs handles Cornelius inference, dewarp, and Milo embedding
enricher.worker.mjs fetches card names and prices from Scryfall after confirmation

The main thread handles the camera feed, draws the corner overlay, manages the scan list, and handles all user input. The workers communicate via postMessage.

Caching

The models and catalog together are about 32 MB. Re-downloading on each visit would make the scanner unusable on mobile. Everything is cached in IndexedDB after the first load.

A manifest.json file contains version strings for each asset. When a model or the catalog is updated, the version bumps and the old cached data is replaced on next open. After first load, the scanner opens in a second or two even on a slow connection — and works fully offline.

The WebGPU problem on Android ARM

WebGPU is theoretically faster than WebAssembly for matrix operations. The first version of the scanner used it. It produced wrong answers on Android ARM devices.

The specific bug was a precision issue in the WebGPU execution provider for ONNX Runtime Web on Android ARM. The embeddings came out subtly wrong — not zeros, not NaN, just numerically incorrect. Cosine similarities dropped enough that identification failed silently. Took a while to find because the behavior was device-specific.

The fix is to always use WASM for inference, even on devices that support WebGPU. WASM is deterministic across platforms and matches the Python/CPU results.

const session = await ort.InferenceSession.create(modelPath, {
  executionProviders: [&quot;wasm&quot;],
});

WebGPU is now an opt-in setting for people who want to test it, but WASM is the default. The cross-pipeline consistency test in tests/test_pipeline_consistency.py was written specifically to catch regressions here — it captures embeddings from both the Python pipeline and the JS-WASM pipeline on the same frame and checks that they agree within a cosine similarity bound.

Scan confirmation: the ScanBucket

The scanner doesn't confirm a card on a single frame. It uses a sliding-window counter that requires the same card to win across several consecutive frames:

push(cardId) {
  if (cardId === this.candidate) {
    this.count++;
    if (this.count &gt;= this.threshold) {
      const result = this.candidate;
      this.reset();
      return result;
    }
  } else {
    this.candidate = cardId;
    this.count = 1;
    if (this.threshold === 1) return cardId;
  }
  return null;
}

The threshold is configurable from settings (1–8, default 4). Lower threshold scans faster; higher threshold is more conservative. Setting it to 1 is useful when you're working through a sorted pile and picking up each card briefly.

After confirmation

When a card is confirmed, a request goes to the enricher worker, which fetches name, set, and market price from the Scryfall API. The main thread adds the card to the scan list immediately with whatever static data it already has, then updates the row when Scryfall responds. This keeps the recognition loop responsive — Scryfall latency doesn't affect scan speed.

The scan list persists to localStorage, so it survives page reloads. The list can be exported as text or CSV.

After Scryfall returns the price, a sound plays: a higher tone for cards above $5, a lower tone for cards above $0.25, nothing for bulk. It's a small thing, but it makes scanning through a box of cards more engaging.

Cross-pipeline consistency tests

The hardest part of the browser port was making sure the JavaScript pipeline produces the same embeddings as the Python one. A small difference in preprocessing (wrong normalization constants, off-by-one in a resize, BGR/RGB channel swap) would produce systematically wrong results that are hard to diagnose from the UI alone.

The solution was to build a test fixture: capture a frame, run it through both pipelines, save both embeddings as JSON, and assert that their cosine similarity is above 0.80. Those fixture files live in tests/fixtures/captures/ and the test runs in CI on every push.

Next: Part 6 — The hybrid split

CollectorVision Part 4: Running It Locally — Python Library and REST Server

2026-04-25T14:05:19Z

Part 4 of the CollectorVision series. Part 1 has the overview.

This post covers the practical side: installing the library, running it against a webcam, and the REST server. Post 6 goes deeper into the deployment split — when to run everything locally versus offloading catalog lookup to a server.

Installing

pip install git+https://github.com/HanClinto/CollectorVision.git

Or with uv:

uv pip install git+https://github.com/HanClinto/CollectorVision.git

Requires Python 3.10+. The only ML dependency is onnxruntime. Model weights are bundled with the package. No PyPI release yet — that's coming.

Quickstart

import cv2
import collector_vision as cvg

catalog = cvg.Catalog.load(&quot;hf://HanClinto/milo/scryfall-mtg&quot;)
image   = cv2.imread(&quot;my_card.jpg&quot;)

detection = cvg.NeuralCornerDetector().detect(image)
crop      = detection.dewarp(image)
emb       = catalog.embedder.embed(crop)
score, card_id = catalog.search(emb)[0]
print(card_id, score)

The catalog loads from HuggingFace on first run (~29 MB) and is cached after that.

Live video

For a webcam feed, call detect() on each frame and use the sharpness gate to skip unconfident frames. Accumulate scores across frames before committing to an answer.

cap = cv2.VideoCapture(0)
detector = cvg.NeuralCornerDetector()
score_map = {}

while True:
    ret, frame = cap.read()
    if not ret:
        break

    detection = detector.detect(frame)

    if detection.card_present and detection.sharpness &gt; 0.10:
        crop = detection.dewarp(frame)
        emb  = catalog.embedder.embed(crop)
        for score, card_id in catalog.search(emb, top_k=5):
            score_map[card_id] = score_map.get(card_id, 0.0) + score

    if score_map:
        best_id = max(score_map, key=score_map.get)
        if score_map[best_id] &gt; 3.5:
            print(&quot;Confirmed:&quot;, best_id)
            score_map.clear()

The threshold of 3.5 is roughly equivalent to the same card winning across four consecutive frames. You can tune this.

REST server

For cases where you want to call the pipeline from a phone app, a web client, or a script over HTTP, there's a FastAPI server in examples/server/.

Install server dependencies:

pip install &quot;git+https://github.com/HanClinto/CollectorVision.git[server]&quot;

Start it:

python examples/server/server.py --hfd HanClinto/milo scryfall-mtg

Identify a card by uploading an image:

curl -X POST http://localhost:8000/identify/upload \
     -F &quot;file=@my_card.jpg&quot;

The response looks like:

{
  &quot;card_present&quot;: true,
  &quot;card_id&quot;: &quot;7286819f-6c57-4503-898c-528786ad86e9&quot;,
  &quot;confidence&quot;: 0.934,
  &quot;embedding&quot;: [0.023, -0.041, ...]
}

The embedding field is included in every response. That's used by the rolling buffer feature — clients can send back their recent frame embeddings and the server will average them before searching, which helps with noise. The server is stateless; the client owns the history.

Pre-cropped images

If you already have a clean card crop — from a flatbed scanner, for instance — you can skip detection entirely:

from PIL import Image

crop = Image.open(&quot;clean_crop.jpg&quot;)
emb  = catalog.embedder.embed(crop)
hits = catalog.search(emb)

Swapping components

The library is built around protocols, not subclassing. Anything that implements detect(image) -> DetectionResult works as a corner detector. The repo has an example using OpenCV Canny edges in examples/advanced/custom_pipeline.py.

Next: Part 5 — The browser scanner

CollectorVision Part 3: Milo — Embedding 108,000 Cards into 128 Numbers

2026-04-25T14:04:22Z

Part 3 of the CollectorVision series. Part 1 has the overview.

After Cornelius finds the card and the perspective is corrected, you have a clean 252 × 352 crop. The next problem is figuring out which of 108,000 cards it is.

Why not a classifier?

The obvious approach is to train a classifier with 108,000 output classes, one per card. This works, but has a few problems:

New cards get released every few months. Adding them means retraining the model.
The model learns to recognize specific training images, not the card abstractly. It tends to be brittle to lighting changes, image quality, and so on.
Cards not in the training set can't be identified at all.

Metric learning handles all three. Instead of predicting a class, the model learns an embedding space where similar-looking cards map to similar vectors. New cards get added to the catalog without changing the model. The model generalizes to new printings and lighting conditions because it's learning what makes cards visually distinct, not memorizing specific training photos.

Milo

Milo is a MobileViT-XXS backbone with a shared linear projection, trained with ArcFace loss using two label types: illustration ID and set code. Input is a 448×448 RGB image, ImageNet-normalized. Output is a 128-dimensional L2-normalized float32 vector.

ArcFace adds an angular margin penalty during training — it doesn't just push similar things closer together, it also pushes everything farther apart. The result is tighter, more separated clusters in embedding space, which gives better discrimination between visually similar cards.

The multi-task training (illustration ID + set code) forces the model to be sensitive to visual differences between printings of the same card — things like frame treatment, collector number placement, set symbol — while remaining robust to photo quality variation.

Search

The catalog is a matrix of reference embeddings, one row per card face. For Magic: The Gathering, that's about 108,000 rows × 128 columns, built by running every Scryfall card image through Milo.

Searching is a batched dot product. Since all embeddings are L2-normalized, the dot product equals cosine similarity:

scores = catalog_embeddings @ query_emb   # (N,) cosine similarities

108,000 cards × 128 dimensions = about 14 million multiply-adds per query. On a modern CPU with SIMD instructions, this runs in under 5ms. In the browser with WebAssembly it's 8–15ms.

Multi-frame aggregation

A single frame is noisy. Slight blur, unusual angle, glare on a sleeve — any of these can pull the embedding in a slightly wrong direction. The fix is simple: run multiple frames and accumulate scores per card.

from collections import defaultdict

score_map = defaultdict(float)
for emb in recent_frames:
    for score, card_id in catalog.search(emb, top_k=5):
        score_map[card_id] += score

best = max(score_map, key=score_map.get)

The correct card accumulates consistently across frames; noise doesn't. Three to five frames is usually enough.

The catalog file

The catalog is stored as an NPZ file with four keys:

embeddings     (108000, 128) float32
card_ids       (108000,) str
source         scalar str — &quot;scryfall&quot;
embedder_spec  scalar str — JSON spec for reconstructing the embedder

Card names and prices are not stored — callers look those up from Scryfall by UUID after identification. This keeps the catalog small and makes it easy to distribute independently of any particular metadata source.

The catalog lives on HuggingFace at hf://HanClinto/milo/scryfall-mtg and is updated monthly. The first load downloads ~29 MB and caches it locally. After that, everything runs offline.

Why 128 dimensions?

128 is a reasonable tradeoff for this task. Fewer dimensions (32, 64) make it hard to distinguish cards that look similar. More dimensions (512, 1024) give diminishing returns and make the catalog larger and the search slower. At 128, the full catalog fits in 28 MB as float32 or 14 MB as float16, and the search is fast enough for real-time use.

Next: Part 4 — Running it locally

CollectorVision Part 2: Cornelius — How the Corner Detector Finds Cards in the Wild

2026-04-25T14:03:29Z

Part 2 of the CollectorVision series. Part 1 has the overview.

Before you can identify a card you have to find it. Cornelius is the model responsible for that — it takes a camera frame and predicts where the four corners of the card are.

This sounds easy. It's not.

What the detector has to deal with

Cards in a real scene come in a lot of shapes. They're held at angles, rotated, half-off-screen, in colored sleeves, on patterned table surfaces, or overlapping other cards. There's no clean white rectangle to look for. Classical approaches based on edge detection and contour finding work reasonably well in controlled conditions, but in practice they require a lot of tuning and tend to fail on anything unusual.

Using a learned model means the detector can be trained on examples of what "card in hand" actually looks like, rather than what a theoretical textbook expects it to look like.

Architecture

Cornelius is a MobileViT-XXS backbone with SimCC coordinate heads. Input is a 384×384 RGB image, ImageNet-normalized. The output is four normalized (x, y) corner coordinates — one per corner of the card — plus a sharpness score.

MobileViT-XXS is a hybrid CNN/Transformer architecture designed for mobile inference. The full thing runs in around 10–15ms per frame on a laptop CPU, 30–50ms on a phone.

SimCC (Simple Coordinate Classification) is the interesting part. Rather than predicting corner positions directly as floating-point numbers, it turns each coordinate axis into a classification problem over a discretized grid. The model predicts a probability distribution over bins, and the expected value of that distribution is the corner position. This lets the model express uncertainty — a sharp peak in the distribution means high confidence; a flat distribution means the model doesn't know.

The sharpness gate

The sharpness score is the mean peak value across all eight softmax distributions (four corners times two axes). It turned out to be a useful proxy for "is there a well-framed card here?"

The model also outputs a card presence logit, but that one isn't reliable — it fires strongly on blank images and hands without cards. The sharpness signal is better. When the card is clearly in frame with clean corners, all eight distributions are sharply peaked. When there's nothing there, or the image is blurry, the distributions go flat.

In practice, frames below a sharpness threshold of around 0.08–0.10 are just skipped. Nothing is forced.

detection = detector.detect(image)
if detection.sharpness &lt; 0.10:
    continue  # try the next frame

Corner ordering

Four predicted corners still need to be assigned to the right positions — top-left, top-right, bottom-right, bottom-left. The ordering uses a standard geometric trick:

s = pts.sum(axis=1)   # x + y
d = np.diff(pts, axis=1).ravel()  # x - y

tl = pts[np.argmin(s)]   # smallest x+y
tr = pts[np.argmin(d)]   # smallest x-y
br = pts[np.argmax(s)]   # largest x+y
bl = pts[np.argmax(d)]   # largest x-y

This works for any convex quadrilateral regardless of how skewed the card is.

Dewarp

Once the corners are ordered, a perspective transform maps the card to a fixed output rectangle. The canonical output size is 252 × 352 pixels — proportional to the physical card dimensions at 4 pixels per millimeter.

detection.dewarp(image) returns a PIL Image, always the same shape, regardless of how the card was held. That consistency matters a lot for the embedder — Milo always sees the same-shaped input.

Failure modes

Cornelius has trouble with:

Cards lying flat on a complex surface, where the card border blends into the background
Very high viewing angles (more than about 60 degrees off axis)
Full-art cards with no clear light-colored border

For most practical use — card held roughly flat, camera more or less overhead — it works reliably. The sharpness gate handles bad frames by skipping them rather than producing wrong answers.

The pluggable interface

The library's CornerDetector interface is a protocol, not a base class. Anything with a detect(image) -> DetectionResult method works as a drop-in replacement. There's an example in the repo of a Canny-edge-based detector implemented in about 30 lines, mostly to show how the interface works.

Next: Part 3 — Milo, the embedding model

CollectorVision: Identifying Trading Cards with On-Device Machine Learning

2026-04-25T14:02:39Z

I've been working on a card scanner for Magic: The Gathering for a while now and wanted to write up how it works.

The short version: you show it a card, it tells you what it is. It handles held cards, sleeved cards, skewed angles, phone cameras. The whole thing runs locally — you can run it in Python on your laptop, or as a static web app in your browser. No server required. The live demo is at https://hanclinto.github.io/CollectorVision/.

The project is called CollectorVision. The code is at https://github.com/HanClinto/CollectorVision.

How it works

The pipeline has three steps.

Step 1 — find the card corners. A small neural network (Cornelius) looks at the frame and predicts where the four corners of the card are. It outputs normalized (x, y) coordinates for each corner, plus a sharpness score indicating confidence. Low sharpness means the frame was blurry or there was no card in view — those frames get skipped.

Step 2 — flatten the card. Given four corners, a perspective transform maps the card to a flat rectangle: 252 × 352 pixels, every time, regardless of how the card was held. This is the canonical crop.

Step 3 — embed and search. A second network (Milo) converts the flat crop to a 128-number vector. That vector gets compared against a prebuilt catalog of ~108,000 reference vectors, one per card face, using a dot product. The closest match is the result.

The whole pipeline runs in under 100ms on a laptop CPU. Milo and Cornelius are both exported to ONNX, so the only ML dependency is onnxruntime — no PyTorch, no GPU.

Pictures

Here is a real-world photo of a card:

Cornelius finds the four corners:

The perspective is corrected to a flat crop:

Milo produces a 128-d embedding. The nearest neighbor in the catalog is Scrying Glass, Urza's Destiny, cosine similarity 0.93.

Installing

For now, install directly from GitHub:

pip install git+https://github.com/HanClinto/CollectorVision.git

Five lines to identify a card:

import cv2
import collector_vision as cvg

catalog = cvg.Catalog.load(&quot;hf://HanClinto/milo/scryfall-mtg&quot;)
image   = cv2.imread(&quot;my_card.jpg&quot;)

detection = cvg.NeuralCornerDetector().detect(image)
crop      = detection.dewarp(image)
emb       = catalog.embedder.embed(crop)
score, card_id = catalog.search(emb)[0]
print(card_id, score)

The catalog (~29 MB) downloads once from HuggingFace on first run and is cached after that. Everything runs offline.

The series

This is the first post in a series going through the details.

This post — overview
Cornelius: the corner detector
Milo: the embedding model
Running it locally — Python library, REST server
The browser scanner
The hybrid split — local inference, server lookup

The interesting parts are in posts 2 and 3. The browser scanner post (5) covers some unusual engineering problems around running ONNX models in WebAssembly and a bug in WebGPU on Android ARM that cost a few days.

Spring is here

2026-04-24T14:36:27Z

Every once in a while, one of our hens will feel broody and sit on a clutch of eggs. Usually she gets bored after a day or two and wanders off (leaving a pile of soon to be rotten eggs), but every once in a while, one of the girls sticks with it long enough to bring chicks to hatch.

Three new chicks hopping around the Herron farm now. Momma is fiercely protective and will peck your feet if you get too close. She's great.

Spring is here.

NRC 2026

2026-04-14T05:55:04Z

NRC 2026 is just around the corner (April 16, 17 & 18), and our students are very excited.

For the past several 6 years my wife and I have hosted and coached a robotics team out of our house for middle and high schoolers. This year our students are bringing a total of 8 bots to the competition, and we're very excited to see how they do!

It's always a wonderful event, and can't say enough good things about the organizers and the judges (all volunteers from Honda) who generously donate so much of their time and energy to put on such a good event every year. Very thankful that such a quality event like this exists in the midwest, and if you live anywhere closer to Marion Ohio, then I highly recommend getting out to visit this at least once.