AFNI Message Board

Dear AFNI users-

We are very pleased to announce that the new AFNI Message Board framework is up! Please join us at:

https://discuss.afni.nimh.nih.gov

Existing user accounts have been migrated, so returning users can login by requesting a password reset. New users can create accounts, as well, through a standard account creation process. Please note that these setup emails might initially go to spam folders (esp. for NIH users!), so please check those locations in the beginning.

The current Message Board discussion threads have been migrated to the new framework. The current Message Board will remain visible, but read-only, for a little while.

Sincerely, AFNI HQ

History of AFNI updates  

|
January 06, 2023 05:34PM
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):

Quote

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 -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 -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
Subject Author Posted

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

BradyRoberts January 06, 2023 05:34PM

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

rick reynolds January 06, 2023 08:11PM

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

BradyRoberts January 06, 2023 10:11PM

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

rick reynolds January 08, 2023 03:40PM

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

BradyRoberts January 09, 2023 09:10AM

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

rick reynolds January 09, 2023 11:04AM