Hi
Just a quick addon - it sounds like you will be alright if you flip
anterior posterior directly after converting from GE.
You can do this by swapping y for -y with avwswapdim
avwswapdim input x -y z output
this will spit out a (det<0) warning - that's fine.
cheers Tim
On Sun, 26 Jan 2003, Jim Murakami wrote:
> 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
>
--
-------------------------------------------------------------------------------
Tim Behrens
Centre for Functional MRI of the Brain
The John Radcliffe Hospital
Headley Way Oxford OX3 9DU
Oxford University
Work 01865 222782
Mobile 07980 884537
-------------------------------------------------------------------------------
|