mrconvert: can not determine phase encoding direction from GE SIGNA Premier v29.0 DTI #2517
Comments
|
Thanks for reporting this issue. I don’t think it really qualifies as a bug. None of the issues with wrong dec or tractography are directly related to missing PE info, they are the result of displaying the dec within a viewer that uses different coordinate conventions. How those different conventions manifest in this particular scenario happens to coincide with successful extraction of the PE direction. That said, I think your DICOMs might be of use to help us extract the PE directions in currently unsupported scenarios. |
|
@bjeurissen based on your suggestions I did some further investigation visualizing the tensors acquired by the scanner. Agree that this is not a bug in mrconvert -force "$dicom" dti-$suffix.mif
dwi2mask -force dti-$suffix.mif mask-$suffix.mif
dwidenoise -force -mask mask-$suffix.mif dti-$suffix.mif dti_denoised-$suffix.mif
dwiextract -force dti-$suffix.mif - -bzero | mrmath -quiet -axis 3 -force - mean b0-$suffix.mif
dwi2tensor -force -mask mask-$suffix.mif dti-$suffix.mif dt-$suffix.mif
tckgen \
-force \
-nthreads 16 \
-algorithm Tensor_Prob \
-select "$NSTREAMLINES" \
-minlength 60 \
-seed_image mask-$suffix.mif \
-mask mask-$suffix.mif \
dti_denoised-$suffix.mif \
streamlines-$suffix.tckI then displayed using mrview b0-ap.mif -odf.load_tensor dt-ap.mif -tractography.load streamlines-ap.tck &
mrview b0-lr.mif -odf.load_tensor dt-lr.mif -tractography.load streamlines-lr.tck &The tensor directions appear flipped in plane for A/P frequency encoding, while the L/R frequency encoding are as expected.
The tractography likewise looks correct for L/R frequency encoding.
|
Based on what you posted above I would say it is a bug. Your DICOMs might be of interest to @jdtournier to fix edge cases in the DICOM conversion. |
|
The I do have data that I could share with phase encode and L/R and A/P directions from the same subject on two different GE scanners. For the moment, I'll convert using |
@jdtournier : how does the code currently deal with this? |
|
This is where this happens for the DW scheme. I guess things could be handled similarly for the PE direction, though that might require some refactoring... |
|
Somewhat relates to #1038. The issue is not with the reference axes relative to which "directions" are defined. The DICOM standard specifies for a given cartesian slice whether the phase encoding was applied along the row or column. The problem is that it does not specify the sign of phase encoding along such. In similar cases I've seen how |
Yes, you're right. I got sidetracked by the original report which was about the DEC maps being wrong when the PE direction is not AP - which I think will relate to the fact that GE tend to rely on the PRS frame rather than the DICOM frame for directional information (at least it does in other contexts). But this shouldn't impact on extracting the correct PE direction, as you say. |
|
For modern GE scanners you can determine phase encoding polarity from the public RectilinearPhaseEncodeReordering (0018,9034). So you can detect: versus For older datasets, you can decode the private UserDefineDataGE (0043,102A). The dcm2niix code for this is here. Albeit, this code was written long ago by reverse engineering this tag which was not publicly documented at the time (I know some of the people who signed the GE NDA leaked documents onto Github, but I did not look at those when I wrote this code). However, my solution has proven robust. @mr-jaemin might be able to provide a clearer definition of this tag. @mr-jaemin has provided sample DICOM datasets that illustrate both methods. |
|
Sorry I myself overlooked the fact that there was indeed an issue with interpreted diffusion directions; I commented based on the deviation of the discussion from the topic title. So we need to explicitly consider two separate issues:
|
@Lestropie, I can confirm that converting from DICOM using processing stepsProcessed both visualizationLeft column is frequency encoding in the
Thanks for all the attention on this issue. |
|
@blezek, I might have some idea about what might be going wrong on the import of the DW directions. I can try to implement some fixes and you can check whether that fixes the issue, or if you can share one example dataset with me, I might be able to make faster progress... |
I'm working through the proper channels to get my images out of my institution, unfortunately, it may take a some time (2 weeks+). Will happily test any fixes in the mean time! |
|
OK, I've had a go at fixing what I think might be the issue. Can you try the |
|
I quickly tested two datasets: "R/L" frequency encoding and "A/P" frequency encoding using dcm2niix and mrconvert. The issue would be related to GE convention. As noted dcm2niix/GE or ge-mri for more details, the GE convention for reported diffusion gradient direction has always been in “MR physics” logical coordinate, i.e Freq (X), Phase (Y), Slice (Z). Note that this is neither “with reference to the scanner bore” (like Siemens or Philips) nor “with reference to the imaging plane” (as expected by FSL tools). This is the main source of confusion. "R/L" frequency encoding (i.e. "A/P" phase encoding) mrconvert output: "A/P" frequency encoding (i.e. "R/L" phase encoding) mrconvert output: |
|
Thanks for looking into it, @mr-jaemin. MRtrix has been able to deal with GE data for years though, so there's more to it than that. My gut feeling is it'll be due to there being a mix of GE private tags and DICOM standard tags both carrying information about the gradient table, and our code might be getting confused about whether it needs to re-orient the gradients or not. The way it has worked so far is to assume that the gradients need to be reoriented if we encounter one of the GE-specific private tags, but if we encounter the DICOM standard ones later in the parse and record those gradients, we'll be rotating them when we shouldn't. The pull request I just pushed (#2523) should fix that - assuming that is indeed the problem... 🤞 |
|
@blezek with regards to your comment
Perhaps @mr-jaemin can confirm whether these user actions change the protocol property. If this behavior can be replicated, perhaps GE can update the software to allow these slice parameters to be locked. |
To be clear, what you're describing elsewhere is not so much a "flip" (as in 180-degree rotation) but a 90-degree rotation (is. exchanging frequency encoding and phase encoding axes)? An alternative explanation for happening here is that the system is determining that a L>>R or R>>L phase encoding direction would result in peripheral nerve stimulation; but rather than refusing to progress with the scan it instead rotates the phase encoding direction to A>>P or P>>A. In my own protocol development I really wanted to use 4 phase encoding directions, but to use L>>R or R>>L it was necessary to drastically reduce the bandwidth, increasing EPI distortions and extending TE. It may only require a slight difference in FoV angulation to trigger this. People may want to use L>>R and R>>L because that's what HCP did to reduce TE. But they were able to get away with it only because the Connectom gradient system doesn't have the same spatial extent as a typical whole-body system, so the gradients roll off below the shoulders and PNS is less of a problem. This is taken to the extreme with the latest head-only gradient coil systems, where they can push the gradient slew rates higher for the same reason. Only a hypothesis though. |
Turns out my gut was wrong, and we've simply never properly handled GE data when the phase-encode direction wasn't AP... Preliminary fix on #2523, though it'll require more extensive testing... |
Thanks @neurolabusc! I've just pushed a commit (31f819d) to parse this field, and that does seem to do the trick - though currently I only have data with a single PE direction, so I won't be able to fully validate till I get hold of some reversed PE data... 😁 [EDIT: I've just spotted the links posted by @neurolabusc with sample validation data - I'll have a look at those now] |
|
@neurolabusc, @mr-jaemin: I've been looking into the sample The 04_Ax_DWI_TENSOR_R2MB2 contains both I note all the other Could this be due to this bit of code, where the polarity is inverted if the slice order is bottom-up? Why would this have anything to do with the PE direction...?!? Also, my DW gradients come out reversed compared to |
Describe the bug
mrconvert(and othermrtrixtools) do not identify the phase encoding direction on GE 3T SIGNA Premier imaging versionv29.0. Results in incorrectdecimages (and really bad tractography!).To Reproduce
Output of
dcminfo -allthese are randomly selected slices from the series, but all images in the respective series have the same phase / frequency encoding directions.
Platform/Environment/Version
OS:
MRtrix3 version (example:
mrinfo -version)The text was updated successfully, but these errors were encountered: