BIAI Lab
Posts Lab note

Why the lab publishes tools, not just papers

A concrete look at the lab's tooling surface, why live services come before repository releases, and how software changes what imaging experiments can be run.

Tooling changes the research itself

In biomedical imaging, software is not just a packaging layer around the paper. It determines how outputs are compared, how reader studies are run, how reconstruction operators are tested, and how quickly a new idea can be checked against the rest of the workflow.

That is why the lab treats tooling as part of the public research surface. A paper may explain the method, but the tools often explain how the method was actually evaluated.

Why the live systems come first

The site puts viz.biailab.com and iqa.biailab.com first because they are the most direct public entry points into the lab’s workflow.

  • viz.biailab.com is for synchronized CT inspection, ROI-based analysis, histogram comparison, NPS curves, diff views, and related visual checks.
  • iqa.biailab.com is for web-based quality assessment workflows and reader-study style data collection.

Those services are useful even before every underlying repository is ready to be published cleanly. A live system can be genuinely public while the codebase behind it is still being documented, simplified, or reviewed for release.

The current public-facing stack also includes tools that sit closer to the core research pipeline:

  • TorchTomo for differentiable CT operators inside PyTorch workflows,
  • dbt-toolbox for digital breast tomosynthesis reconstruction work,
  • jupyterhub_toolbox for the shared computational environment that keeps multi-user research moving.

These are not interchangeable projects. They serve different layers of the lab: visual inspection, reader studies, reconstruction development, and infrastructure.

Why this matters scientifically

If comparison tooling is weak, experiments become harder to interpret. If reader-study infrastructure is fragile, quality assessment becomes expensive to repeat. If projector and backprojector code is not reusable, every new method starts from too far back.

Good tooling changes what a lab can ask and how fast it can answer. That is one reason the lab’s public output includes software alongside papers.

Why some repositories are not public yet

Not every internal codebase is ready to stand alone as a public repository. Some still need documentation, dependency cleanup, or packaging work before they make sense for outside use. The site now reflects that directly: live services are linked where they are public, and repositories appear only when the release is actually ready.