When CT and segmentation really share space

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

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? This lesson gives the discipline: FrameOfReferenceUID is permission to check the geometry, not proof that the geometry matches. The decision is always made on real coordinates.

The anchor: a matching FoR that still misaligns

A directly-derived SEG — one whose source SOP UIDs cite the CT — should share the CT’s grid, and you might assume it does. But 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. The mask then lands one slice off the tumour, silently. A matching FrameOfReferenceUID does not catch this — only 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:

1. Two objects in the same frame can still have different origins, spacings, or orientations (the SEG was resampled; a re-sliced volume was written back into the same frame). Compare geometry (origin/spacing/direction), not just the UID.
2. Real datasets carry surprising FoR values: some tools write a fresh FoR UID even for spatially-identical objects; some inherit one across objects never co-registered. The UID is a hint about intent, not a measurement.

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 (what TRACE-CT actually does)

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. If the references do not point at this CT, the SEG is not derived from it — investigate.
2. Check FoR. A match lets you proceed; a mismatch means an explicit registration is needed before comparison.
3. Compare real geometry — orientation, spacing, and per-frame positions, within tolerance:
   • orientations equivalent? (ImageOrientationPatient cosines agree)
   • spacings equivalent? (PixelSpacing agree)
   • positions equivalent? (per-frame ImagePositionPatient agree)
4. Classify the pairing:
   • 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 (lesson 7).
   • INCOMPATIBLE — cannot be safely related without more information.

This is precisely what TRACE-CT’s check_geometry(), orientations_equivalent(), spacings_equivalent(), and positions_equivalent() do, and what classify_transfer_pair() summarises into those three outcomes. The FoR is checked, but the decision is made on real geometry.

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 logic above.

Registration quality is itself a variable: a slightly-wrong transform overlays the wrong anatomy just as cleanly as a right one. 3D Slicer’s Transforms and General Registration modules exist to compute and visually verify these transforms — which is why Visual QC (lesson 8) is not optional.

Stop and think — then reveal

A SEG and a CT share the same FrameOfReferenceUID, the SEG cites the CT’s series UID, and their array shapes match. You treat it as EXACT_GRID and skip the geometry check. What single failure could still put the mask one slice off the tumour?

A per-frame position mismatch: the SEG’s frames were written at slice positions that do not coincide with the CT’s slice centres (e.g. the SEG was produced on a re-sliced or resampled version of the CT, then written back into the same FoR and shape). Same FoR, same shape, same references — but the per-frame ImagePositionPatient values differ, so the mask snaps to the wrong physical slices. Only positions_equivalent() catches it. Shape and FoR and references together are still not enough; verify the geometry.

What to retain

1. FrameOfReferenceUID is a claim about the coordinate frame — a fast rejection test and a slow acceptance test. A match gives permission to verify geometry; it never proves alignment.
2. Decide CT↔SEG coincidence on real geometry (orientation, spacing, per-frame positions), then classify as EXACT_GRID / RESAMPLING_REQUIRED / INCOMPATIBLE.
3. Objects in different frames are not “misaligned” — they need an explicit registration before any overlay, and that registration’s quality must itself be verified.
4. Shape equality means nothing; FoR equality means little; geometry equality is the decision.

Next: the objects you are aligning come in three forms — SEG, RTSTRUCT and binary mask are not the same thing.