You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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!
The text was updated successfully, but these errors were encountered:
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 thematches = 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
andColumns
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!
The text was updated successfully, but these errors were encountered: