In the initial stage, maybe. The problem is that if we have to scale all the data by the RECO_map_slope, it requires a different approach than the current one. At the moment, all the script does is produce an MRtrix3 compatible header that then references the original raw data (so no copy involved). If we need to scale things differently per volume, then we’d need to convert the data to floating-point format and scale accordingly into a separate file. All do-able with Python, but suddenly a lot messier…
In the long run, I think this is something that would be better managed with MRtrix3’s own image handling backend, but that would require some coding effort. I don’t mind doing this, but what I can’t commit to is testing this to death to make sure all edge cases are appropriately handled. That means getting the transform information right, verifying that the DW orientations are correct across a range of different acquisition scenarios, etc. I’d need a lot of test data, and more importantly, someone to figure out how to extract the relevant information from the headers and interpret it correctly.
So if we can fix up the python script to a level where we’re confident that it handles things well, I’d be happy to write the direct import code at that point. But what I’d like to have is some guarantees that the Python import is solid before I do this…
So you could do this, but bear in mind there is no support within MRtrix3 for the full b-matrix. While we do provide a tensor-fitting routine, it’s very much a low priority for us. There is no real way to handle full b-matrices within a HARDI / multi-shell HARDI framework. There is some recent research from other labs that might be able to handle this in future, but it’s certainly not implemented within MRtrix3, and we have no plans at the moment to do anything about it…
In general, you would be much better off making sure the sequence does not generate large cross-terms. That used to be a problem when the read-dephase gradient was played out at the same time as the 90° slice refocus gradient, before the DW gradients - most other gradients don’t have anywhere near the same effect. If your sequence is still doing this, it’s about 20 years out of date… Also, it’s now recommended to disable the 180° crushers for b>0 images, since the DW gradients are essentially enormous crushers anyway. If you do all of this, there’s essentially nothing but the very short 180° slice-select gradient to worry about, and that self-refocuses very quickly, so should only produce tiny cross-terms.
I guess it’s OK if we know the DW gradients are always relative to the read/phase/slice - I’m just paranoid about getting these things wrong - although it’s admittedly not as big an issue on a preclinical scanner as it might be in a pre-surgical environment… Would be good to get right though.