OHBM Action Point 3: Re-structure diffusion models & nomenclature

[Lestropie]

Currently, the approach taken in the specification of diffusion models is:

1. Provide an exhaustive list of models, describing separately for each the way in which the image data for that particular model should be 'packed' into a single NIfTI image;

2. List, for each model, potential input parameters used in the fitting of the model that could be stored in the sidecar JSON;

3. Provide an additional exhaustive list of potential images that could conceivably be 'derived' from the various models.

I raised a few issues with this approach:

• For many models, direct concatenation of model parameters into a single NIfTI does not make a lot of sense: parameters may have different units, or some may be feasible for isolated interpretation (e.g. axonal water fraction) whereas others may not (e.g. individual tensor coefficients).

• There is a certain amount of redundancy in separately defining the data storage format for each model, given certain concepts are common between multiple models.

• There are certain "data representations", such as XYZ triplets defining fibre orientations, that could conceivably be used either for representation of the intrinsic model outputs, or for quantities calculated downstream of the model fitting. It therefore makes more sense to establish such concepts, and then make reference to them wherever used.

• There are still some ambiguities that have not been resolved; e.g. whether directions are defined with respect to scanner or image axes.

• Didn't like the specification for FSL bedpostx: Apart from the model name, it also assumed that bootstrapped model parameters would be specified, and by extension no other model would possibly define bootstrapped parameters; would prefer to have separate explicit description of how to deal with bootstrapping, with bedpostx simply being the most likely example of such.

We also decided communally that we weren't entirely happy with the "_diffmodel.*" filename suffix, particularly given the prospect of having some models represent their output parameters across multiple NIfTI images.

---

I'm going to provide here a bit of a snapshot of both the nomenclature and the structure of the re-formatting that I'm currently using as my basis for putting together a first draft of the refactor; anyone is free to comment on any aspect of such while I'm in the process.

• Diffusion derivatives

  • Pre-processed diffusion data

  • Diffusion models

    • "Input", "intrinsic" & "extrinsic" parameters

      • Definitions

        ("Input" = Something that must be defined in order to fit the model to the diffusion data; "Intrinsic" = a native result of the model fitting; "Extrinsic" = something that can be calculated from the results of the model fitting, without having to refer back to the original diffusion data)

      • File naming convention

        (3 options here: Intrinsic parameters where all parameters are concatenated in a single NIfTI image; intrinsic parameters where parameters are spread across multiple NIfTIs; extrinsic parameters, which are actually almost identical to the second option but the JSON naming is different)

    • Data representations

      (This is about the different ways that model parameters, particularly those representing orientation information, should be stored as image data; current list is: Scalar, DEC, spherical coordinates (unit norm or otherwise), 3-vectors, SH, amplitudes corresponding to a fixed dense direction set, "coefficient vectors" (specific model-dependent parameters just concatenated together))

    • Orientation conventions

      (Specifying relevant JSON fields to adequately define how orientation-based information should be interpreted)

    • Intrinsic model parameters

      (Comprehensive list of models, referring to above content where relevant; also input parameters that can be defined in sidecar JSONs for each model, and a list of examples)

    • Model bootstrapping

    • Extrinsic model parameters

      (Comprehensive list of known derivative parameters, but referring to previous sections where necessary)

[Lestropie]

Edit: Accidentally hit the Enter button while writing :-/

Overview is now complete; will update if my thinking changes over time, or when I have something resembling a first draft.

[arokem]

I think that this discussion has been superseded by other more recent discussions (e.g., #69). Closing.