Conversation
also minor modifications to tests for dwi2fod
|
OK, quite a few tweaks to the docs - triggered by how bad the description of the SH coefficients looked... |
|
|
Tests are already in there - see d1ba865. Hadn't noticed the authorship. I reckon I might have earned it here... 😁 |
|
I love the overall idea (both the new functionality, as well as the "convention" for 5D multi-SH-shells). Won't have time soon (aka before ISMRM) to do any testing though, but I suppose you've done quite some testing to make sure it all works, right? One thing, now that I think of it (and so I don't forget); I'm sure it's probably clear from the code (but again, sadly I don't have the time to look thoroughly into it), but: when you provide a full gradient table (b-values and all) to the new
(and the authorship thing is all good of course) |
|
Wrt the above, I've come round (rather quickly after posting the above) to preferring assuming ordering with respect to increasing b-value. Still haven't found time to look into the code, documentation, or anything really; but I'm more or less assuming you probably went with that as a convention as well... it's the most consistent with a few other tools (e.g. response function estimation and such). |
- if full DW gradient encoding provided, add to the header as the full dw_scheme entry. This allows the data to be used as-is for further processing as an original DWI series, and generally makes sense: this is DW encoding that was applied to generate the data... - remove the -shell option, since that introduces quite a bit of confusion as to how it applies - notably whether number of shells in DW encoding should match input data before or after shell selection. Best to rely on users to disambiguate. - add gradient import option (should allow users to provide bvecs/bvals if that's how they decided to store their data)
|
Since this alters the documentation, and introduces a new sort of "convention" wrt how SH coefficients are stored (i.e. the addition of how the 5th dimension is used in this context), it might be worthwhile or more efficient to mash this up with #1635 (or somehow combine / coordinate / ... the effort). |
|
I just coincidentally also remembered http://community.mrtrix.org/t/csd-on-standard-dwi-data/2499/5 : a current mistake in the
...should become:
|
3 participants
Adds multi-shell and multi-tissue capability to
shconvandsh2amp.Briefly, this extends SH storage to allow storing SH along the 5th dimension of an image, one per shell.
shconvnow allows multiple ODF/response pairs (much likedwi2fodandmtnormalisedo), and allows multi-shell responses (in which case it'll produce a 5D output).sh2ampcan now accepts directions files in spherical or Cartesian coordinates, full-blown DW encoding files, or an image with a DW encoding in its header (required to handle multi-shell inputs).This allows forward-modelling of all our spherical deconvolution operations, e.g. for MSMT-CSD:
Also in there are a few changes to docs handling, and minor updates to the tests.