Strange Siemens Mosaic DWI to NifTI conversion when DICOM has incorrect (0051,100B)

[ma-tripleT]

Hi team,

The title implies that our input data is not perfect and we know this (we've already given the imaging centre a telling off!).

We have many scans where the (0051,100B) tag (and others) has been supplied to us by the imaging centre as incorrect. That is, the image is 128 x 128 but we have 122 prevalent throughout the DICOM:

(0018,1310) [128,0,0,0]
(0028,0010) [896]
(0028,0011) [896]
(0029,1010) ...
AcquisitionMatrixText=122p128
...
### ASCCONV BEGIN ###
...
sKSpace.lBaseResolution = 128
sKSpace.lPhaseEncodingLines = 122
...
(0051,100B) [122p128]

which results in the output NifTI being "zigzagged" in Z, see attached image where the Sag and Cor views show the zigzag whilst the Ax shows the offset to the left.

It is obvious the cause (incorrect data) and this is immediately present when _mosaic_to_block() reads in the

matches = re.findall(r'(\d+)\D+(\d+)\D*', str(mosaic[Tag(0x0051, 0x100b)].value))[0] and starts dividing up the Mosaic, the number of rows and columns will be incorrect. Since this Mosaic is 40 images in a 7x7 array, the 2nd image in each is offset by 6 pixels, the 3rd by 12 and so on until the 7th is 42 pixels off and the head wraps around. Then resets for the next iteration.

We've temporarily solved it by editing (read: correcting) the (0051,100B) tag.

In our investigation we also found that dicom2niix has no problem with this particular image, and are yet to understand how that is.

This discover motivates my Issue.

My Issue is that dicom2nifti does no "sanity checking" done on these values - why isn't a warning raised about the extra 42 pixels?

I know that Rows and Columns are integer multiples of the resolution of the image, and 896/128 = 7, and 896/122=7.34, so why isn't an error thrown about this being incorrect?

Would it be possible to add in some form of double check before dividing up the Mosaic?

--

Love your work and greatly appreciate your input on how this could be solved for future users with a similar problem.

Thanks in advance!

[blakedewey]

Do you know how dcm2niix checks this value? They might use a different tag that could be more stable.