Allow direction entity in MESE files

[tsalo]

Closes none.

Changes proposed:

• Split MESE and MEGRE suffix entity sets.
• Add optional direction entity to the raw MESE anatomical suffix.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 82.65%. Comparing base (a7dd34a) to head (b0909fb).
Report is 8 commits behind head on master.

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #2100   +/-   ##
=======================================
  Coverage   82.65%   82.65%           
=======================================
  Files          17       17           
  Lines        1534     1534           
=======================================
  Hits         1268     1268           
  Misses        266      266           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[effigies]

What's the use case?

[tsalo]

I have AP and PA MESE scans in a current study, but I don't know why. I don't know if there's a use-case as much as it is something researchers can control, so it seems like it should be reflected in the entity set.

[tsalo]

Apparently we plan to use the AP and PA MESE scans for distortion correction.

[oesteban]

In anatomical images, I think this would be an acceptable use of acq-, but I'd be okay with this change in general.

Apparently we plan to use the AP and PA MESE scans for distortion correction.

Please make sure there's nothing in the B0FieldIdentifier/B0FieldSources interface that disallows it from setting identifiers on these, so distortion can be estimated.

[effigies]

Okay, so you have a use case for AP/PA MESE scans, but what about all the other groups? Do you get AP/PA T1w scans, or is this more in-passing to avoid doing this piecemeal, if other use cases are found?

At least for parametric volumes, I would assume that directions would be inapplicable by the time the final volumes are generated, similar to how echo, flip and part no longer apply.

I am hesitant to add more to the nonparametric group without a specific use case.

[oesteban]

Okay, so you have a use case for AP/PA MESE scans, but what about all the other groups?

If the only use case is fieldmap estimation, then acq- plus ensuring B0FieldIdentifier is explicitly allowed in their metadata should be sufficient to encode this.

[yarikoptic]

If there is operator ability to specify direction in anatomicals, we should allow for this entity. IMHO, overall, when there is appropriate targeted entity, we better allow for it instead of inspiring to absorb into some more generic one (like _acq).

[effigies]

I agree that we shouldn't overload acq, and am happy to approve this for MESE. My hesitation is over a lack of use-case for other suffixes.

[tsalo]

Okay, I've limited my change to the MESE and MEGRE suffixes. I don't have any multi-PED MEGRE data, but I figured it was easier to just add direction to that one entity set than to split the rule.

[effigies]

I would split it. I'm sure that the only reason we kept them together was because they had the same entities at the time, not because of some fundamental sameness.

I could be exposing my ignorance to the world, but my understanding is that gradient echo sequences just don't have the same susceptibility distortions that would justify paired direction acquisitions.