Dimon chooses 'zt' but data is in format 'tz'

AFNI Message Board
1

Happy Friday, everyone!

I’m trying to process some DICOM files using Dimon and it is trying to build a to3d command using ‘-time:zt’ rather than what I think is the proper data format (‘-time:tz’). For context, for each run in the study there were 26 slices and 60 scans per slice, with a TR of 2 seconds, for a total of 1,560 DICOM files per run. Each DICOM file begins with r1_ for the first run (i.e., the files are named r1_0001 through r1_1560).

Here is the code I can get to work using to3d:


to3d -prefix Run1 -time:tz 60 26 0 alt+z r1_*

And here is the Dimon code that I also tried to use just for fun…


Dimon -infile_prefix r1_ \
-dicom_org \
-gert_filename Dimon_generated_to3d_script \
-GERT_Reco \
-gert_create_dataset \
-gert_to3d_prefix Run1+orig \
-use_obl_origin

And here is the incorrect (?) to3d code that Dimon spits out…


to3d -prefix Run1+orig -time:zt 1 60 2.000001sec alt+z -@

The problem is that, when I use the above line of code, the command only picks up the first 60 DICOM files and leaves the remaining 1,500 DICOM files out. Ultimately, I’m not sure if I’m wrong or if Dimon is wrong. I’ve loaded the images using the AFNI Image Viewer and it seems that for every 60 files left or right on the slider bar, the slice changes, leading me to think the files are grouped as 60 t and then 1 z, and then 60 t and then 1 z, etc. etc., hence why I believe the ‘tz’ setting is correct.

For posterity’s sake, I also ‘fixed up’ the code that Dimon generated to include all 26 slices…


to3d -prefix Run1+orig_TEST -time:zt 26 60 0 alt+z r1_*

This actually worked too, and the resulting file is very similar to my original to3d file according to 3dinfo, with one exception: the data at the sub-bricks differ.

Anyone have thoughts? Here is the 3dinfo output of the two files (‘zt’ from Dimon first, then my original ‘tz’ code after it):

Psych-P17601:/mnt/c/Users/brrobert/OneDriveUW/Desktop/fMRIdata/MM03/Organized_Files/Run1> 3dinfo Run1+orig_TEST+orig
++ 3dinfo: AFNI version=AFNI_22.3.07 (Dec 2 2022) [64-bit]

Dataset File: Run1+orig_TEST+orig
Identifier Code: AFN_AQYp2ZQT_rQEpB92vDibfw Creation Date: Fri Jan 6 17:26:54 2023
Template Space: ORIG
Dataset Type: Echo Planar (-epan)
Byte Order: LSB_FIRST [this CPU native = LSB_FIRST]
Storage Mode: BRIK
Storage Space: 19,968,000 (20 million) bytes
Geometry String: “MATRIX(2.75,0,0,-108.625,0,2.75,0,-119.4946,0,0,5,-32.39967):80,80,26”
Data Axes Tilt: Plumb
Data Axes Orientation:
first (x) = Right-to-Left
second (y) = Anterior-to-Posterior
third (z) = Inferior-to-Superior [-orient RAI]
R-to-L extent: -108.625 [R] -to- 108.625 [L] -step- 2.750 mm [ 80 voxels]
A-to-P extent: -119.495 [A] -to- 97.755 [P] -step- 2.750 mm [ 80 voxels]
I-to-S extent: -32.400 [I] -to- 92.600 [S] -step- 5.000 mm [ 26 voxels]
Number of time steps = 60 Time step = 2.00000s Origin = 0.00000s Number time-offset slices = 26 Thickness = 5.000
– At sub-brick #0 ‘#0’ datum type is short: 0 to 844
– At sub-brick #1 ‘#1’ datum type is short: 0 to 944
– At sub-brick #2 ‘#2’ datum type is short: 0 to 770
** For info on all 60 sub-bricks, use ‘3dinfo -verb’ **

----- HISTORY -----
[brrobert@Psych-P17601: Fri Jan 6 17:26:54 2023] to3d -prefix Run1+orig_TEST -time:zt 26 60 0 alt+z r1_0001 r1_0002 r1_0003 … r1_1559 r1_1560

Psych-P17601:/mnt/c/Users/brrobert/OneDriveUW/Desktop/fMRIdata/MM03/Organized_Files/Run1> 3dinfo run1+orig
++ 3dinfo: AFNI version=AFNI_22.3.07 (Dec 2 2022) [64-bit]

Dataset File: run1+orig
Identifier Code: AFN_GSoNChvLC9Ye9fnqXj8DZQ Creation Date: Wed May 22 10:39:06 2019
Template Space: ORIG
Dataset Type: Echo Planar (-epan)
Byte Order: LSB_FIRST [this CPU native = LSB_FIRST]
Storage Mode: BRIK
Storage Space: 19,968,000 (20 million) bytes
Geometry String: “MATRIX(2.75,0,0,-108.625,0,2.75,0,-119.4946,0,0,5,-32.39967):80,80,26”
Data Axes Tilt: Plumb
Data Axes Orientation:
first (x) = Right-to-Left
second (y) = Anterior-to-Posterior
third (z) = Inferior-to-Superior [-orient RAI]
R-to-L extent: -108.625 [R] -to- 108.625 [L] -step- 2.750 mm [ 80 voxels]
A-to-P extent: -119.495 [A] -to- 97.755 [P] -step- 2.750 mm [ 80 voxels]
I-to-S extent: -32.400 [I] -to- 92.600 [S] -step- 5.000 mm [ 26 voxels]
Number of time steps = 60 Time step = 2.00000s Origin = 0.00000s Number time-offset slices = 26 Thickness = 5.000
– At sub-brick #0 ‘#0’ datum type is short: 0 to 796
– At sub-brick #1 ‘#1’ datum type is short: 0 to 617
– At sub-brick #2 ‘#2’ datum type is short: 0 to 587
** For info on all 60 sub-bricks, use ‘3dinfo -verb’ **

----- HISTORY -----
[nikkistuart@v1040-wn-rt-c-22-253.campus-dynamic.uwaterloo.ca: Wed May 22 10:39:06 2019] to3d -prefix run1 -time:tz 60 26 0s alt+z r1_0001 r1_0002 r1_0003 … r1_1559 r1_1560

2

Dimon should always sort the images into a zt pattern. It the to3d command is not getting the files in the correct order (from the @filename order), it means the sorting is not working.

Would you please add the Dimon option “-save_details DET”, run it again, and then send me email with perhaps a tgz attachment of the DET* output files? Or else you can just send the one that has “final_sort” or “final_order”, I forget which. That one file should be sufficient.

Thanks,

  • rick
3

Thanks, Rick! I’ve emailed you the files now.

4

Thanks, Brady.

Actually, it is hardly worth running Dimon here, except that you could probably add the -order_as_zt option to fix the sorting.

I guess those images were run through an anonymizer though, as they do not seem to contain relevant sorting information. Is that the case?
Try adding -order_as_zt and see if that fixes it. I would expect so.

  • rick
5

Hi Rick,

I’m not aware of the data being run through an anonymizer, but I’m also not working with my own data, so who knows. The -order_as_zt function in Dimon fixed the resulting to3d command, so that’s great. Thanks!

  • Brady
6

Great, thanks!

  • rick