OHIF / Viewers

OHIF Medical Imaging Viewer The OHIF Viewer is a zero-footprint medical image viewer provided by the Open Health Imaging Foundation (OHIF) . It is a configurable and extensible progressive web application with out-of-the-box support for image archives which support DICOMweb . Read The Docs Live Demo | Component Library 📰 Join OHIF Newsletter 📰 📰 Join OHIF Newsletter 📰 [![NPM version][npm-version-image]][npm-url] [![MIT License][license-image]][license-url] [![This project is using Percy.io for visual regression testing.][percy-image]](percy-url) | | | | | :-: | :--- | :--- | | | Measurement Tracking | Demo | | | Labelmap Segmentations | Demo | | | Fusion and Custom Hanging protocols | Demo | | | Volume Rendering | Demo | | | PDF | Demo | | | RT STRUCT | Demo | | | 4D | Demo | | | Video | Demo | | | Slide Microscopy | Demo | | | ECG Waveform | Demo | About The OHIF Viewer can retrieve and load images from most sources and formats, render sets in 2D, 3D, and reconstructed representations; allows for the manipulation, annotation, and serialization of observations; supports internationalization, OpenID Connect, offline use, hotkeys, and many more features. Almost everything offers some degree of customization and configuration. If it doesn't support something you need, we accept pull requests and have an ever improving Extension System. Why Choose Us Community & Experience The OHIF Viewer is a collaborative effort that has served as the basis for many active, production, and FDA Cleared medical imaging viewers. It benefits from our extensive community's collective experience, and from the sponsored contributions of individuals, research groups, and commercial organizations. Built to Adapt After more than 8-years of integrating with many companies and organizations, The OHIF Viewer has been rebuilt from the ground up to better address the varying workflow and configuration needs of its many users. All of the Viewer's core features are built using its own extension system. The same extensibility that allows us to offer: • 2D and 3D medical image viewing • Multiplanar Reconstruction (MPR) • Maximum Intensity Project (MIP) • Whole slide microscopy viewing • PDF and Dicom Structured Report rendering • Segmentation rendering as labelmaps and contours • User Access Control (UAC) • Context specific toolbar and side panel content • and many others Can be leveraged by you to customize the viewer for your workflow, and to add any new functionality you may need (and wish to maintain privately without forking). Support • Report a Bug 🐛 • Request a Feature 🚀 • Ask a Question 🤗 • Slack Channel For commercial support, academic collaborations, and answers to common questions; please use Get Support to contact us. Developing Branches branch - The latest dev (beta) release • - The latest dev release This is typically where the latest development happens. Code that is in the master branch has passed code reviews and automated tests, but it may not be deemed ready for production. This branch usually contains the most recent changes and features being worked on by the development team. It's often the starting point for creating feature branches (where new features are developed) and hotfix branches (for urgent fixes). Each package is tagged with beta version numbers, and published to npm such as branches - The latest stable releases Once the branch code reaches a stable, release-ready state, we conduct a comprehensive code review and QA testing. Upon approval, we create a new release branch from . These branches represent the latest stable version considered ready for production. For example, is the branch for version 3.5.0, and is for version 3.6.0. After each release, we wait a few days to ensure no critical bugs. If any are found, we fix them in the release branch and create a new release with a minor version bump, e.g., 3.5.1 in the branch. Each package is tagged with version numbers and published to npm, such as . Note that is always ahead of the branch. We publish docker builds for both beta and stable releases. Here is a schematic representation of our development workflow: Requirements • Yarn 1.20.0+ • Node 18+ • Yarn Workspaces should be enabled on your machine: • Getting Started • [Fork this repository][how-to-fork] • [Clone your forked repository][how-to-clone] • 3. Navigate to the cloned project's directory • Add this repo as a named • 5. to restore dependencies and link projects :::danger In general run with the flag to help avoid supply chain attacks by enforcing reproducible dependencies. That is, if the file is clean and does NOT reference compromised packages, then no compromised packages should land on your machine by using this flag. ::: To Develop _From this repository's root directory:_ Cornerstone3D Integration Testing OHIF's Playwright end-to-end tests can run against a **CS3D branch** or a **published CS3D version**, allowing changes that span both repositories to be validated together before merging. Setting up an integration build • Add the ** ** label to your OHIF pull request. • In the PR body, add a line specifying the CS3D ref: • **Version ref** (e.g. , ) — the workflow resolves it to an exact published version and swaps the CS3D dependency via npm. • **Branch ref** (e.g. , ) — the workflow clones the branch, builds CS3D from source with , and symlinks the built packages into OHIF's . • For forks, use the format (e.g. ). • If no is specified, the default is . • The workflow can also be triggered manually via **workflow_dispatch** with a input. What happens in CI The Playwright workflow runs two jobs: | Job | Purpose | |-----|---------| | **Playwright Tests** | Builds OHIF (with CS3D linked or version-swapped), runs the full Playwright suite, uploads test results and coverage, and deploys a Netlify preview when is active. | | **CS3D Branch Merge Guard** | A lightweight check that **fails** when the label is present and points to a…