[MINC-users] autocrop/MincUtilties and step precision

[Alex Zijdenbos]

Hello all,

I have stumbled on something I might consider a bug in autocrop;
although it is somewhat intricate. It turns out that if one uses the
'v' specification to for instance expand a volume with a certain
number of voxels, like so:

   autocrop -isoexpand 1v <in.mnc> <out.mnc>

the actual expansion may be 2 voxels instead of one. The reason for
this is that autocrop converts the 'voxel' specification to a floating
point distance, that subsequently is used together with the step size
to (re)calculate the number of voxels for the expansion. The latter
happens in MNI::MincUtilities::compute_reshape_args:

   $count[$i] = round ($extent->[$i] / $step->[$i], 1, +1);

since the step size returned by 'mincinfo -attvalue [xyz]space:step'
has limited precision, you are likely to get a step size that looks
like this: 0.0060000000000000001249 (yes these are small voxels). What
then happens is the $count[$i] in the statement above, which is always
rounded up, ends up at the next integer value, and so in the end the
'1v' specification in the autocrop call turns into '2v' - which is
probably not what you wanted when you asked for '1v'.

There are a few ways to solve this; one suggestion would be to change
the above line in MincUtilities to something like:

   $count[$i] = round ($extent->[$i] / $step->[$i] - 1e-6, 1, +1);

thus leaving a tiny bit of slack for precision trouble. But there are
other ways, such as to treat the 'v' specification separately and not
go through all the floating point calculations in that case - somewhat
more work to do.

Suggestions?

-- Alex

PS Re: precision:

$ minc_modify_header -dinsert zspace:step=0.006 test.mnc
$ mincinfo -attvalue zspace:step test.mnc
0.0060000000000000001249

I assume this reflects the inherent precision of the variable storage
in... HDF5?