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 
> <gr...@nmr.mgh.harvard.edu <mailto:gr...@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
>     gr...@nmr.mgh.harvard.edu <mailto:gr...@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.
>
>

-- 
Douglas N. Greve, Ph.D.
MGH-NMR Center
gr...@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

Reply via email to