[Insight-developers] NRRD, NIfTI and 'same space' verification in filters.

[Matt McCormick]

Hi Kent,

On Thu, Aug 9, 2012 at 3:07 PM, Williams, Norman K
<norman-k-williams at uiowa.edu> wrote:
> I am working on the DicomToNRRD converter program, adding the ability to
> convert DICOM series to FSL DWI datasets, and FSL datasets to NRRD.

Thanks for continuing your awesome DICOM work.

>
> There is a problem with respect to the numeric precision in the NRRD
> header.
>
> The DicomToNrrdConverter regression tests converts a DICOM DWI Dataset to
> NRRD, the same data set to FSL which comprises a 4D NIfTI file, a BValues
> text file, and a BVectors FSL file.
>
> In a perfect world, my FSLToNrrd converter would take that FSL set and
> compare it to the NRRD file created from the same original DWI data, and
> they would match.
>
> This actually works if I compare the BValues/BVectors, and do
> voxel-by-voxel comparison.
>
> But I was trying to be clever, and used a pipeline of a
> SubtractImageFilter and ImageStatisticsFilter, which is where I ran into
> this problem:
>
> ERROR: SubtractImageFilter(0x7fe6c48081f0): Inputs do not occupy the same
> physical space!
> InputImage Origin: [-1.3101199e+02, -1.5218300e+02, 4.9731600e-01,
> 0.0000000e+00],
> InputImageIndexedDataObject1 Origin: [-1.3101200e+02, -1.5218300e+02,
> 4.9731600e-01, 0.0000000e+00]
>         Tolerance: 1.0000000e-06
> InputImage Spacing: [1.0000000e+00, 1.0000000e+00, 2.4000039e+00,
> 1.0000000e+00],
> InputImageIndexedDataObject1 Spacing: [1.0000000e+00, 1.0000000e+00,
> 2.4000000e+00, 1.0000000e+00]
>         Tolerance: 1.0000000e-06
>
>
> The problem is that the NRRDImageIO uses a different print precision for
> outputing floating point numbers than the DicomToNrrdConverter, and the
> difference is enough to make the origin X values off by 1.0E+5, and the
> space-checking code in the Image filters uses a tolerance of 1.0E+6.
>
> I can try and fix DicomToNrrdConverter to use the same precision, but this
> is maddening.  Any other suggestions? Is there a better way to compute
> tolerances in the Image Filters?

It seems that the precision check pointed out a real bug in this case,
and the solution is not to change how the tolerances are computed, but
to correct or not allow the loss in precision?

Thanks,
Matt