LEVIATHAN SYSTEMS

AI Infrastructure

Equal Image Arrays Can Occupy Different DICOM Patient Coordinates

Technical contentPublished Updated

Equal image arrays can describe different physical pixel centers. Once values have arrived, compare the delivered array's geometry with its consumer's requirements. An expressly index-only consumer and one that uses patient coordinates can need different input contracts; equal dimensions and values do not settle that decision.

Start with the consumer's use of the delivered array

An array can arrive intact and still leave its physical meaning unresolved. Consider a consumer whose input definition requires only an ordered matrix of values. Now consider another that must associate each result with a location in patient coordinates. The same export can meet the first contract while omitting information needed by the second.

The related DICOM search, metadata and pixel-input article covers whether the required pixel population and representation have arrived. Begin here after that question: what spatial meaning accompanies these particular values? This is input-interpretation education, with a stipulated applicable patient-coordinate Image Plane Module. It is not a rule for every DICOM Information Object Definition or a clinical measurement or operating procedure.

References: [DG1]

Keep index order separate from spacing order

DICOM PS3.3 displayed edition 2026d when checked on October 20, 2026. In C.7.6.2.1.1, i is the zero-based column index and j the zero-based row index. Pixel Spacing (0028,0030) instead lists adjacent-row center spacing first and adjacent-column center spacing second, in millimeters.

Write the mapping as P = S + i × column spacing × X + j × row spacing × Y. S is Image Position (Patient) (0020,0032). X and Y are respectively the row and column direction vectors from Image Orientation (Patient) (0020,0037). Moving along a row changes the column index, so X accompanies i. S locates the first voxel center, not a pixel-corner bounding box.

That vocabulary matters when reviewing an export specification: a field named row direction and a field named row spacing contribute to different terms. Explicit index and spacing definitions remove the ambiguity of a bare pair of numbers.

References: [DG1][DG2]

DGEOM-111: identical 8 × 8 values, different centers

Stipulate two synthetic arrays, A and B, each with eight rows and eight columns and identical values at corresponding indices. Both use the same expressly stipulated coordinate frame, origin S = (10,20,30) mm, row direction X = (1,0,0) and column direction Y = (0,1,0). These axis-aligned directions keep the arithmetic visible.

A has row spacing 2 mm and column spacing 0.5 mm. At column i = 4, row j = 3, the displacement along X is 4 × 0.5 = 2 mm; along Y it is 3 × 2 = 6 mm. Adding those displacements to S gives (10+2,20+6,30) = (12,26,30) mm.

B has row spacing 1 mm and column spacing 1 mm. At the same index, the displacements are 4 × 1 = 4 mm and 3 × 1 = 3 mm. Its center is (10+4,20+3,30) = (14,23,30) mm.

Each array contains 64 pixel positions. The values, shape, selected index, origin and directions agree, yet the selected centers differ because the spacings differ. At index (0,0), both centers coincide with S; agreement at that one point would also miss the difference.

These are invented geometry assignments and arithmetic, with no real scan or patient. No clinical measurement, resampling or registration was performed. Changing a header to describe B's spacing would change the asserted mapping; the edit alone would not establish that A's pixel values had been resampled.

References: [DG1][DG2]

A position needs an identified coordinate frame

DGEOM-111 deliberately supplies a common frame. Without that stipulation, matching coordinate numbers would leave another ambiguity: which spatial reference gives those numbers meaning?

C.7.4.1 uses Frame of Reference UID (0020,0052) to identify the reference shared by spatially related images. A common study label, equal dimensions or matching position numbers alone does not establish that reference. A common UID also leaves the arrays' individual spacings, origins and directions to be interpreted. The standard notes that some localizer relationships need more than a shared UID.

For the buyer, frame identity and anatomical correspondence are separate questions. A UID is not evidence that motion was corrected or a registration was performed. If a consumer needs a relationship between different frames, the delivery must identify the applicable relationship rather than silently treating their numbers as interchangeable.

References: [DG3]

Spacing order does not establish calibration

Section 10.7 separately addresses correction for geometric magnification and calibration against a known object. Pixel Spacing (0028,0030) should not be substituted indiscriminately with detector or display spacing. Correctly reading the pair's order does not establish the calibration context.

The standard says correction or calibration status cannot be determined when Pixel Spacing Calibration Type, Imager Pixel Spacing and Nominal Scanned Pixel Spacing are all absent. Preserve the applicable calibration explanation when the consumer depends on it; a numeric spacing pair alone cannot answer that separate question.

References: [DG2]

Compare the geometry promised at the consumer boundary

An expressly index-only contract might accept A and B as the same input because their matrices match. That conclusion depends on the stated consumer: it cannot be extended to software that uses physical locations. In DGEOM-111, that second consumer would receive different location assignments even though an equality check on the arrays would pass.

Ask the application owner to state whether physical coordinates are required and which array axes its input indices describe. Ask the delivery provider to explain how the applicable geometry remains associated with the exported values. A package that contains an array and an unrelated source header has not yet demonstrated that association.

If the provider declares a crop, reorientation or resampling, the useful evidence is the resulting geometry and the relationship of the delivered array to its source. Identify who supplies and checks that relationship. A claim that metadata was retained does not resolve whether it still describes the exported grid. This is a comparison of the proposed input contract, rather than instructions to perform a transformation.

An array-only offer can therefore be complete for a specified index-only use while leaving a geometry-dependent use unresolved. Resolve that gap with the responsible application and data-delivery owners before treating equal arrays as equivalent physical inputs.

References: [DG1][DG3]

A separate physical cabling need

If the selected infrastructure also needs a confirmed physical cabling package, the related Structured Cabling & Fiber Installation service and project inquiry provide the relevant route. Share a nonconfidential equipment summary, approved endpoints and routes, material responsibilities and the required connection records to discuss scope and availability. DICOM geometry interpretation and application integration remain with the appointed software and data owners.

References: [L1]

Primary sources

  1. [DG1] DICOM PS3.3 2026d, C.7.6.2: Image Plane ModuleChecked 2026-10-20. Applicable planar-image position, orientation and integer-index mapping in C.7.6.2.1.1.
  2. [DG2] DICOM PS3.3 2026d, 10.7: Basic Pixel Spacing Calibration MacroChecked 2026-10-20. Spacing order in 10.7.1.3; separate calibration context in 10.7.1.1–2.
  3. [DG3] DICOM PS3.3 2026d, C.7.4.1: Frame of Reference ModuleChecked 2026-10-20. Frame identity and qualifications on spatial relationships.
  4. [L1] Leviathan Systems: Structured Cabling & Fiber InstallationChecked 2026-10-20. Agreed physical fiber/copper installation, endpoint labels and connection records.

Discuss a separate physical cabling package

Share a nonconfidential equipment, endpoint, route and connection-record outline to discuss physical installation scope and availability.

Discuss a ProjectEmail Project Scope