Hi Octavian,
I’m assuming you’re using the -rpe_header option in this instance?
Because the current implementation tests for exact equivalence between gradient directions with zero tolerance when testing whether or not the volumes should be combined together, such a small difference will indeed result in dwipreproc not combining any volumes. In the changes I have proposed to deal with your other reported dwipreproc issues, I do adjust this to permit some numerical tolerance between gradient directions; but there is inevitably a balance between what that tolerance is, compared to the severity of errors in the gradient table.
I do think that I may have seen such an encoding issue in the past, but unfortunately I don’t recall specifics; others may have had more experience. But the fact that it’s the first non-b=0 volume would suggest to me that it’s an encoding problem rather than a decoding problem.
My advice would be to manually edit the gradient table and correct the discrepancy before running dwipreproc. The difference in the two vector orientations is really very small. Doing the volume combination should provide benefits over retaining all 140 volumes, due to the differential weighting of volumes within each pair in areas of signal stretching / compression.
As an aside: One consequence of acquiring all volumes with one phase encode direction, followed by another phase encode direction, is that once you correct for subject rotation between the matched volume pairs, the diffusion sensitisation gradient orientations relative to the anatomy could be quite inconsistent between the two volumes within each pair; yet we combine the volumes anyway. These subject rotations are probably of greater magnitude than the discrepancy between those two gradient vectors…
Rob