FSL ball-and-sticks output

[Lestropie]

Invested a fair bit of effort in building ball-and-sticks compatibility into the spec and verifying its orientation encoding: https://github.com/Lestropie/DWI_metadata. So would like to get support for that into the tool.

[PeerHerholz]

Hi @Lestropie,

thanks for this! After a quick look, I'm not quite sure re the implementation.
The App so far takes preprocessed dwi data as input and thus we would have to add a few workflows
to incorporate your work, specifically, the orientation encoding validation and then ball-and-sticks compatibility, correct?

Thanks again.

Best, Peer

[Lestropie]

• Integrate FSL dependency into container
• Run bedpostx against sample data
  (can reduce burn-in time & number of samples to reduce computation / storage)
• The way that FSL writes the estimated fibre orientations, as a separate image per angle, is intentionally not permitted by the specification. However there's multiple ways in which one could modify those data to make them compliant (bedpostx stick component concatenation bids-standard/bids-bep016#93), and ideally it would be good to be able to demonstrate all (eg. toggling via a command-line option):
  • For each stick individually, take the inclination and azimuth angles, and concatenate them in the fourth dimension to produce a separate unit spherical coordinate image per stick.
  • Take the inclination and azimuth angles across all sticks, and concatenate them in the fourth dimension to produce a unit spherical coordinates image containing all stick components.
  • For each stick individually, take the fibre volume fraction, inclination and azimuth angles, and concatenate them in the fourth dimension to produce a separate (non-unit) spherical coordinate image per stick.
  • Take the fibre volume fractions, inclination and azimuth angles, and concatenate them in the fourth dimension to produce a single (non-unit) spherical coordinates image containing all stick components.
  • For all four possibilities above, apply both to the "mean" and "merged" outputs.
    (Need to demonstrate the requirement to explicitly encode which image axis corresponds to orientation encoding vs. bootstrap realisations; Bootstrapping bids-standard/bids-bep016#38)
• Take the "dyads" image per stick component, and concatenate them in the fourth dimension to produce a unit 3-vector image containing all stick components.

You don't need to do any validation of orientation encoding here. The purpose of the linked project was to provide adequate guarantees here that if we do the trivial manipulations above, then slap:

{
    "OrientationEncoding": {
        "Reference": "bvec",
        "Type": "spherical"
    }
}

in the sidecar (acknowledging potential change in bids-standard/bids-bep016#106), then there is no error or ambiguity about how stored image intensities relate to estimated fibre orientations. One way that we will be able to prove that such interpretation is correct is by converting fibre orientations estimated by one software into the format expected by the other software, and showing visually that they make anatomical sense. But at least for now I would consider that out of scope for this specific piece of software; focus here should be on just fitting a model and then encoding its outputs.