[Insight-users] data-spacing in itk::Image

[Karthik Krishnan]

The Gaussian filters do take into account the pixel spacing... You can 
verify this with a minimal example and you will find that the gradient 
of the image is inversely proportional to the image spacing.

I hope you haven't overlooked the fact that "Sigma" is always specified 
in physical co-ordinates and *not* in pixel co-ordinates.

karthik



Georgi Diakov wrote:

> Hello everybody,
> It seems that the spacing in an itk::Image object is not quite a real 
> thing. I did the following experiment:
> 1. I have a binary 3D vtkImage with spacing (0.39; 0.39; 3), outlining 
> a segmented region very clearly
> 2. With vtkMarchingCubes I extract the surface of the segmented 
> region. The resulting vtkPolyData (a mesh) is dimensioned according to 
> the spacing (0.39; 0.39; 3), set in the image
> 3. Using the pipeline, I convert the vtkImage to itk::Image
> 4. From the itk::Image, I calculate a gradient map with 
> itk::GradientMagnitudeRecursiveGaussianImageFilter and 
> itk::GradientRecursiveGaussianImageFilter, as described in the ITK 
> Software Guide on page 379 (the hybrid segmentation framework).
> 5. I apply the gradient map and the mesh (converted from vtkPolyData) 
> in the deformable model as described in the ITK Software Guide
>
> Running that setup, the program bursts during the deformation.
>
> Then I increased the number of voxels in the image artificially (x- 
> and y-directions), to maintain the same dimension with spacing (3; 3; 
> 3). Now the program ran fine and the mesh was properly deformed. This 
> brought me to the idea, that the image spacing in itk is not 
> considered in the gradient calculation, thats why the resulting force 
> field is too small to cover the full surface of the mesh (which 
> corresponds to the realistic image dimesions).
>
> How to go around that problem, without the need of having isotropic 
> images with equal spacing in all directions? Artificially pumping 
> voxels into the image is not an elegant solution and costs accuracy 
> (0.39 doesn't fit an integer number of times into 3).
>
> Thanks,
> Georgi
>
> _______________________________________________
> Insight-users mailing list
> Insight-users at itk.org
> http://www.itk.org/mailman/listinfo/insight-users
>