You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, information about slice acquisition order is provided using the following:
options.add_argument('-mb', help='Multiband factor (default = 1)')
options.add_argument('-sorder', help='Slice order (default = 2,1, for odd-even)')
In a lot of datasets, relative slice timing can be computed from the DICOM headers. Currently in MRtrix3, this is done based on all slices of the first volume, where the diffusion sensitisation of that first volume is constant. So if you have a genuine scattered-slice acquisition, I don't know how hard it might be to track the time of acquisition of each slice stack individually, or even what an internal image representation of such might look like. Still, curious to know if there's a possibility for improvement here.
Also worth noting that technically one can have ascending vs. descending slice order without any interleaving; likely never used in practise, but on my mind given I used that for this project. And not sure if it's 100% guaranteed that acquiring "interleaved" means that, regardless of whether it's odd-then-even or even-then-odd, it is always in ascending order within each of those halves; would think so, but would depend on the sequence code.
The text was updated successfully, but these errors were encountered:
Currently, information about slice acquisition order is provided using the following:
In a lot of datasets, relative slice timing can be computed from the DICOM headers. Currently in MRtrix3, this is done based on all slices of the first volume, where the diffusion sensitisation of that first volume is constant. So if you have a genuine scattered-slice acquisition, I don't know how hard it might be to track the time of acquisition of each slice stack individually, or even what an internal image representation of such might look like. Still, curious to know if there's a possibility for improvement here.
Also worth noting that technically one can have ascending vs. descending slice order without any interleaving; likely never used in practise, but on my mind given I used that for this project. And not sure if it's 100% guaranteed that acquiring "interleaved" means that, regardless of whether it's odd-then-even or even-then-odd, it is always in ascending order within each of those halves; would think so, but would depend on the sequence code.
The text was updated successfully, but these errors were encountered: