slicemoco_newalgorithm.sh -d $sub176_176tr -s 2

But at the end I get this not very reassuring message (see my bolding below) which suggests slomoco has run with slice timing set to interleaved.
My question is, did I specify the flag incorrectly? Is there some way for me to verify that it used sequential slice timing?  Please let me know how I should proceeed.

Thankyou,

Dianne Patterson, Ph.D.
Research Scientist
dkp@email.arizona.edu
University of Arizona
Speech and Hearing Science 

=============================================

Running Secondorder Motion Correction using SLOMOCO output
matlab <<<"addpath /MATLAB/slomoco_afni_07_2014; mocoparams=read_motion_newslicealg('tempslmoco_volslc_alg_vol_run1_sub176_176tr.slicemocoxy_afni/motion.wholevol_zt'); slicemoco_newalgorithm_input('run1_sub176_176tr.slicemocoxy_afni+orig','run1_sub176_176tr.brain+orig',mocoparams,2); exit;"
< M A T L A B (R) >
Copyright 1984-2014 The MathWorks, Inc.
R2014a (8.3.0.532) 64-bit (maci64)
February 11, 2014
To get started, type one of these: helpwin, helpdesk, or demo.
For product information, visit http://www.mathworks.com.
>>
tdim =
176
zdim =
36
assuming slice timing==1, for interleaved ascending, siemens style
Wait, script starting...
Elapsed time is 246.858306 seconds.
ErrMessage =
''
InfoOut =
RootName: 'run1_sub176_176tr.slicemocoxy_afni+orig'
DATASET_RANK: [3 176 0 0 0 0 0 0]
BRICK_TYPES: [1x176 double]
BYTEORDER_STRING: 'LSB_FIRST'
ORIENT_SPECIFIC: [0 2 4]
ORIGIN: [-98.3183 135.9666 -33.1909]
DELTA: [3.3611 -3.3611 3.9999]
SCENE_DATA: [0 2 0 -999 -999 -999 -999 -999]
TYPESTRING: '3DIM_HEAD_ANAT'
TAXIS_NUMS: [176 0 77002 -999 -999 -999 -999 -999]
TAXIS_FLOATS: [0 2 0 0 0 -999999 -999999 -999999]
IDCODE_DATE: 'Tue Dec 16 12:22:31 2014'
HISTORY_NOTE: '[dpat@caribou.shs.arizona.edu: Tue Dec 16 12:04:3...'
IJK_TO_DICOM_REAL: [1x12 double]
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: [60 72 36 0 0]
BRICK_FLOAT_FACS: [1x176 double]
BRICK_STATS: [1x352 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 (maci64)
February 11, 2014
To get started, type one of these: helpwin, helpdesk, or demo.
For product information, visit http://www.mathworks.com.
>> using 36 slices, TR=2.000000 seconds
tdim =
176
zdim =
36
tdim =
176
zdim =
36
QA script currently assumes we acquire interleaved asc, odds, then evens
*+ WARNING: If you are performing spatial transformations on an oblique dset,
such as run1_sub176_176tr_pestica/run1_sub176_176tr+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:run1_sub176_176tr_pestica/run1_sub176_176tr+orig.BRIK is 7.057969 degrees from plumb.
*+ WARNING: If you are performing spatial transformations on an oblique dset,
such as run1_sub176_176tr_pestica/run1_sub176_176tr+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:run1_sub176_176tr_pestica/run1_sub176_176tr+orig.BRIK is 7.057969 degrees from plumb.
*+ WARNING: If you are performing spatial transformations on an oblique dset,
such as run1_sub176_176tr_pestica/run1_sub176_176tr+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:run1_sub176_176tr_pestica/run1_sub176_176tr+orig.BRIK is 7.057969 degrees from plumb.
++ 3drefit: AFNI version=AFNI_2011_12_21_1014 (Jul 3 2014) [64-bit]
++ Authored by: RW Cox
++ Processing AFNI dataset run1_sub176_176tr.slicemocoxy_afni.zalg_moco2+orig
++ applying attributes
++ 3drefit processed 1 datasets
++ 3drefit: AFNI version=AFNI_2011_12_21_1014 (Jul 3 2014) [64-bit]
++ Authored by: RW Cox
++ Processing AFNI dataset run1_sub176_176tr.slicemocoxy_afni.zalg_moco2+orig
++ applying attributes
++ 3drefit processed 1 datasets
++ 3drefit: AFNI version=AFNI_2011_12_21_1014 (Jul 3 2014) [64-bit]
++ Authored by: RW Cox
** ERROR: Can't decode 1D: string
** FATAL ERROR: No options given!?
Error reading floating point attribute file** Program compile date = Jul 3 2014

Hi Dianne,

Shoot, I'm sorry, I didn't test this on sequential data. You're setting the string correctly but its not getting passed through because its not in the motion param reading command. Can you add $SLOMOCO_SLICE_ORDER to the read_motion_newslicealg() function as the second parameter in the shell script, by changing:

mocoparams=read_motion_newslicealg('tempslmoco_volslc_alg_vol_$epi.slicemocoxy_afni/motion.wholevol_zt');

to

mocoparams=read_motion_newslicealg('tempslmoco_volslc_alg_vol_$epi.slicemocoxy_afni/motion.wholevol_zt',$SLOMOCO_SLICE_ORDER);

This command is repeated several times (different branch logic), if you do a find and replace to get them all, it should work. Can you try this and let me know if it works? I could also create a new slicemoco_newalgorithm.sh file for you, if you like.

Also, its failing on the last 3drefit inside the shell script - can you comment out the last 3drefit (and may as well comment out the 3dNotes command) and re-run? It won't change the data, although it also means it won't pull the full header information across. There's got to be a better way to do this, but the afni_matlab toolbox doesn't have many options. It may be better to simply re-to3d create the dataset, but I'd like try this first if possible.

Erik

Hi Erick

I had the same issue as Dianne with some ascending data.

I applied the correction you mentioned and the scrip stops at that point without moving. I had to cancel it.

Can this be overcome some other way?

Thank you

Eduardo

Hi Eduardo,

The easiest way would be to modify read_motion_newslicealg.m and read_slicemocoxy_AFNI_files_auto.m to force them to use sequential slice acquisition ordering. On the second line in the first file and qa_slomoco.m, add "slice_timing=2;" and it will use sequential ordering, on the second file, add "slice_acq_order=2;" as the second line. This will force them to use sequential acquisition always! This is just a hack, a workaround for this. The correct way is to use the method Dianne used, and which I will have to add to the scripts, but it will be a few weeks before I can make this change.

Erik

Geez, I'm sorry I didn't see your response Eric.  
I must have failed to check the box to receive responses via email.
More investigation for me revealed that your code was right to choose 
interleaved in the first place (for our siemens)...so I never pursued the issue of setting the order to ascending.


I am looking forward to your next iteration of slomoco though.

-Dianne

Hi Erick

Thanks for the answer, I will try it.
Though you should know it forces Siemens style always, even if you want to use alt-asc. I'm using Phillips acquired data.

Eduardo

No worries!

Eduardo, 
sorry for the Siemens-only prescription and forcing you to use a workaround to use sequential! That was a big oversight on our part and will be fixed in the next release.

As a side note, in case anyone else is having trouble with this but is using an odd number of slices, for using non-Siemens alt-asc, the Siemens alt-asc is practically identical when there are an odd number of slices, but when there are an even number of slices, Siemens is very different (starts on the second slice instead of the first) from plain alt-asc. So if you have a non-Siemens scanner and your acquisition is interleaved and you have an odd number of slices, the default is fine, but if you have an even number of slices, you'll need to modify to use plain alt-asc. Also, will be fixed!

Appreciate the help, great tools anyway.

Eduardo

I have the same problem and need to evaluate data with ascending slice order. Unfortunately, both solutions are problematic. If I apply the hack, for which I added "slice_timing=2;" in qa_slomoco.m and read_motion_newslicealg.m as well as  "slice_acq_order=2;" in read_slicemocoxy_AFNI_files_auto.m, slomoco stops at a point of the processing with the following message:

Wait, script starting...

That seems to be a message from slicemoco_newalgorithm.sh, but I do not really understand why it occurs at all.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
In order to apply the version which you suggested first, the following replacement was carried out in read_motion_newslicealg.m:

mocoparams1=textread(sprintf('%s.0000.1D',filestr),'','headerlines',1);

replaced by

mocoparams1=textread(sprintf('%s.0000.1D',filestr),'','headerlines',1,$SLOMOCO_SLICE_ORDER);

If I proceed in this way the script stops without finishing the image processing.

Hi,

I found something in the qa_slomoc.m which seems to be at the wrong position. In line 378 there is a the following:

disp('QA script currently assumes we acquire interleaved asc, odds, then evens');

I guess this needs to be in the if...then...else statement, directly above this assignment. Can you tell me if I am right?

HI Jörg

Thanks for the feedback. Please feel free to modify the code, if needed, since it is a open source. However,PESTICA and SLOMOCO assume 2D EPI acquisition, which induces slice acquisition order and different slice timing offset, and PESTICA and SLOMOCO need to run the data set BEFORE slice timing correction, input data is strongly recommended to have those correction information. 

The new version of PESETICA and SLOMOCO is being beta-tested and will be distributed soon , in which slice acquisition order is not assumed anymore, and should be provided, and so is slice timing offset. I saved these information when generating the input data, e.g. to3d. You probably add these information using 3drefit before running PESTICA & SLOMOCO.



-Wanyong