GE Processing - Revision history

Huawu: /* Reconstructed image size */

2026-02-04T23:04:25Z

Reconstructed image size

← Older revision		Revision as of 23:04, 4 February 2026
Line 91:		Line 91:
	== '''Reconstructed image size''' ==		== '''Reconstructed image size''' ==

	* By default, images are reconstructed at matrix sizes that are powers of two (presumably for speed). However, this wastes disk and memory space. To change the reconstructed image size, set CV variables rhrcxres, rhrcyres, rhimsize to the same as your acquisition matrix size. For example, if I acquire a 70 x 70 matrix size, I would set rhrcxres=70, rhrcyres=70, rhimsize=70, and then I would get 70x70 images instead of 128x128. In the CNI EPI sequence, set User CV4 to 1 to enable this feature.		* By default, images are reconstructed at matrix sizes that are powers of two (presumably for speed). However, this wastes disk and memory space. To change the reconstructed image size, set CV variables rhrcxres, rhrcyres, rhimsize to the same as your acquisition matrix size. For example, if I acquire a 70 x 70 matrix size, I would set rhrcxres=70, rhrcyres=70, rhimsize=70, and then I would get 70x70 images instead of 128x128. In the CNI EPI sequence, set User CV4 in the Advanced tab to 1 to enable this feature.

	== '''Precise values''' ==		== '''Precise values''' ==

Huawu: /* Reconstructed image size */

2026-02-04T23:04:04Z

Reconstructed image size

← Older revision		Revision as of 23:04, 4 February 2026
Line 91:		Line 91:
	== '''Reconstructed image size''' ==		== '''Reconstructed image size''' ==

	* By default, images are reconstructed at matrix sizes that are powers of two (presumably for speed). However, this wastes disk and memory space. To change the reconstructed image size, set CV variables rhrcxres,rhrcyres,rhimsize. For example, if I acquire a 70 x 70 matrix size, I would set rhrcxres=70, rhrcyres=70, rhimsize=70, and then I would get 70x70 images instead of 128x128. ~~Unfortunately~~, ~~it appears that these CV vars are not saved when you save protocols, so you'll have to do this at least once per scan session.~~		* By default, images are reconstructed at matrix sizes that are powers of two (presumably for speed). However, this wastes disk and memory space. To change the reconstructed image size, set CV variables rhrcxres, rhrcyres, rhimsize to the same as your acquisition matrix size. For example, if I acquire a 70 x 70 matrix size, I would set rhrcxres=70, rhrcyres=70, rhimsize=70, and then I would get 70x70 images instead of 128x128. In the CNI EPI sequence, set User CV4 to 1 to enable this feature.
	* But be careful --- it appears that one you set ~~these CV vars, they will no longer default~~ to ~~the next highest power of two if you change parameters of the sequence. For example, in one instance, I was increasing the matrix size but forgot~~ to ~~change the CV vars, and the resulting reconstructed images were totally corrupted~~. ~~It is important to visually inspect the data in the console as they are acquired in order to verify sanity!~~

	== '''Precise values''' ==		== '''Precise values''' ==

Huawu: /* "Silent" Partial Fourier */

2026-02-04T22:58:47Z

"Silent" Partial Fourier

← Older revision		Revision as of 22:58, 4 February 2026
Line 41:		Line 41:

	== '''"Silent" Partial Fourier''' ==		== '''"Silent" Partial Fourier''' ==
			Note that the effect described below only affected GE EPI sequences before software version RX28. The EPI sequence that most people use at CNI is a modified version of the GE product EPI sequence. Since version RX28 (including the latest MR30), we have implemented a modification in the sequence that avoids this kind of behavior - when TE is not long enough to acquire all the k-space lines, instead of droppinng the entire half of k-space and using a default 8 lines of overscan, the scanner will use the actual TE and echo spacing to calculate the maximum number of k-space lines it can acquire, and as many k-space lines as it can. This means there will not be a sudden drop of SNR due to the Partial Fourier readout.

	* In EPI, if you increase the acquisition time too much (e.g. by having a large matrix size or a short TE), the pulse sequence will be unable to acquire the requisite half of k-space before the TE value. When this happens, the scanner silently decides to simply drop that half of k-space and acquire a default of 8 lines of k-space for that half. This is potentially quite bad, as you lose a lot of SNR, since there will be wasted dead time after the RF pulse up until the beginning of the 8 lines. Moreover, partial acquisitions may result in difficulties in the reconstruction process and thus image artifacts (I have noticed these when scanning phantoms). The safest way to see whether the silent dropping of k-space happens is to check the plotter (to do that, start scanning, pause the scan, and then run plotter from a command window). An easier (but unverified) way is to monitor the Relative SNR number in the console. It appears that once you go over the limit, the relative SNR jumps way down.		* In EPI, if you increase the acquisition time too much (e.g. by having a large matrix size or a short TE), the pulse sequence will be unable to acquire the requisite half of k-space before the TE value. When this happens, the scanner silently decides to simply drop that half of k-space and acquire a default of 8 lines of k-space for that half. This is potentially quite bad, as you lose a lot of SNR, since there will be wasted dead time after the RF pulse up until the beginning of the 8 lines. Moreover, partial acquisitions may result in difficulties in the reconstruction process and thus image artifacts (I have noticed these when scanning phantoms). The safest way to see whether the silent dropping of k-space happens is to check the plotter (to do that, start scanning, pause the scan, and then run plotter from a command window). An easier (but unverified) way is to monitor the Relative SNR number in the console. It appears that once you go over the limit, the relative SNR jumps way down.
Line 46:		Line 47:
	** Regarding using the relative SNR as a index for whether the silent partial fourier occurs, for some reason, you need at least 20 volumes prescribed. I have found that if you prescribe less volumes, then the big jump in relative SNR does not occur.		** Regarding using the relative SNR as a index for whether the silent partial fourier occurs, for some reason, you need at least 20 volumes prescribed. I have found that if you prescribe less volumes, then the big jump in relative SNR does not occur.
	* To deal with the "silent" partial Fourier issue, one strategy is to ensure that you always get full coverage of k-space.		* To deal with the "silent" partial Fourier issue, one strategy is to ensure that you always get full coverage of k-space.
	* A different strategy is to ensure that you get the maximal number of lines of k-space (not the default 8 lines). It is not clear how to do this (perhaps CV variable num_overscan?)

	Here's an example of what happens. This is 70 phase-encode lines:		Here's an example of what happens. This is 70 phase-encode lines:

imported>Huawu: /* Using FSL to process CNI fieldmaps */

2019-07-23T18:42:26Z

Using FSL to process CNI fieldmaps

← Older revision		Revision as of 18:42, 23 July 2019
Line 200:		Line 200:
	===Using FSL to process CNI fieldmaps===		===Using FSL to process CNI fieldmaps===

	The ...fieldmap.nii.gz file that we save in NIMS is what the FSL folks call "A single, real fieldmap image (showing the field inhomogeneity in each voxel)". (NOTE: for older datasets in NIMS, this file uses the 'B0' suffix rather than 'fieldmap'.) The other nifti associated with a fieldmap scan is a magnitude image that can be used for masking, etc.		The ...fieldmap.nii.gz file that we save in NIMS is what the FSL folks call "A single, real fieldmap image (showing the field inhomogeneity in each voxel)". (NOTE: for older datasets in NIMS, this file uses the 'B0' suffix rather than 'fieldmap'.) The other nifti associated with a fieldmap scan is a magnitude image that can be used for masking, etc.

	The fieldmap image is in units of Hz. FSL likes radians/s, so you can convert it with fslmaths:		The fieldmap image is in units of Hz. FSL likes radians/s, so you can convert it with fslmaths:
Line 206:		Line 206:
	fslmaths 8860_6_1fieldmap.nii.gz -mul 6.28 fieldmap_rads		fslmaths 8860_6_1fieldmap.nii.gz -mul 6.28 fieldmap_rads

	Then jump straight to step 5 on the [http://fsl.fmrib.ox.ac.uk/fsl/fslwiki/FUGUE/Guide FSL FUGUE guide]. Although you may want to mask the fieldmap first. E.g.:		Then jump straight to step 5 on the [http://fsl.fmrib.ox.ac.uk/fsl/fslwiki/FUGUE/Guide#Step_5_-_Regularising_the_fieldmap FSL FUGUE guide]. Although you may want to mask the fieldmap first. E.g.:

	bet 8860_6_1.nii.gz fieldmap -m -n		bet 8860_6_1.nii.gz fieldmap -m -n
Line 214:		Line 214:
	fugue --loadfmap=fieldmap_rads -s 1 --savefmap=fieldmap_rads		fugue --loadfmap=fieldmap_rads -s 1 --savefmap=fieldmap_rads

	~~You~~ can ~~find the effective echo spacing, TE, and phase~~-~~encode ('~~unwarp~~') direction from~~ the ~~header of your epi file~~. E.g.~~, using fslhd, look at 'phase_dim' and 'descrip'~~:		Then you can use [http://fsl.fmrib.ox.ac.uk/fsl/fslwiki/FUGUE/Guide#FUGUE FUGUE command-line tool] to unwarp the EPI image. E.g.:

	fslhd 8860_5_1.nii.gz \| grep -E '~~phase_dim\|~~descrip'		fugue -i epi --dwell=dwelltime --loadfmap=fieldmap -u result

			where dwelltime is the same as the effective echo spacing. You can find the effective echo spacing from the header of your epi file. E.g., using fslhd, look at 'descrip':

			fslhd 8860_5_1.nii.gz \| grep 'descrip'

	which produces:		which produces:

	~~phase_dim 2~~
	descrip te=30.00;ti=0;fa=77;ec=0.4800;acq=[80,80];mt=0;rp=2.0;		descrip te=30.00;ti=0;fa=77;ec=0.4800;acq=[80,80];mt=0;rp=2.0;

	showing that ~~the phase-encode is second dimension (that is, the 'y' direction), the TE is 30 milliseconds and~~ the echo spacing ('ec') is 0.48 milliseconds. Note that, as the FSL docs say, "your operator can tell you whether the unwarp direction, or phase encode direction, is x, y or z, but whether it is + or - needs to be determined, currently, by trial and error..." However, we think it's usually + for data acquired here.		showing that the echo spacing ('ec') is 0.48 milliseconds. The phase encoding dimension is usually y for EPI acquisitions. Note that, as the FSL docs say, "your operator can tell you whether the unwarp direction, or phase encode direction, is x, y or z, but whether it is + or - needs to be determined, currently, by trial and error..." However, we think it's usually + for data acquired here.

imported>Bobd: /* Using FSL to process CNI fieldmaps */

2016-01-21T06:41:49Z

Using FSL to process CNI fieldmaps

← Older revision		Revision as of 06:41, 21 January 2016
Line 200:		Line 200:
	===Using FSL to process CNI fieldmaps===		===Using FSL to process CNI fieldmaps===

	The ...fieldmap.nii.gz file that we save in NIMS is what the FSL folks call "A single, real fieldmap image (showing the field inhomogeneity in each voxel)". The other nifti associated with a fieldmap scan is a magnitude image that can be used for masking, etc.		The ...fieldmap.nii.gz file that we save in NIMS is what the FSL folks call "A single, real fieldmap image (showing the field inhomogeneity in each voxel)". (NOTE: for older datasets in NIMS, this file uses the 'B0' suffix rather than 'fieldmap'.) The other nifti associated with a fieldmap scan is a magnitude image that can be used for masking, etc.

	The fieldmap image is in units of Hz. FSL likes radians/s, so you can convert it with fslmaths:		The fieldmap image is in units of Hz. FSL likes radians/s, so you can convert it with fslmaths:

imported>Bobd: /* Using FSL to process CNI fieldmaps */

2015-05-21T22:25:09Z

Using FSL to process CNI fieldmaps

← Older revision		Revision as of 22:25, 21 May 2015
Line 202:		Line 202:
	The ...fieldmap.nii.gz file that we save in NIMS is what the FSL folks call "A single, real fieldmap image (showing the field inhomogeneity in each voxel)". The other nifti associated with a fieldmap scan is a magnitude image that can be used for masking, etc.		The ...fieldmap.nii.gz file that we save in NIMS is what the FSL folks call "A single, real fieldmap image (showing the field inhomogeneity in each voxel)". The other nifti associated with a fieldmap scan is a magnitude image that can be used for masking, etc.

	The fieldmap ~~image~~ image is in units of Hz. FSL likes radians/s, so you can convert it with fslmaths:		The fieldmap image is in units of Hz. FSL likes radians/s, so you can convert it with fslmaths:

	fslmaths 8860_6_1fieldmap.nii.gz -mul 6.28 fieldmap_rads		fslmaths 8860_6_1fieldmap.nii.gz -mul 6.28 fieldmap_rads

imported>Bobd: /* Using FSL to process CNI fieldmaps */

2015-04-07T23:19:14Z

Using FSL to process CNI fieldmaps

← Older revision		Revision as of 23:19, 7 April 2015
Line 223:		Line 223:
	descrip te=30.00;ti=0;fa=77;ec=0.4800;acq=[80,80];mt=0;rp=2.0;		descrip te=30.00;ti=0;fa=77;ec=0.4800;acq=[80,80];mt=0;rp=2.0;

	showing that the phase-encode is second dimension (that is, the 'y' direction), the TE is 30 milliseconds and the echo spacing ('ec') is 0.48 milliseconds. Note that, as the FSL docs say, "your operator can tell you whether the unwarp direction, or phase encode direction, is x, y or z, but whether it is + or - needs to be determined, currently, by trial and error..."		showing that the phase-encode is second dimension (that is, the 'y' direction), the TE is 30 milliseconds and the echo spacing ('ec') is 0.48 milliseconds. Note that, as the FSL docs say, "your operator can tell you whether the unwarp direction, or phase encode direction, is x, y or z, but whether it is + or - needs to be determined, currently, by trial and error..." However, we think it's usually + for data acquired here.

imported>Bobd: /* Fieldmaps */

2015-04-07T23:16:25Z

Fieldmaps

← Older revision		Revision as of 23:16, 7 April 2015
Line 149:		Line 149:

	== '''Fieldmaps''' ==		== '''Fieldmaps''' ==

			===Kendrick's Notes on Fieldmaps===

	One of the major problems that affects EPI data is spatial distortion. It is possible to correct for distortions in EPI data posthoc using fieldmap measurements. Kendrick has developed some MATLAB code that handles spatial distortion and other pre-processing procedures relevant to EPI fMRI data.		One of the major problems that affects EPI data is spatial distortion. It is possible to correct for distortions in EPI data posthoc using fieldmap measurements. Kendrick has developed some MATLAB code that handles spatial distortion and other pre-processing procedures relevant to EPI fMRI data.

	The process can be divided into two basic parts. The first part is getting the fieldmap acquisition right. The second part is using the code to process the EPI and fieldmap data.		The process can be divided into two basic parts. The first part is getting the fieldmap acquisition right. The second part is using the code to process the EPI and fieldmap data.

	Note that the information presented in this section is not yet complete (e.g. one big missing part is how to actually run the MATLAB code, and another missing part is the conceptual background of all this fieldmap stuff).

	'''Fieldmap strategy'''		'''Fieldmap strategy'''
Line 198:		Line 198:
	See [[preprocessfmri]] for details on how to process EPI data using fieldmaps. Note that you need to know the number of phase encode lines (typically your image size along the phase encode dimension, divided by the ASSET acceleration factor) and the phase encode dwell time (which should be stored in the DICOM field (0043,102c): the time per phase-encode line in microseconds).		See [[preprocessfmri]] for details on how to process EPI data using fieldmaps. Note that you need to know the number of phase encode lines (typically your image size along the phase encode dimension, divided by the ASSET acceleration factor) and the phase encode dwell time (which should be stored in the DICOM field (0043,102c): the time per phase-encode line in microseconds).

	~~'''~~Using FSL~~'''~~		===Using FSL to process CNI fieldmaps===

	The ...fieldmap.nii.gz file that we save in NIMS is what the FSL folks call "A single, real fieldmap image (showing the field inhomogeneity in each voxel)". The other nifti associated with a fieldmap scan is a magnitude image that can be used for masking, etc.		The ...fieldmap.nii.gz file that we save in NIMS is what the FSL folks call "A single, real fieldmap image (showing the field inhomogeneity in each voxel)". The other nifti associated with a fieldmap scan is a magnitude image that can be used for masking, etc.

imported>Bobd: /* Fieldmaps */

2015-02-13T00:51:06Z

Fieldmaps

← Older revision		Revision as of 00:51, 13 February 2015
Line 199:		Line 199:

	'''Using FSL'''		'''Using FSL'''

	The ...fieldmap.nii.gz file that we save in NIMS is what the FSL folks call "A single, real fieldmap image (showing the field inhomogeneity in each voxel)". The other nifti associated with a fieldmap scan is a magnitude image that can be used for masking, etc.		The ...fieldmap.nii.gz file that we save in NIMS is what the FSL folks call "A single, real fieldmap image (showing the field inhomogeneity in each voxel)". The other nifti associated with a fieldmap scan is a magnitude image that can be used for masking, etc.

imported>Bobd: /* Fieldmaps */

2015-02-13T00:50:24Z

Fieldmaps

← Older revision		Revision as of 00:50, 13 February 2015
Line 197:		Line 197:

	See [[preprocessfmri]] for details on how to process EPI data using fieldmaps. Note that you need to know the number of phase encode lines (typically your image size along the phase encode dimension, divided by the ASSET acceleration factor) and the phase encode dwell time (which should be stored in the DICOM field (0043,102c): the time per phase-encode line in microseconds).		See [[preprocessfmri]] for details on how to process EPI data using fieldmaps. Note that you need to know the number of phase encode lines (typically your image size along the phase encode dimension, divided by the ASSET acceleration factor) and the phase encode dwell time (which should be stored in the DICOM field (0043,102c): the time per phase-encode line in microseconds).

			'''Using FSL'''
			The ...fieldmap.nii.gz file that we save in NIMS is what the FSL folks call "A single, real fieldmap image (showing the field inhomogeneity in each voxel)". The other nifti associated with a fieldmap scan is a magnitude image that can be used for masking, etc.

			The fieldmap image image is in units of Hz. FSL likes radians/s, so you can convert it with fslmaths:

			fslmaths 8860_6_1fieldmap.nii.gz -mul 6.28 fieldmap_rads

			Then jump straight to step 5 on the [http://fsl.fmrib.ox.ac.uk/fsl/fslwiki/FUGUE/Guide FSL FUGUE guide]. Although you may want to mask the fieldmap first. E.g.:

			bet 8860_6_1.nii.gz fieldmap -m -n
			fslmaths fieldmap_rads.nii.gz -mul fieldmap_mask.nii.gz fieldmap_rads
			fugue --loadfmap=fieldmap_rads --despike --savefmap=fieldmap_rads
			fugue --loadfmap=fieldmap_rads -m --savefmap=fieldmap_rads
			fugue --loadfmap=fieldmap_rads -s 1 --savefmap=fieldmap_rads

			You can find the effective echo spacing, TE, and phase-encode ('unwarp') direction from the header of your epi file. E.g., using fslhd, look at 'phase_dim' and 'descrip':

			fslhd 8860_5_1.nii.gz \| grep -E 'phase_dim\|descrip'

			which produces:

			phase_dim 2
			descrip te=30.00;ti=0;fa=77;ec=0.4800;acq=[80,80];mt=0;rp=2.0;

			showing that the phase-encode is second dimension (that is, the 'y' direction), the TE is 30 milliseconds and the echo spacing ('ec') is 0.48 milliseconds. Note that, as the FSL docs say, "your operator can tell you whether the unwarp direction, or phase encode direction, is x, y or z, but whether it is + or - needs to be determined, currently, by trial and error..."