stowler

# randomly acheived an x2go session w/out static color visual
# spawned from x2go win7 client's built-in x2go xserver after reboot
# here's the x2go client window output

NXPROXY - Version 3.5.0

Copyright (C) 2001, 2010 NoMachine.
See http://www.nomachine.com/ for more information.

Info: Proxy running in client mode with pid '6204'.

stowler

#!/bin/sh

clear


     gm4D="/Users/stowler/ZZ.VBM.2014/inputs/GM_mod_merg_s2.nii.gz"
  blockLH="/Users/stowler/ZZ.VBM.2014/inputs/MNI152_T1_1mm_blockMask_LH.nii.gz"
  blockRH="/Users/stowler/ZZ.VBM.2014/inputs/MNI152_T1_1mm_blockMask_RH.nii.gz"
 idMatrix="/Users/stowler/ZZ.VBM.2014/inputs/id.mat"
parentDir="/Users/stowler/ZZ.VBM.2014/masked.GM_thresh.z165"

stowler

Sorry for the delay. I had to take a crash course in slice timing reconstruction, which is NOT straightforward on the Philips platform.

So, I've managed to reconstruct the files from the 70 TR motor runs with to3d, but only after some nastiness with the file number and slicing order that Philips pukes out. For some odd reason, the time x slice DICOM output failed to generate all of the necessary files (4 IM000 short ) - that took a while to figure out. Additionally, the header information tag was stripped on the Philips output.  Using 2 fields (0020, 0100) and the temporal position identifier - you can suss out the temporal slicing order based on the index of the slice acquisition. However, since the files have to be reindexed, it's not just a matter of advancing through a window to see the offset. This may not be new information to you guys, but it is to me.  From there you just reorder the DICOMs and reconstruct.

The end result is that the temporal slicing is indeed sequential I-to-S with an RAI alignment

stowler

stowler@pano:/data/birc/Florida/AEROBIC_FITNESS/SUBJECTS/AF_s02/AF_s02/acqfiles/Mot_epi04$ ls
20090525_152308Mot_fMRI_4000TRSENSEAF_s04s009a001.nii  DBIEX_9_1.nii  DBIEX_9_1.PAR  DBIEX_9_1.REC


stowler@pano:/data/birc/Florida/AEROBIC_FITNESS/SUBJECTS/AF_s02/AF_s02/acqfiles/Mot_epi04$ 3dinfo 20090525_152308Mot_fMRI_4000TRSENSEAF_s04s009a001.nii 
++ 3dinfo: AFNI version=AFNI_2011_12_21_1014 (Sep  6 2013) [64-bit]
** AFNI converts NIFTI_datatype=4 (INT16) in file 20090525_152308Mot_fMRI_4000TRSENSEAF_s04s009a001.nii to FLOAT32
     Warnings of this type will be muted for this session.
     Set AFNI_NIFTI_TYPE_WARN to YES to see them all, NO to see none.

stowler

Version:1.0 StartHTML:0000000256 EndHTML:0000041465 StartFragment:0000019692 EndFragment:0000041425 SourceURL:file:///P:\BIRC%20imaging\RESEARCH\OTHER%20STUDIES\AerobicFitnessStudy\Zvinkawordgen\fMRI\ScannerParameters\Cog_fMRI_scanner_exam_card.docx
Nucleus =                                "H1";
Coil selection =                       "SENSE-Head-8";
     element selection =            "SENSE";
     connection =                      "d";
Dual coil =                              "no";
CLEAR =                                           "yes";
    body tuned =                      "no";
FOV          FH (mm) =                        240;
             AP (mm) =                 240;

stowler

stowler@qball3:/data/birc/Atlanta/tranThesis/02.collectedData-TREAT_AS_SENSITIVE/mrSourceNiftisScreened$ ls -altr
total 24
drwxrwxr-x 5 stran5  centrify 4096 Jul 17 12:33 ..
drwxr-xr-x 3 stowler centrify 4096 Jul 17 16:45 AF002
drwxr-xr-x 3 stran5  centrify 4096 Jul 18 14:14 AF001
drwxr-xr-x 3 stran5  centrify 4096 Jul 20 16:10 AF004
drwxrwxr-x 6 stran5  centrify 4096 Jul 20 18:17 .
drwxr-xr-x 3 stran5  centrify 4096 Jul 20 18:17 AF006

stowler

AFNI 3dmaskdump INPUT
------------------------------------------------
Appears to use system rounding rint() to convert coordinate floats to integers: 

If user inputs mm coordinates as 3dmaskdump argument, 3dmaskdump converts them to
integer "index coordinates" using serial calls to three functions:
	1) THD_dicomm_to_3dmm() (from thd_coords.c)
	2) THD_3dmm_to_3dfind() (from thd_coords.c)
	3) rint() (from system's buit-in c math, or from faked version in mri_free.c)

stowler

AFNI controller window user INPUT
------------------------------------------------
Appears to use implicit casting + boundary handling to create integer voxel
coordinates from the user-specified mm coordinates in the "Jump to (xyz)" box:


In afni.c , typical use of AFNI_jumpto_dicom() calls AFNI_jumpto_dicom_OLD(),
which converts user-provided mm coordinates to integer voxel coordinates in
three steps:

stowler

AFNI controller window OUTPUT 
------------------------------------------------
Appears to pull existing integer voxel coordinates from internal integer-based
data structures. Doesn't need conversion from float to integer.

When the AFNI controller window is set to display voxel coordinates for the
current crosshair location (GUI "Set Coord Order"->"Voxel Indexes"), it displays
integer coordinates pulled from internal integer data structures.

from afni.c :

stowler

FSL fslview cursor widget
------------------------------------------------
Appears to use explicit casting to convert float mmm coordinates to integer
voxel coordinates, truncating in the process:

line 266 from fslview's cursorwidget.cpp:

	232 void CursorWidget::mmBoxChanged()
	233 {
	...