Hi,
This is all fine.
It is complicated because FSLView will also flip the display to make it
"radiological" for an image that is in the same rough orientation as the
avg152. But it will change the relationship between voxel and mm
coordinates.
So, if you load both the original and swapped images into FSLView you
should see that the image is displayed flipped in L-R, but that for a given
structural point in the brain, the voxel coordinate is the same. Whereas
if you left the cursor in the same place in the window, the mm coordinate
stays the same when you flick between views although the brain, and hence
the point that it is over, will change.
Therefore the old mm origin would have had a voxel coordinate of x=32
but the new one will be x=31, although they will be in the same location
in the FSLView window (i.e. you don't need to move the cursor). This is
simply what avworient implements when it swaps the orientation. It
effectively
remaps the mm coordinates as if the voxel coordinates were reversed across
the x-dimension. That means that the mm coordinate that used to be at
the voxel
with x-coord of 0 is now associated with the voxel with x-coord of 63.
Similarly,
the mm coord that used to be at voxel coords of 1 is now associated with
voxel
coords of 62, and so on, including voxel coord 32 (with mm coord 0) which
now becomes voxel coord 31 (with mm coord 0).
I'm not sure if this was helpful, but the summary is that this is
expected behaviour
as the swaporient has to change how the mm and voxel coordinates relate
to each other (as otherwise the orientation couldn't be changed) and so
now the
mm origin will be associated with a different voxel number.
Unless the actual values of the mm coords are useful to you (and they
normally
are not), the fact that the labels are now the right way around and the the
mm coordinates increase and decrease appropriately is the only crucial
thing.
Of course if you need the origin to stay at the same point in the brain,
then a fix
will need to be applied. Let us know if that's the case.
All the best,
Mark
Pat Vee wrote:
> Mark,
>
> Thanks for looking at this, the info (or at least, what I think you're
> asking for) is below.
>
> Thanks again,
> Pat
>
> For the original:
> qform_name Scanner Anat
> qform_code 1
> qto_xyz:1 -3.000000 0.000000 -0.000000 96.000000
> qto_xyz:2 0.000000 3.000000 -0.000000 -108.922874
> qto_xyz:3 0.000000 0.000000 3.000000 -37.914421
> qto_xyz:4 0.000000 0.000000 0.000000 1.000000
> qform_xorient Right-to-Left
> qform_yorient Posterior-to-Anterior
> qform_zorient Inferior-to-Superior
> sform_name Unknown
> sform_code 0
> sto_xyz:1 0.000000 0.000000 0.000000 0.000000
> sto_xyz:2 0.000000 0.000000 0.000000 0.000000
> sto_xyz:3 0.000000 0.000000 0.000000 0.000000
> sto_xyz:4 0.000000 0.000000 0.000000 0.000000
> sform_xorient Unknown
> sform_yorient Unknown
> sform_zorient Unknown
>
> For the swapped:
> qform_name Scanner Anat
> qform_code 1
> qto_xyz:1 3.000000 0.000000 0.000000 -93.000000
> qto_xyz:2 0.000000 3.000000 0.000000 -108.922874
> qto_xyz:3 0.000000 0.000000 3.000000 -37.914421
> qto_xyz:4 0.000000 0.000000 0.000000 1.000000
> qform_xorient Left-to-Right
> qform_yorient Posterior-to-Anterior
> qform_zorient Inferior-to-Superior
> sform_name Scanner Anat
> sform_code 1
> sto_xyz:1 3.000000 0.000000 0.000000 -93.000000
> sto_xyz:2 0.000000 3.000000 0.000000 -108.922874
> sto_xyz:3 0.000000 0.000000 3.000000 -37.914421
> sto_xyz:4 0.000000 0.000000 0.000000 1.000000
> sform_xorient Left-to-Right
> sform_yorient Posterior-to-Anterior
> sform_zorient Inferior-to-Superior
>
>
>
> On 1/10/07, Mark Jenkinson <[log in to unmask]> wrote:
>
>> Hi,
>>
>> Your are right that only fsl3.3 will deal with qforms happily.
>> I would remove your old fsl3.2 version so that you don't get confusing
>> calls to old versions when paths are setup wrongly.
>>
>> As for origin change, it does seem weird. Can you send us the
>> full qform and sform output (from avwhd) on the pre- and post-images?
>>
>> All the best,
>> Mark
>>
>>
>> On 9 Jan 2007, at 22:05, Pat Vee wrote:
>>
>> > Hi Tim,
>> >
>> > Thanks for the quick reply. Sorry, I should have been more clear -
>> > I saw the series of emails you're referring to and was trying to
>> > follow it, but didn't get the same results. Since sending my 1st
>> > email, I figured out that though I thought I was running fsl3.3,
>> > the command line script was calling 3.2... So, I've been able to
>> > change the orientation by just using avworient -swaporient.
>> > However, I wanted to check something, if you don't mind...
>> >
>> > It's my understanding that reading qform wasn't fully implemented
>> > in fsl3.2 and that I was having problems with avworient, since my
>> > data had sform info, but "unknown" for qform. Now in fsl3.3, both
>> > qform and sform are supported, so avworient can swap
>> > appropriately. So, the images look right and are reported in the
>> > correct orientation. In swapping the data, the "unknown" in the
>> > original data's qform is then replaced with the sform (swapped, of
>> > course). However, the numbers that are stored for x, y, z, are
>> > slightly different pre- and post-swap. Some signs are revered, as
>> > expected - but in the field called "qto_xyz:1" I originally have
>> > "-3 0 -0 96" which is changed to "3 0 0 -93" in the swapped image.
>> > The values in all the other fields are unchanged. Is this ok?
>> >
>> > Thanks,
>> > Pat
>> >
>> > On 1/9/07, Tim Behrens < [log in to unmask] > wrote:Hi -
>> > This email train a few days ago addresses exactly this problem.
>> >
>> > http://www.jiscmail.ac.uk/cgi-bin/webadmin?
>> > A2=ind0612&L=FSL&P=R16636&I=-3&X=1C7CFF1E9EF73B331C&Y=behrens%
>> > 40fmrib.ox.ac.uk
>> >
>> > If you go through this train to the end, you should be ok.
>> >
>> > Note that my first reply had a typo error in one of the commands,
>> > which Kirk found - so you will need to look through my second reply
>> > as well.
>> >
>> > Cheers
>> > T
>> >
>> >
>> > On 9 Jan 2007, at 15:46, Pat Vee wrote:
>> >
>> > > Hi all,
>> > >
>> > > I'm using MRIConvert to convert dicom files to nifti format - after
>> > > doing
>> > > so, I check the orientation with avworient and the images are stored
>> > > neurologically. When I try to swap the orientation (avworient -
>> > > swaporient
>> > > IMAGE) then check again, it says that they're still stored
>> > > neurologically.
>> > > When I view the images in fslview, the "swapped" is exactly the
>> > > same as the
>> > > original. If I look at the header, the only difference that I see
>> > > is that
>> > > the description is changed (from the original description of my
>> > > series) to
>> > > FSL3.2beta - this itself is confusing, since I have FSL3.3
>> > > installed... Any
>> > > thoughts on what I might be doing wrong?
>> > >
>> > > Thanks in advance,
>> > > Pat
>> >
>>
