Ir al contenido principal

Image Viewer Issues

Common problems opening and reading studies in the OmegaAI Image Viewer.

Images load slowly or the viewer feels sluggish​

Symptoms

  • Long delay before the first image appears
  • Scrolling through a series stutters or lags

Likely causes

  1. Limited download bandwidth or high network latency at your location
  2. Many other applications or browser tabs consuming memory
  3. Hardware acceleration disabled in the browser
  4. The study is streaming on demand rather than being served from cache. The viewer caches images locally as you work, so the first open of a study (especially an older one pulled ad hoc) loads slower than a study you or the workstation opened recently

What to try

Warning: save your work before reloading

Reloading the viewer or restarting the workstation discards annotations and measurements that haven't been saved yet. Annotations are not saved continuously, they're written when you click Done or Done & Next, or when you save explicitly. If you have unsaved markup on screen, save it before trying any of the steps below.

  1. Close unused browser tabs and applications, then reload the viewer.
  2. Confirm graphics/hardware acceleration is enabled in your browser settings. In Chrome and Edge this is under Settings > System, labelled "Use graphics acceleration when available" in current Chrome and "Use hardware acceleration when available" in older versions and in Edge.
  3. Expect the first open of an older, ad-hoc study to be the slowest case, it streams over the network rather than coming from cache. If the same study is still slow on a second open, that points at connection or workstation limits instead.
  4. Run the OmegaAI System Check - it measures your actual connection against the recommended 1 Gbps wired connection for diagnostic reading. Upload speed matters as much as download here (see Frequently Asked Questions for the full requirements).

Still stuck? Note the study size and modality, your measured bandwidth (from the System Check above), and whether the slowness affects all studies or only large ones.

The viewer shows a black viewport or images never appear​

Symptoms

  • The viewer layout opens but one or more viewports stay black
  • An error mentioning the rendering engine appears, or the viewer becomes unresponsive

Where to look: the real cause usually shows in the browser console (press F12, or Cmd+Option+I on a Mac, then open the Console tab) as a red error - a WebGL/rendering message points to graphics; other errors point to a study or data problem. See How to Gather Diagnostics.

Likely causes

  1. The browser's graphics (WebGL) context was lost - common after the machine sleeps, the GPU driver updates, or too many GPU-heavy tabs are open
  2. An outdated or unsupported browser
  3. An outdated GPU driver

What to try

Warning: save your work first

Reloading or restarting discards unsaved annotations and measurements (they save on Done / Done & Next, not continuously). If a viewport is black but you have unsaved markup in another viewport, save before reloading.

  1. Reload the browser tab - this restores the rendering engine in most cases.
  2. Close other GPU-intensive tabs and applications (video calls, other viewers) and reopen the study.
  3. Update your browser to the latest version.
  4. Restart the workstation if the problem persists after a reload - this clears a lost GPU context at the driver level.

Still stuck? Run the OmegaAI System Check and save its report, it automatically detects your browser version and GPU model so you don't have to look those up yourself. Send support that report along with the accession number, the browser console error (F12 > Console), and whether it happens on every study or only specific ones. See How to Gather Diagnostics.

MPR or PET-CT Fusion mode is unavailable​

Symptoms

  • The MPR or Fusion tool is grayed out or missing for a study

Likely causes

  1. The series doesn't meet MPR eligibility. Two things must both be true: the modality is CT, MR, or PT, and the orientation plane is Axial, Coronal, or Sagittal. The series also needs more than one slice or frame. This is based entirely on the series' own data, there is no role-based setting that unlocks or blocks it. (See MPR for what MPR does.)
  2. The study is still transferring and the full volume has not arrived yet
  3. Fusion requires exactly two open viewports, one CT and one PET series, sharing the same Frame of Reference (co-registered acquisition)

What to try

  1. Confirm all series in the study have fully arrived before opening advanced modes.
  2. Check that you selected a volumetric (thin-slice) series - scout images and secondary captures cannot be reconstructed.
  3. For Fusion specifically, confirm the layout has exactly two viewports open, one CT and one PET (PT) series from the same, co-registered acquisition (matching Frame of Reference).

Still stuck? Provide the study's modality, series description, and slice thickness when contacting support.

Annotations or measurements are missing​

Symptoms

  • Measurements made earlier are not visible when the study is reopened
  • A colleague cannot see annotations you created

Likely causes

  1. The annotations were saved to a different presentation state than the one currently applied
  2. The viewer is displaying a different series or a reprocessed copy of the images
  3. The annotations were made but never saved - saving isn't continuous while you work, it happens when you click Done or Done & Next (which saves automatically as part of finishing the study), or via an explicit manual save
  4. The viewing user's role has no view access to Presentation State (Home > Image Viewer > QC Module > Presentation State), so saved annotations and display settings are never applied for that user

What to try

  1. Confirm you and your colleague are viewing the same series; the viewer auto-applies a single saved presentation state per study/series rather than letting you choose among several.

  2. Recreate a test annotation, then save it via Done/Done & Next or an explicit manual save, close, and reopen to confirm it persisted - if it does not, note any error shown at save time.

  3. Ask your administrator to check two separate permissions, since either can cause this:

    • Image Viewer > Measurement Panel > Annotations & Measurements - controls the annotations themselves. This is enabled by default.
    • Home > Image Viewer > QC Module > Presentation State - controls the saved display state that annotations are stored alongside. It needs view access to apply a saved state and edit access to save one.
    Note: Presentation State is off by default

    Unlike most permissions, Presentation State starts with no access at all on a new role, neither view nor edit. If annotations aren't applying or saving for a particular colleague, this is the first thing to check, and it explains why it can work for one role and not another in the same organization.

Note: once a study reaches VERIFIED status, further annotation edits may not save. Saving also requires edit access to Presentation State, so confirm that is enabled if edits made before verification aren't persisting.

Still stuck? Include the study accession number, the series number, and roughly when the annotations were created.

Images appear too dark, or the window level looks wrong​

Symptoms

  • Images (often ultrasound) open very dark or washed out until you adjust them
  • The default brightness/contrast is clearly wrong on first open

Likely causes

  1. The incoming DICOM images have no window-level values (WindowCenter/WindowWidth), so the viewer applies automatic window-leveling that doesn't suit them
  2. A window-level preset is being applied that doesn't match the study
  3. Ultrasound (HC/US) studies use the same automatic histogram-based window-leveling as other modalities, which can occasionally pick a range that looks too dark or washed out on some images

What to try

  1. Use the Window Level tool to adjust brightness/contrast, then Reset All to return to a clean baseline if a preset looks wrong.
  2. If a specific modality or scanner is always dark on arrival, the fix is at ingestion (the images arrive without window-level tags). Report the station/scanner to support - this requires an engineering-side ingestion configuration for that device, not a self-service setting, so expect it to be routed as an engineering request rather than resolved on the first call.

Still stuck? Note the modality and the specific scanner/station, and whether it affects every study from that device.

Priors don't hang, or the wrong layout loads (hanging protocols)​

Symptoms

  • Prior studies don't appear in the expected viewport
  • The wrong layout loads, or a protocol doesn't launch at all

See Hanging Protocols in OmegaAI for what a view code actually is and how protocols are configured, the terms below assume that context.

Likely causes

  1. More than one hanging protocol for the same modality is flagged as default
  2. The prior-matching rules rely on DICOM Body Part tags that aren't populated consistently
  3. A protocol has no view code selected, which prevents it from launching
  4. The hanging protocol is scoped to a different managing organization than the study being viewed, so it isn't considered a candidate for that study

What to try (protocol setup is usually an administrator task)

  1. Ask your administrator to confirm exactly one protocol per modality is set as default - remove the default flag from any duplicates.
  2. Ask your administrator to review the Prior Matching Model and match by modality rather than body part when Body Part tags are inconsistent, if priors match unreliably.
  3. Ask your administrator to check that each protocol has a view code set (use ANY if appropriate) - a blank view code stops the protocol from launching.
  4. Ask your administrator to confirm the protocol is scoped to the same managing organization as the study - a protocol scoped to a different organization won't be picked up.

Still stuck? Provide the modality, the protocol name, and an example study where the layout was wrong.

Scrolling moves between series instead of staying within one series (or vice versa)​

Symptoms

  • Scrolling through images unexpectedly jumps to the next series instead of moving through the current one, or the reverse, you expect it to move between series but it stays within one

See Mastering Hanging Protocols for where the viewport toggles live.

Likely cause

This is controlled by a Scroll Between Series toggle set per viewport within a hanging protocol, not a bug, it's a configuration choice that may not match what you expect for that protocol.

What to try

  1. Ask your administrator to open the hanging protocol's settings and select the viewport in question, the setting is a per-viewport toggle in the protocol's Toggles section, not a top-level protocol setting.
  2. Toggle Scroll Between Series to the behavior you want, then save the protocol.
  3. If the change doesn't take effect, confirm the protocol was actually saved before closing the settings panel, then reopen the study to verify.

Still stuck? Note the hanging protocol name, the affected viewport, and whether the behavior is wrong for everyone using that protocol or just you (a personal vs. shared protocol distinction matters here).