Dcm2niix and mrinfo different total readout time

Dear Mrtrix community,

I was checking the read out time and the phase encoding direction for a dataset, to create the topup configuration files. I found a small discrepancy between the output of mrinfo and dcm2niix.

dcm2niix shows:
Data: time: 0.0495301 PE direction: i-
Reverse PE: time: 0.0495301 PE direction: i

mrinfo shows:
Data: time: 0.0499 PE direction: i
Reverse PE: time: 0.0495 PE direction: i-

I’m not worried about the PE direction, I think this is due to different conventions, and it doesn’t affet to the topup file. My worries are about the time, It look like a very small difference between the data and the reverse PE in mrinfo, but is this known? how this could affect to the topup process? Thanks in advance.

Best regards,

Manuel

I had a brief look at the code that handles this, and I can’t really see any obvious reasons why it would introduce errors like this, if they weren’t already in the DICOM file to begin with… Any chance you could look at the output of dcminfo -a -csa <file> for a dicom file from each series, and see what the BandwidthPerPixelPhaseEncode CSA field reports for each? Just to rule that out – although I don’t expect that dcm2niix would be getting it wrong, but you never know…

2 Likes

About this point specifically: I doubt it’ll make much difference, it’s a tiny difference, and topup can handle difference bandwidth in different directions in any case…

Hi @jdtournier ,

Thanks for your reply.

dcminfo -a -csa <file> gives me the following error: dcminfo: dcminfo: [ERROR] error reading file "../Dicom/7_DTI_Neonate_v6_pt1/1.dcm" after few entries. Then I removed the flag -a and I found that the BandwidthPerPixelPhaseEncode for the diffusion data and the reversed image is 20.032000. The same as in the .json files obtained from dcm2niix (20.032). I usually generate my topup_config.txt file by hand using the same values for the raw data and the reversed.

Best regards,

Manuel

OK, I wouldn’t mind taking a look at this file if it’s generating an error when reading with -a.

More to the point: it’s a matter of concern that the same values in both acquisitions give rise to different values in the PE table. Can you confirm both images have the same dimensions too…?

Hi,

I’ll check the best way to send you the images, and I let you know.

Can you confirm both images have the same dimensions too…?

I was checking this and I found something that maybe could be related with this:

when I run mrinfo in the raw image, converted to dicom using dcm2niix:

************************************************
Image:               "8018-750.nii.gz"
************************************************
  Dimensions:        128 x 128 x 56 x 72
  Voxel size:        2 x 2 x 2 x 3.4
  Data strides:      [ -1 2 3 4 ]
  Format:            NIfTI-1.1 (GZip compressed)
  Data type:         signed 16 bit integer (little endian)
  Intensity scaling: offset = 0, multiplier = 1
  Transform:                    1           0   -3.16e-13      -121.1
                                0           1  -2.924e-11      -165.1
                         3.16e-13   2.924e-11           1      -65.28
  comments:          TE=78;Time=135201.870;phase=0;mb=2

Now mrinfo in the same image, in the dicom file:

mrinfo: [done] scanning DICOM folder "../Dicom/7_DTI_Neonate_v6_pt1/"
mrinfo: [100%] reading DICOM series "DTI_Neonate_v6_pt1"
mrinfo: [WARNING] Number of entries in mosaic slice timing (101) does not match number of images in mosaic (56); omitting
************************************************
Image:               "ANONYMISED (8018) [MR] DTI_Neonate_v6_pt1"
************************************************
  Dimensions:        128 x 128 x 56 x 72
  Voxel size:        2 x 2 x 2 x ?
  Data strides:      [ -1 -2 3 4 ]
  Format:            DICOM
  Data type:         unsigned 16 bit integer (little endian)
  Intensity scaling: offset = 0, multiplier = 1
  Transform:                    1           0   -3.16e-13      -121.1
                                0           1  -2.924e-11      -165.1
                         3.16e-13   2.924e-11           1      -65.28
  EchoTime:          0.078
  FlipAngle:         90
  PhaseEncodingDirection: i
  RepetitionTime:    3.4
  TotalReadoutTime:  0.0499
  dw_scheme:         0,0,0,0
  [72 entries]       0,0,0,0
                     ...
                     0.50580150000000001,-0.34587522999999998,0.79027528000000002,750
                     -0.27290904999999999,0.17999113999999999,0.94505238999999996,750

Now for the phase encode reversed:

Nifti:

************************************************
Image:               "8018-REV.nii.gz"
************************************************
  Dimensions:        128 x 128 x 56 x 3
  Voxel size:        2 x 2 x 2 x 3.4
  Data strides:      [ -1 2 3 4 ]
  Format:            NIfTI-1.1 (GZip compressed)
  Data type:         signed 16 bit integer (little endian)
  Intensity scaling: offset = 0, multiplier = 1
  Transform:                    1  -4.897e-12   -3.16e-13      -121.1
                        4.897e-12           1  -2.924e-11      -165.1
                         3.16e-13   2.924e-11           1      -65.28
  comments:          TE=78;Time=135132.263;phase=1;mb=2

Dicom:

mrinfo: [done] scanning DICOM folder "../Dicom/6_DTI_Neonate_v6_rev/"
mrinfo: [100%] reading DICOM series "DTI_Neonate_v6_rev"
************************************************
Image:               "ANONYMISED (8018) [MR] DTI_Neonate_v6_rev"
************************************************
  Dimensions:        128 x 128 x 56 x 3
  Voxel size:        2 x 2 x 2 x ?
  Data strides:      [ -1 -2 3 4 ]
  Format:            DICOM
  Data type:         unsigned 16 bit integer (little endian)
  Intensity scaling: offset = 0, multiplier = 1
  Transform:                    1  -4.897e-12   -3.16e-13      -121.1
                        4.897e-12           1  -2.924e-11      -165.1
                         3.16e-13   2.924e-11           1      -65.28
  EchoTime:          0.078
  FlipAngle:         90
  MultibandAccelerationFactor: 1
  PhaseEncodingDirection: i-
  RepetitionTime:    3.4
  SliceEncodingDirection: k
  SliceTiming:       3.33249998,0,3.4525001,0.1175,3.56999993,0.237499997,3.69000006,0.357499987,3.80999994,0.474999994,3.92750001,0.595000029,4.04750013,0.712499976,4.16499996,0.832499981,4.28499985,0.952499986,4.40500021,1.07000005,4.52250004,1.19000006,4.64249992,1.3075,4.76000023,1.42750001,4.88000011,1.54750001,5,1.66499996,5.11749983,1.78499997,5.23750019,1.90499997,5.35750008,2.02250004,5.4749999,2.14249992,5.59499979,2.25999999,5.7125001,2.38000011,5.83249998,2.5,5.95249987,2.61750007,6.07000017,2.73749995,6.19000006,2.85750008,6.30999994,2.9749999,6.42749977,3.09500003,6.54750013,3.2125001
  TotalReadoutTime:  0.0495
  dw_scheme:         0,0,0,0
                     0,0,0,0
                     0,0,0,0

It looks like the MultibandAccelerationFactor is 1 in the reversed image (obtained from the dicom) and 2 from the nifti. Could be this the reason?

Best regards,

Manuel

I don’t see how it could. But it is odd that there’s no such entry for the first dataset (when read straight from the dicom), but it’s there for the second one; and that dcm2niix reports both as MB 2, whereas we report it as MB 1 (or not at all…).

I reckon it would be good to have a look at it if that’s possible…

I’m not worried about the PE direction, I think this is due to different conventions, and it doesn’t affect to the topup file.

It will affect “the topup file”, but it won’t affect the efficacy of the EPI distortion correction in your use case. The estimated inhomogeneity field will simply be negated with respect to reality.

Id be pretty confident in saying that the dcm2niix directions will be the correct one. MRtrix3 has some additional complexities that make tracking of phase encoding direction convenient for users, but a nightmare for me. Sadists may take pleasure in this GitHub issue, which describes the testing done to get this all correct for the next update.

My worries are about the time, It look like a very small difference between the data and the reverse PE in mrinfo, but is this known?

There is some degree of ambiguity in the definition of “total readout time”. See e.g. this page. Relevant MRtrix3 code is here.

There is some chance that the reversed phase encoding direction contains one more/less k-space line, but this depends on exactly how said reversal is achieved.

how this could affect to the topup process?

Given it’s a 0.1% difference, if this difference were indeed erroneous, it’s likely much smaller in magnitude than the other uncertainties in the field estimation process.

It looks like the MultibandAccelerationFactor is 1 in the reversed image (obtained from the dicom) and 2 from the nifti. Could be this the reason?

MultibandAccelerationFactor is computed based on the slice timing vector. The latter is absent from the first image, and therefore the former cannot be computed and is not reported.


It would indeed be useful to have access to these raw DICOMs to have a poke and prod around.

Rob

Hi @jdtournier and @rsmith,

Thanks for your answers. Sorry for the delay on this. I can send you a sample data. What would be the best way to do this? The only thing is that the data can not leave the EU without filling an approval form.

Best regards,

Manuel

OK, then it sounds like it’ll need to come to me… although I’m not sure whether the UK is still technically considered part of the EU…? :roll_eyes:

In any case, any file transfer service you think is appropriate would be fine. Send it to my gmail address (jdtournier@gmail.com) or if that’s an issue, my KCL address (jacques-donald.tournier@kcl.ac.uk).

Hi @jdtournier,

I sent you an invitation to download the data by mail to your KCL address .

Best regards,

Manuel

1 Like

OK, issue turns out to be that the main dataset is in Siemens mosaic format, while the revPE dataset isn’t… We need to fix the computation of the total readout time based on the actual matrix size, not the matrix size of the DICOM image itself (which is 1024 rather than the actual 128 in your case).

Should be a trivial fix, I’ll try to get that done ASAP.

Thanks for the report! :+1:

2 Likes