DOCSEARCHbyAlgolia
Submit Docs

OHIF Viewer Documentation

website·Indexed 34 days ago

https://v3-docs.ohif.org/

Documentation for the Open Health Imaging Foundation (OHIF) Viewer, an open-source, web-based, zero-footprint DICOM viewer platform. Includes guides on deployment, authorization, configuration, and development, as well as a user guide for measurement tools and a migration guide from version 3.7 to 3.8.

Tokens
104.6K
Snippets
484
Records
665
Agent score
61%

What's inside OHIF

  1. Overview of OHIF Viewer

    OHIF (Open Health Imaging Foundation) Viewer is an open-source, web-based, zero-footprint DICOM viewer platform designed for medical imaging. It provides a configurable and extensible framework for building diagnostic-quality medical imaging applications, supporting various imaging formats (primarily DICOM), advanced visualization tools, customizable workflows, and integration with multiple data sources.

  2. Overview of the Hanging Protocol Service

    The Hanging Protocol Service manages the arrangement of images in viewports by matching available DisplaySets against registered protocols. Each protocol is assigned a score; the protocol with the highest score is applied, and its settings are used to arrange the viewports.

  3. Overview of the OHIF Viewer platform

    The Open Health Imaging Foundation (OHIF) Viewer is an open-source, web-based medical imaging platform designed as a core framework for building complex imaging applications.

    Key technical features include:

    • Performance: Optimized for loading large radiology studies by retrieving metadata first and streaming pixel data as needed.
    • Rendering Engine: Uses Cornerstone3D for decoding, rendering, and annotating medical images.
    • Connectivity: Works out-of-the-box with DICOMWeb-compliant Image Archives and provides a Data Source API for proprietary API formats.
    • Extensibility: Features a plugin framework for creating task-based workflow modes and a reusable UI component library built with React.js and Tailwind CSS.

  4. Overview of OHIF-Maintained Extensions

    OHIF maintains several core extensions located in the extensions/ directory of the OHIF/Viewers repository. Key extensions include:

    • default: Provides default viewer layout, study/series browser, and a DICOMWeb compliant datasource. Includes modules for commands, context, data source, hanging protocol, layout templates, panels, SOP class handling, and toolbar.
    • cornerstone: Provides 2D and 3D rendering functionalities via Viewport, Commands, and Utility modules.
    • dicom-pdf: Renders PDFs for specific SopClassUIDs using Viewport and SopClassHandler modules.
    • dicom-video: Renders DICOM Video files using Viewport and SopClassHandler modules.
    • cornerstone-dicom-sr: Visualizes DICOM Structured Reports using Viewport, Commands, and SOPClassHandler modules.
    • measurement-tracking: Tracks measurements in the measurement panel via Context, Panel, Viewport, and Commands modules.

  5. Overview of OHIF UI components and theming

    OHIF's UI is built on the ui-next component library, which uses a token-based theming system (CSS custom properties with HSL values) and Tailwind CSS.

    Components are categorized into three tiers:

    • Simple components: Atomic blocks (Button, Checkbox, Input, etc.).
    • Compound components: Complex interactions (Select, Dialog, Tabs, etc.).
    • OHIF-specific components: Medical imaging specialized tools (CinePlayer, ToolButton, etc.).

    Theme presets are defined as JSON files and applied via CSS classes to document.body.

  6. Understand OHIF Viewer deployment architecture

    The OHIF Viewer is a 'Dumb Client' Progressive Web Application (PWA) consisting of static HTML, JS, and CSS files. It does not provide medical data itself but interfaces with external data sources. It can be deployed via local networks, remote web servers, CDNs, or service-worker caches. CommonJS bundling is not supported in OHIF-v3.

  7. Implement User Account Control using Keycloak and Nginx

    To secure sensitive medical imaging data on the open web, OHIF can be deployed using an 'authenticating reverse proxy' architecture. This setup ensures that resources are only retrieved if the client is authenticated via OAuth2.

    Architecture Components:

    • Nginx: Acts as the primary reverse proxy, forwarding requests to backend services and ensuring all traffic passes through the OAuth2 Proxy.
    • OAuth2 Proxy: Intermediary that authenticates users via OAuth2 and manages sessions in conjunction with Keycloak.
    • Keycloak: Open-source Identity and Access Management (IAM) that manages user identities and validates credentials.
    • OHIF Viewer: Hosted under the /ohif-viewer route.
    • PACS (Orthanc/DCM4chee): Manages imaging data via /pacs (DICOM web services) and /pacs-admin (administrative interface).

  8. Understand OHIF v3 Architecture

    OHIF v3 is organized as a monorepo with a modular architecture designed for extensibility. The core components include:

    • @ohif/app: The framework controlling extension registration, mode composition, and routing.
    • @ohif/core: Reusable medical imaging functionality for the web.
    • @ohif/ui: A React component library for OHIF-styled applications.
    • Extensions: Building blocks that provide essential functionalities (e.g., rendering, study browsers). In v3, extensions are no longer automatic plugins but are registered to be consumed by modes.
    • Modes: Configuration objects that define how to compose extensions to build specific application workflows on different routes.
    ├── extensions        # Building blocks (e.g., cornerstone, dicom-pdf)
├── modes              # Workflow configurations (e.g., longitudinal)
├── platform
│   ├── core           # Business Logic
│   ├── i18n           # Internationalization
│   ├── ui             # React component library
│   └── app            # Framework connecting platform and extensions

  9. Migrate from OHIF v2 to v3

    Migrating from OHIF v2 to v3 involves a major re-architecture to improve modularity. Key changes include:

    • Package Rename: @ohif/viewer is now @ohif/app to align versioning with the product.
    • State Management: Redux store has been removed and replaced by the React Context API.
    • Rendering Engine: cornerstone-core and cornerstone-tools are replaced by Cornerstone3D, enabling better 3D rendering and volume streaming.
    • UI Framework: The UI has been rewritten using Tailwind CSS. Custom UI components from v2 must be migrated to Tailwind CSS.
    • Hardware Requirements: Cornerstone3D requires WebGL. Ensure target hardware supports WebGL and ideally has a GPU tier 1 or above.

  10. Understand the Viewport-Centric Segmentation Architecture

    In OHIF 3.9 (Cornerstone3D 2.0), the segmentation architecture has shifted from being tied to toolGroups to being tied directly to viewports. This allows for more granular control and a clear distinction between a 'segmentation' (the underlying data structure) and a 'segmentation representation' (how that data is visualized in a specific viewport, such as a 3D Labelmap vs. a Contour).

  11. Migrate active tool handling from OHIF 3.7 to 3.8

    The activeTool concept and its associated getter/setter have been removed. Active tools must now be derived from the toolGroup and the viewport. Remove any code that uses toolbarService.setDefaultTool() and toolbarService.recordInteraction() to activate tools. Instead, use toolbarService.addButtons() and toolbarService.createButtonSection() to define buttons and their placement.
    // Use these methods instead of setDefaultTool/recordInteraction
toolbarService.addButtons([...toolbarButtons, ...moreTools]);
toolbarService.createButtonSection("primary", [
  "MeasurementTools",
  "Zoom",
  "WindowLevel",
  "Pan",
  "Capture",
  "Layout",
  "MPR",
  "Crosshairs",
  "MoreTools",
]);

  12. Scope extension functionality using Contexts

    The @ohif/app tracks active contexts (e.g., ROUTE:VIEWER, ACTIVE_VIEWPORT:CORNERSTONE) that extensions use to scope functionality. This allows modules to conditionally show UI elements (like Toolbar buttons) or execute specific command implementations based on the current active viewport or route.