There is a bug in the new *dcmunpack* that replaces the earlier * unpacksdcmdir* when it is unpacking a "fragmented" dicom directory, i.e. one in which the files were saved to DVD incrementally during the scan, as opposed to dicom files that are saved all at once, after all the scanning is complete.
The difference can be seen with a 'du' command, here is a fragmented, dicom "PRL007", compared to a consolidated one "PRL007C" of the same data:
$ *du* 166156 ./PRL007/DICOM/11020419/14200000 *unconsolidated* 166160 ./PRL007/DICOM/11020419 5188 ./PRL007/DICOM/11020418/50520000 207448 ./PRL007/DICOM/11020418/57160000 101648 ./PRL007/DICOM/11020418/03040000 502616 ./PRL007/DICOM/11020418/42140000 205384 ./PRL007/DICOM/11020418/17590000 1022288 ./PRL007/DICOM/11020418 1188452 ./PRL007/DICOM 1204460 ./PRL007
1022256 ./PRL007C/DICOM/11020418/03040000 *consolidated* 1022260 ./PRL007C/DICOM/11020418 1022264 ./PRL007C/DICOM 1038264 ./PRL007C
When *dcmunpack* unpacks a fragmented dicom, the unpacking *appears* to succeed without errors, but the resulting f.nii file is missing a bunch of acquisitions. Calling dcmunpack on an unconsolidated and consolidated dicom respectively produces the f.nii files below:
*unconsolidated*: /space/ficus/4/users/PRL_sessions/*PRL042*/prl_moco/006/f.nii $ ls -l f.nii -rw-rw-r-- 1 slehar harrisgp 125043040 Jan 6 17:04 f.nii
*consolidated*: /space/ficus/4/users/PRL_sessions/*PRL042C*/prl_moco/006/f.nii $ ls -l f.nii -rw-rw-r-- 1 slehar harrisgp 201720160 Jan 11 20:48 f.nii
Examination with osirix reveals the unconsolidated image to have only 318 acquisitions, the consolidated one has 513 acquisitions.
And just FYI, I wrote a script called *consolidate* (see attached) that does the consolidation you see above, after which *dcmunpack* unpacked it without loss of acquisitions.
This may be an issue that only affects *us* because we do very long ~20 min. functional scans with hundreds of aquisitions, people with more typical scans may not ever experience this issue, and likewise for people who save their scans all at once at the end.
Steve Lehar
Hi Steve, if the same volume is distributed over multiple directories, then it will surely fail (actually, it is mri_convert that assumes that all files for a given volume will be in the same directory). I don't know of anyone else who has had this problem, even those who are scanning for 20 min (maybe they are not unpacking from CDs). doug
Steven Lehar wrote:
There is a bug in the new *dcmunpack* that replaces the earlier *unpacksdcmdir* when it is unpacking a "fragmented" dicom directory, i.e. one in which the files were saved to DVD incrementally during the scan, as opposed to dicom files that are saved all at once, after all the scanning is complete.
The difference can be seen with a 'du' command, here is a fragmented, dicom "PRL007", compared to a consolidated one "PRL007C" of the same data:
$ *du* 166156 ./PRL007/DICOM/11020419/14200000 *unconsolidated* 166160 ./PRL007/DICOM/11020419 5188 ./PRL007/DICOM/11020418/50520000 207448 ./PRL007/DICOM/11020418/57160000 101648 ./PRL007/DICOM/11020418/03040000 502616 ./PRL007/DICOM/11020418/42140000 205384 ./PRL007/DICOM/11020418/17590000 1022288 ./PRL007/DICOM/11020418 1188452 ./PRL007/DICOM 1204460 ./PRL007
1022256 ./PRL007C/DICOM/11020418/03040000 *consolidated* 1022260 ./PRL007C/DICOM/11020418 1022264 ./PRL007C/DICOM 1038264 ./PRL007C
When *dcmunpack* unpacks a fragmented dicom, the unpacking /appears/ to succeed without errors, but the resulting f.nii file is missing a bunch of acquisitions. Calling dcmunpack on an unconsolidated and consolidated dicom respectively produces the f.nii files below:
*unconsolidated*: /space/ficus/4/users/PRL_sessions/*PRL042*/prl_moco/006/f.nii $ ls -l f.nii -rw-rw-r-- 1 slehar harrisgp 125043040 Jan 6 17:04 f.nii
*consolidated*: /space/ficus/4/users/PRL_sessions/*PRL042C*/prl_moco/006/f.nii $ ls -l f.nii -rw-rw-r-- 1 slehar harrisgp 201720160 Jan 11 20:48 f.nii
Examination with osirix reveals the unconsolidated image to have only 318 acquisitions, the consolidated one has 513 acquisitions.
And just FYI, I wrote a script called *consolidate* (see attached) that does the consolidation you see above, after which *dcmunpack* unpacked it without loss of acquisitions.
This may be an issue that only affects *us* because we do very long ~20 min. functional scans with hundreds of aquisitions, people with more typical scans may not ever experience this issue, and likewise for people who save their scans all at once at the end.
Steve Lehar
Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
freesurfer@nmr.mgh.harvard.edu
-
Douglas N Greve -
Steven Lehar