When CT and segmentation really share space

You have a CT and a tumour segmentation. You want to overlay the mask on the image and trust that it sits on the tumour. When is that safe? The tools in this chapter so far — the affine, the slice normal, the grid checks — become decisive here, because the answer cannot be read off a single tag. FrameOfReferenceUID is permission to check the geometry, not proof that the geometry matches. The decision is always made on real coordinates.

A matching FoR that still misaligns

A directly-derived SEG — one whose source SOP UIDs cite the CT — is spatially related to the CT, but it does not have to share the CT’s voxel grid. DICOM explicitly permits a SEG to differ from its source in size and resolution, and to carry its own per-frame positions. The SEG could have been resampled, written onto a re-sliced volume, or carry per-frame positions that differ from the CT’s slice positions. Under a naive index-by-index overlay the mask then lands one slice off the tumour; a geometry-aware viewer or resampler should honor the SEG’s actual positions and either place the mask correctly or expose the mismatch. A matching FrameOfReferenceUID does not catch this — comparing the actual geometry does.

What FrameOfReferenceUID means

FrameOfReferenceUID (0020,0052) names a spatial coordinate system. It is a claim about which patient frame an object’s coordinates are expressed in, not a proof of voxel-level alignment:

• Matching FoR → the objects claim the same patient frame. This is permission to compare geometry directly — but it does not prove identical grids (origin/spacing/direction can still differ).
• Differing FoR → do not overlay blindly. The objects may still be spatially related, but only through an explicit registration that maps one frame to the other.

same FoR      ≠  same voxel grid       (still verify origin/spacing/direction)
different FoR ≠  impossible to relate  (an explicit registration can map them)
different FoR ⇒  do NOT overlay without an explicit spatial relationship

FoR is necessary context; geometry decides

Even with a matching FoR, alignment is decided on real geometry, not the UID. Two objects in the same frame can still have different origins, spacings, or orientations — the SEG was resampled, or a re-sliced volume was written back into the same frame. So the comparison is between geometry (origin/spacing/direction), not between identifiers.

What a matching UID establishes is a shared coordinate frame: the objects’ coordinates may be compared within one reference system. It does not establish grid equality — that is decided by the image-plane geometry. And when the FoR is absent or differs, the objects have no asserted spatial relationship: an explicit, documented spatial relationship must be established before any overlay.

Practical rule: use FoR as context — a match lets you proceed to verify geometry directly; a mismatch tells you an explicit registration is required before any overlay. Geometry is always what decides whether two grids coincide.

The decision procedure

Given a CT and a SEG, decide whether the mask already sits on the CT grid:

1. Resolve the source. Match the SEG’s ReferencedSeriesSequence and per-frame source SOPInstanceUIDs to the CT series/slices. Positive references establish a machine-readable relationship between the SEG and that CT. If the references are absent or do not point at this CT, derivation from this CT is not established by these fields — DICOM permits SEG encodings that rely on Frame of Reference geometry and omit per-frame derivation references — so investigate other reference and provenance evidence; do not conclude “not derived” from absence alone.
2. Check FoR. A match lets you proceed; a mismatch means an explicit registration is needed before comparison.
3. Compare real geometry, with a tolerance prespecified for each quantity — in its physical units and appropriate to the encoding precision; there is no single universal tolerance:
   • dimensions/extent equivalent? (grid shape and frame count match)
   • origin/positions equivalent? (per-frame ImagePositionPatient agree)
   • spacings equivalent? (PixelSpacing, and the slice spacing implied by the frame positions)
   • direction equivalent? (ImageOrientationPatient cosines agree)
   • frame correspondence holds? (each SEG frame maps to the intended CT slice)
   • source/reference consistency holds? (the references from step 1 name this CT and its instances)
4. Classify the pairing — these are chapter labels for this decision, not DICOM enumerated values:
   • EXACT_GRID — geometry matches; use the mask directly, no resampling.
   • RESAMPLING_REQUIRED — same frame/intent but different grid; resample the mask onto the CT grid (the resampling section).
   • INCOMPATIBLE — cannot be safely related without more information.

FoR is context; actual positions, spacing and direction determine whether the grids coincide.

TRACE-CT instruments this territory in committed code, though no single function there produces the three labels above; its preflight instead works with a richer internal status vocabulary, recorded in the learning map. The FoR is checked, but the decision is made on real geometry.

The procedure earns its keep on the failure that slips past every cheaper check. Suppose a SEG and a CT share the same FrameOfReferenceUID, the SEG cites the CT’s series UID, and their array shapes match — and the mask still lands one slice off the tumour. The culprit is a per-frame position mismatch: the SEG’s frames were written at slice positions that do not coincide with the CT’s slice centres, for example because the SEG was produced on a re-sliced or resampled version of the CT and then written back into the same FoR and shape. Same FoR, same shape, same references — but the per-frame ImagePositionPatient values differ, so a naive index-by-index overlay places the mask on the wrong physical slices, while a geometry-aware overlay honors the positions and either places the mask correctly or exposes the offset. The position comparison catches this, and so can a full affine grid comparison or a direct visual overlay. Shape equality means nothing about geometry; FoR equality means only a shared frame; geometry equality is the decision.

Registration: relating objects in different frames

When two objects sit in different frames of reference — a pre-contrast MRI and a post-contrast MRI, or a CT and an MRI — they are not “misaligned”, they are unrelated until you relate them. An explicit registration is a spatial transform (rigid, affine, or deformable) that maps coordinates from one frame to the other. Once you have it, you can resample one object into the other’s frame and then apply the EXACT_GRID/RESAMPLING_REQUIRED logic above.

Registration quality is itself a variable: a slightly-wrong transform overlays the wrong anatomy just as cleanly as a right one. In 3D Slicer, the registration modules (such as General Registration) compute these transforms, while the Transforms module visualizes, edits, and applies them. Visually reviewing the result — scrolling the overlay in multiple orientations — is necessary complementary QC, which is why the visual-QC case study at the end of this chapter (case study) is not optional; but visual agreement does not, by itself, prove registration accuracy.

Knowing that two objects share a space still leaves a representational question: what kind of thing is the segmentation you just aligned? A mask array, a DICOM SEG, and an RTSTRUCT store the same tumour differently, and the next section shows what each form preserves and what it silently discards.

Sources

• DICOM PS3.3, Frame of Reference module (C.7.4), including FrameOfReferenceUID (0020,0052): a shared frame establishes a spatial relation, not grid identity. (current edition)
• DICOM PS3.3, Image Plane module (C.7.6.2): ImagePositionPatient, ImageOrientationPatient, and PixelSpacing semantics. (current edition)
• DICOM PS3.3, Segmentation Image module (C.8.20.2) and Segmentation functional groups (A.51.5): a SEG may differ from its source in size/resolution and carries its own per-frame positions and derivation references. (C.8.20.2, A.51.5)
• DICOM PS3.3, Common Instance Reference module (C.12.2): ReferencedSeriesSequence and instance references. (current edition)
• 3D Slicer documentation — registration modules (compute transforms) and the Transforms module (visualize/edit/apply transforms). (user guide)
• TRACE-CT at commit 7aaf308c76ed2718fd0b364d1cde856969711b72 — bounded case-study implementation: scripts/seg_decode_resample.py geometry helpers and classify_transfer_pair(), scripts/rider_preflight.py geometry states, and scripts/rider_qualification_matrix.py frozen geometry vocabulary. (commit)