Hi,

John - thanks for the info.  This sounds very sensible, although these days I would say that the NIFTI definition of voxel coordinates means that there is an unambiguous, agreed-upon voxel coordinate system that we can all share.  That doesn't mean it is the right way to go though - and internally we use mm as it is nicer, we just have tended to see more problems with badly formed NIFTI files, so have been very slow to trust the qform/sform information, but I think problems like this are now rare enough that it is sensible to trust this.

Basile - the bad news here is that you do need to use the sform (qform) information to convert from SPM to FSL conventions.  In FSL we can use either absolute coordinates (as is used in SPM) or relative ones (what John describes as displacement fields).  However, our mm coordinate system is not the same, so you'll need to map between FSL's and SPM's if you want to get the warp correct.  I'll leave it in your hands as to whether this is worth the effort or not.

All the best,
	Mark



On 28 Aug 2012, at 12:24, John Ashburner <[log in to unmask]> wrote:

> Hi MJ,
> Here's a bit more of a clarification.....
> 
> For the deformation fields generated in SPM, the values in each of the
> three components (ie (:,:,:,1,1), (:,:,:,1,2) and (:,:,:,1,3) ) encode
> the x,y,z coordinates of the corresponding location (in units of mm).
> 
> Here is a bit of info about the SPM conventions, as well as some of
> the justifications for the design choices involved:
> 
> 1) The file encodes the mapping rather than displacement fields for a
> couple of reasons:
>   a) Even in 2012, many people still seem to think that displacements
> can be combined by addition or subtraction, rather than by composing
> or inverting the mappings.  (Attempting to compose deformations by
> adding the displacement fields would be analogous to saying 2*2=3 or
> 3*3=5).  Using the mapping instead of the displacements would (I hope)
> make this abuse a bit less likely.
>   b) It saves needing to encode an additional affine transform matrix
> for dealing with the identity transform to which the displacements are
> added.  This makes life simpler.
> 
> 2) It encodes coordinates in mm, rather than voxels.  If the mapping
> was to voxels, it would not work so well for images that are in
> alignment via the matrices encoded by the sform or qform fields.
> Also, if the mapping is to voxels, the values would depend on whether
> the first voxel in the file is denoted as 1,1,1 (as in MATLAB, Fortran
> or SPM) or as 0,0,0 (as in C or FSL).  The mm coordinates are
> unambiguous - providing the sform (or sform) fields of the image that
> the deformation points to is filled in.
> 
> All the best,
> -John
> 
> 
> 
> 
> On 27 August 2012 10:53, Mark Jenkinson <[log in to unmask]> wrote:
>> Hi,
>> 
>> I have no experience of using this and I don't know anyone else who has, but maybe someone from the list can add to this.
>> 
>> The problem you are experiencing will be about coordinate system conventions.  Our mm coordinate system is just a scalar multiple of the voxel coordinates if the image has a negative sform (or qform) determinant.  If the determinant of the sform (or qform) matrix is positive then is it the same except that the x-voxel-coordinate is flipped first (0 to N-1 becomes N-1 to 0).  Note that this means that our origin is in the 0,0,0 voxel (the centre of the voxel) and that we do not use the qform or sform information (except for the sign of the determinant).  If you can figure out what the SPM conventions are then you should be able to adjust for this, although it may not be easy.  If you are very luck then it will just be a shift that is needed to compensate for a different choice of origin.  If you are not lucky then you'll have to take into account other factors such as the sform (or qform) matrix.
>> 
>> Good luck!
>> 
>> All the best,
>>        Mark
>> 
>> 
>> 
>> 
>> On 27 Aug 2012, at 10:42, Basile Pinsard <[log in to unmask]> wrote:
>> 
>>> Hi all,
>>> 
>>> I have a question that might seems weird which is about using the deformation field from SPM New Segment with fnirt utils.
>>> The output of New Segment seems to be an absolute field, that is values represents the coordinates in space to sample in the input space.
>>> There is an options in applywarp and in convertwarp to use absolute warp and it seems to work with applywarp but the results is translated out of the image and only a portion is visible.
>>> Is there something else to apply ? Do I need to provide a premat/postmat to applywarp?  If so, which and from what can it be derived from the field and input space?
>>> Thanks.
>>> 
>>> basile
>>> 
>