This is something that's been in my head from the outset, but given discussion around candidate proposals I think I need to list it here explicitly.
There is a definite risk of naivety in this project. While I've tried to contemplate the task of diffusion model representation in the most general case possible rather than simply enumerating a list of models in the form in which they are provided in respective softwares, there are almost certainly confounds that I have failed to identify. I have also failed to keep myself up to date with the evolution of BIDS & derivatives of such, so there may be emerging guidelines or conventions that I'm not aware of. I believe that if this BEP were to be presented to the community in its current state or close to it, it would be seen as purely academic, not sufficiently authoritative, and there would not be a strong motivation to adhere to it.
What I personally see as a prerequisite for this BEP to attract any wider interest is a software package for importing and exporting BIDS Diffusion model Derivatives. This would need to:
- Take diffusion model data as they are natively produced in various software packages, and convert them into BIDS Derivatives;
- Take BIDS Derivatives and convert them into the format expected by the native software package such that that software is agnostic to the fact that the data were not self-generated;
- Where possible, take data that were produced by one software, and convert it through the intermediate representation of BIDS Derivatives into the format expected by another software package, such that the second software reads data from the first package as though it was self-generated;
- Enable conversions within the BIDS Derivatives representation; e.g. conversion between SH conventions, changing of reference axes between scanner and image;
- Validate a BIDS Derivatives dataset and confirm that the requisite sidecar data to faciliate robust interpretation is present;
- Consider reasonably exhaustively the set of softwares / diffusion models in the community;
- (optional) Interface possible conversions between representations; e.g. define how one might get from a tensor representation to a 1-volume 3-vector representation based on the principal eigenvector.
Going through this process is likely to highlight issues with the current design. As such, if the extension were to be pushed first, and relevant software conversion tools were then developed after the fact, it would likely just undermine the extension as there could be a lot that would need to change in the specification in order to become functional. I would personally rather try to get the fundamental specification design correct and iron out the bugs and erroneous assumptions by actually attempting to use it before attempting to claim authority via the specification and demand that others use it.
This could be an interesting project for an e.g. computer science student to lead (I've not had success recruiting someone myself). It should also be public so that community members can propose contributions to support the softwares and models they themselves work with. I'd be happy to broadcast on the MRtrix3 forum for contributions once the basic framework is in place. It would also be useful if anyone with experience with a broader range of software packages has informed opinions on what kind of structure such a package would take, or if there's an existing software package that would operate as a suitable exemplar.
This is something that's been in my head from the outset, but given discussion around candidate proposals I think I need to list it here explicitly.
There is a definite risk of naivety in this project. While I've tried to contemplate the task of diffusion model representation in the most general case possible rather than simply enumerating a list of models in the form in which they are provided in respective softwares, there are almost certainly confounds that I have failed to identify. I have also failed to keep myself up to date with the evolution of BIDS & derivatives of such, so there may be emerging guidelines or conventions that I'm not aware of. I believe that if this BEP were to be presented to the community in its current state or close to it, it would be seen as purely academic, not sufficiently authoritative, and there would not be a strong motivation to adhere to it.
What I personally see as a prerequisite for this BEP to attract any wider interest is a software package for importing and exporting BIDS Diffusion model Derivatives. This would need to:
Going through this process is likely to highlight issues with the current design. As such, if the extension were to be pushed first, and relevant software conversion tools were then developed after the fact, it would likely just undermine the extension as there could be a lot that would need to change in the specification in order to become functional. I would personally rather try to get the fundamental specification design correct and iron out the bugs and erroneous assumptions by actually attempting to use it before attempting to claim authority via the specification and demand that others use it.
This could be an interesting project for an e.g. computer science student to lead (I've not had success recruiting someone myself). It should also be public so that community members can propose contributions to support the softwares and models they themselves work with. I'd be happy to broadcast on the MRtrix3 forum for contributions once the basic framework is in place. It would also be useful if anyone with experience with a broader range of software packages has informed opinions on what kind of structure such a package would take, or if there's an existing software package that would operate as a suitable exemplar.