Dear Gordon,

The appropriately pad part simply refers to extending the outer slices  
so that
interpolation doesn't introduce unwanted problems into the code.  It  
is purely
technical and of no real consequence for the users in this case - so  
ignore it.

You certainly are doing something very strange for brain imaging.
There is no option to do *different* 2D registrations for each slice.
If you use a 3D volume with a 2D schedule file, it will try to  
register this
by applying the same translations, rotations and scalings to all slices
in the 3D data set.  This does not sound like what you want.

I think you need to do exactly as you suggest - split your 3D images
up into the respective 2D slices, run flirt for each of the pairs of
2D slices and then combine the resulting 2D slices back into a 3D  
volume.

All the best,
	Mark


On 27 Nov 2009, at 09:36, Junqian Gordon Xu wrote:

> Mark,
>
> Thanks for the clarification. My multi-slice (hence 3D) data is  
> cardiac gated for every single slice, hence 2D registration for each  
> slice is what I wanted.
>
> By "appropriately pad in the through-slice direction", do you mean  
> it registers the first slice between the -in and -ref 3D volume and  
> then applies the transformation matrix in the through-slice for the  
> rest of the slices?
>
> If that's case, what I was doing was not desired because the cardiac  
> gating nature renders distinct motion for individual slices. Yet I'm  
> not concerned about the alignment between the slices at all (I know  
> this is  weird for the brain paradigm). As long as each slice is  
> aligned through-volume, through-slice alignment means little to my  
> application.
>
> Seems I have to extract slices from the 3D volumes, register them  
> with the -2D flag, then assemble them back into 3D volumes. Does  
> that sound right?
>
> Regards
> Gordon
>
> On 11/27/2009 03:04 AM, Mark Jenkinson wrote:
>> Hi,
>> All the sch2D_* files control the number of degrees of freedom
>> used for the registration.  The -2D flag specifies that it should
>> use the sch2D_3dof degrees of freedom *and* to expect a
>> single slice, and appropriately pad in the through-slice direction
>> (for internal code reasons).
>> The last dof in the 6dof case is a x-y shear (or skew).
>> You can run any of the 2D schedule files with 3D data.  It simply
>> applies the 2D transformation to all slices.  You can use any of
>> the schedule files with 3D data, without using the -2D option.
>> It should work fine.  I'm not quite sure what exactly you are
>> saying went wrong, but try it without the -2D option (but still
>> with the -schedule) and see if that works OK.  Make sure you
>> have a 3D volume for both input and reference though, as
>> otherwise it won't work correctly.
>> All the best,
>>    Mark
>> On 27 Nov 2009, at 06:29, Junqian Gordon Xu wrote:
>>> I want to make sure my understanding of the flirt 2D registration  
>>> correct.
>>>
>>> ${FSLDIR}/etc/flirtsch
>>>
>>> 1) sch2D_3dof (same as -2D): x, y translation + in-plane roation
>>>
>>> 2) sch2D_5dof: sch2D_3dof + x, y scaling?
>>>
>>> 3) sch2D_6dof: sch2D_5dof + ?
>>>
>>> 4) Although the example on line suggests flirt -2D for a single  
>>> slice, it apparently worked with 3D volume images as well in my  
>>> trial. The obvious problem is that it only outputs ONE, instead of  
>>> slice#, transformation matrix, which made me worried about whether  
>>> I am abusing flirt -2D. However the resulting image did show  
>>> improvement in alignment and did suggest the code operated on  
>>> individual slice. Yet, can somebody know the details about flirt  
>>> -2D verify its behavior in such situation?
>>>
>>> Thanks
>>> Junqian "Gordon" Xu
>>> National Multiple Sclerosis Society Postdoctoral Fellow
>>> Department of Neurology
>>> Washington University in St. Louis
>>>
>