-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MRTRIX DTI conversion #3
Comments
@Lestropie : do you think this is something you could implement? |
See also #2 |
Sorry wrote #7 but didn't actually reply here. Happy to take responsibility for this bit, but we need to decide on an overall structure of what the code should look like across the various conversions; we don't want completely disparate implementations. |
|
Hi @Lestropie, as we have the first draft of the
Based on #10, we would need to convert files to |
If you want to keep things simple, the process itself is simple also:
The complexity only arises if, for instance, you want changes to the fitting procedure to be reflected in the BIDS Derivatives metadata. Eg. Currently the default tensor fit is IWLS with 2 iterations, but a software user could explicitly request a different procedure at the command-line, or the default behaviour could change between MRtrix3 versions, and ideally the resultant metadata should always be faithful to what was performed. As a very basic single use case it's pretty easy. Indeed we think it's so simple that we've never generated a documentation page for it (MRtrix3/mrtrix3#2456). |
Thx so much @Lestropie! Following the "standard"/"easy" use case without changing defaults, I implemented a first draft of the respective pipeline here, which generates the following output:
Would this be accurate (sorry I have no experience with
Leaving the |
|
Hi @Lestropie, thx for the reply. All the files and their naming pattern are based on the current state of the BEP and I followed the information/examples noted there.
True that, but as these files were listed in the current state of the
Cool thanks for the hint! This is related to #7 in terms of default vs. additional parameters of the respective processing pipeline. |
I wouldn't call this "increased compliance". A BEP016 derivative dataset can have just two files yet be 100% compliant. It's more like "increased breadth of demonstration of compliance". Indeed having different exemplar derivatives with more / fewer model-derived parameters may be worthwhile generating in order to communicate this point. |
I think that a good way forward here would be to pare down the dipy outputs so that we get exactly the same output dataset for both software pipelines. DIPY does not currently generate a b0 through it's CLI, so I wonder whether we should also pare that down from mrtrix. I can see arguments against that. |
That would worry me a little, as it would hide a historically problematic case. Relates to bids-standard/bids-bep016#54, Relates to bids-standard/bids-bep016#64, probably many others that I can't immediately find links to but it relates to the whole MFP / MDP discussion.
|
Write Python code that runs the mrtrix CLI to produce DTI outputs on the preprocessed data (which the current code puts in BIDS format) and then organizes it into a BEP16-compliant derivative dataset.
The text was updated successfully, but these errors were encountered: