Closed Lestropie closed 1 month ago
Any objections to merging this into #24 so that we can fix up things there and keep moving towards a PR on the bids-standard/bids-specification? If I get no objections by mid next week, I will go on ahead with that and we can follow up with more PRs on top of this one (specifically to address the "notes" and "todo" sections of current PR).
I'm eager to merge it to start chipping away at other things. I've been writing code to verify appropriate interpretation of fibre orientations (not at the scope of #23, mostly trying to get an answer to #96), and have already identified one aspect where the spec will need to be augmented to support FSL data.
Replaces #90.
Resolving the BEP against the absence of both complex inheritance and suffix distinction is not as simple as removing complex inheritance and swapping suffices; attempting to do so just breaks everything around it. But given prior precedent I'm pessimistic about my ability to convey this convincingly. So I'm better off making the changes necessary to conform to the main structural constraints (no IP changes, single fixed suffix) that will both retain compatibility with extension beyond the most trivial of diffusion models, and hopefully not be objectionable on other bases.
I've ended up making a much broader scope of changes than just "doing #90 differently", as there are too many moving parts to handle in isolation. I'll try to break up my description here in terms of aspects that address those core structural constraints, vs. other things that to greater or lesser necessity got changed along the way. I can't finish this off right now as I have other urgent tasks, but hopefully this is enough to elicit opinions.
Primary structure
Other changes
bedpostx
example more mature, and thinking about future orientation encoding types, I deemed it necessary to be explicit about which image axes encode orientation information vs. different bootstrap realisations of a model. There are some images that have orientation information but no bootstrapping, some that have bootstrap realisations but no orientation information. Then, in the future, there are orientation encoding types that will require multiple image axes (I'm thinking SHARD and DSI PDFs). So I'm not convinced that saying "bootstrapping comes after orientation stuff" is adequate, and would prefer to be explicit about both._dir-
to discover phase encoding information). And for such abbreviated labels, hard to dictate that a dataset would be non-conformant if some App / user were to store an image with a two-character label that encodes a parameter other than the one that the specification attributes to that two-character label.Outstanding questions
bedpostx
orientations when stored in spherical coordinates:bvecs
, which has a flip along the first axis in the case of a positive determinant?bedpostx
concatenating all stick orientations / volume fractions into images versus having each parameter for each stick stored as its own image.