Sure - you can change the fslvbm_3_proc script to include fslswapdim/
fslorient calls as long as you're careful that they're doing the right
thing!
Cheers.
On 14 Dec 2007, at 00:53, Thomas, Adam (NIH/NIMH) [E] wrote:
> Sorry I'm coming to this thread a little late. I've just been burned
> by the ambiguity created when both qform and sform are unset. I've
> been using both AFNI and FSL tools to analyze my data and they make
> opposite Left/Right assumptions in this case.
>
> The files I was working with came from the FSL VBM pipeline. The
> orientation information seems to get lost when the files are
> converted from NIFTI to Analyze and back again. Would it be possible
> to amend the fslvbm_3_proc script to set the sform with the
> appropriate orientation when the files are converted back to NIFTI?
>
> Cheers,
> -Adam
>
> --
> Adam Thomas [log in to unmask]
> Functional MRI Facility, NIMH/NIH/DHHS
> 10 Center Dr, Room 1D80
> Bethesda MD. 20892-1148
> Phone:301-402-6351
>
>
>> -----Original Message-----
>> From: Jon Clayden [mailto:[log in to unmask]]
>> Sent: Friday, November 30, 2007 8:47 AM
>> To: [log in to unmask]
>> Subject: Re: [FSL] Analyze/Nifti orientation consistency
>>
>> Mark,
>>
>> Thanks very much for taking the time to reply so thoroughly. This
>> clarifies the situation perfectly.
>>
>> Regards,
>> Jon
>>
>> On 30 Nov 2007, at 10:52, Mark Jenkinson wrote:
>>
>>> Hi Jon,
>>>
>>> Unfortunately, nothing has really been strictly standardised in the
>>> case that neither sform nor qform are set. There is a default sform
>>> matrix - but its use is not prescribed and the meaning of the
>>> derived
>>> mm coordinates is still explicitly left up to the application. The
>>> most
>>> authoritative text on this is the original source document -
>>> nifti1.h -
>>> which can be found in $FSLDIR/src/niftiio/
>>>
>>> The relevant extracts are:
>>>
>>>> ...
>>>>
>>>> The (x,y,z) coordinates refer to the CENTER of a voxel. In
>> methods
>>>> 2 and 3, the (x,y,z) axes refer to a subject-based coordinate
>>>> system,
>>>> with
>>>> +x = Right +y = Anterior +z = Superior.
>>>>
>>>> ...
>>>>
>>>> METHOD 1 (the "old" way, used only when qform_code = 0):
>>>> -------------------------------------------------------
>>>> The coordinate mapping from (i,j,k) to (x,y,z) is the ANALYZE
>>>> 7.5 way. This is a simple scaling relationship:
>>>>
>>>> x = pixdim[1] * i
>>>> y = pixdim[2] * j
>>>> z = pixdim[3] * k
>>>>
>>>> No particular spatial orientation is attached to these (x,y,z)
>>>> coordinates. (NIFTI-1 does not have the ANALYZE 7.5 orient field,
>>>> which is not general and is often not set properly.) This method
>>>> is not recommended, and is present mainly for compatibility with
>>>> ANALYZE 7.5 files.
>>>>
>>>> ...
>>>
>>>
>>> Note that it is METHOD 1 which applies in your case, and that the
>>> definition
>>> of what +x, +y and +z mean in terms of anatomy are *not* specified
>>> for this
>>> case. Therefore it is up to each package to decide what to do. We
>>> do something
>>> consistent with how we used to treat Analyze files, which is to
>>> assume that
>>> they were ordered in the same way as the standard space templates,
>>> which
>>> were always in RAS with respect to their mm coordinates, and LAS
>>> with respect
>>> to their voxel coordinates. By this | mean that going in the +x
>>> direction would
>>> be going towards the Right for the mm coordinates (the right side is
>>> the most
>>> positive x mm coordinate) while it is going towards the Left for the
>>> voxel coordinates
>>> (the left side has the greatest positive x voxel coordinate). We
>>> felt that this
>>> compatibility with the old Analyze files and the way that FSL used
>>> to work (assuming
>>> that all files within a pipeline were consistently ordered) was the
>>> best thing to do.
>>>
>>> I guess the worst part is that the nifti code which we use in the
>>> library tends to
>>> report these defaults for the sform when we don't use them. I like
>>> using the fslhd -x
>>> option as then you don't see the sform or qform if they do not
>>> contain usable
>>> information. Hopefully people will soon eradicate all files without
>>> orientation information
>>> from the world at large, but until then, this is how things are.
>>>
>>> Hope this usefully clarifies things.
>>> All the best,
>>> Mark
>>>
>>>
>>>
>>>
>>>
>>>
>>> On 30 Nov 2007, at 10:30, Jon Clayden wrote:
>>>
>>>> Hi Mark, and thanks for the clarification.
>>>>
>>>> My impression from the Nifti specification was that when the
>>>> qform_code and sform_code are both zero, the file is treated as if
>>>> it had an sform matrix of
>>>>
>>>> ( pixdim[1] 0 0 )
>>>> ( 0 pixdim[2] 0 )
>>>> ( 0 0 pixdim[3] )
>>>>
>>>> which would mean that the data ordering corresponds to the Nifti
>>>> default of RAS. Is this in fact not the case then, and instead the
>>>> default orientation reverts to LAS in these circumstances for
>>>> backwards compatibility?
>>>>
>>>> Jon
>>>>
>>>>
>>>> On 29 Nov 2007, at 23:34, Mark Jenkinson wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> This stuff is all quite confusing I'm afraid, but I think I know
>>>>> what is going on.
>>>>> If you look at the full output of fslhd, you should see that the
>>>>> qform_name is
>>>>> Unknown and the qform_code is 0 (the former is a worded
>>>>> description of the
>>>>> latter). This indicates that this nifti file *does not contain*
>>>>> orientation information
>>>>> (assuming your sform_name is Unknown as well). Hence the fslhd
>>>>> program
>>>>> guesses the x_orient based on a default qform, which isn't useful
>>>>> I'm afraid.
>>>>> The alternative output with fslhd -x only shows you the sform and
>>>>> qform when
>>>>> they contain useful information - so maybe you'll find that
>>>>> better.
>>>>>
>>>>> In general it is dangerous to use nifti files without any
>>>>> orientation information or
>>>>> to use Analyze (as it has no intrinsic, standard orientation
>>>>> information in it).
>>>>> Internally to most fsl tools, such orientation-less files will be
>>>>> treated as radiological
>>>>> where it matters (e.g. in flirt) and things should work fine.
>>>>> However, to be safer
>>>>> it is best to encode the information in nifti file if you are sure
>>>>> which way around the
>>>>> axes are. You can change the nifti information with fslorient.
>>>>> Note that you need
>>>>> to set either the sform or qform code to a non-zero value first,
>>>>> as otherwise it will
>>>>> ignore all attempts to include orientation information. You can
>>>>> check if you have
>>>>> things correct by using FSLView which will label your axes based
>>>>> on this info.
>>>>>
>>>>> I hope this helps make things clearer.
>>>>> All the best,
>>>>> Mark
>>>>>
>>>>>
>>>>>
>>>>> On 29 Nov 2007, at 21:05, Jon Clayden wrote:
>>>>>
>>>>>> Dear all,
>>>>>>
>>>>>> I'm confused about FSL's conventions for dealing with Analyze
>>>>>> files. It says on the FSL site at
>> <http://www.fmrib.ox.ac.uk/fsl/fsl/formats.html
>>>>>>> that Analyze files are treated as being in radiological
>>>>>> convention, i.e. LAS. However, if I convert an Analyze file to
>>>>>> Nifti using fslchfiletype I get a header indicating that the file
>>>>>> is *RAS*, as shown below. Moreover, the image data is unchanged,
>>>>>> rather than being flipped left-to-right as seems to be the case
>>>>>> with the header.
>>>>>>
>>>>>> Can anyone shed any light on why this is?
>>>>>>
>>>>>> Cheers,
>>>>>> Jon
>>>>>>
>>>>>>
>>>>>> $ ls basic*
>>>>>> basic.hdr.gz basic.img.gz
>>>>>> $ fslhd basic | grep -a file_type
>>>>>> file_type ANALYZE-7.5
>>>>>> $ cp basic.hdr.gz basic2.hdr.gz
>>>>>> $ cp basic.img.gz basic2.img.gz
>>>>>> $ ls basic*
>>>>>> basic.hdr.gz basic.img.gz basic2.hdr.gz basic2.img.gz
>>>>>> $ fslchfiletype NIFTI_PAIR_GZ basic2
>>>>>> $ fslhd basic2 | grep xorient
>>>>>> qform_xorient Left-to-Right
>>>>>> sform_xorient Unknown
>>>>>> $ diff basic.img.gz basic2.img.gz
>>>>>> $
>
---------------------------------------------------------------------------
Stephen M. Smith, Professor of Biomedical Engineering
Associate Director, Oxford University FMRIB Centre
FMRIB, JR Hospital, Headington, Oxford OX3 9DU, UK
+44 (0) 1865 222726 (fax 222717)
[log in to unmask] http://www.fmrib.ox.ac.uk/~steve
---------------------------------------------------------------------------
|
