$ 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