
Building a DICOM Viewer That Runs in the Browser
The engineering story behind GalaxyMed: full CBCT volumes, Curved MPR and Dental AI, running in a browser tab.
A cone-beam CT scan of a jaw is a few hundred megabytes of three-dimensional data. A dentist wants to open it, spin it around, trace a nerve canal, drop a virtual implant, and be planning treatment within a few seconds — in a browser tab, on whatever laptop happens to be in the room. That one sentence hides almost every hard problem we spent a long time solving on GalaxyMed, and it's a fair window into how we build medical software.
Why put any of this in a browser?
The classic answer to "we need to view CBCT scans" is a desktop workstation: heavy software, installed and licensed per machine, updated by hand, tied to one computer in one room. Clinics dislike maintaining it, and it quietly limits who can look at a case and from where.
A browser flips that. Open a patient study from any device, no install, with access controlled centrally. The catch is that browsers were designed to render documents, not to stream and reconstruct volumetric medical imaging in real time. Closing that gap was the whole project.
Problem one: the data is enormous
You can't simply download a full CBCT volume and hand it to the browser to decode — you'd watch a spinner while hundreds of megabytes arrive and unpack. So the viewer streams and decodes progressively: the clinician starts working with the study almost immediately while the rest fills in behind the scenes. Window/level, panning and zoom all have to stay smooth on top of data that's still loading.
Problem two: it has to be genuinely three-dimensional
A picture viewer shows slices. A planning tool shows anatomy. GalaxyMed runs a full MPR workspace — axial, coronal and sagittal views synchronized, alongside an interactive 3D reconstruction — so moving in one view moves the others, and the clinician keeps a spatial sense of the case instead of flipping through a stack of images. That means real GPU work: WebGL and WASM in the browser, and CUDA acceleration in the native desktop builds that share the same core.
Problem three: Curved MPR, where it gets clinical
This is the mode implantologists actually plan on, and it's the one that separates a viewer from a workstation. Curved MPR reconstructs the scan along the natural curve of the dental arch and turns a raw volume into a practical planning space:
- define the arch in the axial view, and the panoramic and cross-sectional slices build automatically along it;
- control the spacing between cross-sections — 1 mm, 6 mm, whatever the case needs — and the slab thickness, to reveal exactly as much anatomy as you want to see;
- trace canals, measure, draw curves and rotate the volume, with every result tied to the reconstruction.
Getting that to feel immediate — not "adjust a parameter, wait, look" — is where most of the hard engineering lives.
Problem four: AI that assists instead of distracting
On top of the imaging sits a layer of Dental AI: automatic segmentation of teeth, mandible and airway, and detection of cephalometric landmarks. The discipline here isn't only training models — it's running them so the clinician gets useful structure without the interface stalling or, worse, quietly presenting something wrong. In medicine, a confidently incorrect result is more dangerous than a slow one.
The part nobody sees: state that survives
A diagnosis isn't a single glance. Measurements, arch curves, canal tracings, rotations and 3D segmentations are all saved as part of the case, so it can be reopened weeks later and continued exactly where it was left — and handed to a second specialist who sees the same context. From there the segmented model exports to STL, so it drops straight into CAD/CAM, surgical-guide, lab and 3D-printing workflows. The viewer is one station in a longer chain, and it has to play nicely with the rest of it.
What the project taught us
Three things, really. Correctness is not a feature you add later — it's the ground floor. Performance is a clinical feature: a tool that's a beat too slow doesn't get used, and one that's unpredictable doesn't get trusted. And building one shared core that ships to both a browser and native desktop apps is worth the extra discipline it demands.
None of this is glamorous from the outside — it's a viewer that opens fast and does what a clinician expects. That's exactly the point. It's the kind of work we like: high-stakes, unforgiving and quietly hard. If you're building something in this territory, talk to us.
