Hi Kent, On Thu, Aug 9, 2012 at 3:07 PM, Williams, Norman K <[email protected]> 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 _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Kitware offers ITK Training Courses, for more information visit: http://kitware.com/products/protraining.php Please keep messages on-topic and check the ITK FAQ at: http://www.itk.org/Wiki/ITK_FAQ Follow this link to subscribe/unsubscribe: http://www.itk.org/mailman/listinfo/insight-developers
