Hi,
Sorry to retrace several people's steps over the issue of laterality,
but without the
luxury of scanning an asymmetrical phantom I need to make an educated
choice over
whether I am interpretting my data correctly.
So to summarise, I have 3d volumetric data and corresponding functional
EPIs. I have
converted my 3d data using MRIcro, and used the "save as" option to
output the
data in neurological orientation (left is left). I used a little
convertor called ge2spm
to convert EPI data (I.* format) to analyze format. However, I suspect
that this automatically
flips the images both vertically and horizontally (since that's what SPM
expects), and when
I view the output with "slices" the nose is at the top.
I concatenate my EPIs to make 4d data suitable for FEAT, then run the
analysis using the
functional and volumetric data (all of which I think are in neurological
orient.)
I guess FEAT doesn't need to perform a 180deg rotation of either set of
images to align them with
the standard, so should output the results "as is" i.e. in neurological
orient.(?)
When I try to view results with AFNI, the 3d gets flipped horizonatally
(left is right) - I know this
because the patient has a lesion in the left hemisphere. So I should
set the AFNI env variable
AFNI_LEFT_IS_LEFT. Will this convention be applied to both the 3d and
the statistical maps?
Please let me know if you think I've made any wrong assumptions in this
incredibly long ramble :)
Yours,
Jon.
Tim Behrens wrote:
>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
>-------------------------------------------------------------------------------
>
>
>
>
|