Mrtrix 3.0.3 import broken, 3.0.2 fine?

I am trying mrtrix 3.0.3 and it looks like the data import for philips data may be broken?
What I show left and right is the exact same data, on the same computer (CVL at Monash).
As you can see it looks very different (it looks the same if I use mrconvert first), you can see the value at the location [77 65 58 0] is different.

Now I don’t know where the error is, the specific installation or a mrtrix version issue?
Anyone who can test the data on another MRtrix 3.0.3 installation?
Happy to share some data to test on a different computer?

Hi Mark,

We make changes to the DICOM handling every so often as issues get reported, and that can sometimes affect what you get. There have been recent changes that affect the order of the volumes on Phillips data, I expect that’s what you’re seeing. The b=0 volume for some reason ends up last with the recent changes. Try comparing the data offset by one volume, it’ll hopefully match. If that’s not the case, please let us know and we can take a look.

In case you’re worried how that might affect your analysis: it shouldn’t make any difference as long as the DW scheme (bvecs/bvals) matches up correctly – which it should. The bigger problem on Phillips is the potential presence of a synthetic trace-weighted image that often gets added at the end of the series – it’s quite difficult to detect correctly, and you may need to strip it out manually (though that will hopefully no longer be required with the changes below).

On top of that, there are more changes in the pipeline that will affect Phillips data – they’re not yet merged to master, but it shouldn’t be long now…


Hi Donald
Nope, that’s not it. The imported data is really broken.

Ah, yes, that’s not right. It looks like this issue, recently reported also for Phillips data. If that’s the case, the fix is just waiting to merge as part of the pull request I linked to above. If you’re happy to share the data with me, I can take a look.

What I hadn’t realised was that this wasn’t an issue with 3.0.2 – I’ll look into what changed between the two versions to figure out what we did differently. I have a battery of test data that I use to verify that everything works as expected when I make changes to the DICOM handling, so I’m surprised I wouldn’t have picked this up if there had been such an obvious a regression… :grimacing:

no worries, I send you a PM, happy to contribute to your test library with an unusual dataset…

Hi Mark,

Thanks for the data. I can confirm it’s messed up in 3.0.3, and not with 3.0.2, as you stated. It’s fine with the changes that are pending on this pull request (full details actually on this one for anyone who’s interested) – though the order of volumes is different, as I mentioned earlier.

After a bit of investigation, it turns out the problem was introduced in this commit, which tried to simplify the handling a bit, but that ended up picking up the wrong InstanceNumber entry in your specific dataset. Since this is the last line of defence for sorting the slices (everything else is otherwise identical between volumes), this ends up messing up the sorting.

The reason why we end up picking the wrong InstanceNumber is that there are actually 3 such tags in your data. For example, this is what I can see for one slice (file) in your dataset:

dcminfo -a DICOM/ | grep InstanceNumber
[DCM] 0020 0013 IS        2     1134     InstanceNumber                       0 
[DCM] 0020 0013 IS        4     2598   InstanceNumber                         108 
[DCM] 0020 0013 IS       10     5428     InstanceNumber                       522119740 

but only the middle one is the right one… The first one is nested within a standard DICOM ReferencedPerformedProcedureStepSequence sequence, while the last one is nested within a private Philips-specific Sequence (with tag 2001 9000, I don’t actually know what that corresponds to). I can get it to work if I also ignore tags nested within private (non-standard sequences), which can be done with this change at line 38 in core/file/dicom/image.cpp (in the 3.0.3 branch):

           // ignore anything within IconImageSequence:
           if ( ==  0x0088U && seq.element == 0x0200U)
+          // ignore anything within sequences with unknown (private) group:
+          if ( & 1U)
+            return;

I’m considering adding this to the master branch as well, but I’ll need to check that this doesn’t break anything else first…

Part of the (many) intricacies of DICOM parsing is that manufacturers like to put important parameters in different places, sometimes as top-level items, sometimes nested within other Sequences, and these things change between versions of the same manufacturers’ software (and even more so across manufacturers). Here, they’ve used a standard DICOM tag in multiple places, and we need to figure out which of them is relevant – and to do so in a way that works across manufacturers and scanner variants. Unfortunately, it’s very much a process of trial-and-error, and so the only way to ensure things keep working correctly is by testing on as many real-world datasets as we can get our hands on – therefore: a big thanks for adding to my pile of test data!

All the best,

Thanks Donald for letting me know.
So for now I don’t work on fixing the massive installation.
Yes I can imaging data import is a nightmare.

1 Like