Open one real CT and read its contract

Everything so far has been a mental model. This case makes the model concrete by following one public CT object through the checks that precede any trust in its array. The goal is not to memorise tags or to make a viewer the authority. It is to build the reflex of reading the metadata before trusting the pixels.

Read one real object without trusting it blindly

The named case is from Zhao B, Schwartz LH, Kris MG, and Riely GJ, Coffee-break lung CT collection with scan images reconstructed at multiple imaging parameters (Version 3) [Dataset], The Cancer Imaging Archive, identified by its stable DOI. The public record supports same-day repeat CT scans and availability of CT data, SEG data, and lesion contours. It identifies the Version 3 image data as available under the CC BY 4.0 licence. The TCIA record remains the authority for current access terms; those terms are not inferred here. No patient data is added to this repository, and the case does not depend on access to a private or project-local file.

The TRACE-CT learning map records an implementation route, but it is not a reader prerequisite. The same contract- reading method applies to a single-file CT DICOM obtained through a public TCIA series under that source’s terms.

Case step 1: Read the object as a contract

Begin by reading the object as a chain rather than as a list of fields. Establish its SOP Class and Modality, then place it in the hierarchy with PatientID, StudyInstanceUID, and SeriesInstanceUID. SOPInstanceUID identifies the concrete source object. This is the identity half of the check, not a conclusion about clinical equivalence. A versioned pydicom 3.0.2 inspection example is kept in the 3D Slicer companion; the stable interpretation here does not depend on a particular API printout. The official pydicom pixel-data guide documents the corresponding decoded-array path.

PixelRepresentation tells whether the stored PixelData is signed or unsigned (0 means unsigned and 1 means signed), the dtype half of the stored-value trap. BitsAllocated, Rows, and Columns describe how the array is represented, while RescaleSlope and RescaleIntercept state the transform that must be considered before interpreting the values as HU. If 0 + intercept lands near the air reference, that is an encoding-plausibility signal: it predicts the result for stored zero, but does not establish that stored zero is an observed air sample or validate the image minimum. The DICOM CT Image Module defines the CT rescale attributes.

The remaining fields prepare the spatial and reconstruction checks. PixelSpacing, ImagePositionPatient, and ImageOrientationPatient describe the slice’s placement and in-plane axes; SliceThickness is nominal slice thickness, whereas SpacingBetweenSlices, when present, describes center-to-center separation. ConvolutionKernel helps identify the reconstruction context. These fields should be interpreted according to the applicable object specification; absence of a field is not a semantic zero. The DICOM Image Plane Module defines the relevant spatial attributes. The source-Series and source-object UID roles are developed in the identifier section.

Case step 2: Decode the stored pixels

The versioned pydicom example in the 3D Slicer companion decodes the stored samples with pixel_array and applies the object’s linear rescale or Modality LUT with the official apply_rescale operation. The manuscript keeps the operation’s meaning stable while the exact API example remains dated with pydicom 3.0.2.

If outside-body air is present, inspect a representative region or distribution and compare it with the air reference near −1000 HU, while checking padding, artifacts, and the encoded transform. A known water region can be compared with the 0 HU reference. Do not treat the global minimum as a required air statistic, and do not infer from a plausible intensity range that the complete object contract is valid. The stored-value explanation describes why a wrong transform can still produce a plausible-looking array.

This check makes the contract-versus-payload split concrete: the array holds encoded intensity and the physical meaning depends on RescaleSlope and RescaleIntercept. That result covers the intensity layer only. It says nothing yet about whether the object belongs to the intended Series, is spatially ordered, or is clinically interchangeable with another reconstruction.

Case step 3: Compare neighboring positions

With the intensity scale identified, inspect two neighbouring slices from the same Series. The purpose is to see which metadata turns separate objects into a candidate stack. For consistently oriented, parallel slices, compute the slice normal as the cross product of the row and column direction cosines, as developed in the geometry chapter, and check whether the ImagePositionPatient values differ only along that normal. In-plane shifts or orientation differences are investigation signals: validate the intended representation rather than concluding from them alone that no useful volume can be formed.

Compare ImageOrientationPatient and PixelSpacing between the two slices as well. A regular Series is expected to preserve the relevant in-plane geometry, so a difference is a reason to investigate rather than silently combine the arrays. Finally, measure the center-to-center distance between slice positions along the normal and compare it with SpacingBetweenSlices when that attribute is present. Interpret SliceThickness as nominal thickness, not as a second name for the measured center spacing. This is the important change in viewpoint: spacing is measured from geometry and then compared with metadata, rather than being trusted because a tag exists. It is the seed of the geometry chapter’s slice-ordering section.

Case step 4: Use a viewer as complementary evidence

The final reader is a viewer. Load the intended public Series into a viewer such as 3D Slicer and compare what it displays with the metadata interpretation. Check the displayed spacing and origin, inspect the displayed DICOM metadata, and apply an appropriate lung-window display preset. The official Slicer DICOM documentation and Volumes documentation describe the version-sensitive UI and display behavior; those details belong in the companion rather than in the evergreen case.

The viewer is complementary evidence, not an oracle. If Slicer and the pydicom readout disagree, trust neither blindly. Find the tag or processing step that differs; the disagreement is a diagnostic lead, not a reason to select whichever rendering looks more convincing. The 3D Slicer companion provides the visual side of the verified Witowski case material and its small RIDER procedure without making a generic tutorial or a local project path part of this case.

Case step 5: Carry the geometry question into Chapter 4

The case ends by carrying five representative fields into the accepted Chapter 4 geometry, segmentation, and resampling material rather than treating them as a final verdict: ImagePositionPatient, ImageOrientationPatient, PixelSpacing, SliceThickness, and FrameOfReferenceUID. Together they name important spatial information that must be examined before this Series can be called a safe, regular 3D volume, but the list is not exhaustive. Dimensions, per-instance consistency, unique positions, measured center spacing, and the applicable spatial relationship also matter; the detailed construction and resampling decisions remain outside this case.

The useful reflex is now explicit: read the contract, then trust the pixels. RescaleSlope/Intercept, PixelRepresentation, the UIDs, and the geometry tags come before any array operation. HU conversion and representative air or water checks can expose a wrong scale, but a plausible intensity range is not a complete validation. Measured order and spacing come from adjacent slice positions along the normal; filenames and InstanceNumber are only secondary diagnostic consistency checks, never replacements for geometry. pydicom and Slicer are two readers of the same contract; when they disagree, the differing tag or processing step is the diagnosis to pursue.

For the dense tag table, the VR/transfer-syntax reference, the SOP-class list, and the full failure-mode catalogue, see the CT & DICOM reference. The contract checks in this case leave one question deliberately open: how do these spatial attributes establish patient-space geometry, and when must a mask or volume be resampled? That is the subject of Chapter 4 — Physical Geometry, Segmentation, and Resampling.