New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Voxel size rounding errors when converting between formats #420

Open
bjeurissen opened this Issue Dec 14, 2015 · 5 comments

Comments

Projects
None yet
4 participants
@bjeurissen
Member

bjeurissen commented Dec 14, 2015

I get a slightly odd voxel size reporting using mrinfo on some data sets.

When I run mrinfo on the raw DICOM dir, I get:

2.4000000953674316 x 2.4000000953674316 x 2.4000015258789062 x ?

When I convert the data to mif and run mrinfo, I get:

2.3999999999999999 x 2.3999999999999999 x 2.3999999999999999 x ?

When I convert the mif to nifti and run mrinfo, I get:

2.4000000953674316 x 2.4000000953674316 x 2.4000000953674316 x ?

Where are these minute discrepancies coming from? Looks pretty harmless, but it might be confusing to end users.

@bjeurissen

This comment has been minimized.

Member

bjeurissen commented Dec 14, 2015

Does this have to do with each format using a different data type or precision to store the voxel size? If so, it is probably unavoidable, but then it might be useful to show less digits in the mrinfo command.

@jdtournier

This comment has been minimized.

Member

jdtournier commented Dec 15, 2015

Is this on updated_syntax? I assume it is, you wouldn't get the full double precision output otherwise in mrinfo... So we now store the transform using double precision throughout MRtrix3 (on updated_syntax), but as you say different formats differ in how this is stored on file. The DICOM reader will use 32 bit floats (stored on file as strings ?!? You gotta love DICOM), but since it's the first step in the chain, that wouldn't be the issue. There might be an issue with mif format not using full precision when writing out the transform matrix, which I think @maxpietsch sorted out recently (although that might not have been merged yet).

NIfTI is different again, storing the transform in floating-point format, as either a quaternion (qform) or the coefficients of the affine matrix directly (sform). I'm guessing results would differ depending on which version was used. On top of that, the sform includes the voxel scaling (it's the full voxel->world matrix), so the matrix needs to be adjusted to remove that for use in MRtrix, which might introduce further loss of precision.

So there's plenty of scope for minor discrepancies. I am surprised about the DICOM vs mif difference though. The mif format shouldn't be lossy now. Unless that commit of @maxpietsch hasn't made it to updated_syntax yet...? I can see commit bbaaec5, but that only affects mrinfo...

As to getting mrinfo to output full precision by default: I think I agree that it's probably unnecessary, 6 digits should be ample most of the time. Maybe we can use the full precision for the specific options, i.e. -vox & -transform...?

@maxpietsch

This comment has been minimized.

Member

maxpietsch commented Dec 15, 2015

bbaaec5 does increase the transformation precision for mif files link but does not touch the way the voxel size is printed or stored.

Can you check whether sed -nr '/transform|vox/p' image.mif gives you the same answer as mrinfo?

I agree that the full precision is probably not needed in the default mrinfo output. That's why I changed the output for the -transform option to full precision while the standard output is rounded:

$cat bogus.mih
mrtrix image
dim: 96,96,60
vox: 2.4000000953674316,2.4000000953674316,2.4000000953674316
layout: +0,+1,+2
datatype: Float32LE
mrtrix_version: 0.3.12-1050-g62ace960
comments: untitled
comments: transform modified
transform: 0.999986,5.4228e-08,0.00523597,-122.725
transform: -0.000737919,0.990016,0.14092,-109.461
transform: -0.00518369,-0.140922,0.990003,-32.1313
file: bogus.dat

$ release/bin/mrinfo -transform bogus.mih
  0.999986, 5.4228e-08, 0.00523597,   -122.725
-0.000737919,   0.990016,    0.14092,   -109.461
-0.00518369,  -0.140922,   0.990003,   -32.1313

$ release/bin/mrinfo bogus.mih
************************************************
Image:               "bogus.mih"
************************************************
  Dimensions:        96 x 96 x 60
  Voxel size:        2.4000000953674316 x 2.4000000953674316 x 2.4000000953674316
  Data strides:      [ 1 2 3 ]
  Format:            MRtrix
  Data type:         32 bit float (little endian)
  Intensity scaling: offset = 0, multiplier = 1
  Transform:                    1   5.423e-08    0.005236      -122.7
                       -0.0007379        0.99      0.1409      -109.5
                        -0.005184     -0.1409        0.99      -32.13
  comments:          untitled
                     transform modified
  mrtrix_version:    0.3.12-1050-g62ace960

maxpietsch added a commit that referenced this issue Dec 15, 2015

@maxpietsch

This comment has been minimized.

Member

maxpietsch commented Dec 15, 2015

Changed the precision of the voxel size output in cd56439 to 6 digits.

Can you double check that you consistently used the updated syntax versions of mrconvert and mrinfo?

@thijsdhollander

This comment has been minimized.

Member

thijsdhollander commented Dec 15, 2015

I can't really check much from where I am now, but I recall seeing (minor) loss of precision in other places as well (over at least the last year or so), such as, e.g., certain tractography parameters after they've been written to the header (comments). Things like step sizes that were requested to be exactly 0.5mm or something, but then the header (well, at least as reported by mrinfo) reads 0.4999999999 or 0.50000000001 or similar. The most obvious other times I saw loss of precision, was indeed the voxel size. I haven't consciously made the comparison between before and after Max' commits yet.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment