Smooth the surface of a segment created from stl file


I tried to use median smoothing in Segment Editor on a segment node created from an stl input.

However, after ~15 min smoothing task didn’t complete.

Could someone look into it?
I am trying to smooth this segment for using in VMTK’s extract centerline module. When I use this geometry without smoothing (i.e the segment node generated from original input), I am not able to extract centerlines.

All of these meshes are pretty bad quality: their surface is not smooth, they have unnecessarily small cells, and they contain lots of mesh errors.

For example, “Supplemental STL File 1.stl” has over 1500 non-manifold edges. I’ve tried to fix them using MeshLab but this file made MeshLab crash. The only way I could do something with it was to remesh it completely (load it as a segmentation, create binary labelmap representation, make that the master representation, and create closed surface representation).

“Supplemental STL File 3.stl” is much better. On that I was able to run Extract centerline module without any cleaning or fixing.

Thanks a lot for looking into this.

I created a binary labelmap representation of “Supplemental STL File 3.stl” to identify the image spacing.
Untitled .

The units are in mm. I would like to know if these units correspond to the actual dimensions of the geometry present in the stl file. For instance, is it safe to consider that the values obtained in the quantification results table of extract centerline module are in mm?

Extract centerline module reports results in the same unit as the point coordinates in the STL file. If those point coordinates are in millimeter then the radius is in millimeter, too.

Could you please suggest how to check for the units of point coordinates of the imported STL file in Slicer?

One of the big issues with STL files is that there is no standard way of specifying what unit is used for point coordinates.

Unless you have an object of known size in the image, you need to ask the producer of the STL file. For 3D printing of objects at real-life size, most common units are mm (this is Slicer’s assumption) and m, but sometimes inch or tenth of an inch is used, and of course any arbitrary scaling factor can be used.

1 Like

Hi @lassoan

When I load the multiframe tiff associated with the geometry in STL File3, I find the following Volume information


and I also have the information that scale of these images: 1 px = 2.31 μm from the associated study.

Should I replace default x = 0.352 mm,y=0.352 mm,z =1 mm in image spacing (displayed in Volume information) with x=2.31 um, y=2.31 um, z=2.31 um

May I know how to interpret the units of the quantification results using the above information?

0.352mm/pixel corresponds to 72dpi, which is probably some default value in the TIFF file writer. So, replacing spacing values by 2.31 would make sense. Then you would get all your results in micrometer unit. Note that Slicer would display mm as unit (unless you change the length unit name in application settings, but there are some limitations related to this - see details here).