Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
ma-tripleT opened this issue Aug 16, 2021 · 1 comment

Comments

@ma-tripleT
Copy link

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) [122p
128]

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.
dicom2nifti_zigzag

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
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants