Smooth the surface of a segment created from stl file

Hello,

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

Untitled

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).

Hi @lassoan
I am trying to smooth vessel segments present in an stl file. I tried all the options available Median, Gaussian … with default kernel size. For some reason, all the segments disappear. Prior to smoothing, I used the island icon to retain only the largest connected component and that failed too. Could you please have a look?

This file is an artificial network (probably reconstructed from centerline detection). It is already smooth. The faceted look is just due to surface normals are not generated by default for STL files. You can go to Surface toolbox module, enable “Normals”, and Apply.

Thank you. When I use this model in the extract centerline module
after (hitting Normals) the end points are not detected. Is this because of the “artificial network”?

@lassoan I also tried to view a smaller subset of the network present in the stl file shared above . But the network extraction and centerline extraction didn’t find the properties of all the branches. Many endpoints are undetected in “Auto detect”. Could you please suggest how to get this working?

@lassoan This is a kind reminder