# Smoothing causes offset of portion of copied segment

I have a large segment (whole body) and I want to make a copy of this and delete everything but the head. This all works fine, except when I view the head segment and the body segment in the 3D view with smoothing turned on, the head only segment is offset by a few pixels. This is only in the 3D view and only if smoothing is turned on.

Here is body (orange) and head (blue) together, with smoothing turned off. Blue is a direct copy of orange.

Now, head and body with smoothing on, set to 0.1:

Note the shift to the right of the image of the blue segment when smoothing is turned on.

Any ideas? Thanks!

-Hollister

Are the voxels isotropic?
Ideas for investigation:

• What happens if you resample segmentation in this region to a higher resolution?
• What happens if you draw or paint in thin structures in different orientations? Is the displacement always present and in a consistent direction? For example you could paint in a sphere, hollow it so it is thin shell, and then smooth that and see what orientations lead to displacements.

One idea which comes to mind is that smoothing will tend to shrink convex areas and will tend to expand concave areas, so that could explain some net motion of a structure which is concave on one side and convex on the opposite side. However, this wouldn’t explain why two identical objects would become displaced from one another due to smoothing.

That looks to me like a bug in the smoothing. Can you reproduce it on a simpler structure?

Thanks for the ideas!

Voxels are isotropic. I’ll work on getting an example using a simpler structure.

I think I have an example that shows the issue in a simpler structure using demo data. There are two segments, a large green one and a smaller red one that is a copy of part of the large green one. When you hide/show the segments, you can see a small shift in position of the smaller red one. It is not to the same degree as the example I showed above, this is possibly due to differences in resolution - MRHead is much lower res than the micro-CT scan from my original image.

Dropbox link to MRB file below.

Any ideas and suggestions would be most welcome! Thanks!!

-Hollister

For issues like this I have always used a little 10x10x10 voxel image with some segmentation. You can find it in the SampleData module, it’s called TinyPatient. The shift will be very obvious if it’s there.

Is there a component of the smoothing algorithm which takes into account the total size of the object to be smoothed? If, for example, the bounding box size were used to normalize something, the bounding box size is quite different in both these cases.

If I turn off all smoothing on the segments @hherhold generated, the surface renderings look identical (as they should). At other smoothing factors, there are definite, but small, shifts between the surfaces. The error may show up as an error in physical dimensions or in voxel dimensions, so it makes sense to play with both of those. I’ll take a look at TinyPatient if I get a chance.

I’ve seen things like this happen in the past when data is resampled but a shift in the origin is not taken into account. Since, like DICOM, our origin is in the center of a voxel and not the corner, the origin is shifted when we resample the images to a different spacing without changing the physical size of the image bounds.

1 Like

As @mikebind suspected, the vtkWindowedSincPolyDataFilter normalizes coordinates (rescales the input to a unit cube if NormalizeCoordinates is enabled; which it is), therefore the smoothing result depends on the bounding box size. In general, the difference should be negligible, but it seems that it is possible to see a perceivable shift in real-world applications where the ROI size is very different along the 3 axes.

Disabling coordinates normalization fixes the issue, but I’ll need to check with Will Schroeder (developer of this algorithm) what other issues it may cause if we skip normalization.

1 Like

Question posted to the VTK forum:

1 Like

Thank you very much!