# Weasis DICOM Viewer Review: PACS Integration and Image Review > Weasis is an open-source DICOM viewer for standalone workstations and browser-linked clinical workflows. Its main strength is the range of DICOM transports, export paths and plug-in support, while deployment requires attention to authentication, source configuration and licensing. **nroduit/Weasis** — Weasis is a web-based DICOM viewer for advanced medical imaging and seamless PACS integration. - Repository: https://github.com/nroduit/Weasis - Website: https://weasis.org - Stars: 1,439 · Forks: 410 - Language: Java - License: NOASSERTION - Published: 2026-10-16 · Updated: 2026-10-16 · Language: en - Canonical page: https://hysenlabs.com/projects/nroduit-weasis ## What Weasis Handles in Clinical Image Workflows Weasis addresses a specific problem: viewing and handling medical images across local files and connected clinical systems. It is intended for healthcare professionals, research institutions and engineers who need to inspect DICOM studies in a desktop application or load them through a browser-based workflow. The README presents it as both a standalone DICOM viewer and a web-accessible viewer. The supported data types go beyond ordinary image slices. The README lists multi-frame files, Enhanced CT, MR and ultrasound volumes, SR, PR, KOS, SEG, AU, RT, ECG and Parametric Map data. It also documents codecs including JPEG, JPEG-LS, JPEG 2000, JPEG-XL, RLE and Deflated Explicit VR Little Endian. That breadth matters when a viewer must serve a mixed archive rather than a single acquisition type. Weasis also includes a Dicomizer module for converting standard images, videos, PDFs and STL meshes into DICOM files. This makes it relevant to imaging pipelines that need to prepare material for DICOM-oriented systems. The feature does not mean that every source can be handled without constraints. The README does not give a detailed conversion matrix, codec licensing notes or error behavior, so those points require verification for a specific workflow. ## How Weasis Connects to PACS and DICOMweb Weasis uses two documented integration paths. A server-side gateway such as ViewerHub can broker access to PACS or DICOMweb, handle authentication, generate manifests and expose one endpoint to the viewer. This model centralizes integration logic and reduces the amount of connection configuration placed in each workstation. The client-side path configures DICOM nodes and DICOMweb sources directly inside Weasis. The documented DICOM transport services include C-FIND, C-GET, C-MOVE and C-STORE. Its DICOMweb support covers QIDO-RS, WADO-RS and STOW-RS over HTTPS. WADO-URI is also listed for older PACS servers and the Weasis XML manifest flow. These are distinct integration models. Gateway-backed deployments keep more of the mediation layer on the server, while direct sources place the connection details in the viewer configuration. Browser and clinical-system integration uses the `weasis://` protocol, plus argument-driven launch, manifest-based study loading and downloadable manifests delivered through WADO. Authentication options include Basic authentication, OAuth 2.0 and OpenID Connect with Authorization Code with PKCE and a loopback redirect. The README names Keycloak and Google Cloud Healthcare as examples of compliant providers. It does not document default identity-provider settings, token storage or session expiry, so deployments should verify those details against the linked integration documentation. ## Installing Weasis and Starting a First Review The README directs users to the binary download page for desktop distributions and to a separate build guide for compiling the project. It lists Windows, macOS and Linux distributions, but does not include a command-line installation procedure. Therefore, there is no install command to reproduce here. For a first desktop use, download the appropriate binary distribution from the linked DICOM viewer download page, install it using the files supplied by that distribution, and open Weasis. The README also links a live demo with different datasets, which is the documented way to inspect the interface before connecting it to a clinical source. The repository is a Maven-based multi-module project, with modules including `weasis-core`, `weasis-dicom`, `weasis-imageio`, `weasis-launcher`, `weasis-opencv`, `weasis-acquire` and `weasis-distributions`. The README does not state the required JDK version, Maven version or build command, so a source build should follow the linked “How to build Weasis” documentation rather than an improvised command. The linked download and demo pages are the appropriate first steps for users who only need to evaluate the viewer. ## Desktop Viewer Capabilities and Export Paths Weasis is not limited to receiving studies from a PACS. The README documents local export as DICOMDIR ZIP, ISO with an embedded Weasis CD viewer, JPEG, PNG, TIFF, AVI and MP4. Sending is supported through C-STORE to a PACS or through STOW-RS to a DICOMweb server. These paths give an imaging team several choices for moving data between review, archive and exchange destinations. The viewer interface is described as responsive and suitable for high-DPI screens. Preferences can be configured on the server and client side, with overrides at default, workstation and user levels. This is useful for deployments that need a common baseline with local adjustments. It also creates a configuration surface that administrators must understand before distributing the application to multiple users. A plug-in API and Weasis plug-in archetype are documented for custom development. The repository layout also includes `annotations/`, `tests/` and `archetype/`, which is consistent with a component-oriented Java project. The README does not specify plug-in binary compatibility rules, supported extension versions or a complete list of maintained plug-ins. Custom integrations should therefore treat the plug-in documentation and build setup as separate compatibility checks. ## Limits for Clinical Deployment and Research Use The first limitation is operational rather than visual. Weasis can connect directly to PACS, VNA, RIS, HIS and EHR infrastructure, but the README does not provide a turnkey server configuration, identity-provider setup or production deployment recipe. A team may need to configure source endpoints, HTTPS, authentication and manifest behavior before it can use the viewer with real clinical data. The second limitation is that the feature list does not establish every interoperability outcome. DICOM support is broad, but the README does not state which transfer syntaxes are enabled in each distribution, how unavailable codecs are handled, or how the viewer reports malformed or unsupported objects. It also does not describe performance limits for large volumes, concurrent users or gateway workloads. Claims about speed, throughput and scalability would need validation outside the README. The licensing information also needs direct review. The README displays EPL 2.0 and Apache 2.0 badges and describes the viewer as open source under either licence. The repository metadata classifies the licence as Other because GitHub could not map the custom arrangement, and the root contains `LICENSE`, `LICENSE.Apache-2.0`, `LICENSE.EPL-2.0` and `3rd-party-licenses.md`. An organization should inspect those files before redistribution or integration. This article does not provide legal advice. ## Weasis Compared with a Gateway-Only Viewer The clearest alternative described by the README is a gateway-centered deployment using ViewerHub, with direct Weasis configuration as the contrasting model. ViewerHub handles PACS or DICOMweb access, authentication and manifest generation before exposing a single endpoint. This differs from configuring DICOM nodes and DICOMweb sources inside Weasis itself. Choose the gateway approach when centralized control, a common endpoint and server-side authentication are priorities. Choose direct client configuration for a standalone workstation or a smaller site without a gateway. The gateway path may reduce duplicated client configuration, but it introduces another server component to deploy and secure. The direct path avoids that component, but source and authentication settings become part of workstation administration. Weasis is therefore not simply a browser wrapper or a standalone image viewer. The project supports both deployment styles and documents desktop, portable media and web launch. The selection should follow the actual clinical architecture, not just the viewer's rendering capabilities. ## Maintenance, Releases and Upgrade Cost The repository is not archived, and the last push was on 2026-10-15. Recent release tags include v4.7.3 on 2026-08-25, v4.7.2 on 2026-08-03 and v4.7.1 on 2026-07-09. The README points to `CHANGELOG` for release history. These facts indicate recent project activity, but they do not document upgrade compatibility for every plug-in, configuration file or third-party component. The multi-module structure means an upgrade can involve more than replacing one viewer executable. Administrators may need to review changes in `weasis-core`, `weasis-dicom`, `weasis-imageio`, `weasis-launcher`, `weasis-distributions` and related plug-ins. The repository does not include a migration guide in the README, so an upgrade should begin by checking `CHANGELOG.md` and the linked documentation for affected modules and plug-ins. License review is also part of adoption cost. The presence of separate EPL 2.0, Apache 2.0 and third-party license files means organizations should identify which terms apply to the code they distribute and which obligations apply to dependencies. The README is clear about the two advertised project licenses, but the custom classification and root files should be resolved before procurement. ## Conclusion Weasis fits healthcare teams and research institutions that need desktop DICOM review alongside PACS, VNA, RIS or EHR integration. It is less suitable for a buyer who wants a hosted viewer with installation details supplied by the project itself. Verify the applicable LICENSE file, intended DICOM transport, authentication requirements, plug-in compatibility and export format before adoption. ## FAQ ### What is Weasis used for? Weasis is an open-source DICOM viewer for standalone and web-based medical imaging review. The documentation positions it for healthcare professionals and research institutions working with PACS, VNA, RIS, HIS, EHR and DICOM workflows. ### How do I install Weasis? The README links to a binary download page for Windows, macOS and Linux distributions. It also links to a build guide for source builds, but does not provide install commands or required Java and Maven versions in the README. ### Can Weasis connect to DICOMweb and a PACS? Yes. The documented client-side integrations include QIDO-RS, WADO-RS and STOW-RS over HTTPS, along with classic DICOM operations such as C-FIND, C-GET, C-MOVE and C-STORE. A gateway such as ViewerHub can also broker access and expose one endpoint. ## Sources - [Issues](https://github.com/nroduit/Weasis/issues) - [nroduit/Weasis on GitHub](https://github.com/nroduit/Weasis) - [Project website](https://weasis.org) - [README](https://github.com/nroduit/Weasis/blob/master/README.md) - [Releases](https://github.com/nroduit/Weasis/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/nroduit-weasis