Hi Samuel,
Attempting to have these information handled properly has been quite the nightmare for me. It’s unfortunately not as easy as “read” <—> “write” in this context, because there’s a bunch of other moving parts at play, including arbitrary image strides, internal image reorientation, and internal vs. external storage of phase encoding data. But I believe it was @dchristiaens who has commented to me previously that for acquisitions where phase encoding directions are not strictly sign-flipped, an inversion of the first axis is necessary for topup / eddy to work correctly; so it’s entirely possible that there is indeed some residual MRtrix3 issue even after my efforts.
I did a comprehensive test where I acquired all 12 possibilities of slice encoding direction & phase encoding direction and made sure that MRtrix3 imported that information from DICOM correctly.
So I tend to think the issue is likely downstream of that.
On reflection, I think I may have overlooked one of these confounds (sorry if this is TMI, I’m kind of thinking out loud and figuring it out as I write…). When writing any information to JSON that is based on image axes, the relevant code has to predict ahead of time what reordering of image axes is going to be done during NIfTI export, and apply the same transformations to such sidecar data, so that the two separate sources of exported data retain correspondence. However on inspection, I’m failing to account for this specifically in instances where phase encoding information in the eddy config / index format are loaded from / saved to file. So if your image is not strictly RAS, what’s happening is that the exported phase encoding data are entirely compatible with the image data as stored internally by MRtrix3, but then on export MRtrix3 modifies the image axis orientations, which is the part that breaks correspondence between the exported NIfTI and the exported phase encoding data.
You may well find that if you do:
DICOM_SERIES='*b3000*' mrconvert DICOM/ - -strides +1,+2,+3,+4 | mrconvert - dti.nii -export_grad_fsl dti.bvec dti.bval -export_pe_eddy acq_par.txt index.txt
, then topup and eddy will behave correctly. The raw data may not be identical to what dcm2niix produces, but they would be internally consistent and hence not lead to processing issues.
Having access to a dataset where the current MRtrix3 behaviour is known to be wrong would likely help me here in verifying that any fix I implement is doing the right thing. If you are able to provide such, that would be great.
I do have to be careful though in modifying the code around here as there’s yet another confound:
P.S.: Not sure whether it’s relevant, but just in case: When I used other software for spherical deconvolution (such as Explore DTI or StarTrack), I always had to change the sign of the x component of my BVECS file.
This is actually more likely to be a problem with those softwares (and historically incomplete documentation of the bvecs format), not ours. See relevant post here. Prior to that fix, we also failed to take into account the handedness of the image coordinate system in interpretation of bvecs data. This meant that the software behaved entirely reasonably if utilising data generated internally by MRtrix3, but incorrectly if both the bvecs data were generated by FSL and if the corresponding NIfTI image used a radiological / “right-handed” coordinate system (hope I got that right? 
). Most likely what you are observing is those softwares suffering from the same problem.
What I don’t actually recall establishing with a high degree of certainty is whether or not the topup / eddy “datain / config” file format uses the same interpretation of sign on the first image axis as does the bvecs format 
I have created a new issue on GitHub; any updates to the code & testing thereof can be tracked there.
Cheers
Rob