bedpostx stick component concatenation

[Lestropie]

Contemplating how best to demonstrate bedpostx stick orientations during #92.

Something I realised early on is the contrast in precedent between having 3-vector images with multiple orientations stored as triplets, versus no such precedent for orientations stored in spherical coordinates and instead splitting them across files. Indeed bedpostx goes even further in the other direction, splitting each spherical coordinate between two files.

However the expectation currently being set by the BEP, being not only concatenation of polar angles to form spherical coordinates but also concatenation across multiple orientations, could possibly be disliked. I do think it should be supported by the specification, but perhaps not what is used for the demonstrative example. The multiple stick components should maybe instead be split across images. I don't think that it should be permissible to keep the two polar angles split between two images---since they can't be interpreted in isolation and need to be grouped to encapsulate the appropriate encoding---but having one spherical coordinate image and one volume fraction image per stick would both be consistent with the rest of the specification in terms of separate representation of separate compartments in a multi-compartment model, but also require less manipulation to get from a bedpostx output to a BIDS-compliant dataset.

[Lestropie]

The other factor to consider here is the relevant filenames if the multiple stick components are split across files. The simple option is to just encode it within the _param- entity; so eg.:

sub-01_model-ballsticks_param-polar1_dwimap.nii.gz
sub-01_model-ballsticks_param-vf1_dwimap.nii.gz
sub-01_model-ballsticks_param-polar2_dwimap.nii.gz
sub-01_model-ballsticks_param-vf2_dwimap.nii.gz
sub-01_model-ballsticks_param-polar3_dwimap.nii.gz
sub-01_model-ballsticks_param-vf3_dwimap.nii.gz

The only alternative I see currently is introducing a new entity, something like index:

sub-01_model-ballsticks_param-polar_index-1_dwimap.nii.gz
sub-01_model-ballsticks_param-vf_index-1_dwimap.nii.gz
sub-01_model-ballsticks_param-polar_index-2_dwimap.nii.gz
sub-01_model-ballsticks_param-vf_index-2_dwimap.nii.gz
sub-01_model-ballsticks_param-polar_index-3_dwimap.nii.gz
sub-01_model-ballsticks_param-vf_index-3_dwimap.nii.gz

[arokem]

Just noting that the question of "index" is also being discussed here, where the suggestion is to use "item" instead, because the word "index" is already being used elsewhere.