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

Troubleshooting incorrect import behavior #862

Open
annchenknodt opened this issue Sep 19, 2024 · 2 comments
Open

Troubleshooting incorrect import behavior #862

annchenknodt opened this issue Sep 19, 2024 · 2 comments

Comments

@annchenknodt
Copy link

I have a diffusion sequence that consists of 8820 dicoms, and i have successfully imported it to a 96x96x60x147 nii file in >400 cases. However, I now am dealing with a scan where I seem to have 8820 complete dicoms but dcm2niix is unable to figure out how to stack them into niftis, so I'm looking for suggestions on how to troubleshoot this. I'm not sure if it's related, tho suspect it likely is, that Siemens has recently updated us to a new PACS system (and also pushed some minor updates to the scanner), and we've had some issues with successfully exporting data from the scanner ever since, especially with this diffusion sequence, which is the longest in our protocol. I had a similar issue with another scan, but had the tech re-export from the scanner, and dcm2niix worked on the re-exported data. Since the re-export did not seem to work with this one and it seems like all the dicoms are there and complete, I'm hoping that there's something I can do to arrange the images / tweak the metadata to help dcm2niix understand how to stack them. I tried running dcm2niix with option -m 1 but got the same result (didn't see any other options that seemed like they could potentially be relevant here).

Here is the output I'm getting from dcm2niiX:

Chris Rorden's dcm2niiX version v1.0.20240202  (JP2:OpenJPEG) (JP-LS:CharLS) GCC8.4.0 x86-64 (64-bit Linux)
Found 9000 DICOM file(s)
Warning: Series 13 includes partial volume (issue 742): 1 slices acquired but ICE dims (0021,118e) specifies 60
...
Warning: Series 13 includes partial volume (issue 742): 1 slices acquired but ICE dims (0021,118e) specifies 60
Slice positions repeated, but number of slices (8820) not divisible by number of repeats (7): converting only complete volumes.
Warning: Discrepancy between reported (4.7s) and estimated (88.6286s) repetition time (issue 560).
Warning: Seconds between volumes varies
Warning: Instance Number (0020,0013) order is not spatial.
Warning: Volume number does not vary (0019,10A2; 0020,0100; 2005,1063; 2005,1413), assuming meaningful instance number (0020,0013).
Error: Check sorted order: 4D dataset has 7 volumes, but volume index ranges from 0..0
Warning: Unable to determine slice direction: please check whether slices are flipped (derived image)
Warning: Siemens XA exported as classic not enhanced DICOM (issue 236)
Convert 8820 DICOM as /cifs/hariri-long/Studies/DBIS_P52/SYNCED_FROM_OTAGO/Raw_Data/DMHDS0832_diffTake2/DMHDS/1013_DMHDS_Diff_147_p2s2_20240816141818 (96x96x1260x7)

And here is what I was getting before i updated my dcm2niiX to the latest version, in case it's helpful:

Chris Rorden's dcm2niiX version v1.0.20170724 GCC4.4.7 (64-bit Linux)
Found 9000 DICOM image(s)
slices stacked despite varying acquisition numbers (if this is not desired please recompile)
Slice positions repeated, but number of slices (8820) not divisible by number of repeats (8): missing images?
Dims 96 96 8820 1 8
Warning: Interslice distance varies in this volume (incompatible with NIfTI format).
 Distance from first slice:
dx=[0 ... 542]
Convert 8820 DICOM as DMHDS0832_diffTake2/DMHDS/013_DMHDS_Diff_147_p2s2_20240816141818 (96x96x8820x1)

Thanks!

@neurolabusc
Copy link
Collaborator

Please see the Public Service Announcement - I would strongly discourage exporting Siemens XA data as classic DICOMs, rather you should consider setting this for enhanced export. I suggest you work with the Siemens Research Collaboration Manager as you proceed. While classic XA DICOM export might work some of the time, in my experience they are impoverished and fragile.

My from the output sense is that this is an issue with your images and not dcm2niix. If you want more feedback, share a problematic dataset with my institutional email

@annchenknodt
Copy link
Author

Thank you so much for sharing that link!! Certainly explains many things. I do agree that this is an issue with my images and not dcm2niix, so mainly I'm wondering if there's something I can tweak on my images to "fix" them, or if going back and starting from the source is the only option (Siemens hasn't been particularly helpful in dealing with our issues so far at least, but I will speak with the tech about the enhanced export option). Since I have over 400 cases where i have successfully used dcm2niix to import this sequence from our XA30 skyra (including 40-50 cases since the scanner service which precipitated our latest troubles), I wonder if there's something in the headers of the working dcms that I can mirror to the problematic dicoms or something... I realize that my understanding here is limited and this may be a very unreasonable idea.

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