When running a third party script, I found that for some subjects the gradient table was being dropped where one would expect it to be preserved. This turned out to be happening in an mrcalc call, due to an inconsequential imprecision. One input image had separate gradient table handling via text files, whereas the other was entirely MRtrix3 handling.

Within Header::merge_keyval(), there is already special handling of slice timing vectors where there may be some imprecision between two data paths but the merged header should preserv that information. The same should happen for a gradient table: as long as dw_scheme is close enough between two headers, the resulting merged header should preserve the gradient table; they shouldn't have to be string-equivalent.