MRtrix3 provides a set of tools to perform various advanced diffusion MRI analyses, including constrained spherical deconvolution (CSD), probabilistic tractography, track-density imaging, and apparent fibre density
In the origin story of dwifslpreproc, I had to deal with the scenario where the user's input DWIs had one or more spatial axes with odd size. When first released, FSL only came with a single config file for topup, and it included downsampling the image data by a factor of 2 in earlier iterations; running this on such an image would result in the command crashing. My original solution was to crop planes from the DWIs as necessary to make the size even; later I changed this to instead pad the image through duplication of planes, such that subsequent removal of those planes would return the DWIs back to the same size as the original.
Since then, FSL now provides multiple topup config files, including one that doesn't involve any downsampling. Though I'm conscious that topup already takes a long time to compute, and not downsampling in early iterations pushes this out even further. So I've not deprecated that code.
The way dwifslpreproccurrently achieves this is through mrconvert to extract the plane to duplicate, and mrcat to do the padding. This also means that Header::concatenate() can do its magic with respect to things like the slice timing vector if necessary. I am however now in a context where this technique causes problems.
A better way would be to use a single mrgrid call, specifying which axes need to be padded and by how much. I however currently see two potential issues with its use in this way:
Currently the padding operation only supports filling by a scalar value. In order to minimally bias the subsequent image processing operation, being susceptibility field estimation, I would prefer that the operation instead involve duplication of the planes at the edge of the image FoV.
The process of concatenating two images may have consequences for metadata; in the context of dwifslpreproc, specifically slice timing. mrgrid should ideally perform the expected manipulations of such data; preferably through the actual use of Header::concatenate() so that it is all centralised and any future explicit support of new metadata fields of interest should propagate.
[ ] If mrgrid is augmented in this way, not only should it be used for the padding operation in dwifslpreproc, but it should also be correspondingly used to crop the image after FSL commands have performed their processing.
(much of this code predates mrgrid)
[ ] Consider modifying dwifslpreproc to always pad spatial axes to be a factor of 4, such that the topup config file that involves downsampling by a factor of 4 (if present) can be used. I'm guessing that this will result in faster execution.
In the origin story of
dwifslpreproc, I had to deal with the scenario where the user's input DWIs had one or more spatial axes with odd size. When first released, FSL only came with a single config file fortopup, and it included downsampling the image data by a factor of 2 in earlier iterations; running this on such an image would result in the command crashing. My original solution was to crop planes from the DWIs as necessary to make the size even; later I changed this to instead pad the image through duplication of planes, such that subsequent removal of those planes would return the DWIs back to the same size as the original.Since then, FSL now provides multiple
topupconfig files, including one that doesn't involve any downsampling. Though I'm conscious thattopupalready takes a long time to compute, and not downsampling in early iterations pushes this out even further. So I've not deprecated that code.The way
dwifslpreproccurrently achieves this is throughmrconvertto extract the plane to duplicate, andmrcatto do the padding. This also means thatHeader::concatenate()can do its magic with respect to things like the slice timing vector if necessary. I am however now in a context where this technique causes problems.A better way would be to use a single
mrgridcall, specifying which axes need to be padded and by how much. I however currently see two potential issues with its use in this way:Currently the padding operation only supports filling by a scalar value. In order to minimally bias the subsequent image processing operation, being susceptibility field estimation, I would prefer that the operation instead involve duplication of the planes at the edge of the image FoV.
The process of concatenating two images may have consequences for metadata; in the context of
dwifslpreproc, specifically slice timing.mrgridshould ideally perform the expected manipulations of such data; preferably through the actual use ofHeader::concatenate()so that it is all centralised and any future explicit support of new metadata fields of interest should propagate.[ ] If
mrgridis augmented in this way, not only should it be used for the padding operation indwifslpreproc, but it should also be correspondingly used to crop the image after FSL commands have performed their processing. (much of this code predatesmrgrid)[ ] Consider modifying
dwifslpreprocto always pad spatial axes to be a factor of 4, such that thetopupconfig file that involves downsampling by a factor of 4 (if present) can be used. I'm guessing that this will result in faster execution.