open-discussion > Secondorder motion correction errors
Showing 1-5 of 5 posts
Display:
Results per page:
Apr 6, 2015  11:04 PM | Gabe Castillo
Secondorder motion correction errors
I'm having errors pop up about an hour into running slomoco on a dataset. This data was acquired obliquely in case that helps. Also, I have specified type 3 slice order(GE interleaved), but the 2nd order correction seems to go back to the default(1).

I should add that the setup_slomoco.sh script has the following line:
export PESTICA_SLICE_TIMING="siemens-alt-asc"
I don't know the correct text to specify GE ordered interleaved slicing.

It also seems that the matlab path is not being propagated correctly, as I have this line in setup_slomoco.sh:


export MATLAB_AFNI_DIR=/usr/local/afni_matlab


But when I use the path command in matlab, the BrikLoad command is successfully found

Any help would be appreciated. Please see output below:
Running Secondorder Motion Correction using SLOMOCO output

matlab <<<"addpath /usr/local/slomoco; mocoparams=read_motion_newslicealg('tempslmoco_volslc_alg_vol_213_PDF.PCOG14.WMEM1.slicemocoxy_afni/motion.wholevol_zt'); slicemoco_newalgorithm_input('213_PDF.PCOG14.WMEM1.slicemocoxy_afni+orig','213_PDF.PCOG14.WMEM1.brain+orig',mocoparams,3); exit;"

assuming slice timing==1, for interleaved ascending, siemens style
Wait, script starting...
Undefined function 'BrikLoad' for input arguments of type 'struct'.

Error in slicemoco_newalgorithm_input (line 17)
[err, im, ainfo, ErrMessage]=BrikLoad(ep2d_filename, Opt);

>> Undefined function 'BrikLoad' for input arguments of type 'struct'.

Error in qa_slomoco (line 14)
[err, ima, ainfo, ErrMessage]=BrikLoad(ep2d_filename, Opt);

>> *+ WARNING: If you are performing spatial transformations on an oblique dset,
such as 213_PDF.PCOG14.WMEM1_pestica/213_PDF.PCOG14.WMEM1+orig.BRIK,
or viewing/combining it with volumes of differing obliquity,
you should consider running:
3dWarp -deoblique
on this and other oblique datasets in the same session.
See 3dWarp -help for details.
++ Oblique dataset:213_PDF.PCOG14.WMEM1_pestica/213_PDF.PCOG14.WMEM1+orig.BRIK is 14.743005 degrees from plumb.
*+ WARNING: If you are performing spatial transformations on an oblique dset,
such as 213_PDF.PCOG14.WMEM1_pestica/213_PDF.PCOG14.WMEM1+orig.BRIK,
or viewing/combining it with volumes of differing obliquity,
you should consider running:
3dWarp -deoblique
on this and other oblique datasets in the same session.
See 3dWarp -help for details.
++ Oblique dataset:213_PDF.PCOG14.WMEM1_pestica/213_PDF.PCOG14.WMEM1+orig.BRIK is 14.743005 degrees from plumb.
*+ WARNING: If you are performing spatial transformations on an oblique dset,
such as 213_PDF.PCOG14.WMEM1_pestica/213_PDF.PCOG14.WMEM1+orig.BRIK,
or viewing/combining it with volumes of differing obliquity,
you should consider running:
3dWarp -deoblique
on this and other oblique datasets in the same session.
See 3dWarp -help for details.
++ Oblique dataset:213_PDF.PCOG14.WMEM1_pestica/213_PDF.PCOG14.WMEM1+orig.BRIK is 14.743005 degrees from plumb.
++ 3drefit: AFNI version=AFNI_2011_12_21_1014 (Feb 9 2015) [64-bit]
++ Authored by: RW Cox
** ERROR: Can't open dataset 213_PDF.PCOG14.WMEM1.slicemocoxy_afni.zalg_moco2+orig
++ 3drefit processed 0 datasets
++ 3drefit: AFNI version=AFNI_2011_12_21_1014 (Feb 9 2015) [64-bit]
++ Authored by: RW Cox
** ERROR: Can't open dataset 213_PDF.PCOG14.WMEM1.slicemocoxy_afni.zalg_moco2+orig
++ 3drefit processed 0 datasets
++ 3drefit: AFNI version=AFNI_2011_12_21_1014 (Feb 9 2015) [64-bit]
++ Authored by: RW Cox
** ERROR: Can't open dataset 213_PDF.PCOG14.WMEM1.slicemocoxy_afni.zalg_moco2+orig
++ 3drefit processed 0 datasets

Error: Cannot open dataset

EDIT: Added some relevant info regarding startup script and matlab path variables.
Apr 7, 2015  12:04 AM | Gabe Castillo
RE: Secondorder motion correction errors
I fixed the afni_matlab path issue, but the script continues to assume slice timing to be 1 or siemens-alt-asc. I have tried setting the value of PESTICA_SLICE_TIMING to 3(no quotes) and "3" (with-quotes) in the setup script(and running it prior to slomoco) to no avail.


> setup_slomoco.sh
setting up for PESTICA+SLOMOCO environment because it is not already setup
> slicemoco_newalgorithm.sh -d 213_PDF.PCOG14.WMEM1 -s 3
setting SLCMOCO_DIR to directory where this script is located (not the CWD)
***** Using copied input in 213_PDF.PCOG14.WMEM1_pestica/213_PDF.PCOG14.WMEM1+orig.HEAD as input timeseries
***** Using 213_PDF.PCOG14.WMEM1.brain+orig.HEAD to mask out non-brain voxels


Running Secondorder Motion Correction using SLOMOCO output

matlab <<<"addpath /usr/local/slomoco; mocoparams=read_motion_newslicealg('tempslmoco_volslc_alg_vol_213_PDF.PCOG14.WMEM1.slicemocoxy_afni/motion.wholevol_zt'); slicemoco_newalgorithm_input('213_PDF.PCOG14.WMEM1.slicemocoxy_afni+orig','213_PDF.PCOG14.WMEM1.brain+orig',mocoparams,3); exit;"

< M A T L A B (R) >
Copyright 1984-2014 The MathWorks, Inc.
R2014a (8.3.0.532) 64-bit (glnxa64)
February 11, 2014

To get started, type one of these: helpwin, helpdesk, or demo.
For product information, visit http://www.mathworks.com.

>>
tdim =

240

zdim =

37

assuming slice timing==1, for interleaved ascending, siemens style
Wait, script starting...
Apr 7, 2015  12:04 AM | Gabe Castillo
RE: Secondorder motion correction errors
I have pasted the output it generates below. 


ErrMessage =


''

InfoOut =

RootName: '213_PDF.PCOG14.WMEM1.slicemocoxy_afni+orig'
DATASET_RANK: [3 240 0 0 0 0 0 0]
BRICK_TYPES: [1x240 double]
BYTEORDER_STRING: 'LSB_FIRST'
ORIENT_SPECIFIC: [0 3 5]
ORIGIN: [-114.8830 -130.5460 78.9731]
DELTA: [4 4 -4]
SCENE_DATA: [0 2 0 -999 -999 -999 -999 -999]
TYPESTRING: '3DIM_HEAD_ANAT'
TAXIS_NUMS: [240 37 77002 -999 -999 -999 -999 -999]
TAXIS_FLOATS: [0 2 0 78.9731 -4 -999999 -999999 -999999]
TAXIS_OFFSETS: [1x37 double]
IDCODE_DATE: 'Mon Apr 6 16:23:18 2015'
HISTORY_NOTE: '[gabe@chile: Mon Apr 6 10:44:21 2015] to3d -pref...'
IJK_TO_DICOM_REAL: [4 0 0 -114.8830 0 4 0 -130.5460 0 0 -4 78.9731]
LABEL_1: 'zyxt'
LABEL_2: 'zyxt'
DATASET_NAME: 'zyxt'
WORSLEY_DF: []
WORSLEY_NCONJ: []
WORSLEY_FWHM: []
TypeName: 'short'
TypeBytes: 2
ByteOrder: 'ieee-le'
Orientation: [3x2 char]
FileFormat: 'BRIK'
Extension_1D: ''
DATASET_DIMENSIONS: [64 64 37 0 0]
BRICK_FLOAT_FACS: [1x240 double]
BRICK_STATS: [1x480 double]

err =

0

2nd order Moco Done!

< M A T L A B (R) >
Copyright 1984-2014 The MathWorks, Inc.
R2014a (8.3.0.532) 64-bit (glnxa64)
February 11, 2014

To get started, type one of these: helpwin, helpdesk, or demo.
For product information, visit http://www.mathworks.com.

>> using 37 slices, TR=2.000000 seconds

tdim =

240

zdim =

37

non-sensical or unsupported slice acquisition order inputted:

slice_acq_order =

3

Error in read_slicemocoxy_AFNI_files_auto (line 8)
if (exist('moco_folder')==0)

Output argument "inplane" (and maybe others) not assigned during call to
"/usr/local/slomoco/read_slicemocoxy_AFNI_files_auto.m>read_slicemocoxy_AFNI_files_auto".

Error in qa_slomoco (line 56)
[inplane,inplane6]=read_slicemocoxy_AFNI_files_auto(filestr_in,slice_timing);

>> *+ WARNING: If you are performing spatial transformations on an oblique dset,
such as 213_PDF.PCOG14.WMEM1_pestica/213_PDF.PCOG14.WMEM1+orig.BRIK,
or viewing/combining it with volumes of differing obliquity,
you should consider running:
3dWarp -deoblique
on this and other oblique datasets in the same session.
See 3dWarp -help for details.
++ Oblique dataset:213_PDF.PCOG14.WMEM1_pestica/213_PDF.PCOG14.WMEM1+orig.BRIK is 14.743005 degrees from plumb.
*+ WARNING: If you are performing spatial transformations on an oblique dset,
such as 213_PDF.PCOG14.WMEM1_pestica/213_PDF.PCOG14.WMEM1+orig.BRIK,
or viewing/combining it with volumes of differing obliquity,
you should consider running:
3dWarp -deoblique
on this and other oblique datasets in the same session.
See 3dWarp -help for details.
++ Oblique dataset:213_PDF.PCOG14.WMEM1_pestica/213_PDF.PCOG14.WMEM1+orig.BRIK is 14.743005 degrees from plumb.
*+ WARNING: If you are performing spatial transformations on an oblique dset,
such as 213_PDF.PCOG14.WMEM1_pestica/213_PDF.PCOG14.WMEM1+orig.BRIK,
or viewing/combining it with volumes of differing obliquity,
you should consider running:
3dWarp -deoblique
on this and other oblique datasets in the same session.
See 3dWarp -help for details.
++ Oblique dataset:213_PDF.PCOG14.WMEM1_pestica/213_PDF.PCOG14.WMEM1+orig.BRIK is 14.743005 degrees from plumb.
++ 3drefit: AFNI version=AFNI_2011_12_21_1014 (Feb 9 2015) [64-bit]
++ Authored by: RW Cox
++ Processing AFNI dataset 213_PDF.PCOG14.WMEM1.slicemocoxy_afni.zalg_moco2+orig
++ applying attributes
++ 3drefit processed 1 datasets
++ 3drefit: AFNI version=AFNI_2011_12_21_1014 (Feb 9 2015) [64-bit]
++ Authored by: RW Cox
++ Processing AFNI dataset 213_PDF.PCOG14.WMEM1.slicemocoxy_afni.zalg_moco2+orig
++ applying attributes
++ 3drefit processed 1 datasets
++ 3drefit: AFNI version=AFNI_2011_12_21_1014 (Feb 9 2015) [64-bit]
++ Authored by: RW Cox
++ Processing AFNI dataset 213_PDF.PCOG14.WMEM1.slicemocoxy_afni.zalg_moco2+orig
++ applying attributes
++ 3drefit processed 1 datasets
Apr 9, 2015  01:04 PM | Erik Beall
RE: Secondorder motion correction errors
Hi Gabe,

Thanks for trying out SLOMOCO, its really great once you get it working! So to summarize, you've been running with a different slice acquisition order than the default, and the last part of the script fails, please correct me if thats wrong. I have good news...

Fortunately, SLOMOCO is not as sensitive to slice acquisition order as PESTICA, as long as the same setting is used throughout the script.  Unfortunately the first part of the script just assumes interleaved ascending order, and the last part reads it from the command environment. As long as its the same for both parts (and yes, I need to fix this in the next release, this is not a nice way to leave software), it will run correctly, so please run it with the default original slice order for now (siemens-alt-asc).  In fact, siemens-alt-asc is identical to GE interleaved when you have an odd number of slices (the difference only occurs when you have an even number of slices, then it starts on slice #2 on Siemens, but even in that case you can leave it as the default in this script). I'm sorry I left such a weird hack in the script, it will be fixed in the next release. Once it works, you should get a pair of saved images for the motion parameters, and the motion parameters in the slomoco.combined.reg6dof.txt for every slice.

Erik
Apr 11, 2015  12:04 AM | Gabe Castillo
RE: Secondorder motion correction errors
Hi Erik,
  Thanks for the info. When I run it with the default slice order, it seems to run fine. 

On a different note, is there a preferred or specified order for doing fieldmap corrections as well as slice-time-correction(using AFNI's 3dTshift) with SLOMOCO?

Thanks,
  Gabe