dwifslpreproc: strip DW encoding from padding slice#2382
Conversation
As discussed on the forum: https://community.mrtrix.org/t/dwifslpreproc-error-somewhere-after-the-topup-process/5248/4 This is to avoid potential mismatch with the original DWI series in the subsequent mrcat call, which can result in the DW scheme being labelled as 'variable' and removed altogether.
Lestropie
left a comment
Lestropie
left a comment
There was a problem hiding this comment.
We discussed the general issue of mismatching header key-values during team meeting 20/10.
While I still think it makes sense for the back-end to be flagging mismatches in instances of key-value merging across multiple sources, the issue is that in many instances there is numerical data encoded as strings in such data, and therefore zero tolerance for imprecision. The problem is that the heuristically permissible tolerance may be key-specific, which precludes a general solution.
Currently there's a dedicated solution for slice timing due to imprecision observed in Siemens DICOM headers. Here it makes sense to add some tolerance to dw_scheme specifically because MRtrix3 is internally automatically performing a string - float - string conversion. This change should still IMO go to master because it's arising in the middle of a Python script and therefore a user can't override; but for dev I think it makes sense to add a code branch in Header::merge_keyval() to introduce some tolerance when checking dw_scheme.
2 participants
As discussed on the forum: https://community.mrtrix.org/t/dwifslpreproc-error-somewhere-after-the-topup-process/5248/4
This is to avoid potential mismatch with the original DWI series in the subsequent mrcat call, which can result in the DW scheme being labelled as 'variable' and removed altogether. This will fix that specific issue in
dwifslpreproc, and should be merged tomasterASAP given there's now been several reports of this particular problem.In due course, we'll need to discuss what the correct behaviour ought to be here. It doesn't seem right for a slight mismatch to lead to an actual loss of information. I would also be keen to find a general solution, rather than just patch up this specific use case. I think that'll need a separate discussion though...