#494 Several multi-frame files are interpreted as a series

[Dženan Zukić]

Clinical collaborators sent us a zip file with several multi-frame DICOMs, with sizes such as 512x396x221 and 512x396x256. However, simple code using GDCM interprets them as a single series, and subsequent reading fails with message:

itk::ExceptionObject (000000FC485EDB10)
Location: "void __cdecl itk::ImageSeriesReader<class itk::Image<short,3> >::GenerateData(void)"
File: C:\Dev\ITK-git\Modules\IO\ImageBase\include\itkImageSeriesReader.hxx
Line: 353
Description: itk::ERROR: ImageSeriesReader(0000022DBE2A2700): Size mismatch! The size of  C:\a\multi-frame misinterpretation/IM_0001 is [512, 396, 221] and does not match the required size [512, 396, 1] from file C:\a\multi-frame misinterpretation/IM_0001

[Dženan Zukić]

Not all of the files are interpreted as belonging to the same series, some files are a series all to themselves (and all of them should be). The distinguishing feature of the files which are not erroneously grouped into a series is different XY size, e.g. 800x600x1 or 256x442x256.

[Mathieu Malaterre]

I have to say I am a bit lost here. Are you sure this bug is related to GDCM (ie. itk::GDCMImageIO) ? It looks to me this is something deeper in the itk pipeline (series reader?). Can you read two multi-frames TIFF images with those dimensions without issues ? In any case I can try to reproduce the issue, may take a bit longer unless you could share the code + dataset.

[Mathieu Malaterre]

Analysis:

GDCM is confused because volumes are similar in properties (gdcminfo):

MediaStorage is 1.2.840.10008.5.1.4.1.1.3.1 [Ultrasound Multi-frame Image Storage]
TransferSyntax is 1.2.840.10008.1.2.4.50 [JPEG Baseline (Process 1): Default Transfer Syntax for Lossy JPEG 8 Bit Image Compression]
NumberOfDimensions: 3
Dimensions: (512,396,256)
SamplesPerPixel    :1
BitsAllocated      :8
BitsStored         :8
HighBit            :7
PixelRepresentation:0
ScalarType found   :UINT8
PhotometricInterpretation: MONOCHROME2 
PlanarConfiguration: 0
TransferSyntax: 1.2.840.10008.1.2.4.50
Origin: (0,0,0)
Spacing: (1,1,1)
DirectionCosines: (1,0,0,0,1,0)
Rescale Intercept/Slope: (0,1)
Orientation Label: AXIAL

But should not:

(200d,3303) LO [0.36813678694904567\0.31559023607524217\0.5439881912405645]         # 58,3 Voxel Spacing
        (0028,0030) DS [0.31559023607524\0.36813678694904 ]         # 34,2 Pixel Spacing

while:

(200d,3303) LO [0.36813678694904567\0.3171173776510386\0.7081075899297093 ]         # 58,3 Voxel Spacing
        (0028,0030) DS [0.31711737765103\0.36813678694904 ]         # 34,2 Pixel Spacing

Because Pixel Spacing information is located in Private Attributes instead of the expected Public attribute (see: http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.8.5.5.html), gdcm fails to see the mismatch. The ITK pipeline only fails later one failing to concat two 3D images into a single 4D images.

This is a data problem: Spacing should have been correctly defined in the public sequence.

GDCM could be extended to also search for pixel spacing information in private attributes. But this is a feature request and not a bug in this case.