Our Siemens Trio spits out 0 - 4095 phase images. However, there are windowing tags set in the DICOM header, so the range of values that are in the actual DICOM files depends on whether the utility you use to read them pays attention to the "rescale" tags or not. I'd recommend using a header reader to check your tags.

-Daniel


-----Original Message-----
From: FSL - FMRIB's Software Library on behalf of Doug Greve
Sent: Fri 8/29/2008 11:41 AM
To: [log in to unmask]
Subject: Re: [FSL] A couple of questions on EPI unwarp
 
Something must have happened to your phase images. How did you convert
them from dicom? Generally, they are 0-4095. Siemens scanners only
produce non-negative values (unless you have some custom software). I
wrote epidewarp.fsl a few years ago, so it won't reflect new tools
developed since then.

doug

X Liu wrote:

>Dear FSL developers and experts, I have been testing EPI unwarp using the 
>new version of FSL 4.1.0 within FEAT and epidewarp.fsl script (v1.32). I would 
>like to confirm a couple of issues I have encountered.
>
>1. Our Siemens Allegra scanner produces two GRE field maps (one magnitude 
>and one phase). The phase map has a range from -4096 to 4092, which looks 
>like the real fieldmap as at 
>http://www.fmrib.ox.ac.uk/fsl/fugue/feat_fieldmap.html (last image). When 
>using epidewarp.fsl script (with TE difference, EPI echo spacing parameters), 
>without rescaling the range, prelude complains about the values out of range. 
>FEAT doesn't complain and move forward since it doesn't call prelude, but the 
>result looks over stretched.
>
>2. By rescaling the range of the phase map (only divided by 2 so that the 
>range is -2048 to 2046, is this correct, or I have to make the range from 0 to 
>4095, or I still need to go through other steps involving prelude and TE 
>difference value according to the above webpage?), both epidewarp.fsl and 
>FEAT produce reasonable unwarping results. But the results from epidewarp.fsl 
>seem less stretched and more reasonably shaped (e.g., the brain stem seems 
>being pushed more backward by FEAT's dewarping). I looked into the source 
>codes of featlib.tcl and found that most of the major steps are consistent 
>across two approaches (with extra steps in FEAT) but couldn't identify what 
>causes the difference in results.
>
>3. For the final unwarping, FEAT uses more recent functions - applywarp and 
>convertwarp, whereas epidewarp.fsl uses just fugue and shift map. I assume 
>they are equivalent but the former is more flexible in terms of combining the 
>unwarp and other transformation (e.g., motion parameters, EPI to T1 affine or 
>nonlinear).
>
>4. For demean the unwarp map, epidewarp.fsl subtracts the mean from the 
>shift map, whereas FEAT subtracts the 50% percentile from the phase map. 
>Does this difference matter?
>
>Regards, XL
>
>
>  
>

-- 
Douglas N. Greve, Ph.D.
MGH-NMR Center
[log in to unmask]
Phone Number: 617-724-2358 
Fax: 617-726-7422

In order to help us help you, please follow the steps in:
surfer.nmr.mgh.harvard.edu/fswiki/BugReporting