Mandibular Canal From CBCT: Segmentation → STL → Web Overlay

I get asked about mandibular canal work more than almost any other dental structure. Teams want the canal labeled on CBCT, turned into a mesh, and shown with the scan in a browser. That path is clear: CBCT → labels → surface → overlay.

This post walks that path only. How the stages fit together, why STL sits in the middle, and what breaks when the transform or the mesh is wrong.

If you want to manipulate the CBCT shown in this image, you can do that on our dental viewer. This sample is already loaded there.

What the pipeline actually is

The pipeline has three stages:

1. From CBCT to labelmaps. The canal (and any other structures you care about) get labeled in the volume. That can be done manually, or with an algorithmic approach such as AI-based segmentation. Either way, the output is a labelmap in the CBCT’s space.
2. 3D reconstruction of those labelmaps. Turn each label into a surface. Here you control how rough or smooth the mesh is — smoothing, hole filling, and how fine the triangulation stays.
3. Keep surfaces in the same reference frame as the CBCT. The generated meshes must live in the same coordinate system as the original volume so every segmented structure lines up with the anatomy, the same way it does on the raw slices.

After that, load the volume and the meshes in a dental DICOM web viewer. Reviewers scrub MPR, toggle overlays, and look at the canal next to bone and teeth in 3D.

Dental software teams, OEMs, and education groups often want exactly this: canal (and related structures) visible in the browser, with the scan underneath.

Why STL sits in the middle

Voxel labels are fine while you are still editing the segmentation. For a web overlay, a mesh is usually easier to ship and draw. STL is common because almost every dental and medical mesh tool can write it, and most 3D viewers can read it.

A few practical notes from pipeline work:

• Keep the transform from CBCT voxel space to mesh space. If that matrix is wrong, the canal floats off the anatomy in the viewer even when the segmentation looked fine.
• Prefer a clean closed surface for the canal when you can. Thin tunnels and broken shells make the overlay hard to read and can confuse loaders that expect manifold geometry.
• Decimate with care. Aggressive decimation shrinks file size and can also erase the thin canal shape until it no longer matches the slices underneath.

Showing the canal in a dental web viewer

Once you have meshes aligned to the volume, the viewer work is mostly integration:

1. Load the CBCT as DICOM (or a volume format your stack already supports).
2. Load the canal STL (and any other structures) as secondary objects.
3. Apply the same patient / volume coordinate frame so each mesh sits on the right anatomy in multiplanar views and in 3D.
4. Give simple display controls: opacity, color, show / hide. Reviewers need to turn an overlay off and check the raw voxels.

Want to turn meshes on and off yourself? Open the same case on our dental viewer and scrub the volume with the overlays live.

That is enough for education labs, internal review, OEM demos, and collaboration between engineering and clinical advisors. People look at the same canal geometry together, next to the scan.

Failure modes I see in real pipelines

CBCT is noisy. Metal, beam hardening, and motion leave streaks and gaps. Labels can miss a segment, thicken a wall, or invent a short bridge across an artifact. When that happens, the STL looks confident in 3D and wrong on the axial slices. Always check the overlay against MPR, not only against the pretty mesh view.

Aggressive mesh decimation is the next common break. A canal is a thin tube. Decimate like you would for a dense bone surface and you get a jagged ribbon that no longer follows the lumen. File size drops, and the overlay stops matching the anatomy.

Bad STL topology breaks overlay alignment or display. Non-manifold edges, flipped normals, duplicate vertices, and multiple disconnected shells can make the viewer reject the file, render only part of the canal, or place fragments with the wrong offset. Export settings that “fix” normals without preserving the CBCT-to-mesh transform are a quiet source of misalignment.

Also common: units. Millimeters vs voxels vs meters. One wrong scale factor and the canal is a hairline next to the jaw or a giant pipe through the face. Catch that in a smoke test before you show anyone a demo.

Where this fits in a product

Canal overlay is one building block inside a dental imaging product. Typical starting points:

• Show the canal with the CBCT in a browser so product, engineering, and advisors share the same view.
• Bundle canal with other structures (mandible, teeth, skull) as separate meshes so each can be colored, faded, or hidden.
• Ship the same overlay pattern for OEM demos and education labs without turning the whole app into a full implant-library suite on day one.

If you later need implant libraries, guide design, or other modules on top, that is additive product work. The canal path above still stands on its own: labels → surfaces → aligned overlay.

Pieces of the stack

• Labels: CBCT → canal (and related) labelmaps, manual or algorithmic.
• Mesh: label → surface → STL with a recorded transform and conservative decimation.
• Viewer: a dental / CBCT web client that loads the volume and mesh overlays together, with opacity and show / hide.

You own the UX. Keep the mesh readable against the slices, and keep the coordinate frame honest.

Concrete next step

If you are a dental software team, OEM, or education buyer and you want mandibular canal overlay in a web viewer, Contact us. Send a sample CBCT (de-identified) and say whether you already have canal labels or need that step in the pipeline. The ask is simple: canal visible with the scan in the browser, meshes in the same frame as the volume.