One acquisition, several different images

Tonight · ~25 min · read · energy: low · setup: none

A patient is scanned once. You download the study and find four CT series where you expected one: a thin 1.25 mm lung-kernel stack, a thick 5.0 mm soft-tissue stack, a coronal reformat, and a scout. They are not duplicates and they are not errors — they are different reconstructions of the same measured projections. This lesson is about why that happens and why it is a first-class quantitative variable.

The anchor: same gantry pass, different pictures

Recall from lesson 1 that the slice is the output of a reconstruction algorithm. The raw projections are fixed once the patient leaves the gantry, but reconstruction is re-runnable: the scanner (or a workstation) can re-reconstruct the same data with different settings to answer different clinical questions. Each setting produces a separate series.

The clinically motivated choices — and their quantitative consequences — are:

Reconstruction kernel (the dominant texture variable)

The kernel (ConvolutionKernel, (0018,1210)) is the frequency filter applied during back-projection. It trades spatial resolution against noise:

Sharp / bone / lung kernels (e.g. Siemens B70f): high spatial resolution, more noise, sharper edges. Preferred for lung parenchyma and bone detail.
Soft / standard kernels (e.g. B30f, B40f): lower noise, smoother. Preferred for soft-tissue reading and measurement consistency.

The quantitative fact that drives this whole chapter:

A texture feature computed on a sharp-kernel reconstruction can differ substantially from the same feature on a soft-kernel reconstruction of the same raw data. Kernel is not a metadata nicety; it is a feature-determining variable.

This is why TRACE-CT’s preflight deliberately selects both a 1.25 mm LUNG and a 5.0 mm STANDARD reconstruction per acquisition, and tags them with classify_source_role() — so the reconstruction-sensitivity experiment is built into the data, not an afterthought.

Slice thickness vs slice spacing

These are independent concepts that are often numerically equal in routine thin reconstructions, which is why they get conflated:

Slice spacing = distance between the centres of consecutive slices. It sets the z-resolution and whether the stack is a regular volume.
Slice thickness = the collimated/imaged slab each slice averages through. It sets partial-volume blurring along z.

A 5 mm-thick slice and a 1.25 mm slice of the same anatomy carry different information about small structures: the thick slice averages anatomy through its slab, blurring boundaries. For quantitative work you need to know both, and you will need both again in Chapter 2 when spacing decides whether the stack is a usable 3D volume.

Dose and spectrum

Two acquisition facts that matter for the quantitative path (we will not turn this into a physics textbook):

kVp / spectrum changes the effective attenuation of some materials through beam hardening, so CT numbers are not perfectly scanner/protocol-invariant — directly relevant to multi-centre radiomics and harmonisation.
Dose (mAs / CTDI) drives noise, which drives texture features and segmentation stability. Noisy low-dose data looks quantitatively different even when the underlying anatomy is identical.

You do not need to derive dose equations. You need to record these and treat them as covariates or stratification variables.

Contrast phase

Contrast changes what the HU means. An enhancing tumour after iodinated contrast is brighter than the same tumour pre-contrast, and the brightness reflects perfusion, not the tumour’s intrinsic attenuation.

Never pool contrast and non-contrast series as if they were equivalent. The HU scale is the same; the biology the number reflects is not.

Putting it together: the dependency you must internalise

A radiomic feature is not a property of “the tumour”. It is a function of (image, mask, geometry, preprocessing), and the image is itself a function of reconstruction choices. So the chain is:

flowchart LR
    P["Raw projections<br/>(fixed)"] --> R1["B70f, 1.25 mm"]
    P --> R2["B30f, 5.0 mm"]
    P --> R3["Coronal reformat"]
    R1 --> F1["feature value A"]
    R2 --> F2["feature value B"]
    R3 --> F3["not a volume"]
    F1 -.different from.-> F2

Same patient, same gantry pass, different feature values. This is not noise; it is the structure of the problem. The discipline it forces is simple and absolute: record the reconstruction, report it with every result, and never pool across reconstructions without intending to.

Stop and think — then reveal

Two CT series come from the same acquisition but were reconstructed with different kernels (one sharp/lung, one soft/standard). Should you expect their radiomic texture features to match? What about their shape features?

Texture features (GLCM, GLRLM, …): no — the kernel directly changes the spatial frequency content and noise the matrices count on, so edge/noise-sensitive statistics will differ, sometimes substantially. Shape features (volume, sphericity, …): broadly yes — shape is computed from the mask, not the grey values, so it is insensitive to the kernel provided the mask itself did not change. (The mask can change if it was derived by thresholding, but shape as a class is kernel-independent.) This split — shape robust to kernel, texture sensitive to it — is one of the most useful rules of thumb in all of Chapter 3.

What to retain

One acquisition → several series, each a different reconstruction of the same projections. They are different images, not duplicates.
Kernel is the dominant texture variable; slice thickness drives partial volume; dose drives noise; contrast phase changes what HU means. Record all of them.
Shape features are largely kernel-independent; texture features are not. That asymmetry will return throughout the radiomics chapters.
Reconstruction lives at the Series level — which is exactly what the next lesson formalises when it shows how DICOM organises these series into an examination.

Next: how does DICOM actually keep these series — and their slices — straight? The hierarchy that turns files into an exam.