Hi everyone,
I recently switched the phase encoding direction of the functional sequence I've been using from F >> H to R >> L and ran into a problem with epidewarp.fsl (in version 4). The unwarping was still happening along the F >> H axis in the new images where phase encoding was R >> L.
(Note: I'm working with NHPs in sphinx position, but I'll describe my problem in standard coordinates to keep everything somewhat simpler)
Because thought that epidewarp.fsl might be having a difficult time determining the phase encoding direction, I swapped the position of the F >> H and R >> L dimensions in my nifti file (going from LIP to IRP) and the dewarping now seems to work.
Is there something going wrong in the unpacking such that the phase encoding information is lost? Also, is the phase encoding information stored anywhere in the nifti, so that I can automatically detect and correct cases like this?
Thanks for the help, Clark
Hi Clark, the phase encode direction is always lost since that information is not represented in the nifti header. epidewarp.fsl always assumes that the phase encode direction is in the row direction. doug
On 11/13/2012 07:32 AM, Clark Fisher wrote:
Hi everyone,
I recently switched the phase encoding direction of the functional sequence I've been using from F>> H to R>> L and ran into a problem with epidewarp.fsl (in version 4). The unwarping was still happening along the F>> H axis in the new images where phase encoding was R>> L.
(Note: I'm working with NHPs in sphinx position, but I'll describe my problem in standard coordinates to keep everything somewhat simpler)
Because thought that epidewarp.fsl might be having a difficult time determining the phase encoding direction, I swapped the position of the F>> H and R>> L dimensions in my nifti file (going from LIP to IRP) and the dewarping now seems to work.
Is there something going wrong in the unpacking such that the phase encoding information is lost? Also, is the phase encoding information stored anywhere in the nifti, so that I can automatically detect and correct cases like this?
Thanks for the help, Clark _______________________________________________ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
hi doug,
just to follow up on this. if i had the phase encode direction (we currently store various dicom attributes in a nifti header extension), where would i provide it?
cheers,
satra
On Tue, Nov 13, 2012 at 11:27 AM, Douglas N Greve <greve@nmr.mgh.harvard.edu
wrote:
Hi Clark, the phase encode direction is always lost since that information is not represented in the nifti header. epidewarp.fsl always assumes that the phase encode direction is in the row direction. doug
On 11/13/2012 07:32 AM, Clark Fisher wrote:
Hi everyone,
I recently switched the phase encoding direction of the functional
sequence I've been using from F>> H to R>> L and ran into a problem with epidewarp.fsl (in version 4). The unwarping was still happening along the F>> H axis in the new images where phase encoding was R>> L.
(Note: I'm working with NHPs in sphinx position, but I'll describe my
problem in standard coordinates to keep everything somewhat simpler)
Because thought that epidewarp.fsl might be having a difficult time
determining the phase encoding direction, I swapped the position of the F>> H and R>> L dimensions in my nifti file (going from LIP to IRP) and the dewarping now seems to work.
Is there something going wrong in the unpacking such that the phase
encoding information is lost? Also, is the phase encoding information stored anywhere in the nifti, so that I can automatically detect and correct cases like this?
Thanks for the help, Clark _______________________________________________ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
-- Douglas N. Greve, Ph.D. MGH-NMR Center greve@nmr.mgh.harvard.edu Phone Number: 617-724-2358 Fax: 617-726-7422
Bugs: surfer.nmr.mgh.harvard.edu/fswiki/BugReporting FileDrop: www.nmr.mgh.harvard.edu/facility/filedrop/index.html
Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
The information in this e-mail is intended only for the person to whom it is addressed. If you believe this e-mail was sent to you in error and the e-mail contains patient information, please contact the Partners Compliance HelpLine at http://www.partners.org/complianceline . If the e-mail was sent to you in error but does not contain patient information, please contact the sender and properly dispose of the e-mail.
actually, I have no idea:). This is a wrapper around the FSL programs. I wrote the code always assuming that the phase encode direction was the row direction. Usually, it gets unpacked that way. Is the data getting reoriented along the way? doug
On 11/13/2012 11:34 AM, Satrajit Ghosh wrote:
hi doug,
just to follow up on this. if i had the phase encode direction (we currently store various dicom attributes in a nifti header extension), where would i provide it?
cheers,
satra
On Tue, Nov 13, 2012 at 11:27 AM, Douglas N Greve <greve@nmr.mgh.harvard.edu mailto:greve@nmr.mgh.harvard.edu> wrote:
Hi Clark, the phase encode direction is always lost since that information is not represented in the nifti header. epidewarp.fsl always assumes that the phase encode direction is in the row direction. doug On 11/13/2012 07:32 AM, Clark Fisher wrote: > Hi everyone, > > I recently switched the phase encoding direction of the functional sequence I've been using from F>> H to R>> L and ran into a problem with epidewarp.fsl (in version 4). The unwarping was still happening along the F>> H axis in the new images where phase encoding was R>> L. > > (Note: I'm working with NHPs in sphinx position, but I'll describe my problem in standard coordinates to keep everything somewhat simpler) > > Because thought that epidewarp.fsl might be having a difficult time determining the phase encoding direction, I swapped the position of the F>> H and R>> L dimensions in my nifti file (going from LIP to IRP) and the dewarping now seems to work. > > Is there something going wrong in the unpacking such that the phase encoding information is lost? Also, is the phase encoding information stored anywhere in the nifti, so that I can automatically detect and correct cases like this? > > Thanks for the help, > Clark > _______________________________________________ > Freesurfer mailing list > Freesurfer@nmr.mgh.harvard.edu <mailto:Freesurfer@nmr.mgh.harvard.edu> > https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer > > -- Douglas N. Greve, Ph.D. MGH-NMR Center greve@nmr.mgh.harvard.edu <mailto:greve@nmr.mgh.harvard.edu> Phone Number: 617-724-2358 <tel:617-724-2358> Fax: 617-726-7422 <tel:617-726-7422> Bugs: surfer.nmr.mgh.harvard.edu/fswiki/BugReporting <http://surfer.nmr.mgh.harvard.edu/fswiki/BugReporting> FileDrop: www.nmr.mgh.harvard.edu/facility/filedrop/index.html <http://www.nmr.mgh.harvard.edu/facility/filedrop/index.html> _______________________________________________ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu <mailto:Freesurfer@nmr.mgh.harvard.edu> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer The information in this e-mail is intended only for the person to whom it is addressed. If you believe this e-mail was sent to you in error and the e-mail contains patient information, please contact the Partners Compliance HelpLine at http://www.partners.org/complianceline . If the e-mail was sent to you in error but does not contain patient information, please contact the sender and properly dispose of the e-mail.
freesurfer@nmr.mgh.harvard.edu
-
Clark Fisher -
Douglas N Greve -
Satrajit Ghosh