Which open-source DICOM viewer fits which workflow
If you are choosing a viewer for a hospital, imaging network or research group, the short answer is that the OHIF Viewer suits web-first teams whose archive already speaks DICOMweb, while Weasis suits mixed PACS environments and desktop-heavy reading. The OHIF Viewer is MIT-licensed and delivered through the browser as a progressive web application, so clinicians open studies without installing software on each workstation. Weasis is dual-licensed under EPL 2.0 and Apache 2.0 and ships desktop builds for Windows, macOS and Linux, with a web mode for launching from portals.
The OHIF Viewer's advantage matters most when your archive already implements DICOMweb. It reads QIDO-RS, WADO-RS and STOW-RS through independent root URLs, and its documentation lists DCM4CHEE Archive 5.x and Orthanc among configurable archives. Check the DICOMweb data source settings against your archive version before committing, and confirm how your authentication and reverse proxy will sit in front of the viewer. The extension system and features such as multiplanar reconstruction and longitudinal measurement tracking matter when your team wants to build or customize reading workflows, which means budgeting for a developer who can maintain that configuration over time.
Weasis fits better where classic DIMSE query and retrieve still carries daily work, or where radiologists expect a full desktop application with multi-monitor calibration. It can be launched from EHR and RIS portals through the weasis:// protocol and connects to PACS, VNA, RIS or EHR either through a gateway such as ViewerHub or by configuring DICOM nodes and DICOMweb sources directly. Its support for multi-frame and enhanced CT, MR and ultrasound, SR, SEG, RT and ECG makes it a practical choice for research groups that need to inspect unusual object types. Stone Web is not a standalone viewer. It is an official Orthanc plugin option, so choose it only if Orthanc is already your archive and your users accept its interface.
Which viewer suits each scenario
This table matches five common DICOM viewing scenarios to the viewer that usually fits best, with the supplied fact behind each choice. Read each row as a starting point, then confirm the flagged items in your own archive, identity and network setup before you commit.
| Scenario | Best fit | Why, and what to confirm |
|---|---|---|
| DICOMweb-first archive with browser access for many users | OHIF Viewer | OHIF is a zero-footprint web viewer that supports DICOMweb archives out of the box, with independent QIDO-RS, WADO-RS and STOW-RS root URLs. Confirm that your archive exposes all three endpoints and how it handles authentication for many concurrent users. |
| Existing DIMSE-based PACS with desktop readers | Weasis | Weasis supports classic DIMSE query/retrieve and store alongside DICOMweb, so it can sit on an existing DICOM node configuration. Confirm which DIMSE operations your PACS enables for the desktop client and which workstation operating systems your readers use. |
| Orthanc-centred stack | OHIF Viewer or Weasis, with Stone Web as a plugin option | OHIF is documented against Orthanc as its main example, and Stone Web and OHIF are both official Orthanc plugins. Confirm which Orthanc plugins your version ships and whether your users need a browser viewer, a desktop viewer or both. |
| Research group needing extensions and segmentation rendering | OHIF Viewer | OHIF includes segmentation rendering as labelmaps and contours, a longitudinal measurement tracking mode and an extension system for custom tools. Confirm that the extensions you need exist or can be built by your team, and test segmentation output against your own data formats. |
| Team launching the viewer from an EHR or RIS portal | Weasis | Weasis can be opened from browsers and EHR or RIS portals with a single click through the weasis:// protocol, and it integrates with PACS through DICOM nodes, DICOMweb sources or a gateway such as ViewerHub. Confirm that your portal can emit the launch link and that workstations have Weasis installed and registered for the protocol. |
How the OHIF Viewer, Weasis and Stone Web each work
The OHIF Viewer, Weasis and Stone Web differ mainly in where the viewer runs and which server it expects to reach. The cards below set out each option's license, delivery model and latest cited release, so you can check the fit against your archive, your desktop estate and your research or clinical workflow.
OHIF Viewer, a browser-delivered viewer
The OHIF Viewer is a zero-footprint progressive web application from the Open Health Imaging Foundation, licensed MIT. Users open it in a browser, so nothing installs on workstations, which suits clinical and research teams that want one maintained build. It is configurable and extensible, and it reads from DICOMweb sources through independent QIDO-RS, WADO-RS and STOW-RS root URLs. Its work is primarily supported through an NIH National Cancer Institute grant (U24 CA199460). Check the release you pin, v3.13.13 published 16 October 2026, against your browser policy and your archive's DICOMweb behavior.
Weasis, a desktop and web viewer
Weasis is dual-licensed under EPL 2.0 and Apache 2.0 and ships desktop distributions for Windows, macOS and Linux. It also runs for web-based use and can be launched from browsers, EHR and RIS portals through the weasis:// protocol. It connects to PACS and VNA systems through classic DIMSE query, retrieve and store, or through DICOMweb, and it supports OAuth 2.0 and OpenID Connect against Keycloak or Google Cloud Healthcare. Weasis fits teams that need a workstation viewer with multi-monitor calibration and CD export. The release cited is v4.7.3, published 25 August 2026. Confirm the authentication setup with your identity team before rollout.
Stone Web, an Orthanc plugin
Stone Web is an official Orthanc plugin, so it is served by the Orthanc server rather than deployed as a separate application. The Orthanc licensing FAQ places the web viewer plugins under AGPLv3 or later, while the Orthanc core is GPLv3 or later. Because the viewer lives inside the server, you must plan the whole stack together, including HTTPS and a reverse proxy when the server is reachable beyond localhost. Confirm the exact plugin terms, supported browsers and feature set in the Orthanc plugin documentation before you commit. Stone Web suits teams already running Orthanc who want a viewer without adding a second service.
Archive pairing decides the viewer
Each viewer depends on how your archive exposes studies, so the archive is often the decisive input. The OHIF documentation lists DCM4CHEE Archive 5.x and Orthanc among DICOMweb archives it can be configured against, using Orthanc as its main example. Weasis can query classic DIMSE nodes as well as DICOMweb sources. Ask your PACS or VNA vendor which protocols and authentication methods they support, and test study retrieval with your largest modalities. A viewer that works with a demonstration archive may still need configuration changes against your production archive, including root URLs, certificates and access rules.
Capability comparison across the three viewers
This table compares the OHIF Viewer, Weasis and Orthanc's Stone Web plugin on delivery, archive protocols, authentication, visualization and extensibility. Where a cell reads 'confirm with the vendor', no supplied fact settles the point, so verify it against a current build before you rely on it.
| Capability | OHIF Viewer | Weasis | Orthanc Stone Web (plugin) |
|---|---|---|---|
| License | MIT | Dual-licensed under EPL 2.0 and Apache 2.0 | Orthanc web viewer plugins are AGPLv3 or later; confirm Stone Web terms |
| Delivery model | Browser-based progressive web app, zero-footprint | Desktop on Windows, macOS and Linux; also launched from browsers and EHR portals via weasis:// | Served by an Orthanc server to a web browser |
| DICOMweb (QIDO-RS, WADO-RS, STOW-RS) | Supported out of the box with independent root URLs | Supported, with QIDO-RS, WADO-RS and STOW-RS | Confirm with the vendor |
| DIMSE query and store, WADO-URI | Confirm with the vendor | DIMSE query/retrieve and store, plus WADO-URI | Confirm with the vendor |
| Authentication | Confirm with the vendor | Basic, OAuth 2.0 and OpenID Connect, tested against Keycloak and Google Cloud Healthcare | Orthanc user accounts when remote access is enabled; confirm SSO options |
| Multiplanar reconstruction, 3D and MIP | Multiplanar reconstruction, 3D viewing and MIP | Confirm with the vendor | Confirm with the vendor |
| Segmentation, whole slide, PDF and SR, longitudinal tracking | Labelmap and contour segmentation, whole slide microscopy, PDF and DICOM SR, longitudinal measurement tracking | SR and SEG display; confirm whole slide and longitudinal tracking | Confirm with the vendor |
| Multi-frame and enhanced CT, MR and ultrasound; ECG and parametric maps | Confirm with the vendor | Multi-frame and enhanced CT, MR and ultrasound, plus ECG and parametric maps | Confirm with the vendor |
| Multi-monitor calibration, CD export and extension system | Extension system for configurable builds; confirm CD export | Multi-monitor calibration; exports DICOMDIR, ZIP or ISO with embedded viewer | Confirm with the vendor |
How web and desktop delivery change clinical and research workflows
A zero-footprint browser viewer such as the OHIF Viewer changes where the software runs. Clinicians open a study from a browser, so there is no viewer to install on each workstation, and a change to the hosted application reaches users without a client upgrade. OHIF is built as a configurable progressive web application, is licensed MIT, and reads from any archive that implements DICOMweb through its QIDO-RS, WADO-RS and STOW-RS root URLs. Before you commit, confirm that your team can host, cache and update the web application, because the browser becomes the only client that every reader depends on.
A desktop viewer keeps the work that depends on local hardware and offline use. Weasis runs on Windows, macOS and Linux and supports multi-monitor calibration, which matters for readers who compare images across screens. It can export a DICOMDIR, a ZIP or an ISO with the viewer embedded for CDs, which covers patients or referring clinicians who need a disc to carry to another site. Weasis can also be launched from a browser or EHR portal through the weasis:// protocol, so a desktop install can sit beside a web workflow. Ask your radiology lead which workstations need calibrated displays and offline review, and decide per role rather than per department.
Authentication sits in a different place in each model. With a browser viewer, sign-in is enforced by the web application and by the archive, so the archive must refuse unauthenticated requests even when the viewer is the only route in. Weasis can authenticate with Basic, OAuth 2.0 or OpenID Connect, including against Keycloak. For Orthanc, the archive accepts HTTP only from localhost by default; if RemoteAccessAllowed is enabled, AuthenticationEnabled should be true with users defined in RegisteredUsers, and HTTPS and a reverse proxy are recommended for Internet exposure. An archive reached from outside the hospital network needs that hardening whichever viewer you choose, and the check belongs in your acceptance test.
What clinical and research teams each need from a viewer
Clinical reading teams care most about getting studies on screen quickly, reading them consistently, and getting images out of the building in a controlled way. Weasis is the stronger fit when radiologists and technologists work at workstations that need a native desktop application, since it runs on Windows, macOS and Linux and can be launched with a single click from a browser, EHR or RIS portal through the weasis:// protocol. Its support for multi-monitor calibration and for displaying multi-frame and enhanced CT, MR and ultrasound, along with SR, SEG and ECG, matches reading-room hardware and mixed modality worklists. Weasis can also export DICOMDIR, ZIP or an ISO with the viewer embedded for CDs, which matters where patients or referring offices still receive physical media.
- Desktop delivery: Weasis installs on reading workstations, which suits sites that prefer local applications over a browser session.
- Launch from the EHR or RIS: The weasis:// protocol opens studies from a portal with one click, which reduces context switching at the workstation.
- Multi-monitor calibration: Relevant where diagnostic display consistency is set up by local biomedical or imaging staff.
- Embedded media export: The ISO option with the viewer included matters only where physical disc distribution is still part of the workflow.
- Web delivery where desktops are restricted: OHIF is delivered as a progressive web application, so it suits sites that cannot install software on shared or thin-client machines.
Confirm with your radiology and clinical engineering leads which display hardware and workstation policies apply, and whether any local rules govern media export before choosing a delivery model.
Research and trial imaging teams usually need repeatable measurements, segmentation outputs and an audit trail of how images were analyzed. OHIF Viewer is the stronger fit here because it is built as a configurable and extensible progressive web application and includes multiplanar reconstruction, 3D viewing, MIP, segmentation rendering as labelmaps and contours, whole slide microscopy, PDF and DICOM SR rendering, and a longitudinal measurement tracking mode. Its extension system lets a research group add tools or workflows without forking the core. This advantage applies when the study needs quantitative follow-up across time points, or when a reader panel works in a shared browser environment across sites.
- Longitudinal measurement tracking: Useful for serial imaging studies where the same lesion or region is followed across visits.
- Segmentation as labelmaps and contours: Lets reviewers inspect ground-truth or model-generated masks alongside the source series.
- Whole slide and 3D tools: Relevant where a protocol includes pathology slides or volumetric reconstruction.
- Extension system: Allows a research team to adapt the interface to a protocol, provided it has developers who can maintain the extension.
- MIT license: Permits internal modification and redistribution under the license terms, which suits sponsor-funded consortia that want to inspect and change the code.
Confirm which measurement and export formats your sponsor or core lab requires, and whether the protocol needs any validation of the viewer's tools before use.
IT and platform teams running the archive care about how the viewer connects to storage, how it authenticates users and how it keeps protocols open. OHIF supports image archives that implement DICOMweb out of the box, with independent QIDO-RS, WADO-RS and STOW-RS root URLs, and its documentation lists DCM4CHEE Archive 5.x and Orthanc among archives it can be configured against. Weasis supports classic DIMSE query and retrieve and store, DICOMweb QIDO-RS, WADO-RS and STOW-RS, and WADO-URI, along with Basic, OAuth 2.0 and OpenID Connect authentication that works against Keycloak and Google Cloud Healthcare. Teams that need both DIMSE modalities and web access should plan for Weasis or a gateway such as ViewerHub.
- Separate DICOMweb endpoints: Independent root URLs let the platform team route each service and apply different access rules.
- DIMSE compatibility: Weasis matters where older modalities or PACS nodes still speak classic DICOM networking.
- OAuth 2.0 and OpenID Connect: Relevant when the identity provider is already in place and single sign-on is required.
- Archive pairing: Orthanc's official viewer plugins include Stone Web and OHIF, so teams already running Orthanc may keep the viewer on the same server.
- Gateway option: A gateway such as ViewerHub is one way to join PACS, VNA, RIS or EHR systems when direct configuration is not practical.
Confirm with the archive vendor which DICOMweb services and authentication methods are enabled in your version, and test the exact endpoints and identity flow before rollout.
How to choose and pilot an open-source DICOM viewer
This sequence moves a team from archive and protocol facts to a tested choice between the OHIF Viewer and Weasis, with a licensing and support check before any commitment.
Confirm the archive and protocols in use
The architecture lead lists every image archive the viewer must reach and records whether each one speaks DICOMweb (QIDO-RS, WADO-RS and STOW-RS), classic DIMSE query and retrieve and store, or both. The OHIF Viewer works against archives that implement DICOMweb, and its documentation names DCM4CHEE Archive 5.x and Orthanc among the archives it can be configured against. Weasis covers both DIMSE and DICOMweb, so a mixed archive estate often points toward it. The step is done when each archive has a documented endpoint type and a named owner who can confirm its configuration.
List reader groups and their devices
Clinical, research and IT stakeholders list who opens images, from which locations and on which devices. Web delivery through the OHIF Viewer needs only a supported browser, while Weasis is installed as a desktop application on Windows, macOS or Linux and can also be launched from an EHR or RIS portal through its weasis:// protocol. Record which groups need desktop features such as multi-monitor calibration, and which need access from unmanaged or shared workstations. The step is done when each reader group maps to a delivery model and a device profile that the team can test.
Decide where authentication lives
The security team decides whether users sign in to the viewer, to the archive, or to both, and which OpenID Connect provider issues their identities. Weasis supports Basic, OAuth 2.0 and OpenID Connect authentication and has been used against Keycloak and Google Cloud Healthcare. Orthanc, if it is the archive, does not accept remote HTTP connections by default and should use authentication with registered users and HTTPS behind a reverse proxy when exposed. Confirm the token flow, scopes and session lifetime with the identity owner and the viewer documentation. The step is done when a written access model names the provider, the client registration and who can read which studies.
Run a pilot with representative study types
On a test archive that holds copies of production-like data, the clinical reviewers open a defined set of study types: multi-frame and enhanced CT, MR and ultrasound, structured reports (SR), segmentations (SEG), radiotherapy objects (RT), and whole slide microscopy where the workflow includes pathology. Weasis lists support for SR, SEG, RT, ECG and parametric maps, and the OHIF Viewer lists segmentation rendering, DICOM SR and whole slide microscopy among its features. Each reviewer scores rendering accuracy, measurement tools, load behavior and any missing object type. The pilot is complete when every study type in the test set has a pass or fail result and each gap has a documented workaround or a reason to reject the candidate.
Check licensing and support paths
Procurement and legal confirm the license that applies to the chosen viewer and any components it depends on. The OHIF Viewer is MIT licensed and Weasis is dual licensed under EPL 2.0 and Apache 2.0, so both need a standard review. If the team also runs Orthanc, note that its core is GPLv3 or later and its PostgreSQL and web viewer plugins are AGPLv3 or later. Orthanc has no paid edition. Orthanc Team SRL sells deployment, configuration and development services, including pre-paid dedicated support hours valid for 12 months, quoted on request. Ask any other provider for a written scope, the support hours included and the process for upgrades. The step is done when the license review and a support quote are on file and the decision record names the viewer, its archive and the owner of each ongoing task.
Questions buyers ask before choosing a DICOM viewer
What does it cost to license OHIF Viewer, Weasis or Orthanc?
Neither OHIF Viewer nor Weasis charges a license fee. The OHIF Viewer is licensed MIT, and Weasis is dual-licensed under EPL 2.0 and Apache 2.0. There is no paid edition of Orthanc. Orthanc's core is licensed GPLv3 or later, while its scalability and cloud plugins, including the PostgreSQL and web viewer plugins, are licensed AGPLv3 or later, so confirm with counsel how those terms apply to your distribution and whether you modify the code. Your recurring costs are the infrastructure, the staff time to run it, and any paid services you buy, such as Orthanc Team SRL's pre-paid dedicated support hours, which are quoted on request.
What drives the cost of integrating a DICOM viewer?
The main drivers are the archive configuration, identity integration, the EHR or RIS launch path, and testing against real studies. Archive work covers DICOMweb endpoints or DIMSE nodes, storage and database setup, and retrieval performance. Identity work covers OAuth 2.0 or OpenID Connect with your provider. Launch work covers how users reach the viewer from the EHR, including the weasis:// protocol for Weasis. Under a fixed-scope written agreement, DeployOpen is paid for the scoped work it plans, implements, tests and documents, while your organization pays its own staff, your archive vendor if you use one, and any hosting. Ask each vendor and DeployOpen to split the quote by these components so you can see who is paid for what.
How long does DICOM viewer integration take?
No integration duration has been established for this comparison, and the time depends mainly on how many archives you connect, how complex your identity setup is, and how many clinical workflows the viewer must support. A single archive with an existing identity provider is a smaller job than several archives with a new identity provider and EHR launch. Ask DeployOpen for a fixed-scope written timeline that lists the archives, identity components, launch points, test cases and sign-off milestones, and ask your internal teams to confirm which dependencies they control.
Can an internal team set up a DICOM viewer without outside help?
Yes, a pilot can usually be run by an internal team using the documentation for each viewer, provided the team has the right skills. For the OHIF Viewer, you need DICOMweb configuration knowledge covering the QIDO-RS, WADO-RS and STOW-RS root URLs. For Weasis, you need DIMSE or DICOMweb configuration and OAuth 2.0 or OpenID Connect setup. For Orthanc, you need archive administration, including remote access settings, authentication with registered users, and HTTPS behind a reverse proxy if the server is exposed. A production rollout also needs testing, backup planning and clinical sign-off, which is where many internal teams want an outside reviewer.
What does DeployOpen need from our team to start an engagement?
DeployOpen needs access to the systems the viewer must work with, and a named owner for each decision. In practice that means read access or a test environment for the image archive, administrative access to the identity provider or a test tenant, a set of representative test studies covering the modalities you use, and the EHR or RIS launch details. You also need sign-off owners for clinical workflow, security, and the archive, who can accept test results in writing. These items are normally agreed in the written scope before work starts, so the quote can reflect what your environment already provides.
Can we change to a different DICOM viewer later?
Yes, the viewer is usually the easiest component to replace because both the OHIF Viewer and Weasis are open-source clients that read from standard archive interfaces. The cost of a switch lies mainly in the archive integration, which may need new DICOMweb or DIMSE settings, authentication changes and EHR launch updates, and in retraining users on different layouts and tools. Keeping the archive interface standard, documenting the launch configuration and keeping test studies in a reusable set will reduce the effort of any later change.
Does the choice of archive affect how securely a viewer can be deployed?
Yes, the archive and the viewer share the security boundary, so the choice affects authentication, transport and access control. Orthanc only accepts HTTP connections from localhost by default, and when remote access is enabled, its documentation says authentication should be turned on with users defined in the registered-user settings, and that HTTPS and a reverse proxy are recommended for Internet exposure. Weasis supports Basic, OAuth 2.0 and OpenID Connect, and the OHIF Viewer relies on the DICOMweb endpoints you configure. Confirm how each component authenticates users, logs access and protects data in transit before you approve a design.
How DeployOpen scopes viewer selection and integration
DeployOpen approaches DICOM viewer selection as a scoped engagement inside your own infrastructure, starting from the archives, identity setup and clinical or research workflows you already run. We plan, implement, integrate, document and support the viewer you choose, so the decision rests on your environment rather than on a generic recommendation.
How we scope
- Written scope lists which archives, DICOMweb or DIMSE endpoints, and viewers are in and out of the engagement.
- We confirm your identity provider, single sign-on requirements and how users will reach the viewer from an EHR or RIS.
- Scope names the workflows to test, such as multi-frame CT, SR, SEG or longitudinal review, before any build starts.
- Engagements are fixed-scope, so deliverables and timelines are agreed in writing before work begins.
How we build
- We deploy the chosen viewer and archive within your cloud accounts, data centers or air-gapped networks.
- Integration covers DICOMweb root URLs, DICOM nodes, authentication settings and HTTPS termination at the reverse proxy.
- Configuration is tested against sample studies that match the modalities and file types your users actually open.
- Hardening follows your security baseline, including access restrictions and the authentication settings the archive vendor documents.
How we hand over
- Documentation records the configuration, data source mappings, user access model and the tests that were run.
- Runbooks explain how to add a new archive, update the viewer and roll back a failed change.
- Handover sessions walk your engineers through operation, so your team can extend or troubleshoot the setup itself.
- Evidence for compliance assessments is organized, though auditors and certification bodies make the final determinations.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainers can cover tracking of viewer and archive releases, with upgrades tested before they reach clinical users.
- Ask us to confirm the support scope, response expectations and upgrade cadence in the written proposal.
- Security testing of the deployed viewer and archive can be scoped as part of the same engagement.
