OK, thanks, I look forward to the solution.

I think I may already have found it.
When I rerun my processing pipeline I get images displayed correctly with the new FSLVIEW.

Others have written about this sort of problem and it refers to the interaction between AFNI and FSL NIFTI formats.

My processing pipeline is

DICOM->AFNI->NIFTI->FSL->(eddy_correct/dtifit/etc)

If I take an AFNI dataset (Axial, 3dinfo says RAI) and do the following :-

3dresample -prefix 08dtilas -inset 08dtirai+orig -orient RPI
3dAFNItoNIFTI 08dtilas+orig

and then run the result (08dtilas.nii) through fslview and fslorient, the data seems to be truly LAS,

i.e. ++x moves the line to the label L on the axial/coronal image (which is on the right side of the displayed images)
      ++y moves the line to the label A on the axial/sagittal images (which is at the top of the axial image and on the right side of the sagittal)
      ++z moves the line to the label S on the coronal/sagittal images (which is at the top of the displayed images)

and

fslorient -getorient 08dtilas

yields RADIOLOGICAL

Prior to using this approach I tried a number of approaches involving avworient, avwswapdim etc, but I could never get
it quite right.

For example I find that the following almost works but takes a little longer if your default format is NIFTI_GZ :-

3dAFNItoNIFTI 08dtirai+orig
fslorient -getorient 08dtirai  -> NEUROLOGICAL  (don't know why ?????)
fslorient -forceradiological 08dtirai
fslswapdim 08dtirai -x -y z 08dtilas
fslorient -getorient 08dtilas -> RADIOLOGICAL

The labels in the displayed images on FSLVIEW are the same as with the approach above, but the actual data is L-R reversed.

If I try

fslswapdim 08dtirai x -y z 08dtilas

I get the following error message

WARNING:: Flipping left/right orientation (as det < 0)

However the result works properly i.e. is the same as for the method involving 3dresample (the pixels in the file are
in exactly the same order, and both the sform and qform matrices are the same).

These issues are a bit of a pain for those of us working between packages, thanks for the
ongoing help.

-roddy

>>> Tim Behrens <[log in to unmask]> 8/22/2007 12:13 PM >>>
OK - I know the answer to half of this, and I think Dave and Matthew  
know the answer to the other half (but they have left for the day now).

The reason  your lines appear flipped is this. Previously Fslview  
presented vectors with respect to "world" coordinates (mm), but Fdt  
coded lines wrt the data grid. They were consistent for radiological  
data, and therefore inconsistent for Neurological data.

This meant that if your lines looked right in fslview, they would be  
WRONG for FDT and tractography.
i.e., the lines in the image you have sent me should not have worked  
for tractography.


Now fslview has been made to be compatible with FDT, so that it  
displays wrt data grid. So now, if it looks right in fslview, it  
should work in Fdt.

What this means is that you have to flip your bvecs in x (i.e. take  
the negative of all of your x values in  your b-vectors).
The good news is that the FA won't change, and that tractography  
might now work!

The bad news is that you cannot flip from Radiological to  
Neurological formats without flipping bvecs as well. You have to  
stick with one.

I'm sorry for not announcing this change - we are not quite up to  
date with the FAQ.



I think Dave and Matthew know about the shifting problem, and will  
hopefully answer you in the morning.


Cheers

T




On 22 Aug 2007, at 17:47, Roderick McColl wrote:

> Sure, the ref number is 653046 and the file I uploaded is 653046.zip
>
> It has screenshots from each version of FSLVIEW and the data used.
> Just the FA is shown in the screenshots.
>
> Thanks
>
> -roddy
>
>>>> Tim Behrens <[log in to unmask]> 8/22/2007 11:28 AM >>>
> Can you upload the data onto
> www.fmrib.ox.ac.uk/cgi-bin/upload.cgi 
>
> and send me the reference number please?
>
> Thanks
>
> T
> On 22 Aug 2007, at 17:24, Roderick McColl wrote:
>
>> Two other issues related to the new FSLVIEW, at least as it impacts
>> my data.
>>
>> In comparison to the FSLVIEW in FSL 3.3, when I look at DTI data
>> using the FSLVIEW in FSL 4.0
>> using V1 and FA, the axial and coronal images are displaced to the
>> left of the display box (to the right of the head)  by about 40 per
>> cent of the FOV,
>> and the lines don't "look right". Does this reflect some change in
>> the detection of orientation between the two versions?
>>
>> -roddy
>>
>>>>> Matt Glasser <[log in to unmask]> 8/21/2007 9:50 AM >>>
>> Hi,
>>
>>
>>
>> The new version of FSLView has the annoying habit of taking the
>> cal_max from
>> the NIFTI header of the FA and using it when displaying the FA
>> modulated
>> color map no matter what the Max is set to inside FSLView.  This
>> means that
>> if a high cal_max value is set somewhere in the preprocessing
>> chain, you
>> can't display an FA modulated color map in FSLView without manually
>> editing
>> the header to change cal_max to 1.  It would be better if FSLView
>> used the
>> value in the Max box or assumed all FAs had a max of one.
>>
>>
>>
>> Thanks,
>>
>>
>>
>> Matt.