I have a folder of CT data from 2013 that I haven’t looked at in years. Something has nagged at it for most of those years: a guineafowl’s right leg bone measured differently in two scans of the same animal. This week I pointed Claude Code (Opus 5.5) at the folder and let it dig. It found a real error and gave me a corrected model at the end of it. And the level of competency and “intelligence” that was on display was far beyond what I’ve experience with AI so far.
The data, and the problem with it
The animal is a guineafowl, one of our XROMM study subjects. For the uninitiated, XROMM — X-ray Reconstruction of Moving Morphology — combines 3D bone models from CT with high-speed biplanar X-ray video to re-animate bones moving in 3D space. Part of the workflow involves surgically implanting small radiopaque beads into the bones, which get tracked in the X-ray movies to recover bone position to a fraction of a millimetre. The beads are glorious for motion tracking and absolutely murderous for CT imaging: dense metal throws streak and bloom artifacts through every reconstruction that contains them.
In May 2013 we scanned the bird in one piece on our Animage Fidex — a veterinary cone-beam CT — at 512² voxels and 0.456 mm spacing. A few weeks later (the folder says “Jul2013”; the DICOM headers say 11 June, and I’m going to believe the headers) we re-scanned the disarticulated legs at higher resolution: 352² at 0.236 mm, four series, legs in straight “linear” positions on the bed.
For years, the working assumption in the lab had been that the late-May scans were the trustworthy ones for scale and the June re-scans were the pretty ones for shape. The nagging problem: the right tarsometatarsus — the lower leg bone, the one that actually matters for guineafowl locomotion — measured about 76 mm in the nice June scans and 72 mm in the ugly May scan. Four millimetres is not a rounding error. It’s nearly half a centimetre of bone hanging over the end of the model. And it was the right bone only: the left tarsometatarsus agreed between vintages, which is the kind of asymmetry that makes you suspect the scanner, the bed, yourself, and the previous owner of the scanner, in that order.
I remembered that the later scans came from a period when we’d found the Fidex getting lengths wrong along the bed axis.
Claude to the rescue
This is all I gave Claude:
User: I have some CT data of a bird. loading it into dragonfly world, I can see the spacing looks accurate. However, the scale seems wrong. I’ve two CT scans of the same animal, and it’s tarsometatarsus is longer in one scan than the other. I know the later scans came from a machine where we found lengths (Vet CT scanner with rotating X-ray and a bed, length along the bed) were incorrect. All this data was collected 13 years ago! I think GFLAR06\CTData\GFLAR06_CT data is the correct scale, but it’s low resolution, and suffers from major artifacting from the metal beads implanted.Other data in GFLAR06\CTData\GFLAR06_CT_Jul2013 (there’s 4 folders of scans) seems to have the legs disarticulated, and the tarsometatarsus appears to be longer.
I guess I’m asking if you can see any major errors anywhere? the former data set reports x and y spacing of 0.455784 mm, and Z of 0.455783999999959, the latter dataset 0.23601 in x and y and 0.236010000000009 in Z. note that the resolution is better (half x/y/z distance) yet the slice files are half the size in kb (~200k vs ~500k in GFLAR06_CT)
That’s it.The first thing Claude did was write pydicom scripts to detect the implanted metal markers and compute centroids in 3D space. Inter-bead distances within a bone are rigid. They can’t change between scans, so they test scale directly. Claude went and figured out which 3D constellations of markers were consistent between scans. When Claude started identifying individual bones from two very different scans (one articulated, one not), I genuinely felt a little uneasy at how far AI has come. It produced images as it worked:
The tibiotarsi — the upper leg bones, which have plenty of beads spread over ~100 mm — agreed between May and June to within 0.7%, RMS 0.24 mm. The left tarsometatarsus bead spans matched to within 0.4%. A uniform 5% Z error would have shown up as a 1.3 mm discrepancy in bead spans 25–29 mm long. It didn’t. There was no global scale error. The June Z scale was fine.
The problem was the right tarsometatarsus, which is precisely the one bone where the beads can’t save you: two near the proximal end and one at mid-shaft, nothing distal. All the ruler-able distances sit proximal to where the length discrepancy lives. The scale test passes because it literally cannot see the broken part.
Again, these were generated by the AI directly, from raw DICOM files.
Then, without me telling Claude where the right tarsometatarsus was in the scans, it pulled it out, aligned it consistently based on the markers and measured the length:
This is _hard_ for a person to do, and would take a decent chunk of time to load data, align and produce these graphs. but there it is – you can see the markers lining up but the length of the bone is bigger in the June scan. And what’s crucial here is that the markers still align, so there’s an error between the mid-shaft and the distal portion. That error turned out to be an invisible stitching error from the machine.
Anyway, based on this and further analysis from Claude it was able to produce two deliverables – firstly, a mesh based on the much nicer scan that was correctly deformed and resized to account for the error. This new mesh looks much better, and properly aligns with the XROMM X-ray videos, so can be used for rotoscoping. The second output was a new scan volume, with the correction applied.
Conclusion
I know it’s a minor thing, but the fact Claude took this raw data, analysed it, identified bones from a bird without any prompting, then was able to pull out individual bones, align, analyse, and then produce valuable outputs for further work was astonishing.
This is the most blown away by AI I’ve been so far. I had no idea the frontier models were this good yet. And this wasn’t even the edge of the frontier, this was just Opus 5.5, not Fable.
There’s some very interesting times ahead.
Leave a Reply