By the way, another problem with this SEG file is that it is not 3D.
I.e., it does not have a frame of reference (UID) and does not specify a 3D orientation or 3D positions per slice (nor for that matter pixel spacing information).
Rather, for each slice, it references the original image that slice is to be applied to (and a 1:1 pixel correspondence is specified).
That is not really the way the SEG IOD was intended to be used with 3D cross-sectional modalities, but it is valid (which is why dciodvfy doesn’t complain about missing Frame of Reference UID, Pixel Measures Sequence > Pixel Spacing, Plane Position Sequence > Image Position (Patient), Plane Orientation Sequence > Image Orientation (Patient)); see:
http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_A.51.5.html#sect_A.51.5.1
AFAIK, 3DSlicer only supports the “Frame of Reference relative” approach, and not the “corresponding pixel in a referenced image” approach (which was intended for projection X-rays and photographs, etc.), so even if Siemens had encoded Columns to match PixelData, it still wouldn’t work with this SEG instance.
To work around this, you could copy in the corresponding attributes and values from the referenced slices as a pre-processing step.
A corollary of this may be that fixing Columns to match PixelData (rather than fixing PixelData to match Columns) is that the result will no longer match the referenced images (which I haven’t seen), which would no longer be valid per the standard.
David
PS. Strangely, in the top level data set (as opposed to per-frame functional group item) Source Image Sequence, Siemens says Spatial Locations Preserved = “NO”, which is rather contradictory, since the whole point of the “corresponding pixel in a referenced image” approach is that spatial locations are consistent (since they are not communicated in any other way than by reference). I.e., this value should “YES” IMHO, if sent at all (which it does not need to be, nor indeed does Source Image Sequence in the top level data set).