Error during conversion : slices not stacked

[stity]

I ran into what seems a bug during the conversion of a DICOM series.

Encountered behavior
One of the slices was excluded from the series with the following error :

Found 208 DICOM file(s)
slices not stacked: dimensions or bit-depth varies
Convert 207 DICOM as image (640x640x207x1)
slices not stacked: dimensions or bit-depth varies
Convert 1 DICOM as  imagea (128x128x1x1)
Warning: Check that 2D images are not mirrored.

Two files are created.

Expected behavior
There should be only one file

Likely root cause of the problem

After a bit of investigation among the DICOM tags we did the following findings:

• Rows, Columns, Bits Allocated, Bits Stored tags are identical in the main section
• Rows, Columns, Bits Allocated, Bits Stored can be different in what seems to be a thumbnail stored in the DICOM file inside a Sequence Tag

Tags of a "normal" slice :

(0028,0002) US 1                                                  # 2,1 Samples per Pixel
(0028,0004) CS [MONOCHROME2 ]                                     # 12,1 Photometric Interpretation
(0028,0010) US 640                                                # 2,1 Rows
(0028,0011) US 640                                                # 2,1 Columns
(0028,0030) DS [0.421875\0.421875 ]                               # 18,2 Pixel Spacing
(0028,0100) US 16                                                 # 2,1 Bits Allocated
(0028,0101) US 12                                                 # 2,1 Bits Stored
(0028,0102) US 11                                                 # 2,1 High Bit
(0028,0103) US 0                                                  # 2,1 Pixel Representation

(0088,0200) SQ (Sequence with defined length)                     # 4218,1 Icon Image Sequence
  (fffe,e000) na (Item with defined length)
    (0028,0002) US 1                                              # 2,1 Samples per Pixel
    (0028,0004) CS [MONOCHROME2 ]                                 # 12,1 Photometric Interpretation
    (0028,0010) US 64                                             # 2,1 Rows
    (0028,0011) US 64                                             # 2,1 Columns
    (0028,0034) IS [1\1 ]                                         # 4,2 Pixel Aspect Ratio
    (0028,0100) US 8                                              # 2,1 Bits Allocated
    (0028,0101) US 8                                              # 2,1 Bits Stored
    (0028,0102) US 7                                              # 2,1 High Bit
    (0028,0103) US 0                                              # 2,1 Pixel Representation
    (7fe0,0010) OB 0a\0a\0a\0a\0a\0a\0a\0a\0a\0a\0a\0a\0a         # 4096,1 Pixel Data`

Tags of the left out slice :

(0028,0002) US 1                                                  # 2,1 Samples per Pixel
(0028,0004) CS [MONOCHROME2 ]                                     # 12,1 Photometric Interpretation
(0028,0010) US 640                                                # 2,1 Rows
(0028,0011) US 640                                                # 2,1 Columns
(0028,0030) DS [0.421875\0.421875 ]                               # 18,2 Pixel Spacing
(0028,0100) US 16                                                 # 2,1 Bits Allocated
(0028,0101) US 12                                                 # 2,1 Bits Stored
(0028,0102) US 11                                                 # 2,1 High Bit
(0028,0103) US 0                                                  # 2,1 Pixel Representation

(0088,0200) SQ (Sequence with defined length)                     # 4218,1 Icon Image Sequence
  (fffe,e000) na (Item with defined length)
    (0028,0002) US 1                                              # 2,1 Samples per Pixel
    (0028,0004) CS [MONOCHROME2 ]                                 # 12,1 Photometric Interpretation
    (0028,0010) US 64                                             # 2,1 Rows
    (0028,0011) US 64                                             # 2,1 Columns
    (0028,0034) IS [1\1 ]                                         # 4,2 Pixel Aspect Ratio
    (0028,0100) US 8                                              # 2,1 Bits Allocated
    (0028,0101) US 8                                              # 2,1 Bits Stored
    (0028,0102) US 7                                              # 2,1 High Bit
    (0028,0103) US 0                                              # 2,1 Pixel Representation
    (7fe0,0010) OB 07\07\07\07\07\07\07\07\07\07\07\07\07         # 4096,1 Pixel Data

(07a3,10ce) SQ (Sequence with defined length)                     # 16522,? (1)  GDCM:UNKNOWN
  (fffe,e000) na (Item with defined length)
    (0028,0002) US 1                                              # 2,1 Samples per Pixel
    (0028,0004) CS [MONOCHROME2 ]                                 # 12,1 Photometric Interpretation
    (0028,0010) US 128                                            # 2,1 Rows
    (0028,0011) US 128                                            # 2,1 Columns
    (0028,0034) IS [1\1 ]                                         # 4,2 Pixel Aspect Ratio
    (0028,0100) US 8                                              # 2,1 Bits Allocated
    (0028,0101) US 8                                              # 2,1 Bits Stored
    (0028,0102) US 7                                              # 2,1 High Bit
    (0028,0103) US 0                                              # 2,1 Pixel Representation
    (07a1,0010) LO [ELSCINT1]                                     # 8,1 Private Creator
    (7fe0,0010) OB 07\07\07\08\07\07\07\07\07\07\07\07\07         # 16384,1 Pixel Data

Proposed solution
dcm2niix should ignore the tags in sub sequences and see that the two images have the same size

[neurolabusc]

dcm2niix should parse valid icons without problem. My best guess is that this image was corrupted by a PACS system running an obsolete version of GEIIS. This software would insert an icon image that is incompatible with the DICOM standard. The latest versions of dcm2niix have a couple kludges to handle these DICOM-like images, but it is hard to detect these in all cases without causing problems with legitimate Enhanced DICOM images. In particular, the issue can be compounded if the data is later saved with an implicit VR. I note one of your tags refers to a vendor that no longer exists (ELSCINT1) which is consistent with being corrupted by an old version of GEIIS.

• Can you share a dataset? If so, I am happy to look at this. Otherwise feel free to submit a pull request with a patch.
• Can you confirm you are running a recent version of dcm2niix.
• Your proposal of ignoring the SQs will have the unintended consequence of breaking all enhanced DICOM conversion.

[neurolabusc]

@stity my most recent code includes a patch that might work - it attempts to ignore the private SQ 07a3,10ce. You might want to check the providence of your data and see how that SQ got injected - the other images in your set use the normal SQ for icons. Without seeing your data, I am not sure my kludge will work, but it should be close. I do think this reveals a limitation of your images, and not my software. I have never had this reported, but since ELSCINT no longer exists, it may be hard to get vendor support.

[stity]

@neurolabusc Unfortunately I can't share my dataset. I tried to build and run from your latest code and it worked. Are you planning on doing a release soon ?
Thank you for the quick fix and your availability.

[neurolabusc]

There will be a new stable release when issue 240 is closed.