// the find
nroduit/Weasis
Weasis is a web-based DICOM viewer for advanced medical imaging and seamless PACS integration.
Weasis is a Java/OSGi-based DICOM viewer that runs as a desktop app (Windows, macOS, Linux) and can be launched from a browser via a custom protocol handler. It targets radiologists, PACS administrators, and institutions that need a free, standards-compliant viewer without a commercial license. It's been around long enough to have serious feature depth — MPR, volume rendering, ECG, RT structures, structured reports — which puts it well beyond a toy project.
The protocol coverage is genuinely thorough: DIMSE (C-FIND/C-GET/C-MOVE/C-STORE), DICOMweb (QIDO-RS/WADO-RS/STOW-RS), WADO-URI, and OIDC/OAuth2 with PKCE — that's the full stack most hospital integration projects actually need. The OSGi plugin architecture (via the archetype module) means you can add custom tools without forking the core, which is rare in open-source medical viewers. The pixel pipeline is production-grade: gantry-tilt correction in oblique MPR uses backward mapping with trilinear interpolation, and the lossy compression indicator surfaced in the information overlay is a small but clinically important detail that most viewers skip. SonarCloud gates on the main branch and SBOM-tracked dependencies are table stakes now, but it's still good to see them enforced rather than aspirational.
It's a Swing desktop application in 2026 — the 'web-based' claim in the description is misleading; it's a desktop app launched from a browser via a custom URL scheme, not a browser-native viewer. Anyone expecting something like OHIF or Cornerstone running in a tab will be surprised. The OSGi build (Felix/Karaf or similar, given the bundle structure) makes the development setup non-trivial — getting a working build environment is a multi-step process that the README punts to an external docs site. The plugin API is documented but the archetype is basic; if you need to hook into the image pipeline rather than just add a toolbar button, you're reading source code. Test coverage appears concentrated on the identity and pixel/LUT pipeline; the actual rendering and layout code — the parts most likely to produce subtle bugs — are conspicuously absent from the test surface.