Hi Gregory,
Actually, for an AP/PA phase encode axis, that will probably be incorrect.  The PhaseEncodingDirectionPositive value in the Siemens DICOMs is useful because it summarizes the impact of both the "Phase enc. dir" setting and the "Invert RO/PE Polarity" flag in the sequence, and we use that value to validate that the PA/AP/RL/LR labels that we assign to our Series Descriptions match what we would expect.  However, that DICOM variable only tells you about Siemens internal coordinate system, which is not actually what "Positive" in the input "SpinEchoPhaseEncodePositive" is based upon.

You'll notice that the comment in Examples/Scripts/GenericfMRIVolumeProcessingPipelineBatch.sh
says
SpinEchoPhaseEncodePositive is "RL in HCP data, PA in 7T HCP data"

So, our convention is to use PA as the SpinEchoPhaseEncodePositive input with scans acquired with an AP/PA phase encoding axis.  But as you've seen, the DICOMs have PhaseEncodingDirectionPositive = 0 for "PA" scans.  That's because the convention in the HCP pipelines is to assign the "positive" SE Field Map direction as the one that will generate a topup-derived field map with the same polarity as what a standard gradient echo field map collected on a Siemens scanner (and created using 'fsl_prepare_fieldmap') would look like, so that we can use the same PhaseEncodeList values either way for the EPI being corrected.

That hopefully explains the behavior of how this all comes together.  However, let me stress again to you (and any future readers of this thread), that the accuracy of your settings as regards distortion correction should be confirmed empirically.  i.e., switch EITHER your assignments for SpinEchoPhaseEncode{Positive,Negative}, OR the direction of PhaseEncodeList for the EPI scan being corrected (but not both).  If your original settings are correct, then switching the polarity at one point in the chain in that fashion will lead to more severe distortion.  Similarly, if one is using gradient echo based field maps, I would switch the direction of PhaseEncodeList and confirm the polarity that way.

cheers,
-MH

-- 
Michael Harms, Ph.D.
-----------------------------------------------------------
Conte Center for the Neuroscience of Mental Disorders
Washington University School of Medicine
Department of Psychiatry, Box 8134
660 South Euclid Ave. Tel: 314-747-6173
St. Louis, MO  63110 Email: [email protected]

From: <Book>, Gregory <[email protected]>
Date: Wednesday, December 17, 2014 8:34 AM
To: "Harms, Michael" <[email protected]>, Matt Glasser <[email protected]>, "[email protected]" <[email protected]>
Subject: Re: [HCP-Users] spin echo phase encoding direction

Thanks for the info. I ran all the possible combinations of phase encoding directions and the invert option, and their effects on the DICOM header. This was actually very useful for us to understand the data. It seems that the CSA header field #20 (PhaseEncodingDirectionPositive) does take into account the prescribed direction and the invert option. So in this case, I assume I should use the SE image with the DICOM header of PhaseEncodingDirectionPositive=1 as the SpinEchoPhaseEncodePositive image in the HCP setup script?

 

From: Harms, Michael [mailto:[email protected]]
Sent: Monday, December 15, 2014 5:41 PM
To: Book, Gregory; Harms, Michael; Glasser, Matthew; [email protected]
Subject: Re: [HCP-Users] spin echo phase encoding direction

 

 

Hi Greg,

Ultimately, getting all the signs right is a complicated combination of (1) how the manufacturer implements its PE gradient blips, (2) the DICOM to NIFTI converter that you use (and whether you 'reorient' the data, e.g., using 'fslreorient2std'), (3) your settings for "Phase enc. dir." and "Invert RO/PE Polarity and (4) the plane/oriention that the EPI is acquired in.  It is very dangerous for us to provide you a "rule", as it is very difficult to anticipate all usage cases.  That's why I stressed the importance of confirming that you have all the conventions correct in your own data (by explicitly inverting the value of the "PhaseEncodeList" parameter in the pipeline, and seeing if the result indeed gets worse).

 

That said, as a sanity check for you, on a Siemen's scanner, acquiring transverse slices, using 'dcm2nii' as your NIFTI converter, with transverse slices, I would expect that you find the following:

If phase encoding direction=COL, and directionPositive=1, then PEdir="-y"

If phase encoding direction=COL, and directionPositive=0, then PEdir="+y"

 

As Matt noted, those "PEdir" (i.e., PhaseEncodeList values) themselves are dependent on a certain convention for the SpinEchoFieldMaps, which I believe is outlined in the comments of the HCP pipeline scripts.

 

cheers,

-MH

 

-- 

Michael Harms, Ph.D.

-----------------------------------------------------------

Conte Center for the Neuroscience of Mental Disorders

Washington University School of Medicine

Department of Psychiatry, Box 8134

660 South Euclid Ave. Tel: 314-747-6173

St. Louis, MO  63110 Email: [email protected]

 

From: <Book>, Gregory <[email protected]>
Date: Monday, December 15, 2014 4:17 PM
To: "Harms, Michael" <[email protected]>, Matt Glasser <[email protected]>, "[email protected]" <[email protected]>
Subject: Re: [HCP-Users] spin echo phase encoding direction

 

Ok, good to know what that means as to how the data is collected relative to the label.

 

So with the original example of a console entered A>>P, what does that mean if the PhaseEncodingDirectionPositive is 1 or 0?

-G


From: Harms, Michael [[email protected]]
Sent: Monday, December 15, 2014 4:10 PM
To: Book, Gregory; Glasser, Matthew; Harms, Michael; [email protected]
Subject: Re: [HCP-Users] spin echo phase encoding direction

 

Hi,

If you had "A>>P" with "Invert RO/PE Polarity" checked, then that would be the same as if you had set "P>>A" and "Invert RO/PE Polarity" was left unchecked.

 

The *dInPlaneRot field does NOT include the impact of the "Invert RO/PE Polarity" flag.  Sorry, I directed you to the wrong shadow field previously.  "PhaseEncodingDirectionPositive" is (according to my notes) subfield #20 of (0029, 1010).  If it doesn't have a value, that means it value was 0 for that scan.  (Its value is either 0 or 1).

 

cheers,

-MH

 

-- 

Michael Harms, Ph.D.

-----------------------------------------------------------

Conte Center for the Neuroscience of Mental Disorders

Washington University School of Medicine

Department of Psychiatry, Box 8134

660 South Euclid Ave. Tel: 314-747-6173

St. Louis, MO  63110 Email: [email protected]

 

From: <Book>, Gregory <[email protected]>
Date: Monday, December 15, 2014 2:59 PM
To: Matt Glasser <[email protected]>, "Harms, Michael" <[email protected]>, "[email protected]" <[email protected]>
Subject: Re: [HCP-Users] spin echo phase encoding direction

 

I’m slightly more confused now. So, using the CMRR sequences, if I set the phase encoding direction on my spin echo to A>>P, and “Invert RO/PE Polarity” option is checked… a) what is the actual phase direction of the data b) what is recorded in the DICOM header in the *.dInPlaneRot field?

 

 

 

From: Glasser, Matthew [mailto:[email protected]]
Sent: Monday, December 15, 2014 2:33 PM
To: Book, Gregory; Harms, Michael; [email protected]
Subject: Re: [HCP-Users] spin echo phase encoding direction

 

If your phase encoding directions are inverted, I would recommend swapping the SpinEchoPositive and NegativeImage values.  This would make the computed field map have the same sign as a typical field map and then the PhaseEncodeList would not have to change.

 

Peace,

 

Matt.

 

From: <Book>, Gregory <[email protected]>
Date: Monday, December 15, 2014 at 12:16 PM
To: "Harms, Michael" <[email protected]>, "[email protected]" <[email protected]>
Subject: Re: [HCP-Users] spin echo phase encoding direction

 

Would that be the *.dInPlaneRot value for each slice in the CSA header?

 

From: Harms, Michael [mailto:[email protected]]
Sent: Monday, December 15, 2014 10:11 AM
To: Book, Gregory; [email protected]
Subject: Re: [HCP-Users] spin echo phase encoding direction

 

 

The value of "PhaseEncodingDirectionPositive" in the shadow field (0029,1020) reflects the combination of both "Phase enc. dir." on the Routine tab (e.g., "A>>P" vs. "P>>A") AND the setting of "Invert RO/PE Polarity" on the Sequence/Special tab.

 

As long as you have one of each polarity, you can use the spin echo field map correction.   I highly recommend that you purposely try both possible assignments, and visually confirm which one is giving the correct results.  That's because the correct setting for PhaseEncodeList (e.g., "y-" vs. "y+") can in theory even be dependent on which DICOM to NIFTI converter you use.  (e.g., if one converter returns a +LAS orientation, while another returns a +LPS orientation, then the proper settings for PhaseEncodeList may be swapped).

 

cheers,

-MH

 

-- 

Michael Harms, Ph.D.

-----------------------------------------------------------

Conte Center for the Neuroscience of Mental Disorders

Washington University School of Medicine

Department of Psychiatry, Box 8134

660 South Euclid Ave. Tel: 314-747-6173

St. Louis, MO  63110 Email: [email protected]

 

From: <Book>, Gregory <[email protected]>
Date: Monday, December 15, 2014 8:38 AM
To: "[email protected]" <[email protected]>
Subject: [HCP-Users] spin echo phase encoding direction

 

I have another question about the spin echo images, hopefully this will be my last question!

 

It turns out that we’ve been collecting our spin echo images with the “Invert RO/PE Polarity” option selected, which apparently inverts the phase encoding direction 180deg, but does not record this to the DICOM header. We’ve been collecting the EPI images without this inversion.

So, for our data:

EPI is A>>P

“A>>P” SE is actually P>>A

“P>>A” SE is actually A>>P

 

Would we be able to use the spin echo correction if we simply switched the positive and negative images? So, would this work for our data?

TaskList=”task1”

PhaseEncodeList=”y-“

SpinEchoPositiveImage=”the P>>A labeled image (actually acquired A>>P)”

SpinEchoNegativeImage=”the A>>P labeled image (actually acquired P>>A)”

 

-G

 

_________________________________________________

Gregory Book

Senior Technology Manager

Olin Neuropsychiatry Research Center, Institute of Living, Hartford Hospital

200 Retreat Avenue

Hartford, CT 06106

Tel: 860-545-7267 Fax: 860-545-7797

[email protected]

http://nidb.sourceforge.net

 


This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure, or distribution is prohibited. If you are not the intended recipient, or an employee or agent responsible for delivering the message to the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message, including any attachments.

_______________________________________________
HCP-Users mailing list
[email protected]
http://lists.humanconnectome.org/mailman/listinfo/hcp-users

 


The materials in this message are private and may contain Protected Healthcare Information or other information of a sensitive nature. If you are not the intended recipient, be advised that any unauthorized use, disclosure, copying or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error, please immediately notify the sender via telephone or return mail.

_______________________________________________
HCP-Users mailing list
[email protected]
http://lists.humanconnectome.org/mailman/listinfo/hcp-users

 


The materials in this message are private and may contain Protected Healthcare Information or other information of a sensitive nature. If you are not the intended recipient, be advised that any unauthorized use, disclosure, copying or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error, please immediately notify the sender via telephone or return mail.

_______________________________________________
HCP-Users mailing list
[email protected]
http://lists.humanconnectome.org/mailman/listinfo/hcp-users

 


The materials in this message are private and may contain Protected Healthcare Information or other information of a sensitive nature. If you are not the intended recipient, be advised that any unauthorized use, disclosure, copying or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error, please immediately notify the sender via telephone or return mail.

_______________________________________________
HCP-Users mailing list
[email protected]
http://lists.humanconnectome.org/mailman/listinfo/hcp-users

 


The materials in this message are private and may contain Protected Healthcare Information or other information of a sensitive nature. If you are not the intended recipient, be advised that any unauthorized use, disclosure, copying or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error, please immediately notify the sender via telephone or return mail.

_______________________________________________
HCP-Users mailing list
[email protected]
http://lists.humanconnectome.org/mailman/listinfo/hcp-users

 


The materials in this message are private and may contain Protected Healthcare Information or other information of a sensitive nature. If you are not the intended recipient, be advised that any unauthorized use, disclosure, copying or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error, please immediately notify the sender via telephone or return mail.

_______________________________________________
HCP-Users mailing list
[email protected]
http://lists.humanconnectome.org/mailman/listinfo/hcp-users

Reply via email to