Dimon - Sorting Issue?

Hello!

We just moved to a new location with a new scanner and we are having trouble with our processing pipeline. Our Seimens scanner outputs all the scans from a scanning session (localizer, MPR, etc.) into one folder. A few examples are listed in the attached png. When I unpack the files using freesurfer (unpacksdcmdir), it tells me the info below.

1 Localizer ok 256 256 3 1 MR.1.3.12.2.1107.5.2.19.45407.2017120111250035990000191
2 T1w_MPR ok 320 300 224 1 MR.1.3.12.2.1107.5.2.19.45407.2017120111331335771600696
3 T1w_MPR ok 320 300 224 1 MR.1.3.12.2.1107.5.2.19.45407.2017120111331335072100695
4 ep2d_bold_1_speech ok 448 448 1 3 MR.1.3.12.2.1107.5.2.19.45407.2017120111364684688802025
5 ep2d_bold_1_speech ok 448 448 1 25 MR.1.3.12.2.1107.5.2.19.45407.2017120111453666582902396
6 ep2d_bold_2_speech ok 448 448 1 20 MR.1.3.12.2.1107.5.2.19.45407.2017120111573891098805295
7 ep2d_bold_3_speech ok 448 448 1 42 MR.1.3.12.2.1107.5.2.19.45407.2017120112125922493307559
8 ep2d_bold_rest ok 560 560 1 150 MR.1.3.12.2.1107.5.2.19.45407.2017120112213624227612316

Our previous data was packaged into folders for each run and we would apply the below sequence
Dimon -infile_prefix (dicom data e.g. 123) -dicom_org -use_last_elem -GERT_Reco -save_file_list dimon.list -quit
to3d -prefix (s999_MPRAGE_1) -@ <dimon.list

However, now when I input Dimon -infile_prefix MR -dicom_org -use_last_elem -GERT_Reco -save_file_list dimon.list -quit, I get the output below.

Dimon -infile_prefix MR -dicom_org -use_last_elem -GERT_Reco -save_file_list dimon.list -quit

Dimon running, use to quit…

– scanning for first volume
– reading 691 image files *+ WARNING: Image Positions do not lie in same direction as cross product vector: 0.707107

– first volume found (2 slices)
– scanning for additional volumes…
– run 1: 1 - zoffset outside volume range of 0.000000 to 30.000000

  • banishing image MR.1.3.12.2.1107.5.2.19.45407.2017120111331335771600696 to FAILED state
    → will try to continue…

** bad image state: ind 4, errs 0, state -2 (FSTATE_FAILED), file MR.1.3.12.2.1107.5.2.19.45407.2017120111331335771600696
. . .

final run statistics:
volume info :
slices : 2
z_first : 0
z_last : 30
z_delta : 30
oblique : no
mos_nslices : 0

run #   1 : volumes =   1, first file (#0) = MR.1.3.12.2.1107.5.2.19.45407.2017120111250036157300193

– writing file list to dimon.list…

** have 688 unprocessed image(s)

I assume this has something to do with the files not being named and/or sorted correctly, but I’m not really sure how to go about fixing the issue. I’ve tried dicom_hdr MR*, which gives me a whole lot of info on the dicoms, but I don’t know what to do with that to create a sorting/name rule, or if there is a simpler solution.

Any help would be greatly appreciated!

Thanks!
Samantha

You could use Chris Rorden’s dcm2niix for this. We now distribute that with AFNI, and you can use it with a command like this to take DICOM files from different acquisition datasets.

dcm2niix_afni -f %p_%s directoryname

replacing directoryname with your own.

Hi Samantha,

You can also use @move.to.series.dirs to create those
directories, one per series number, and move the DICOM
images into them. Run it using -test first, and it will say
what it plans to do. See the 2 simple examples in the
-help output.

Note that with “-action copy” it will not move the files,
but make copies of them. Also, applying a directory
prefix via -dprefix might be helpful.

  • rick

Thank you both! These both worked in my colleague’s computer who has a more updated version of afni. Unfortunately I tried to update mine and I keep getting this output.

bash-3.2$ @update.afni.binaries -d
– have AFNI binaries under /usr/local/AFNI/
– install dir: using existing /usr/local/AFNI/
– attempting to install package macosx_10.7_Intel_64 under
install dir: /usr/local/AFNI/…
– have install dir
nuking old temporary directory…
rm: cannot remove ‘.tmp.install/macosx_10.7_Intel_64.tgz’: Permission denied
++ working in new temp dir, .tmp.install
mkdir: cannot create directory ‘.tmp.install’: File exists
** failed to create new or remove old temp dir, .tmp.install

It looks like AFNI is installed under the /usr/local/AFNI
directory, which you do not own. Are you sharing that
set of binaries with someone else on that computer, or
are you the only one using AFNI from there?

  • rick

I just ended up downloading anfi fresh and now the script runs no problems!

Thanks so much! Also Dr. Kristina Simonyan says hi and thank you for the help :slight_smile:

All the best,
Samantha

That is great, Samantha!

And please give a big hi to Kristina!

  • rick