Andy,
    As you say, FEAT does not rotate the data (except in the registration
phase of FEAT).   So the data you input is displayed in Slices and in the
FEAT report.html with the front of the head looking down and the right side
of the head on the left side of the image because that is how GE outputs the
I.00x files (see my last note).   The I.00x files have the image inverted
top to bottom.   For Axial images (the anterior part of the head will be at
the bottom of the image and the right side of the head will be on the left
of the image).   For Sagittally acquired images (the top of the head will be
on the bottom of the image and the anterior part of the head and face will
be on the left of the image).   For Coronally acquired images (the top of
the head will be on the bottom of the image and the right side of the head
will be on the right side of the image).    This is true for all pulse
sequences.   The data is acquired and displayed on the MR console in
standard RPI format.
    The I.00x files are created when you ask the scanner to output the data
for you to export to another machine.   They exist in the scanner as
disjointed image and header data within the GE scanner database.   It is
when the scanner makes the I.00x file that the problem occurs.   On older
scanners these images will be called E####S##I#.MR.  When Signa combines the
headers and data to make the image files for export the computer scans the
data from bottom to top of the image and reads it into the data portion of
the file in that order.   Most (if not all) image processing programs will
skip the header (if told how long) and will then read the lines of data as
though the image is being read from the top  line to the bottom (backwards
from the I.00x reality).
    Incidentally, if you expect to read the images back into Signa for
printing or some thing else, the data needs to be inverted after the headers
otherwise signa will reinvert the data and you will have "upside down"
images when they come up in Signa.   GE generally frowns upon putting images
back into Signa after they have been messed with.
    SO......     If you are using an axial data set, the image files are
inverted (not rotated) front to back.    When you run your script to make
the Analyze file pair, the data stays inverted as it is converted from the
2000 or so 2D images to the one 4D data set.    When it is read into FSL it
stays inverted and shows up as such in Slices and on the report.html.
    The problem you are having with the horrible registration is if you
don't do Full registration between the data and the standard brain.   If you
try to just do Normal registration (+/- 90 degrees of rotation allowed) FSL
just cannot align your Analyze data set with the standard brain Analyze data
set (they are looking in 180 degrees opposite directions).    It really does
a horrible job if faced with this problem.   At least you know there is a
problem.   When you use Full registration, and FSL is allowed to rotate your
inverted dataset 180 degrees it now can actually align it with the Standard
brain (of course the right side of your brain is now overlayed on the left
side of the standard brain).   This is a more subtle problem to detect.
    This problem can be compounded when you bounce back and forth between
FSL and AFNI.   For instance, if you scan a brain axially on your Signa,
then read it out to the I.00x file the data is inverted front to back.    If
this file is read by Slices or FSL the front of the head is down and the
back is up, the right side of the head is on the left and the left on the
right.   Now you process the data in FSL and view the Analyze format output
data in AFNI.   AFNI inverts the data right for left to display it in what
it thinks is LPI.   But your data was inverted before, so it has now been
inverted twice.  Now, it is displayed in AFNI inverted front to back (by
Signa) and right for left (by AFNI).   Now you mess around with it and
register it with a data set by rotating it to match the format of the
standard data.   Makes my brain hurt just to think about it.
    My advice would be to rewrite your script to invert the image files to
begin with prior to inputting them into Analyze format.   If not, just keep
track of how many times you are inverting and rotating the images.  Hope
this helps.
        Jim

Andy Goldfine wrote:

> Thanks so much for your detailed help.  When I run the analysis in FEAT
> it actually doesn't rotate the EPI image, I just get a horrible
> registration result and my data is shown upsidedown. So what I've been
> doing from the beginning (apparenty correctly by accident!) is flipping
> my highres anatomical and MNI images using ImageJ and using those
> flipped brains for the analysis.  So assuming that the flipped brains
> started out in radiological convention (RPI) then my final result or
> anatomical and functional is in RAI and everything is lined up.
>
> Can you confirm if the MNI and if a MPRAGE done on a GE scanner come
> out in RPI or LPI formats?
>
> Andy
>
> On Saturday, January 25, 2003, at 08:50  PM, Jim Murakami wrote:
>
> > Andy,
> >     The problem is with the GE to Analyze step.   Each GE image (when
> > extracted from the scanner using ximg for older scanners or the Image
> > Export function in RTIP for those using this platform) are stored in a
> > file format such that there is a header and then the Data.   The data
> > is
> > inverted top to bottom during the step from the scanner to the file you
> > export to your workstation for processing.
> >     For instance, if you started with an axial image of the head on a
> > GE
> > scanner.   At the scanner console you would be looking at it with the
> > medical/radiological convention (right side of the head on the left of
> > the image, left side of the head on the right side of the image,
> > anterior
> > part of the head at the top of the image, and posterior part of the
> > head
> > at the bottom of the image).
> >     When you ask the scanner to extract the image from the database on
> > the scanner is writes the data into a file called I.001 or
> > E####S###I1.MR    This is the file which sits in the Unix directory on
> > the scanner computer that you then tar and ftp to your workstation.
> > This file is written such that there is a header and then a file
> > containing 256x256 (or 64x64) 16 bit ints.    Here is the goofy part.
> > The first line of data is actually the line from the BOTTOM of the
> > image
> > and not the top.   The last line of ints is the line from the TOP of
> > the
> > image.    SO, if you just skip the header and read the data into an
> > image
> > file and then look at it.   The image will be inverted (not rotated)
> > top
> > to bottom relative to the image you saw on the GE console.    If you
> > view
> > this image in "slices" you will see the image inverted top to bottom
> > (anterior part of head on the bottom, posterior part of head on top,
> > left
> > side of head on the right of the image, and right side of the head on
> > the
> > left of the image).   THIS IS THE IMPORTANT PART.    When you read the
> > 4d
> > Analyze data set into FSL (not sure what happens in AFNI) it gets read
> > in
> > this way.   That is why slices and the FEAT report.html files show the
> > person looking at the bottom of the image.    This in and of itself is
> > ok, if you remember which side of the image is which.
> >     Here comes the bad part.    When you register the data set with the
> > Standard brain in FSL (which has the brain looking "up" in the picture
> > (if viewed in slices and by FSL)  FSL ROTATES the image 180 degrees to
> > match up with the Standard brain.   It does not invert the image, but
> > rotates it.   Therefore, the functional data set gets displayed in LPI
> > format on top of the standard brain which is in medical format.  (The
> > two
> > data sets are inverted right to left relative to each other).
> >     One must be very careful about which side of the head is which when
> > working with these GE files.    I would advise people to run a 3D data
> > set on an asymmetric phantom.   Pump it through your GE to Analyze
> > conversion scripts.   And see which side of the image is left and right
> > before and after pumping it through FSL or AFNI.
> >     Jim
> >
> > Andy Goldfine wrote:
> >
> >> I didn't realize this wasn't normal until these past few threads, but
> >> the results of every one of my FEAT runs has the y-axis in anterior to
> >> posterior.  When I look at the data before running FEAT using to3d
> >> (from AFNI) it's all in LPI format.  [FYI, my original data is
> >> converted from GE to Analyze by an internal program called adw24d and
> >> then I need to create a .hdr using avwcreatehd since adw24d creates a
> >> .hdrs and a .img.]  Does this happen to anyone else?  What am I doing
> >> wrong?
> >>
> >> Thanks