Download Weasis DICOM Viewer

Installation Methods

• Manual Installation (Native Installers)
• Automatic Updates (Package Managers)

Prerequisites

Weasis runs on Windows, macOS, and Linux without requiring additional frameworks like Java. However, certain graphics capabilities are needed for Volume Rendering.

Native Installers

Download standalone installers for manual installation:

For older releases, visit these repositories:

• GitHub Releases - Latest releases
• SourceForge - Legacy repository (older than v3.5.1)

Stay Updated: Subscribe to our Google Group and select “Email” to receive release notifications.

Package Management Systems

Install via package managers to receive automatic updates.

Windows

• Microsoft Store
• Windows Package Manager (winget)

  winget install WeasisTeam.Weasis

• Chocolatey

  choco install weasis

  Ideal for enterprise deployment with PowerShell, CHEF, or Puppet

macOS

• Homebrew (Intel & Apple Silicon)

  brew install --cask weasis

Linux

• Flathub (x86_64 & arm64)

  flatpak install flathub io.github.nroduit.Weasis

• Snap Store (x86_64 & arm64)

  sudo snap install weasis

• Arch Linux (AUR)

  yay -S weasis-bin

Embedding in dcm4chee

This page explains how to integrate Weasis with dcm4chee-arc-light using weasis-pacs-connector. To launch Weasis without the connector, follow the alternative instructions.

Follow these steps for the integration with weasis-pacs-connector:

1. Install dcm4chee, if not already done (Installation with Docker is straightforward).

2. Go here and download weasis-pacs-connector.war — See Configuration Matrix below for the recommended version according to your dcm4chee-arc-light version.

3. Open the WildFly management console (at http://<your-host>:9990). Note: with some Keycloak versions, the management console may not be accessible.

   • Select the “Deployments” tab
   • Add weasis-pacs-connector.war using the “Add” button (Choose Upload a new deployment or select Replace when the file already exists)
     Note

     Alternatively one may deploy the .war using JBoss Command Line Interface Console.

4. Configure weasis-pacs-connector (optional if default settings are sufficient).
   The default configuration is stored in two files inside weasis-pacs-connector.war. To override the default configuration:

   • Download the current download>weasis-pacs-connector.properties and download>dicom-dcm4chee-arc.properties (configuration of the dcm4chee archive)
   • Edit the configuration as needed. For example, dcm4chee may be running on a different computer than Weasis, or the AE Title of dcm4chee may have been changed. If so, edit weasis-pacs-connector.properties or dicom-dcm4chee-arc.properties (Change pacs.host, pacs.port, and pacs.aet).
   • Copy weasis-pacs-connector.properties and dicom-dcm4chee-arc.properties into $WILDFLY_HOME/standalone/configuration (where $WILDFLY_HOME is the path of the running Wildfly).
     With the docker installation use the docker copy command ($ docker cp …)
     Tip

     Instead of copying the files into $WILDFLY_HOME/standalone/configuration, JBoss Command Line Interface Console can be used to override files in the war. Add the two configuration files with the deployment-overlay command:
     

     deployment-overlay add --name=dcm4chee-arc --deployments=weasis-pacs-connector.war --content=WEB-INF/classes/weasis-pacs-connector.properties=/tmp/weasis-pacs-connector.properties,WEB-INF/classes/dicom-dcm4chee-arc.properties=/tmp/dicom-dcm4chee-arc.properties --redeploy-affected

   • To apply the new configuration, from the management console “Disable” weasis-pacs-connector.war then “Enable”

5. To activate Weasis in the dcm4chee-arc-light user interface (See also Invoke Image Display in dcm4chee): you need to add attributes by either editing docker-compose.env (from 5.22.0) or from the left menu Configuration > Devices > dcm4chee-arc > Extensions > Edit extension > Child Objects > Web Applications > DCM4CHEE:

   • Configure the URL for a view button at patient or study level and then copy the properties from Configuration Matrix.
     • From dcm4chee-arc-light 5.10.2 to 5.19.0, the left menu: Configuration > Devices > dcm4chee-arc > Extensions > Archive Device
     • From dcm4chee-arc-light 5.19.1 the left menu: Configuration > Devices > dcm4chee-arc > Extensions > Edit extension > Child Objects > Web Applications > DCM4CHEE
     • From dcm4chee-arc-light 5.22.0 by editing docker-compose.env (allows applying properties at deploy time). Note: the character & must be escaped (e.g., IID_STUDY_URL=../../weasis-pacs-connector/weasis?studyUID={{studyUID}}\\&access_token={{access_token}})
       Note

       URL parameters

       • access_token is necessary in secure mode (secured RESTful services) from dcm4chee-arc-light 5.15.1
       • _self avoids opening a new empty window in the browser
         
   • InfoOptional Add other properties in the URL.
   • Refresh the web page and the view button should appear as in the screenshot above
   • To launch the viewer from the web portal, the client computer must have installed the Weasis package.

Configuration Matrix

dcm4chee-arc-light 5.10.2 to 5.19.0

Unsecured Mode

Secured Mode (from 5.15.1)

dcm4chee-arc-light 5.19.1 to 5.22.1

Unsecured Mode

Secured Mode

dcm4chee-arc-light 5.22.2 to 5.30.x

Unsecured Mode

Secured Mode

dcm4chee-arc-light 5.31.0+

Unsecured Mode

Secured Mode

Weasis Web Protocol

The Weasis Protocol enables the launch of Weasis (starting from v3.6.0) in a web context using a specific URI scheme: weasis://?commands.

How to Use the Weasis Protocol

To launch Weasis from various contexts:

1. From a Web Page: Create a link that begins with weasis://? (see below How to build an URI).
   If certain web frameworks (e.g., WIKI) or contexts only support HTTP protocols, you can use a URL redirection starting with https://. A tool such as Weasis PACS Connector can help with this.
2. From the Command Line: Utilize the appropriate Weasis command from the terminal:
   ​

   Windows Linux macOS

   start weasis://?%24dicom%3Aget+-w+%22https%3A%2F%2Fnroduit.github.io%2Fdemo-archive%2FLumbar%2Fmf.xml%22

   xdg-open weasis://?%24dicom%3Aget+-w+%22https%3A%2F%2Fnroduit.github.io%2Fdemo-archive%2FLumbar%2Fmf.xml%22

   open weasis://?%24dicom%3Aget+-w+%22https%3A%2F%2Fnroduit.github.io%2Fdemo-archive%2FLumbar%2Fmf.xml%22

How to Build a URI

The weasis://? URI scheme allows you to launch Weasis directly from the system’s URI handler. By constructing the correct URI path, you can execute Weasis commands to load images or perform other actions.

Weasis PACS Connector can dynamically generate manifests (listing references for images to load) and build the required URI through an API. This tool also manages user preferences and other launch parameters.

If you’re not using the Weasis PACS Connector, you can build a URI manually by following these steps:

1. Choose Commands: Select one or more commands to execute.
2. Encode the Commands: Use a URL encoder to format the commands correctly for URI inclusion.
3. Prefix the Commands: Add the weasis://? scheme at the beginning of the encoded command string to create the final URI.

Example: Loading a Remote Image

1. Use $dicom:get to load an image from URL

   $dicom:get -r "https://nroduit.github.io/demo-archive/us-palette.dcm"

2. Format the URI path with a URL encoder

   %24dicom%3Aget+-r+%22https%3A%2F%2Fnroduit.github.io%2Fdemo-archive%2Fus-palette.dcm%22

3. Make the final URI by adding “weasis://?” at the beginning Open the remote image

Examples to Load Images

If you use weasis-pacs-connector, please refer to Launch Weasis.

• Use $dicom:get to load a static XML manifest containing direct links (without WADO server) Launch

  $dicom:get -w "https://nroduit.github.io/demo-archive/Lumbar/mf.xml"

• Use $dicom:rs to load DICOM files with DICOMWeb RESTful services (see other examples) Launch

  $dicom:rs --url "https://demo.orthanc-server.com/dicom-web" -r "patientID=5Yp0E"

• Use $dicom:get to load an image from URL and remove all the previous images if Weasis is already open Launch

  $dicom:close --all $dicom:get -r "https://nroduit.github.io/demo-archive/us-palette.dcm"

• Use $dicom:get to load multiple local folders and a remote image Launch

  $dicom:get -l "D:/DICOM/Overlay" -l "D:/DICOM/Shutter" -r "https://nroduit.github.io/demo-archive/us-palette.dcm"

• Use $image:get to load a non DICOM image Launch

  $image:get -u "https://user-images.githubusercontent.com/993975/59107662-6c9ed300-8939-11e9-83ee-28f2725f4ae1.jpg"

Modify the Launch Parameters

The command for modifying the configuration at launch is $weasis:config which can have different arguments:

• cdb is the Weasis web context (The URL of weasis-native.zip package in ViewerHub). If the value is null, the weasis version installed from the native installer is used. In the weasis-pacs-connector configuration, the default value is defined by weasis.base.url.
• arg is an argument for the launcher. The value must start by $, like arg="$dicom:close –all" (Note: the value can also be directly in the base URI, outside $weasis:config). Single-valued argument but can be specified multiple times.
• pro is a property for the launcher containing a key and a value separate by a space. Single-valued property but can be specified multiple times.
• auth is the web authorization parameter
• wcfg is the URL the remote Weasis configuration service.

Here are some examples that modify the launcher properties without using weasis-pacs-connector:

• Configuration for launching Weasis Dicomizer Launch

  $weasis:config pro="felix.extended.config.properties file:conf/dicomizer.json" pro="gosh.port 17181"

• Change the user, by default, is the one of the current system session. The local preferences are associated to a user. Launch

  $weasis:config pro="weasis.user user2"

Enterprise Deployment: Browser Protocol Configuration

By default, Weasis registers the weasis:// protocol through standard OS mechanisms. To ensure a seamless user experience in institutional environments, administrators can suppress the browser’s security confirmation dialog using central policies.

Official Documentation:

• Chrome Enterprise Policy List
• Microsoft Edge - URLAllowlist
• Mozilla Policy Templates

Windows Registry Editor Version 5.00

; Chrome
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome\URLAllowlist]
"1"="weasis://*"

; Chromium
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Chromium\URLAllowlist]
"1"="weasis://*"

; Microsoft Edge
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Edge\URLAllowlist]
"1"="weasis://*"

; Firefox
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Mozilla\Firefox\WebsiteFilter\Exceptions]
"1"="weasis://*"

{
  "URLAllowlist": ["weasis://*"]
}

{
  "policies": {
    "WebsiteFilter": { "Exceptions": ["weasis://*"] }
  }
}

<key>URLAllowlist</key>
<array>
    <string>weasis://*</string>
</array>

Building Weasis

These instructions guide you through building Weasis directly from its GitHub repository. For IDE-based builds, refer to the Weasis plugin development guidelines.

Prerequisites

1. JDK 25 or higher
2. Maven 3.8.1 or higher
   If your computer is behind a proxy server, refer to the Maven proxy configuration guide.
3. Git

Getting the Source Code

In order to clone the repository, install Git and either use a graphical client or run the following command in a terminal:

git clone https://github.com/nroduit/Weasis.git

Building All Plugins

• Navigate to the root directory of the cloned Weasis repository, compile and install all plugins into the local Maven repository:

  mvn clean install

• Package weasis-native.zip (located in target/native-dist/), since Version4.0.0 :

  mvn -P compressXZ -f weasis-distributions clean package

  Tip

  -P compressXZ: Option for compressing the packages in xz, only from Weasis 3.6.0. The compression pack200 is not supported anymore (removed from Java 14), before 3.6.0 the profile was -P pack200.
  

  Tip

  -P purgeI18nPackage: Option to delete the translation package in the local maven repository (active by default). To disable this option, add - before the profile:

  mvn -P compressXZ,-purgeI18nPackage -f weasis-distributions clean package

  Warning

  For production, the version must not include SNAPSHOT (as packages with a SNAPSHOT are always downloaded, not cached). To remove SNAPASHOT or create your own release (use a specific name to prevent package conflicts in the cache), update the changelist property. From the Weasis root folder, execute:

  mvn -Dchangelist=-mybuild-beta clean install
  mvn -Dchangelist=-mybuild-beta -P compressXZ -f weasis-distributions clean package

Building native binaries and installers

Starting with Version4.0.0, the native installer has fully replaced the portable and Java WebStart distributions.

The official build process is executed via GitHub Actions using GitHub-hosted runners across Linux, macOS, and Windows.

However, you can also build the native binaries and installer locally using the package-weasis.sh script. This process is not guaranteed to work on all systems, as it requires proper configuration of multiple tools. Refer to the jpackage prerequisites for more details.

• Obtain the weasis-native.zip file, extract the archive, and navigate to the root folder in a Bash prompt.
• Run the following command to build the native binaries and installer:
  ​

  Bash

  ./build/script/package-weasis.sh --jdk "/home/.jdks/openjdk-25"

Guidelines

Weasis Plugin Development

This page describes the necessary configurations to be able to debug Weasis using an IDE. For developers who want to create new plugins, you can visit How to build and install a plugin.

We recommend the use of IntelliJ IDEA because the following instructions are based on it. Nevertheless, it is possible to use other IDEs by configuring weasis-launcher with similar instructions described in Add a launcher.

Prerequisites

1. Install IntelliJ IDEA (Community or Ultimate Edition 2024.3 or higher)
2. Use JDK 25 or higher and set the language level to SDK Default in File > Project Structure… >.
   Required Maven version is 3.8.1 or higher.
3. In File > Settings… > Plugins install google-java-format plugin from Marketplace and enable it from google-java-format Settings

Code style and convention

Weasis uses google-java-format as coding conventions. The format can be applied by Maven through the Spotless plugin or from the IDE (by importing the IntelliJ Java Google Style file). Formatting code with an IDE is not 100% compatible with Spotless, so it is better to use the latter before submitting new commits. This guarantees identical code formatting regardless of the system or code editor used.

• From Maven command: mvn spotless:apply
• From the Maven panel

Getting the source and building Weasis

• Getting the Source
  • For an external Git client, see Building Weasis.
  • From IntelliJ IDEA: New > Project from Version Control…
    • In the Get from Version Control dialog, select the menu Repository URL and enter the following URL: https://github.com/nroduit/Weasis.git (public repository)
• Building Weasis plugins
  • In the maven panel, select clean/install in Lifecycle of weasis-framework (root) to compile and to install all the plugins in the local Maven repository.

Add a launcher

For running or debugging Weasis, you need to create a launcher:

• Open Run > Edit Configurations…

• Create a new Application

  • Select weasis-launcher as a module (field starting by -cp)
  • Main Class: browse org.weasis.launcher.AppLauncher
  • Click on Modify Options
    • Select Add dependencies with “Provided” scope to classpath
    • Select Do not build before run
    • Select Add VM Options and enter -Xms64m -Xmx768m -Dgosh.port=17179
  • Working Directory: remove the current value and add %MODULE_WORKING_DIR% from the Insert Macros button
    Note

    As the default build task has been removed it is necessary to apply the Maven command install on modules with modified code before launching the Run or Debug mode.
    Keeping the build task and delegating the build to Maven does not seem configurable for a multi-module project, see this issue.

• Examples of launching parameters by entering values in the Program arguments text box

  • Loading DICOM files from a local path:

    $dicom:get -l \"D:\images test\dicom\"

    Note

    Some command interpreters need to escape the quotes or double quotes required for paths or URLs. This is the case with IntelliJ IDEA or Eclipse.
    For more commands at startup see also Weasis commands.

    Warning

    In Eclipse launcher parameters, ‘&’ within URLs needs to be escaped with a backslash.

• Examples of other VM options for overriding the default Preferences

  • Removing the possibility of exporting DICOM: -Dweasis.export.dicom=false
  • Defines a new user (for getting specific preferences): -Dweasis.user=user1
  • Examples with specific configuration files:
    • For launching Weasis Dicomizer: -Dfelix.extended.config.properties=file:target/conf/dicomizer.json
    • Configuration from a URL: -Dfelix.extended.config.properties=https://mysite.com/weasis/conf/config.json
      Note

      felix.config.properties defines the location of base.json (the OSGI configuration and the list of plugins to install/start)
      felix.extended.config.properties defines the location of a json file (extends/overrides base.json)

Internationalization

Translation files are hosted and managed on the Transifex website. Get an account and help to translate to your language! If your language is missing, just head over to Transifex and request a new language.

Building Weasis-i18n

weasis-i18n is the internationalization project (i18n) of Weasis. As a separate project, it can have its own release cycle. The OSGi fragments of plugins contain only the translation files which are merged during runtime to the matching module of the application.

To obtain daily built packages, see this page.

Prerequisites

1. JDK 11 or higher
2. Maven 3 or higher
   If your computer is behind a proxy server, configure maven.
3. Git or directly download the source code from GitHub

Getting the Source

To clone the repository, first install GIT and either clone using a graphical GIT client (such as Tortoise Git) or directly from the command line using the command:

$ git clone https://github.com/nroduit/weasis-i18n.git

Build the distribution

Go in the weasis-i18n directory, Compile and install all the plugins in the local Maven repository

$ mvn clean install -Dtransifex.token="<your-token>"

All the APIs require to be authenticated. So the value “your-token” must be replaced by your generated token, see how to get this token on Transifex.

Command if you are behind a proxy server:

$ mvn clean install -DproxySet=true -DproxyHost="host" -DproxyPort="port" -Dtransifex.token="<your-token>"

Apply the translations

The translation package can be built manually as described below, or it is automatically built every 24 hours and can be downloaded from here. When Building Weasis, the last package is downloaded automatically.

• In order to update Weasis with new translations, unzip weasis-i18n.zip and either:
  • Pass the weasis.i18n location into the launch command:

    $weasis:config pro="weasis.i18n <your-uri>"
    $weasis:config pro="weasis.i18n file:/home/weasis-i18n-dist-4.0.0-SNAPSHOT"
    $weasis:config pro="weasis.i18n https://<your-domain>/weasis-i18n-dist-4.0.0"

  • Replace the files in the “bundle-i18n” folder where Weasis is installed (not possible when Weasis is distributed from an application store or the Mac signed package).

Weasis Architecture

Weasis is built on a modular architecture powered by OSGi: the dynamic module system for Java. This design allows for a highly flexible, dynamic, and extendable structure. At its core, Weasis utilizes the Apache Felix OSGi framework, a lightweight open-source implementation of the OSGi specification.

Key Architectural Features

The following diagrams illustrate the main plugin types (known as bundles in OSGi terminology) and their relationships. These include Viewer, Viewer Tool Pane, Tool Bar, Data Explorer, and Codec bundles, which are dynamically registered using Declarative Services—a mechanism to seamlessly provide or consume services in the OSGi environment.

Understanding The Categories of Plugins

Weasis employs a modular approach, where individual plugins (or bundles in OSGi terminology) handle specific functionalities. Here are the plugin categories represented by layers in the diagram:

1. Media Viewer and Editor
   This category handles the main viewing and editing functionalities. Except the 2D viewer, it includes specialized viewers for different modalities and representations.
2. UI Aggregator
   UI Aggregator plugins bring together various interface components to create a cohesive and user-friendly experience. They dynamically adapt the interface to include provided tools or modules, ensuring that Weasis remains customizable and modular.
3. Data Access and Management (Data Explorer)
   This category focuses on managing how data is loaded, retrieved, and handled within the system.
4. Codec (Media Decoding)
   Codec plugins are responsible for decoding and interpreting medical media files in the DICOM format and other supported formats. They sometimes include native libraries.
5. Utility and Core Services
   This plugin provides essential utility functions and core services needed to support the other modules.

Each of these categories contributes to the flexibility and extensibility of Weasis, enabling it to be customized and adapted to different clinical and research workflows.

Fragment Bundles

A fragment bundle is a special type of bundle that is attached to a host bundle to provide additional resources or classes. In Weasis, fragment bundles are used to provide translations and native libraries for codecs. This design allows for a clean separation of concerns and ensures that only the required resources are loaded at runtime.

Bundle Translation Management

Each bundle has its translation files packaged in a separate bundle fragment (ending in i18n), an OSGi concept that merges these files dynamically during runtime. This design allows translations to be maintained independently, and they are automatically loaded by the application whenever they are available.

Codec Support with Native Libraries

Certain Codec bundles contain fragments with native libraries (using JNI wrappers). The Weasis launcher dynamically loads only the required native binaries relevant to the platform on which it is running, ensuring lightweight and efficient operation.

Shortcuts

Keyboard and Mouse Shortcuts

Here is a list of the default keyboard and mouse shortcuts in Weasis. The shortcuts are divided into different categories for better understanding.

Central panel containing viewers and editors

Selected view in the 2D DICOM Viewer

Selected view in the MPR Viewer

MPR view inherits the same shortcuts as the 2D viewer, with the following additional shortcuts since v4.6.0 :

DICOM explorer

Graphics

Tips and Tricks

Window / Level Adjustment

• Move the mouse horizontally to the right to increase the window width (reduce the perceived contrast).
• Move the mouse vertically upwards to lower the window center (increase the perceived brightness).
  Tip: Use Preferences to reverse the direction of level adjustments.

Drawing a Segment

You can draw a segment in two ways:

1. Click + Drag: Click, drag to draw, then release.
2. Click > Release > Drag: Click to start, release, drag to draw, and release again.

Customize

• Integration
• Preferences
• Build Plugins

Weasis Commands

The commands listed below can be applied at start-up or in a telnet session. All the commands starting with “dcmview2d:” allow you to drive Weasis and are not adapted to be used at start-up.

To obtain the list of commands, after starting Weasis, open a local telnet session of the OSGI Console and type lb for getting the list of bundles and their state or type help for getting all the available commands:

telnet localhost 17179

Trying 127.0.0.1...

Connected to localhost.localdomain.

Escape character is '^]'.

____________________________

Welcome to Apache Felix Gogo

g!

List of Weasis commands

dcmview2d:layout

g! dcmview2d:layout
Select a split-screen layout
Usage: dcmview2d:layout ( -n NUMBER | -i ID )
  -n --number=NUMBER  select the best matching number of views
  -i --id=ID          select the layout from its identifier
  -? --help           show help

dcmview2d:mouseLeftAction

g! dcmview2d:mouseLeftAction
Change the mouse left action
Usage: dcmview2d:mouseLeftAction COMMAND
COMMAND is (sequence|winLevel|zoom|pan|rotation|crosshair|measure|draw|contextMenu|none)
  -? --help       show help

dcmview2d:move

g! dcmview2d:move
Pan the selected image
Usage: dcmview2d:move -- X Y
X and Y are Integer. It is mandatory to have '--' (the end of options) for negative values
  -? --help       show help

dcmview2d:reset

g! dcmview2d:reset

Reset image display
Usage: dcmview2d:reset (-a | COMMAND...)
COMMAND is (winLevel|zoom|pan|rotation)
  -a --all        reset to original display
  -? --help       show help

dcmview2d:scroll

g! dcmview2d:scroll
Scroll into the images of the selected series
Usage: dcmview2d:scroll ( -s NUMBER | -i NUMBER | -d NUMBER)
  -s --set=NUMBER       set a new value from 1 to series size
  -i --increase=NUMBER  increase of some amount
  -d --decrease=NUMBER  decrease of some amount
  -? --help             show help

dcmview2d:synch

g! dcmview2d:synch
Set a synchronization mode
Usage: dcmview2d:synch VALUE
VALUE is (None|Stack|Tile)
  -? --help       show help

dcmview2d:wl

g! dcmview2d:wl
Change the window/level values of the selected image (increase or decrease into a normalized range of 4096)
Usage: dcmview2d:wl -- WIN LEVEL
WIN and LEVEL are Integer. It is mandatory to have '--' (the end of options) for negative values
  -? --help       show help

dcmview2d:zoom

g! dcmview2d:zoom
Change the zoom value of the selected image
Usage: dcmview2d:zoom (set VALUE | increase NUMBER | decrease NUMBER)
  -s --set=VALUE        [decimal value]  set a new value from 0.0 to 12.0 (zoom magnitude, 0.0 => default, -200.0 => best fit, -100.0 => real size)
  -i --increase=NUMBER  increase of some amount
  -d --decrease=NUMBER  decrease of some amount
  -? --help             show help

dicom:get

g! dicom:get
Load DICOM files remotely or locally
Usage: dicom:get ([-l PATH]... [-w URI]... [-r URI]... [-p] [-i DATA]... [-z URI]...)
PATH is either a directory(recursive) or a file
  -l --local=PATH   open DICOMs from local disk
  -r --remote=URI   open DICOMs from a URI
  -w --wado=URI     open DICOMs from an XML manifest
  -z --zip=URI      open DICOM ZIP from a URI
  -p --portable     open DICOMs from configured directories at the same level of the executable
  -i --iwado=DATA   open DICOMs from an XML manifest (GZIP-Base64)
  -? --help         show help

dicom:close

g! dicom:close
Close DICOM files
Usage: dicom:close  (-a | ([-y UID]... [-s UID]...))
  -a --all           close all the patients
  -p --patient=ID    close a patient from its patient ID (since v4.4.1)
  -y --study=UID     close a study, UID is Study Instance UID
  -s --series=UID    close a series, UID is Series Instance UID
  -? --help          show help

dicom:rs

g! dicom:rs
Load DICOM files from DICOMWeb API (QIDO/WADO-RS)
Usage: dicom:rs -u URL -r QUERYPARAMS... [-H HEADER]... [--query-header HEADER]... [--retrieve-header HEADER]... [--query-ext EXT] [--retrieve-ext EXT] [--accept-ext EXT]
  -u --url=URL               URL of the DICOMWeb service
  -r --request=QUERYPARAMS   Query params of the URL, see weasis-pacs-connector
  -H --header=HEADER         Pass custom header(s) to all the requests
  --query-header=HEADER      Pass custom header(s) to the query requests (QIDO)
  --retrieve-header=HEADER   Pass custom header(s) to the retrieve requests (WADO)
  --query-ext=EXT            Additionnal parameters for Query URL (QIDO)
  --retrieve-ext=EXT         Additionnal parameters for Retrieve URL (WADO)
  --accept-ext=EXT           Additionnal parameters for DICOM multipart/related Accept header of the retrieve URL (WADO). Default value is: transfer-syntax=*
  --show-whole-study         when downloading a series, show all the other series (ready for download) from the same study
  -? --help                  show help

image:get

g! image:get
Load images remotely or locally
Usage: image:get ([-f file]... [-u url]...)
  -f --file=FILE     open an image from a file
  -u --url=URL       open an image from a URL
  -? --help          show help

image close

g! image:close
Close images
Usage: dicom:close (-a | ([-g UID]... [-s UID]...))
  -a --all         close all series
  -g --group=UID   close a group from its UID
  -s --series=UID   close an series/image from its UID
  -? --help        show help

weasis:info

g! weasis:info
Show information about Weasis
Usage: weasis:info (-v | -a)
  -v --version    show version
  -a --all        show weasis specifications
  -? --help       show help

weasis:ui

g! weasis:ui
Manage user interface
Usage: weasis:ui (-q | -v)
  -q --quit     shutdown Weasis
  -v --visible  set window on top
  -? --help     show help

acquire:patient

g! acquire:patient
Load Patient Context from the first argument
Usage: acquire:patient (-x | -i | -s | -u) arg
arg is an XML text in UTF8 or an url with the option '--url'
  -x --xml         open Patient Context from an XML data containing all DICOM Tags
  -i --inbound     open Patient Context from an XML data containing all DICOM Tags, decoding syntax is [Base64/GZip]
  -s --iurlsafe    open Patient Context from an XML data containing all DICOM Tags, decoding syntax is [Base64_URL_SAFE/GZip]
  -u --url         open Patient Context from a URL (XML file containing all DICOM TAGs)
  -? --help        show help

weasis:config (only at launch)

This command can be used only at launch, see Modify the launch parameters

dicom:get -w "http://localhost/weasis-pacs-connector/manifest?patientID=97026728&modalitiesInStudy=MR"

System Resources

Weasis routinely handles studies far larger than its memory: a CT or MR series is hundreds of slices, a digital mammography image is tens of megabytes, a 3D volume is hundreds of megabytes. The System resources panel shows, in real time, how much of the machine Weasis is using, whether the hardware matches your daily practice, and — when it does not — what to upgrade.

Open it from the menu Help > System resources.

The panel does not change anything by itself. It is a diagnostic view: it observes, measures across all your sessions, and gives a verdict you can act on.

How memory works in Weasis

To read the panel, it helps to know that Weasis uses memory in two separate pools:

• JVM heap — holds the user interface, the DICOM metadata and temporary copies of pixels. Its maximum size is fixed when Weasis starts.
• Native image memory — holds the decoded pixel data of images. This is the pool that grows when you open large studies. It is not part of the heap; it is sized from the physical memory of the machine.

A third pool, GPU memory (VRAM), is used only by the 3D viewer.

This separation is why a single “memory” number is not enough — and why the panel shows both pools side by side.

Reading the panel

The dialog refreshes every two seconds while it is open. It has five sections.

Hardware

A static description of the machine:

Live pressure

Three bars showing current use, each with its peak value for the session:

• JVM heap — interface and metadata memory.
• Native image memory — decoded images currently cached.
• CPU load — processor use by Weasis.

A bar turning red above 90 % means that pool is close to its limit. Native image memory reaching its limit is normal and harmless: Weasis simply drops the least-recently-seen images from the cache and reloads them transparently when you scroll back. A heap bar staying near 100 %, on the other hand, is a real warning sign.

Assessment

The verdict — the heart of the panel. Each line is rated with one of four levels:

• Overall — the worst of the rows below.
• Memory — based on real failure signals, not on raw usage: out-of-memory errors, a 3D volume that had to spill to disk, or sustained garbage-collection overhead. A rare event is tolerated; a recurring one turns the verdict red.
• CPU — sub-optimal on 2 cores or fewer; abundant on 8+ cores left mostly idle.
• Recommended upgrade — see below.

Workload

What the heaviest study you opened actually demanded: the largest image (in megabytes) and the largest volume (in number of slices). These explain why a verdict came out the way it did.

Events (all sessions)

The counters behind the memory verdict, accumulated over every session:

A non-zero count is not necessarily a problem — the panel colors a counter red only when it is the signal currently causing a sub-optimal memory verdict.

Acting on the recommendation

When Memory or CPU is sub-optimal, the Recommended upgrade line gives a concrete target. Weasis distinguishes a configuration problem from a hardware one:

• A larger heap (-Xmx) — shown when the machine has free RAM but Weasis was not allowed to use enough of it. This is fixed by changing a setting, not by buying hardware.
• More RAM — shown when the heap is already a fair share of physical memory: the machine itself is the limit.
• More CPU cores — shown when too few cores slowed image decoding and reconstruction.

Increasing the memory limits

The heap maximum and the native-memory budget are controlled by start-up options. The simplest way to raise the heap is the -Xmx option; the native-image pool is controlled by a Weasis property:

For an installed Weasis, edit the java-options of the application configuration (for example app/Weasis.cfg next to the installation). For a study workstation that opens large studies, raising the native-memory percentage keeps more images cached and avoids reloads:

weasis.native.memory.percent=70

The full set of memory parameters is described in the Memory Management developer guide.

Exporting the report

The Copy report button places a plain-text summary of the whole panel on the clipboard — hardware, verdict, recommendation and event counters. Paste it into a bug report or a message to your IT department when asking for a hardware upgrade.

Dicom Conformance

Compatibility of DICOM Transfer Syntax

This table lists the DICOM Transfer Syntaxes supported by Weasis.

Supported “Photometric Interpretation” pixel format

This table lists the Photometric Interpretation supported by Weasis.

Imaging Hub

This page describes how to install the Imaging Hub, a Docker Compose stack for managing dcm4chee PACS, ViewerHub, and related services.

Included Services

This stack comprises the following components:

• dcm4chee: PACS server for storing and retrieving medical images.
• ViewerHub: Manages the launch of different viewers.
• MinIO: Object storage server compatible with Amazon S3 APIs.
• Redis: Cache service storing manifest data for Weasis resources.
• Postgres: Database backend for ViewerHub and dcm4chee.
• Keycloak: Manages user authentication and access.
• Config-server: Manages configuration of all services.
• Eureka: Provides service discovery for stack components.

Prerequisites

• Docker
• Docker Compose CLI

Configurations

This stack supports multiple configurations:

• Debug (local): Includes all the required stack except ViewerHub and uses local volumes.
• Unsecure (unsecure): Enables HTTP and uses development-grade settings. dcm4chee and ViewerHub services have no authentication.
• Secure (secure) [Not yet available]: Enables HTTPS and uses production-grade settings. dcm4chee and ViewerHub services have authentication.

Usage

Run the following commands based on the environment:

• For debugging ViewerHub:

  ./scripts/start.sh local

  And then run ViewerHub from your IDE

Minio

Minio is an open-source object storage server compatible with Amazon S3 APIs. It is used to store resources required by the different versions of Weasis.

Access the Minio console at: http://localhost:9090

Use the following credentials:

• User: viewer-hub
• Password: viewer-hub

Keycloak

Keycloak is an open-source identity and access management server used to authenticate users.

Access the Keycloak console at: http://localhost:8085

Use the following credentials:

• User: admin
• Password: admin

Dcm4chee

Dcm4chee is a PACS server that enables storing and retrieving medical images.

Access the dcm4chee console at: http://localhost:8080/dcm4chee-arc/ui2/en/study/study

For secure mode, access the dcm4chee console at: https://localhost:8443/dcm4chee-arc/ui2/en/study/study Use the following credentials:

• User: admin
• Password: changeit

Viewer-Hub Gateway

ViewerHub gateway is used to handle different types of authentication in order for viewers to get authentified when requesting data from the pacs.

ViewerHub Gateway handles basic authentication and oAuth2 (client credential and authorization code flow).

In order to install the gateway, follow the instructions in the README.md file: https://github.com/nroduit/viewer-hub-gateway

ViewerHub

ViewerHub is a web application that manages the launch of different viewers.

Access the ViewerHub console at: http://localhost:8081

Use the following credentials:

• User: viewer-hub-user
• Password: password

Guidelines for development

This page provides guidelines for developing and debugging ViewerHub.

We recommend the use of IntelliJ IDEA because the following instructions are based on it.

Add a Launcher

• Open Run > Edit Configurations…
• Add in VM options the following properties:

  -Duser.timezone=UTC
  -DENVIRONMENT=local
  -DEUREKA_CLIENT_SERVICE_URL_DEFAULT_ZONE=http://localhost:8761/eureka
  -DREGION=local
  -DDATACENTER=local
  -Dserver.port=8081
  -Dmanagement.server.port=19001
  -DBACKEND_URI=http://localhost:8081
  -DDB_HOST=localhost
  -DDB_PORT=45101
  -DDB_NAME=viewer-hub
  -DDB_USER=viewer-hub
  -DDB_PASSWORD=viewer-hub
  -DCONFIGSERVER_URI=http://localhost:8888
  -DS3_ACCESS_KEY=access-key
  -DS3_SECRET_KEY=secret-key
  -DS3_ENDPOINT=http://localhost:9080
  -DS3_BUCKET_NAME=viewer-hub-bucket
  -DBACKEND_URI=http://localhost:8081

• Then clean/install + Run…

ViewerHub

In order to access to ViewerHub:

http://localhost:8081

with

User: viewer-hub-user
Password: password

Launch Weasis

Launch the below URL to launch Weasis and load the dicom image stored in the Dcm4chee or Orthanc pacs:

• Spring profile “connectors-dicom-no-gtw”

Dcm4chee:

http://localhost:8081/display?viewer=WEASIS&studyUID=1.3.12.2.1107.5.1.4.54023.30000004093013443132800000021&archive=dcm4chee-local

Orthanc:

http://localhost:8081/display?viewer=WEASIS&studyUID=1.3.12.2.1107.5.1.4.54023.30000004093013443132800000021&archive=orthanc-local

• Spring profile “connectors-dicom-gtw”

Dcm4chee:

http://localhost:8081/display/auth?viewer=WEASIS&studyUID=1.3.12.2.1107.5.1.4.54023.30000004093013443132800000021&archive=dcm4chee-local

Orthanc:

http://localhost:8081/display/auth?viewer=WEASIS&studyUID=1.3.12.2.1107.5.1.4.54023.30000004093013443132800000021&archive=orthanc-local

Launch Ohif

Launch the below URL to launch Ohif and load the dicom image stored in the Dcm4chee or Orthanc pacs:

• Spring profile “connectors-dicom-no-gtw”

Dcm4chee

http://localhost:8081/display?viewer=OHIF&studyUID=1.3.12.2.1107.5.1.4.54023.30000004093013443132800000021&archive=dcm4chee-local

Orthanc

http://localhost:8081/display?viewer=OHIF&studyUID=1.3.12.2.1107.5.1.4.54023.30000004093013443132800000021&archive=orthanc-local

• Spring profile “connectors-dicom-gtw” or “connectors-dicomweb-gtw”

Dcm4chee

http://localhost:8081/display/auth?viewer=OHIF&studyUID=1.3.12.2.1107.5.1.4.54023.30000004093013443132800000021&archive=dcm4chee-local

Orthanc

http://localhost:8081/display/auth?viewer=OHIF&studyUID=1.3.12.2.1107.5.1.4.54023.30000004093013443132800000021&archive=orthanc-local

Launch 3D Slicer

You need to install 3D Slicer in your machine to use it.

Launch the below URL to launch 3D Slicer and load the dicom image stored in the Dcm4chee or Orthanc pacs:

• Spring profile “connectors-dicom-gtw” or “connectors-dicomweb-gtw”

Dcm4chee

http://localhost:8081/display/auth?viewer=SLICER&studyUID=1.3.12.2.1107.5.1.4.54023.30000004093013443132800000021&archive=dcm4chee-local

Orthanc

http://localhost:8081/display/auth?viewer=SLICER&studyUID=1.3.12.2.1107.5.1.4.54023.30000004093013443132800000021&archive=orthanc-local

Launch Micro Dicom

You need to install Micro Dicom in your machine to use it. You also need to add the MICRODICOM AET to the Dcm4chee pacs and to configure the Dicom server corresponding to the Dcm4chee pacs in MicroDicom (localhost:11112, aet DCM4CHEE)

Launch the below URL to launch Micro Dicom and load the dicom image stored in the Dcm4chee or Orthanc pacs:

• Spring profile “connectors-dicom-no-gtw”

Dcm4chee

http://localhost:8081/display?viewer=MICRODICOM&studyUID=1.3.12.2.1107.5.1.4.54023.30000004093013443132800000021&archive=dcm4chee-local

Orthanc

http://localhost:8081/display?viewer=MICRODICOM&studyUID=1.3.12.2.1107.5.1.4.54023.30000004093013443132800000021&archive=orthanc-local

Information

These URLs work with the Imaging Hub stack. If you are using a different setup, you may need to adjust the URL accordingly.

For more information, refer to the Launch APIs documentation.

Connectors

This page outlines the configuration of connectors used by Viewer-Hub to connect to DICOM archives.

Model

In order to retrieve the metadata used to identify the studies to display, connectors are configured to enable connections to various PACS or VNA systems.
Three types of connectors are defined in the configuration server: DB, DICOM, and DICOM_WEB.

These connectors are defined according to this model: connector_model.yml

Global connector configuration

The global connector configuration is defined as follows:

connector:
    # If value is present: use the connectors specified, if not present or wrong connector ids: use all the valid connectors defined in the config
    default: # connectorId1, connectorId2

    # Limit the dicom-web connector when retrieving metadata at study or serie level
    dicom-web-level-limit: # STUDY, SERIE

    config:
        connector-id:
            type:  # Type of connector used => DB, DICOM, DICOM_WEB
            
            # ------- Search Criteria ----
            search-criteria:
                deactivated: # If a search criteria needs to be deactivated=> SOP_INSTANCE_UID, SERIE_INSTANCE_UID, STUDY_INSTANCE_UID, STUDY_ACCESSION_NUMBER, PATIENT_ID

            # ------- Specific parameters for Weasis manifest----
            weasis:
                manifest:
                    transfer-syntax-uid:
                    compressionRate:
                    requireOnlySOPInstanceUID:  # true/false
                    additionnalParameters:
                    overrideDicomTags:
                    httpTags: 

Database connector

This connector is used to connect to the PACS database in order to find the metadata of studies, series, instances to retrieve.

db-connector:
    user: # Database user
    password: # Encoded password
    uri: # Database uri
    driver: # Database driver
    query:
        select: # SQL query to retrieve patientName, patientId, patientBirthDate, patientSex, studyInstanceUid, studyDate, accessionNumber, studyId, referringPhysicianName, studyDescription, seriesInstanceUid, modality, seriesDescription, seriesNumber, sopInstanceUid, instanceNumber
        accession-number-column: # Accession number column used in the SQL query above
        patient-id-column: # Patient id column used in the SQL query above
        study-instance-uid-column: # Study instance uid column used in the SQL query above
        serie-instance-uid-column: # Serie instance uid column used in the SQL query above
        sop-instance-uid-column: # Sop instance uid column used in the SQL query above
    wado: 
        authentication:
            ... => described below in the section "Authentication configuration"

DICOM connector

This connector is used to connect to the PACS in Dicom in order to find the metadata of studies, series, instances to retrieve.

dicom-connector:
    dimse:
        calling-aet: # Calling aet
        aet: # Aet
        host: # Host
        port: # Port
        # Specific configuration for dicom connector when using CFind
        tls:
            mode:
            need-client-authentication:
        keyStore:
            url:
            type:
            password:
            keyStorePassword:
        truststore:
            url:
            type:
            password:
    wado: 
        authentication:
            ... => described below in the section "Authentication configuration"

DICOM Web connector

This connector is used to connect to the PACS in Dicom Web in order to find the metadata of studies, series, instances to retrieve.

dicom-web-connector:
    qido-rs:
        authentication:
            ... => described below in the section "Authentication configuration"
    wado-rs:
        authentication:
            ... => described below in the section "Authentication configuration"

Authentication configuration

Authentication configuration is used to build the web clients for Dicom Web connectors which will get the metadata from the archive or used to handle Weasis authentication when building the manifest in order for Weasis to retrieve the images

    authentication:
        type: # BASIC, OAUTH2
        oauth2:
            oidc-id: # Id of the oidc configuration (defined in application-oidc.yml)
            server:
                url:  # Url 
                port: # Port 
                context: # Context 
        basic:
            login: # Basic credential login 
            password: # Basic credential password
            server:
                url: # Url 
                port: # Port 
                context:  # Context 

Launch APIs

Launch viewers from your own web application

The display service is available at the URL: http://localhost:8081/display

To launch viewers from your own web application, you need to build the URL with the following parameters:

• viewer: The specific viewer used to display studies. Available viewer parameter values: “WEASIS”, “OHIF”, “SLICER”, “MICRODICOM”. If this parameter is not present in the request, viewer-hub will determine which viewer to display depending on selection rules (based on modalities and archives) defined in the admin interface of viewer-hub.
• archive: The archive name to be used to retrieve the study. The list of archives is defined in the config server.
• patientID: The Patient ID of the study to be displayed. Note to handle a universal patientID, add IssuerOfPatientID like in hl7: patientID=1168514^^^issuerValue
  • Ex: http://localhost:8081/display?viewer=WEASIS&patientID=1168514&archive=dcm4chee-local
  • Ex with multiple patientID: http://localhost:8081/display?viewer=WEASIS&patientID=1168514&patientID=2023231696&archive=dcm4chee-local
  • Ex with URL encoding of separators ^^^ and IssuerOfPatientID value test: http://localhost:8081/display?viewer=WEASIS&patientID=1168514%5E%5E%5Etest&archive=dcm4chee-local
• studyUID: The Study Instance UID of the study to be displayed.
  • Ex: http://localhost:8081/display?viewer=WEASIS&studyUID=1.3.12.2.1107.5.1.4.54023.30000004093013443132800000021&archive=dcm4chee-local
• accessionNumber: The Accession Number of the study to be displayed.
  • Ex: http://localhost:8081/display?viewer=WEASIS&accessionNumber=2066852&archive=dcm4chee-local
• seriesUID: The Series Instance UID of the series to be displayed.
  • Ex: http://localhost:8081/display?viewer=WEASIS&seriesUID=1.3.12.2.1107.5.1.4.54023.30000004093016410718700008612&archive=dcm4chee-local
  • Ex with multiple studies and series: http://localhost:8081/display?viewer=WEASIS&studyUID=1.3.6.1.4.1.5962.1.2.2.20031208063649.855&studyUID=1.3.6.1.4.1.5962.1.2.2.20031208063649.857&seriesUID=1.2.840.113704.1.111.4924.1273631010.17&archive=dcm4chee-local
• objectUID: The SOP Instance UID of the object to be displayed.
  • Ex: http://localhost:8081/display?viewer=WEASIS&objectUID=1.3.12.2.1107.5.1.4.54023.30000004093016410718700010432&archive=dcm4chee-local

Filters

• mostRecentResults: The number of the most recent studies to be displayed.
  • Ex: http://localhost:8081/display?viewer=WEASIS&patientID=11685148&mostRecentResults=2
• modalitiesInStudy: Filter the studies containing the specified modalities.
  • Ex with only CT or XA: http://localhost:8081/display?viewer=WEASIS&patientID=1168514&modalitiesInStudy=CT,XA&archive=dcm4chee-local
• containsInDescription: Filter the studies containing the specified string in the study description. Note that the search is case-insensitive and diacritic-insensitive.
  • Ex with only coronary or thorax: http://localhost:8081/display?viewer=WEASIS&patientID=1168514&containsInDescription=coronary,thorax&archive=dcm4chee-local
• lowerDateTime: Filter the studies which are older than the specified date.
  • Ex CT older than 01.01.2010 12:00:00: http://localhost:8081/display?viewer=WEASIS&patientID=1168514&modalitiesInStudy=CT&lowerDateTime=2010-01-01T12:00:00Z&archive=dcm4chee-local
• upperDateTime: Filter the studies which are more recent than the specified date.
  • Ex CT more recent than 01.01.2010 12:00:00: http://localhost:8081/display?viewer=WEASIS&patientID=1168514&modalitiesInStudy=CT&upperDateTime=2010-01-01T12:00:00Z&archive=dcm4chee-local

Launch viewers with IHE IID profile

he Invoke Image Display Profile enables an Image Display Invoker, typically a non-image-aware system such as an EHR, PHR, or RIS, to request the display of patient studies, which are then presented by an image-aware system like an Image Display (PACS). The display service is available at the URL: http://localhost:8081/display/IHEInvokeImageDisplay

To launch Weasis with IHE IID profile, you need to build the URL with the following parameters:

• viewer: The specific viewer used to display studies. Available viewer parameter values: “WEASIS”, “OHIF”, “SLICER”, “MICRODICOM”. If this parameter is not present in the request, viewer-hub will determine which viewer to display depending on selection rules (based on modalities and archives) defined in the admin interface of viewer-hub.
• archive: The archive name to be used to retrieve the study. The list of archives is defined in the config server.
• requestType: The type of the request (PATIENT, STUDY)
• patientID: The Patient ID of the study to be displayed. Note to handle a universal patientID, add IssuerOfPatientID like in hl7: patientID=1168514^^^issuerValue
• studyUID: The Study Instance UID of the study to be displayed.
  • Ex: http://localhost:8081/display/IHEInvokeImageDisplay?viewer=WEASIS&requestType=STUDY&studyUID=1.3.12.2.1107.5.1.4.54023.30000004093013443132800000021
• accessionNumber: The Accession Number of the study to be displayed.
  • Ex: http://localhost:8081/display/IHEInvokeImageDisplay?viewer=WEASIS&requestType=STUDY&accessionNumber=2066852

Filters

• mostRecentResults: The number of the most recent studies to be displayed.
  • Ex: http://localhost:8081/display/IHEInvokeImageDisplay?viewer=WEASIS&requestType=PATIENT&patientID=11685148&mostRecentResults=2
• modalitiesInStudy: Filter the studies containing the specified modalities.
  • Ex studies containing CT or XA: http://localhost:8081/display/IHEInvokeImageDisplay?viewer=WEASIS&requestType=PATIENT&patientID=11685148&modalitiesInStudy=CT,XA
• containsInDescription: Filter the studies containing the specified string in the study description. Note that the search is case-insensitive and diacritic-insensitive.
  • Ex studies containing coronary or thorax: http://localhost:8081/display/IHEInvokeImageDisplay?viewer=WEASIS&requestType=PATIENT&patientID=11685148&containsInDescription=coronary,thorax
• lowerDateTime: Filter the studies which are older than the specified date.
  • Ex studies older than 01.01.2010 12:00:00: http://localhost:8081/display/IHEInvokeImageDisplay?viewer=WEASIS&requestType=PATIENT&patientID=11685148&lowerDateTime=2010-01-01T12:00:00
• upperDateTime: Filter the studies which are more recent than the specified date.
  • Ex studies more recent than 01.01.2010 12:00:00: http://localhost:8081/display/IHEInvokeImageDisplay?viewer=WEASIS&requestType=PATIENT&patientID=11685148&lowerDateTime=2010-01-01T12:00:00

Weasis Manifest

Manifest

The manifest contains the list of exams, series, and instances to retrieve when loading images by Weasis.

The manifest is represented in this format.

The creation of the manifest occurs when a client calls ViewerHub to launch Weasis through the launch URL using the Launch APIs.

Construction

According to the search criteria of the request, ViewerHub constructs the manifest through connectors.

There are 3 types of connectors:

• DB (database)
• DICOM (DICOM DIMSE)
• DICOM_WEB (Weasis will use DICOMWeb connector in a future release).

DB queries or DICOM calls are made to retrieve the necessary information to populate the manifest according to the search criteria.

The connectors are defined according to a model in the config server.

Cache Redis

Once the manifest built, it will be stored in a Redis cache for a defined period (TTL currently 3 minutes).

This mechanism allows multiple instances of ViewerHub, as the retrieval of the manifest by Weasis is asynchronous.

It is also useful when the user requests the visualization of the same study within the TTL period: the manifest will be retrieved directly from the Redis cache.

The key for retrieving the manifest corresponds to the hash of the search criteria.

Cryptography

When launching the Weasis viewer with ViewerHub, a URL containing search criteria in “query parameters” is used.

It is possible to encrypt these search parameters when launching the Weasis viewer in order to not transmit certain sensitive data in plain text (e.g. patient identifier).

To enable this feature, the application-cryptography.yml file in the config-server must be modified by setting the “enabled” field below to true.

# - Cryptography
cryptography:
    enabled: false
    password: '{cipher}'
    salt: '{cipher}'

Defining a password and a salt is also necessary to encode/decode the search parameters.

The same encryption algorithm must be used on the client side (encryption) and on the ViewerHub side (decryption).

User Guide

• Viewer Selection
• Weasis

GUI Overview

Essential aspects of the interface

The image below shows the main elements of the Weasis graphical user interface. Click any of the green or blue areas to jump to the dedicated documentation for that element.

The default DICOM workspace has two main areas:

1. The DICOM Explorer on the left (blue) — used to import and export data and to pick the series to display.
2. The main area on the right (green) — hosts the open viewers and players as tabs. The available menus, toolbars, and tools change depending on the viewer currently in focus.
   • In the screenshot above, the active viewer is the DICOM 2D Viewer , which is the default for image series.
   • A tab with a multi-view layout can only display images from a single patient, but the same patient can appear in several tabs.
   • Each tab is a docked panel that can be moved by drag-and-drop, including side-by-side splits — see Docking for the full layout options.
   • For navigating through the Patient / Study / Series / Image hierarchy, see the DICOM Explorer page.

Minimal configuration before starting

A few settings make Weasis noticeably more comfortable the first time you launch it. Open the preferences dialog from the main menu: File > Preferences (Alt + P).

Language and regional settings

In the General tab, pick your preferred language and regional format (dates, numbers). Only languages with at least 30 % translation coverage appear in the list. Dates, numbers, and other locale-sensitive values follow the selected regional format throughout the interface.

➜ See Language and regional settings for the detailed instructions.

Theme and scaling factor

In the Appearance tab:

• Choose a theme that suits your environment and reduces eye strain. The recommended theme is Core Dark — Flat Weasis.
• Set a scaling factor that matches your system display scaling. This is especially recommended for HiDPI screens — Weasis will scale fonts, icons, and every UI component consistently.

➜ See Styles and themes for the detailed instructions.

Other viewers and players in the DICOM workspace

Depending on the SOP Class of the loaded series, Weasis opens one of the following:

• Multi-Planar Reconstruction (MPR) viewer
• Maximum Intensity Projection (MIP) viewer
• DICOM 3D Volume Renderer
• DICOM ECG viewer
• DICOM Structured Report (SR) viewer
• DICOM Audio player
• DICOM PDF viewer — opened with the default system application registered for PDF files.
• DICOM Video player — opened with the default system player registered for MPEG files.

Overlay viewers — applied on top of an image series rather than opened on their own — include DICOM Segmentation (SEG), DICOM RT, and Presentation State (PR / GSPS).

Other workspaces

• Dicomizer — the workspace for converting standard images into DICOM objects.
• Standard image explorer — workspace for non-DICOM images (configured through the non-dicom-explorer.json profile).

DICOM Import

How to import DICOM files

Weasis can ingest DICOM data from many sources:

• Drag and drop files, folders, or DICOM ZIP archives from the system file explorer.
• Double-click a DICOM file in the system file explorer (file association).
• Local Device — browse files, folders, or DICOM ZIP archives from inside Weasis.
• DICOMDIR — load a DICOM CD/DVD or any folder that contains a DICOMDIR index.
• DICOM Query/Retrieve — query a remote PACS over classic DICOM (C-FIND / C-MOVE / C-GET) or DICOMweb (QIDO / WADO-RS) and retrieve selected studies.
• Commands — local or remote commands launching Weasis with a target series (see the Weasis Protocol).

To send data the other way — out of Weasis to a file, a PACS node, or a CD/DVD — see DICOM Export.

From the system file explorer

Drag and drop

Files, folders, or DICOM ZIP archives selected in the system file explorer can be opened by dragging and dropping them into the central area of Weasis. The accepted drop target depends on the central panel state:

• Empty central panel — any file a Weasis viewer can open, including standard images such as TIFF, PNG, and JPEG.
• DICOM Explorer or any DICOM viewer (2D, MPR, 3D, SR, AU…) — only DICOM files and DICOM ZIP archives. Weasis opens each series in the most appropriate viewer.

File association

DICOM files can be opened by double-clicking them from the system file explorer.

From the Weasis menu or toolbar

Two import entry points sit next to each other in the toolbar (and under File > Import in the main menu):

• The first button opens the standard DICOM import dialog described below (File > Import > DICOM).
• The second button is a shortcut for the DICOMDIR / CD-ROM workflow (File > Import > DICOM CD).

Local Device

Since Version4.7.0, DICOM ZIP is also accepted in the local-import workflow:

• Files — browse and select one or more DICOM files or DICOM ZIP archives via the file chooser. If a ZIP archive is password-protected, a password prompt is shown.
• Folders — browse and select one or more folders via the file chooser. Folders containing DICOM ZIP archives are also supported.
• Search recursively — when enabled, the import also descends into subdirectories.

DICOMDIR

Loads a DICOMDIR-based study from a CD/DVD or any folder that already contains a DICOMDIR index file:

• Path — browse to a folder containing a DICOMDIR.
• Detect CD-ROM — try to load a DICOM CD/DVD directly.
• Copy images into the local temporary directory — useful for slow reading devices such as CD-ROM drives.

DICOM Query/Retrieve

Queries a remote PACS and retrieves selected studies into the DICOM Explorer. The dialog has two tabs — DICOM Source and Search Criteria.

DICOM Source tab