Reviving FreeCT
70s and psychedelic. You can kinda see the anatomy in the center.
A broken heart.
Just so much noise. So much more than there actually is in the underlying data. Unclear what happened here.
Josh and I have been working to bring FreeCT into the modern era.
FreeCT 2.0, the source code, has had a couple of stop/starts since the first version and since my return to UCLA, which ironically is still to this day the most complete and accurate in its handling of flying focal spot geometries. That version concerned itself mostly with speed and performance (computing was in a different era back then) but produced a tool that was so inscrutable to build and utilize that it was almost worthless to anyone but me. One of our most important design goals for FreeCT 2.0 is to remember that the very practical reality that humans are the ones using the tool and it should be accessible even if you’re not a software developer.
The new version emphasizes FreeCT as a tool for exploring raw CT projection data, which includes reconstruction but also targets FreeCT at things like extracting relevant metadata, describing a raw data file (proprietary formats mean you often have no idea what you’re looking at and require a hex editor to unearth anything useful), helping a user visualize their sinogram data.
Although the math of our clinical, diagnostic-quality recon is complex, it’s not the hardest part of the problem. The hardest part is how to sanely pass around all of the metadata required to interpret and reconstruct the data at the various stages. So much of is is basically global (as in, we might need it at every stage of the reconstruction process) but that doesn’t really tend to make for good, sane, maintainable code.
Given my current obligations, immediate-term code maintenance is not something I have infinite time for (although sometimes I think I’m trying to) and long-term, we’d like to be able to concentrate on the broader theoretical questions of reconstruction and it’s applications, rather than tweaking the backprojection math to handle small edge cases introduced by manufacturers.
One of the unique, and possibly misguided, parts of building a research tool to do these reconstructions is that we don’t get to customize/optimize the reconstruction to a physical scanner the way that manufacturers do or a contracted company might. This means that running FreeCT on new data is often a fascinating (often discouraging) process as you discover all of the idiosyncrasies you failed to consider in the previous geometry.
The images at the top are our finest errors so far: either completely insane or hints at the underlying date while still being horribly wrong and unacceptable. It’s a beautiful part of the mathematical reconstruction process that few really ever get to see.
We’re building to ultimately release our code, but not there yet. There are still some small issues with geometry and quantitative accuracy that we need to sort out, many of which could be solved with some sort of standardized geometry and/or standardized file format.
2025-06-28 08:05