Field Mapping

• How do I run field maps on 3T?
• What is the current status of the field map processing code?
• What unwarp direction (-unwarpdir) should I use?
• The field map script works, but the results don't look right. What's wrong?
• I can't copy the prescriptions!
• Once in a while when I run the field mapping correction for scans the results are all wacky, but most of the time it's fine.
• What are all those weird images that pop up when a field map is run? Is the scanner broken?
• I use EPI with frequency-encode direction set to A/P. Should I set my field map scans to the same frequency-encode direction?
• Why sometimes ppge procedure generates dark localized artifacts in the EPI unwarped briks?
• Sometimes coils spontaneously switch from BODY to 8 channel head coil when using fieldmap scans. How I can prevent this?
• Problems removing tmp folder in Mac-OSX systems with ppge or command line rm -rf.

• How do I run field maps on 3T?

For directions read the Field Map User's Guide and also consult the FAQ answers.

• What is the current status of the field map processing code?
  

Recent Updates:
- Mar 17, 2008: ppge4 was modified to add the capability of handling datasets acquired the "ASSET" option.  When the "ASSET" option is used, the actual EPI dwell time is less than the dwell time reported in the image header. This update is backward compatible and work on the non-ASSET datasets as well.  There is no change in usage for this update.

- Sept 7, 2007:  A new verion of ppge4 that is comaptible with FSL4.0 is available now.  FSL4.0 changed the names of all avw tools (to fsl tools).  Some minor changes in the usage is also found in FSL4.0 , e.g. the usage change in fslmaths (formerly known as avwmaths).

- August 10, 2007: ppge4 and dicomrx has been updated (thanks for the help of Dr. Brock Kirwan from Larry Squire Lab) to not use dicom2, Instead it uses the AFNI build in command dicom_hdr.   Since dicom_hdr is available in both Linux and Mac version of AFNI (whereas dicom2 was compiled only  for linux), this update allows users to run ppge4 in both Linux and Macs.

The following programs/scripts are needed to run ppge4 (right click on the file name to download):
1. ppge4(FSL3.2) 
    or 
    ppge4_fsl4.0 (FSL4.0)   (remember to rename it to ppge4 after download)

2. epidewarp4.ucsd (FSL3.2)
    or
    epidewarp4.ucsd_fsl4.0 (FSL4.0)  (remember to rename it to epidewarp4.ucsd after download)

3. dicomrx  (Linux)
    or
    dicomrx_mac (Intel-based Mac, thanks to Dr. Brock Kirwan) (remember to rename it to dicomrx after download )
    or 
    dicomrx_mac_ppc (ppc-based  Mac G5, thanks to Dr. Stephen McCullough)  (remember to rename it to dicomrx after download )


Here are the older version of ppge4 scripts that use dicom2 and FSL3.2 (for Linux only):
1. ppge4
2. epidewarp4.ucsd
3. dicomrx
4. dicom2



From the end of 2007, the Center has stopped supporting  the predecessors of ppge4 (i.e. ppge, ppge3).  Compared to ppge and ppge3, ppge4 offers more robust performance in dewarping EPI and DTI images acquired on the GE 3T scanners, especially when there are large phase variations in the field map data due to field inhomogeneity and subtle subject movements. Note that ppge4 requires NIFTI neuroimage format. The table below summarizes the differences in the function and usage of ppge, ppge3 and ppge4.

  

	ppge	ppge3	ppge4
Summary	ppge is the original field map  processing script. It uses ANALYZE  neuroimaging data format.	ppge3 provides a few improvements over ppge. It uses NIFTI_GZ (default) format and no longer supports ANALYZE format.	ppge4 is the most recent development . It introduces some fundamental changes in the processing method and improvements over ppge3. It uses NIFTI_GZ (default) format and does not support ANALYZE.
Features	ppge has been working well for many applications. However there have been reports of ppge failing in processing saggital EPI images and in the presence of excessive phase wraps in the raw field map data.;	ppge3 improves the processing efficiency by eliminating the need for converting data to an intermediate bxh format. In addition, ppge3 adds robustness in processing images acquired in various slice orientations. However, ppge3 is still susceptible to large phase wraps that may exist in some raw field map measurements.	Other than the features inherited from ppge3, ppge4 addresses the issue with processing large phase wraps. It also adds a command line option (-nphase) to provides flexibilities for users to unwrap phase images. ppge4 adds matrix size check and automatic resampling in case of matrix size conflicts between epi and field map acquisitions. In addition, ppge4 eliminates the TR input at command line. Instead, TR is read in from the dicom file header.
Required Files ( download from here)	ppge epidewarp.ucsd dicom2 dicom2bxh bxh2abalyze dicomrx	ppge3 epidewarp3.ucsd dicom2 dicomrx	ppge4 epidewarp4.ucsd dicomrx
System Requirements	Linux AFNI FSL	Linux AFNI (2006 or newer, 32 bit) FSL(3.2 or newer)	Linux  or Mac AFNI (2006 or newer, 32 bit) FSL(3.2 or newer)
FSLOUTPUTTYPE	ANALYZE	NIFTI_GZ(default) or NIFTI	NIFTI_GZ(default) or NIFTI
Instructions	type ppge @ command line	type ppge3 @ command line	type ppge4 @ command line
Example Usages	Default usage: ppge -d1 s207074 -d2 s207183 -i s207292 -o brikname -TR 2000 Alternate usage: turn off motion correction and masking and dewarp in x direction ppge -d1 s207074 -d2 s207183 -i s207292 -o brikname -TR 2000 -nomoco -nomask -unwarpdir x	Default usage: ppge3 -d1 s207074 -d2 s207183 -i s207292 -o brikname -TR 2000 Alternate usage: turn off motion correction and masking and dewarp in x direction ppge3 -d1 s207074 -d2 s207183 -i s207292 -o brikname -TR 2000  -nomoco -nomask -unwarpdir x	Default usage: ppge4 -d1 s207074 -d2 s207183 -i s207292 -o brikname   Alternate usage: turn off motion correction and masking and dewarp in x direction ppge4 -d1 s207074 -d2 s207183 -i s207292 -o brikname   -nomoco -nomask  -unwarpdir x
Questions?	kunlu@ucsd.edu

• What unwarp direction (-unwarpdir) should I use?

This is no easy answer to this question. The unwarpdir depends on what direction was selected as the phase encoding direction, and how this gets treated by the reconstruction software. This information is not typically available in MRI images. In addition, the direction of the K-space transversal during acquisition (e.g. bottom-up and top-down view ordering) reverses the sign of the applied distortion and therefore the sign of unwarpdir.  

The table below provides general guidance on some commonly used phase encoding directions and their corresponding unwarpdir selections.  However users should always verify these selections on a few sample datasets.   For oblique slice orientations (which are not listed in the table), the best advice is to try a few possible unwarpdir and decide on the correct one base on some prominent anatomical markers. 

Slice Orientation	Phase Encoding Direction	View Order	unwarpdir
Axial	Anterior-Posterior	bottom up	y
		top down	y-
	Right-left	bottom up	x-
		top down	x
Sagittal	Superior - inferior	bottom up	y-
		top down	y
	Anterior-Posterior	bottom up	x
		top down	x-
Coronal	Superior - inferior	bottom up	y-
		top down	y
	Right-left	bottom up	x-
		top down	x+

• The field map script works, but the results don't look right. What's wrong?

The most common source of error is when the user doesn't copy the field map graphical prescription correctly between scans so check to make sure you've done that correctly. In particular, make sure phase-encoding direction and matrix size are the same for all your fieldmap scans and your EPI scans.

• I can't copy the prescriptions!

The user interface has a somewhat quirky personality, which takes some time to become familiar with. In general, if you've already copied a graphical prescription to a scan, realize you've made a mistake and try to copy another prescription, you may find yourself out of luck. If this happens to you, usually the best thing to do is to copy in a fresh protocol and copy the correct prescription to it. You can then cut the protocol that didn't work out.

• Once in a while when I run the field mapping correction for scans the results are all wacky, but most of the time it's fine.

Check to make sure that you are running the fm_TE1_NFS protocol prior to running fm_TE2_NFS protocol. This is because TE1 will run autoshim, while TE2 just uses the shim values from TE1.

• What are all those weird images that pop up when a field map is run? Is the scanner broken?

For each slice, the field map generates 4 images: magnitude, phase, real, and imaginary. Only the real and imaginary are used by the processing software. The magnitude images look similar to most MRI images you are probably familar with, while the phase images will generally have stripes through the image.

• I use EPI with frequency-encode direction set to A/P. Should I set my field map scans to the same frequency-encode direction?

Yes, the frequency-encode direction should be the same for the EPIs and the field map scans.

• Why sometimes ppge procedure generates dark localized artifacts in the EPI unwarped briks?

This artifact is a result of inadvertent use of the 8 channel head coil (8HRBRAIN coil) while acquiring fieldmap scans. Currently only the BODY coil can be used to acquire fieldmap scans, thus before running those scans make sure that the correct coil is used.

• Sometimes coils spontaneously switch from BODY to 8 channel head coil when using fieldmap scans. How I can prevent this?

The unintended change of a coil (e.g. from BODY to 8HRBRAIN) can occur if the warning message indicating the change in coil (when browsing through series) is acknowledged by pressing “Apply All” button. Using “Apply” button instead will minimize the risk of inadvertent coil switching.

• Problems removing tmp folder in Mac-OSX systems with ppge or command line rm -rf.

The implementations of the "rm" command line tool in Mac OSX may have problem removing files and directories recursicely, please see this web page for more information:

http://docs.info.apple.com/article.html?artnum=107884