An MRI Scan Is Not a Stack of Images

When people hear “medical-image model,” they often picture a neural network reading an image. My first Phase 2 lesson was more basic:

Before a model sees an MRI, someone has to decide what an MRI examination is.

It is not one image. It is a folder of series, and each series is a stack of slices captured from a different angle or with a different scanner setting.

One study
  ├── sagittal series
  ├── coronal series
  ├── axial series
  └── occasionally: localizers, broad views, duplicates, edge scans

The model needs a consistent representation. Building that representation was the real work.

1. File order is not anatomy order

MRI data uses DICOM, a clinical imaging format that stores pixels plus metadata. It is tempting to read files in alphabetical order and call that a volume. That can be wrong.

The reliable order comes from each slice’s physical location and orientation. The loader therefore checks that a series belongs together, derives its anatomical plane from orientation metadata, sorts slices by physical position, and rejects ambiguous geometry.

Why care? Imagine a flip book with pages shuffled. The pictures are individually fine, but motion and structure disappear. A 3D or multi-slice model sees the same kind of nonsense when slice ordering is wrong.

Learning: the data loader is part of the model. It decides what information reaches the network.

2. “Readable” does not mean “useful”

The representative audit covered 160 studies, 983 series, and tens of thousands of slices. The files decoded cleanly and the geometry checks passed. Good news—but not the end of the question.

Visual review found series that were technically valid yet less useful for this task: broad-field scans, localizer-like images, and edge-of-volume views. A file can satisfy its format while still being a weak learning example.

This is the difference between two checks:

I built a conservative selector that keeps the useful plane-and-contrast diversity rather than forcing every study into one “best” series. A hard content filter was tested and rejected after review showed it would throw away some diagnostically useful scans.

Learning: a filter is a hypothesis, not a fact. Review what it removes.

3. Make different scans comparable without pretending they are identical

MRI series vary in slice count, image size, spacing, intensity scale, and scan protocol. A first baseline needs a stable shape, so preprocessing does four things:

physically order slices
        ↓
sample a fixed number across the volume
        ↓
normalize intensity within that series
        ↓
resize and pad to a fixed image shape

Padding is important. Stretching every image to fit a square can distort anatomy. Padding preserves the aspect ratio while giving the network a predictable tensor shape.

This does not make every MRI equivalent. It gives the model a consistent canvas while retaining as much structure as a simple first pass can.

4. Why NPY appeared in the pipeline

An NPY file is a straightforward NumPy array stored on disk. Think of it as a pre-packed, model-ready block of numbers.

Raw DICOM is the source of truth. It is rich and clinically structured, but repeatedly opening thousands of small files and parsing metadata can slow training. Compressed formats save space but add decompression work every time data is read.

The storage benchmark led to a hybrid decision:

“Memory-mappable” means the operating system can read only the section of a large file that is needed instead of loading the entire cache into memory. That is useful when a training job repeatedly samples many small volumes.

The cache is not a replacement for DICOM. It is a speed layer built from a versioned recipe.

Interview concept — materialized feature cache: a precomputed representation that trades storage for faster, more repeatable training reads. It must have a clear version and provenance, or it becomes an unexplained source of differences between experiments.

5. What I would say in an interview

If asked how I would prepare MRI data, I would answer in this order:

1. Define the prediction unit: a study, not an isolated slice.
2. Inspect metadata and pixel behavior on a representative, stratified sample.
3. Sort by physical geometry, never just filename order.
4. Validate both file correctness and task relevance.
5. Standardize sampling, intensity, and spatial shape with a versioned recipe.
6. Benchmark the I/O path before training, because slow data feeds waste accelerator time.
7. Preserve raw source data and make derived caches reproducible.

Notice that model architecture comes last. A better network cannot rescue shuffled slices or a cache whose provenance is unknown.

What this does—and does not—buy us

The Phase 2 pipeline gives the first baseline a repeatable, checked input path. It does not prove the chosen slice budget, resolution, or selector is optimal. Those are future experiments, measured against a fixed validation boundary.

That is the discipline I am trying to learn: use an engineering decision to make the next experiment possible, then let the next experiment challenge that decision.

Next: how I turned multilingual reports into cautious training signals →

This post shares aggregate engineering lessons only. It does not include MRI images, identifiers, private code, or case-level findings. It is not medical advice or evidence of clinical validity.