{
commandsManager.runCommand('commandName', data);
}}
/>
);
};
return [{ name: 'example', component: wrappedViewport }];
};
```
#### Example Viewport Component
A simplified version of the tracked `OHIFCornerstoneViewport` is shown below, which
creates a cornerstone viewport:
```jsx
function TrackedCornerstoneViewport({
children,
dataSource,
displaySets,
viewportId,
servicesManager,
extensionManager,
commandsManager,
}) {
return (
/** Resize Detector */
/** Div For displaying image */
e.preventDefault()}
onMouseDown={e => e.preventDefault()}
ref={elementRef}
>
An example of three cornerstone Viewports
{children}
);
}
```
#### Parameters
- `data` (required): Any data that, when changed, should trigger a recalculation of the maximum height. This can be an array, object, or primitive value.
- `buffer` (optional): Additional space (in pixels) to leave below the element. Defaults to 20px.
- `minHeight` (optional): Minimum height (in pixels) for the element. Defaults to 100px.
#### Returns
An object containing:
- `ref`: A React ref object that must be attached to the target DOM element
- `maxHeight`: A CSS-compatible string value for the calculated maximum height (e.g., "500px")
#### Implementation Details
- The hook uses `window.innerHeight` and the element's position to calculate the available space between the element's top edge and the bottom of the viewport.
- It subtracts the specified buffer from the available height to ensure there's space below the element.
- The calculated height is constrained by the specified minimum height to prevent the element from becoming too small.
- The hook uses `requestAnimationFrame` to ensure the initial calculation happens after the component has been rendered and positioned in the DOM.
- It automatically recalculates the maximum height when:
- The window is resized
- The `data`, `buffer`, or `minHeight` dependencies change
- The hook properly cleans up event listeners and animation frame requests when the component unmounts.
This hook is particularly useful for panels, menus, and content areas that need to dynamically adjust their height based on their position in the viewport, ensuring a good user experience without unexpected scrolling or content clipping.
---
### useMeasurementTracking
Source: https://docs.ohif.org/llm/platform/hooks/useMeasurementTracking.md
#### useMeasurementTracking
The `useMeasurementTracking` hook provides measurement tracking information for a specific viewport, including the tracking state and UIDs of tracked measurements associated with the viewport's series.
#### Overview
This hook gives components access to tracking information for measurements in a viewport. It monitors the tracked measurements service and measurement service to provide up-to-date tracking states and the list of measurement UIDs associated with the series displayed in the viewport.
#### Import
```js
import { useMeasurementTracking } from '@ohif/extension-cornerstone';
```
#### Usage
```jsx
function MeasurementTrackingInfo({ viewportId }) {
const {
isTracked,
isLocked,
seriesInstanceUID,
trackedMeasurementUIDs
} = useMeasurementTracking({
viewportId,
});
return (
Series UID: {seriesInstanceUID}
Tracking Status: {isTracked ? 'Tracked' : 'Not Tracked'}
Locked: {isLocked ? 'Yes' : 'No'}
Tracked Measurements: {trackedMeasurementUIDs.length}
{trackedMeasurementUIDs.map(uid => (
{uid}
))}
);
}
```
#### Parameters
- `options` - Configuration options:
- `viewportId` (required): The ID of the viewport to track
#### Returns
An object containing the following properties:
- `isTracked`: Boolean indicating if the series in the viewport is currently tracked
- `isLocked`: Boolean indicating if tracking is enabled (locked) globally
- `seriesInstanceUID`: The Series Instance UID of the background display set in the viewport
- `trackedMeasurementUIDs`: Array of measurement UIDs that are associated with the tracked series in the viewport
#### Events
The hook automatically updates when any of these events occur:
From the tracked measurements service:
- `TRACKING_ENABLED`
- `TRACKING_DISABLED`
- `TRACKED_SERIES_CHANGED`
- `SERIES_ADDED`
- `SERIES_REMOVED`
From the measurement service:
- `MEASUREMENT_ADDED`
- `RAW_MEASUREMENT_ADDED`
- `MEASUREMENT_UPDATED`
- `MEASUREMENT_REMOVED`
- `MEASUREMENTS_CLEARED`
---
### useMeasurements
Source: https://docs.ohif.org/llm/platform/hooks/useMeasurements.md
#### useMeasurements
The `useMeasurements` hook provides access to measurements from the measurement service, with automatic updates when measurements are added, updated, or removed.
#### Overview
This hook retrieves measurements from the measurement service and maps them to a display-friendly format. It monitors various measurement service events and updates the returned measurements automatically when changes occur.
#### Import
```js
import { useMeasurements } from '@ohif/extension-cornerstone';
```
#### Usage
```jsx
function MeasurementPanel() {
const measurementFilter = measurements => measurements.someFilter;
const measurements = useMeasurements({
measurementFilter,
});
return (
{measurements.map(measurement => (
{measurement.label}
{measurement.displayText.primary.map((text, i) => (
{text}
))}
))}
{isMixedPatients && (
Multiple patients loaded
)}
{patientInfo.PatientName}
ID: {patientInfo.PatientID}
Sex: {patientInfo.PatientSex}
DOB: {patientInfo.PatientDOB}
Study UID: {studyInstanceUID}
All Parameters:
{Array.from(searchParams.entries()).map(([key, value]) => (
{key}: {value}
))}
);
}
```
#### Parameters
- `options` (optional): Configuration options
- `lowerCaseKeys` - Boolean indicating whether to convert all parameter keys to lowercase (default: false)
#### Returns
A `URLSearchParams` object containing all parameters from both:
- The query string (e.g., `?param1=value1¶m2=value2`)
- The hash fragment (e.g., `#param3=value3¶m4=value4`)
If parameters with the same key exist in both the query string and hash fragment, the hash fragment values take precedence.
#### Implementation Details
- The hook uses React Router's `useLocation` to access the current URL.
- It first creates a URLSearchParams object from the location's search property.
- It then creates another URLSearchParams object from the location's hash property (excluding the leading '#').
- The parameters from the hash are added to the search parameters, overriding any duplicate keys.
- If the `lowerCaseKeys` option is enabled, it creates a new URLSearchParams object with all keys converted to lowercase.
This is particularly useful in OHIF where parameters may be specified in either the query string or hash fragment, and where case-sensitivity of parameter names might vary across different systems.
---
### useSessionStorage
Source: https://docs.ohif.org/llm/platform/hooks/useSessionStorage.md
#### useSessionStorage
The `useSessionStorage` hook provides a convenient way to store and retrieve data from the browser's sessionStorage with automatic JSON serialization and deserialization. It also offers the option to automatically clear the stored data when a page unloads.
#### Overview
This hook wraps the browser's sessionStorage API to provide a more React-friendly interface. It handles JSON serialization/deserialization automatically and maintains the stored values in local state for reactive updates. The hook also includes a unique feature to clear specific items from sessionStorage when the page unloads, which is useful for temporary session data that shouldn't persist.
#### Import
```js
import { useSessionStorage } from '@ohif/ui-next';
```
#### Usage
```jsx
function UserPreferencesPanel() {
const [preferences, setPreferences] = useSessionStorage({
key: 'viewer-preferences',
defaultValue: { theme: 'dark', fontSize: 'medium' },
clearOnUnload: false,
});
const updateTheme = (theme) => {
setPreferences({ ...preferences, theme });
};
return (
User Preferences
Current Theme: {preferences.theme}
updateTheme('light')}>Light Theme
updateTheme('dark')}>Dark Theme
);
}
function TemporaryWorkspace() {
const [workspace, setWorkspace] = useSessionStorage({
key: 'temp-workspace',
defaultValue: { annotations: [] },
clearOnUnload: true, // This data will be cleared when the page unloads
});
return (
Temporary Workspace
This workspace will be cleared when you leave the page
{/* Workspace UI components */}
);
}
```
#### Parameters
An options object with the following properties:
- `key` (required): The sessionStorage key under which to store the data
- `defaultValue` (optional): The default value to use if no data exists in sessionStorage for the given key. Defaults to an empty object (`{}`)
- `clearOnUnload` (optional): Whether to clear this item from sessionStorage when the page unloads. Defaults to `false`
#### Returns
An array containing:
1. The current value from sessionStorage (parsed from JSON)
2. A function to update the value in both state and sessionStorage
The update function automatically handles JSON stringification of the data.
#### Implementation Details
- The hook uses a global Map (`sessionItemsToClearOnUnload`) to track items that should be cleared when the page unloads.
- It utilizes the browser's `visibilitychange` event to implement the clearOnUnload feature. When the page becomes hidden (which happens both when switching tabs and when unloading), items marked for clearing are removed from sessionStorage.
- If the page later becomes visible again (e.g., when switching back to the tab), the items are restored from the Map.
- The hook's update function merges the new value with the current state using the spread operator, maintaining a similar behavior to React's `setState`.
- All data is automatically serialized to JSON before storing in sessionStorage and deserialized when retrieving.
---
### useViewportDisplaySets
Source: https://docs.ohif.org/llm/platform/hooks/useViewportDisplaySets.md
#### useViewportDisplaySets
The `useViewportDisplaySets` hook provides access to display sets associated with a viewport, organized into categories based on their role and potential usage.
#### Overview
This hook retrieves all display sets associated with a specific viewport and categorizes them into background, foreground, overlays, and potential display sets that could be added to the viewport in different roles. It allows components to efficiently access and manage viewport display sets for various UI interactions like layer menus and display set selectors.
#### Import
```js
import { useViewportDisplaySets } from '@ohif/extension-cornerstone';
```
#### Usage
```jsx
function ViewportLayerControls({ viewportId }) {
const {
backgroundDisplaySet,
foregroundDisplaySets,
overlayDisplaySets,
potentialOverlayDisplaySets,
potentialForegroundDisplaySets,
potentialBackgroundDisplaySets,
} = useViewportDisplaySets(viewportId);
return (
Background
{backgroundDisplaySet?.SeriesDescription}
Foreground ({foregroundDisplaySets.length})
{foregroundDisplaySets.map(ds => (
{ds.SeriesDescription}
))}
Overlays ({overlayDisplaySets.length})
{overlayDisplaySets.map(ds => (
{ds.SeriesDescription}
))}
Available Overlays ({potentialOverlayDisplaySets.length})
{potentialOverlayDisplaySets.map(ds => (
{ds.SeriesDescription}
))}
);
}
```
#### Parameters
- `viewportId` (optional): The ID of the viewport to get display sets for. If not provided, uses the active viewport.
- `options` (optional): Configuration options to control which display sets to include:
- `includeBackground`: Whether to include the background display set (default: true)
- `includeForeground`: Whether to include foreground display sets (default: true)
- `includeOverlay`: Whether to include overlay display sets (default: true)
- `includePotentialOverlay`: Whether to include potential overlay display sets (default: true)
- `includePotentialForeground`: Whether to include potential foreground display sets (default: true)
- `includePotentialBackground`: Whether to include potential background display sets (default: true)
#### Returns
An object containing requested display set collections based on options:
- `allDisplaySets`: All display sets in the viewer (only if requested)
- `viewportDisplaySets`: The display sets currently in the viewport
- `backgroundDisplaySet`: The primary display set for the viewport (base image)
- `foregroundDisplaySets`: Display sets currently shown with background (non-overlay layers)
- `overlayDisplaySets`: Segmentation display sets currently applied as overlays
- `potentialOverlayDisplaySets`: Display sets that could be toggled on as overlays (derived modalities)
- `potentialForegroundDisplaySets`: Display sets that could be added as foreground layers
- `potentialBackgroundDisplaySets`: Display sets that could replace the current background
Each property is only included if the corresponding option is true.
#### Implementation Details
- The hook automatically adapts to viewport changes through the `useViewportGrid` hook.
- It only fetches and processes display sets that are needed based on the provided options.
- Display sets are categorized based on their modality and properties.
- Potential display sets are sorted by priority to present the most relevant options first.
- Derived overlay modalities (like SEG, SR) are treated differently than other display sets.
- The hook uses memoization extensively to optimize performance and prevent unnecessary recalculations.
---
### useViewportHover
Source: https://docs.ohif.org/llm/platform/hooks/useViewportHover.md
#### useViewportHover
The `useViewportHover` hook provides information about whether the mouse is currently hovering over a specific viewport and whether that viewport is active.
#### Overview
This hook monitors mouse movement to track hover state over a viewport element by its ID. It also checks whether the viewport is currently active (selected) in the viewer. This is useful for implementing conditional UI elements or behaviors that depend on user interaction with viewports.
#### Import
```js
import { useViewportHover } from '@ohif/extension-cornerstone';
```
#### Usage
```jsx
function ViewportOverlay({ viewportId }) {
const { isHovered, isActive } = useViewportHover(viewportId);
return (
{isHovered && !isActive && (
Click to activate
)}
{isActive && (
Active viewport controls
)}
Segmentations not available for this modality
;
}
if (!segmentationsWithRepresentations.length) {
return No segmentations available
;
}
return (
{segmentationsWithRepresentations.map(({ segmentation, representation }) => (
{segmentation.label}
{Object.entries(segmentation.segments).map(([segmentIndex, segment]) => (
{segment.label}
{segment.displayText.primary.map((text, i) => (
{text}
))}
))}
))}
Manager
Description
Extension Manager
Aggregating and exposing modules and features through out the app
Services Manager
Single point of registration for all internal and external services
Commands Manager
Register commands with specific context and run commands in the app
Hotkeys Manager
For keyboard keys assignment to commands
[core-services]: https://github.com/OHIF/Viewers/tree/master/platform/core/src/services
[services-manager]: https://github.com/OHIF/Viewers/blob/master/platform/core/src/services/ServicesManager.js
[cross-cutting-concerns]: https://en.wikipedia.org/wiki/Cross-cutting_concern
---
### Service Manager
Source: https://docs.ohif.org/llm/platform/managers/service.md
#### Services Manager
#### Overview
Services manager is the single point of service registration. Each service needs
to implement a `create` method which gets called inside `ServicesManager` to
instantiate the service. In the app, you can get access to a registered service
via the `services` property of the `ServicesManager`.
#### Skeleton
_Simplified_ skeleton of `ServicesManager` is shown below. There are two public
methods:
- `registerService`: registering a new service with/without a configuration
- `registerServices`: registering batch of services
```js
export default class ServicesManager {
constructor(commandsManager) {
this._commandsManager = commandsManager;
this.services = {};
this.registeredServiceNames = [];
}
registerService(service, configuration = {}) {
/** validation checks **/
this.services[service.name] = service.create({
configuration,
commandsManager: this._commandsManager,
});
/* Track service registration */
this.registeredServiceNames.push(service.name);
}
registerServices(services) {
/** ... **/
}
}
```
#### Default Registered Services
By default, `OHIF-v3` registers the following services in the `appInit`.
```js title="platform/app/src/appInit.js"
servicesManager.registerServices([
CustomizationService,
UINotificationService,
UIModalService,
UIDialogService,
UIViewportDialogService,
MeasurementService,
DisplaySetService,
ToolBarService,
ViewportGridService,
HangingProtocolService,
CineService,
]);
```
#### Service Architecture
If you take a look at the folder of each service implementation above, you will
find out that services need to be exported as an object with `name` and `create`
method.
For instance, `ToolBarService` is exported as:
```js title="platform/core/src/services/ToolBarService/index.js"
import ToolBarService from './ToolBarService';
export default {
name: 'ToolBarService',
create: ({ configuration = {}, commandsManager }) => {
return new ToolBarService(commandsManager);
},
};
```
and the implementation of `ToolBarService` lies in the same folder at
`./ToolbarSerivce.js`.
> Note: The create method is critical for any custom service that you write and
> want to add to the list of services
> Note: For typescript definitions, the service type should be exported
> as part of the Types export on the module. This is recommended going forward
> and existing services will be migrated. As well, the capitalization of the
> name should be lower camel case, with the type being upper camel case. In
> the above example, the service instance should be `toolBarService` with the
> class being `ToolBarService`.
#### Accessing Services
Throughout the app you can use `services` property of the service manager to
access the desired service.
For instance in the `PanelMeasurementTableTracking` which is the right panel in
the `longitudinal` mode, we have the _simplified code below_ for downloading the
drawn measurements.
```js
function PanelMeasurementTableTracking({ servicesManager }) {
const { MeasurementService } = servicesManager.services;
/** ... **/
async function exportReport() {
const measurements = MeasurementService.getMeasurements();
/** ... **/
downloadCSVReport(measurements, MeasurementService);
}
/** ... **/
return <> /** ... **/ ;
}
```
#### Registering Custom Services
You might need to write you own custom service in an extension.
`preRegistration` hook inside your extension is the place for registering your
custom service.
```js title="extensions/customExtension/src/index.js"
import WrappedBackEndService from './services/backEndService';
export default {
// ID of the extension
id: 'myExtension',
preRegistration({ servicesManager }) {
servicesManager.registerService(WrappedBackEndService(servicesManager));
},
};
```
and the logic for your service shall be
```js title="extensions/customExtension/src/services/backEndService/index.js"
// Canonical name of upper camel case BackEndService for the class
import BackEndService from './BackEndService';
export default function WrappedBackEndService(servicesManager) {
return {
// Note the canonical name of lower camel case backEndService
name: 'backEndService',
create: ({ configuration = {} }) => {
return new BackEndService(servicesManager);
},
};
}
```
with implementation of
```ts
export default class BackEndService {
constructor(servicesManager) {
this.servicesManager = servicesManager;
}
putAnnotations() {
return post(/*...*/);
}
}
```
with a registration of
```ts title="types/index.ts"
import BackEndService from "../services/BackEndService/BackEndService";
export { BackEndService };
```
#### Service Mode Lifecycle
Services may implement initialization and cleanup for mode specific data.
In order to prevent defects where there are differences between initial
and subsequent displays of a study, the contract of the service is that the
state the service is in on mode entry shall be the same whether the mode was
entered or was exited and entered again.
To implement storage/recovery of state, the mode must store the data on
exiting the mode, and restore the data in it's onModeEnter. For example,
the mode may decide to preserve measurement data in the onModeExit, and
to restore it in the onModeEnter. This does not violate the contract since
it is the mode's decision to apply the stored state, and to cache it.
#### onModeEnter
A service may implement an onModeEnter call to initialize the service to
be ready for entering a mode.
This is called before the mode `onModeEnter` is called.
#### onModeExit
When entering a mode, the service contract states that the service needs to
be in the same state whether it is a fresh load or has previously entered the mode.
The onModeExit allows a service to clean itself up after the mode 'onModeExit'
has stored any persistent data.
---
## Modes
### Modes Introduction
Source: https://docs.ohif.org/llm/platform/modes/index.md
#### Modes
#### Overview
A mode can be thought of as a viewer app configured to perform a specific task,
such as tracking measurements over time, 3D segmentation, a guided radiological
workflow, etc. Addition of modes enables _application_ with many _applications_
as each mode become a mini _app configuration_ behind the scene.
Upon initialization the viewer will consume extensions and modes and build up
the route desired, these can then be accessed via the study list, or directly
via url parameters.
OHIF-v3 architecture can be seen in the following:
> Note: Templates are now a part of “extensions” Routes are configured by modes
> and/or app
As mentioned, modes are tied to a specific route in the viewer, and multiple
modes/routes can be present within a single application. This allows for
tremendously more flexibility than before you can now:
- Simultaneously host multiple viewers with for different use cases from within
the same app deploy.
- Make radiological viewers for specific purposes/workflows, e.g.:
- Tracking the size of lesions over time.
- PET/CT fusion workflows.
- Guided review workflows optimized for a specific clinical trial.
- Still host one single feature-rich viewer if you desire.
#### Anatomy
A mode configuration has a `route` name which is dynamically transformed into a
viewer route on initialization of the application. Modes that are available to a
study will appear in the study list.
The mode configuration specifies which `extensions` the mode requires, which
`LayoutTemplate` to use, and what props to pass to the template. For the default
template this defines which `side panels` will be available, as well as what
`viewports` and which `displaySets` they may hang.
Mode's config is composed of three elements:
- `id`: the mode `id`
- `modeFactory`: the function that returns the mode specific configuration
- `extensionDependencies`: the list of extensions that the mode requires
that return a config object with certain
properties, the high-level view of this config object is:
```js title="modes/example/src/index.js"
function modeFactory() {
return {
id: '',
version: '',
displayName: '',
onModeEnter: () => {},
onModeExit: () => {},
validationTags: {},
isValidMode: () => {},
routes: [
{
path: '',
init: () => {},
layoutTemplate: () => {},
},
],
extensions: extensionDependencies,
hangingProtocol: [],
sopClassHandlers: [],
hotkeys: []
};
}
const mode = {
id,
modeFactory,
extensionDependencies,
};
export default mode;
```
Property
Description
id
unique mode id used to refer to the mode
displayName
actual name of the mode being displayed for each study in the study summary panel
onModeEnter
hook is called when the mode is entered by the specified route
onModeExit
hook is called when the mode exited
validationTags
validationTags
isValidMode
Checks if the mode is valid for a study
routes
route config which defines the route address, and the layout for it
extensionDependencies
extensions needed by the mode
hanging protocol
list of hanging protocols that the mode should have access to
sopClassHandlers
list of SOPClass modules needed by the mode
hotkeys
hotkeys
#### Consuming Extensions
As mentioned in the [Extensions](../extensions/index.md) section, in `OHIF-v3`
developers write their extensions to create reusable functionalities that later
can be used by `modes`. Now, it is time to describe how the registered
extensions will get utilized for a workflow mode via its `id`.
Each `mode` has a list of its `extensions dependencies` which are the
the `extension` name and version number. In addition, to use a module element you can use the
`${extensionId}.${moduleType}.${element.name}` schema. For instance, if a mode
requires the left panel with name of `AIPanel` that is added by the
`myAIExtension` via the following `getPanelModule` code, it should address it as
`myAIExtension.panelModule.AIPanel` inside the mode configuration file. In the
background `OHIF` will handle grabbing the correct panel via `ExtensionManager`.
```js title="extensions/myAIExtension/getPanelModule.js"
import PanelAI from './PanelAI.js';
function getPanelModule({
commandsManager,
extensionManager,
servicesManager,
}) {
const wrappedAIPanel = () => {
return (
Hello Custom Route ,
},
],
},
},
},
},
]
```
Then after you define the module, you can add it to the customizationService in the AppConfig and reference it by the name you provided.
```js
customizationService: [
// Shows a custom route -access via http://localhost:3000/custom
'@ohif/extension-default.customizationModule.helloPage',
],
```
You can provide multiple custom routes in the same module, for instance another extension can also push to the routes array.
```js
export default function getCustomizationModule({ servicesManager, extensionManager }) {
return [
{
name: 'secondPage',
value: {
customRoutes: {
routes: {
$push: [
{
path: '/second',
children: () => Hello Second Route ,
},
],
},
},
},
},
]
}
```
Then you can add it to the customizationService in the AppConfig and reference it by the name you provided.
```js
customizationService: [
// Shows a custom route -access via http://localhost:3000/custom
'@ohif/extension-default.customizationModule.helloPage',
// Shows a custom route -access via http://localhost:3000/second
'@ohif/extension-default.customizationModule.secondPage',
],
```
---
### Customization Service
Source: https://docs.ohif.org/llm/platform/services/customization-service/customizationService.md
import { customizations, TableGenerator } from './sampleCustomizations';
import Heading from '@theme/Heading';
import TOCInline from '@theme/TOCInline';
#### Customization Service
There are a lot of places where users may want to configure certain elements
differently between different modes or for different deployments. A mode
example might be the use of a custom overlay showing mode related DICOM header
information such as radiation dose or patient age.
The use of `customizationService` enables these to be defined in a typed fashion by
providing an easy way to set default values for this, but to allow a
non-default value to be specified by the configuration or mode.
:::note
`customizationService` itself doesn't implement the actual customization,
but rather just provide mechanism to register reusable prototypes, to configure
those prototypes with actual configurations, and to use the configured objects
(components, data, whatever).
Actual implementation of the customization is totally up to the component that
supports customization.
:::
#### General Overview
This framework allows you to configure many features, or "slots," through customization modules. Extensions can choose to offer their own module, which outlines which values can be changed. By looking at each extension's getCustomizationModule(), you can see which objects or components are open to customization.
Below is a high-level example of how you might define a default customization and then consume and override it:
1. **Defining a Customizable Default**
In your extension, you might export a set of default configurations (for instance, a list that appears in a panel). Here, you provide an identifier and store the default list under that identifier. This makes the item discoverable by the customization service:
```js
// Inside your extension’s customization module
export default function getCustomizationModule() {
return [
{
name: 'default',
value: {
defaultList: ['Item A', 'Item B'],
},
},
];
}
```
By naming it `default`, it is automatically registered.
:::info
You might want to have customizations ready to use in your application without actually applying them. In such cases, you can name them something other than `default`. For example, in your mode, you can do this:
```js
customizationService.setCustomizations([
'@ohif/extension-cornerstone-dicom-seg.customizationModule.dicom-seg-sorts',
]);
```
This is really useful when you want to apply a set of customizations as a pack, kind of like a bundle.
:::
3. **Retrieving the Default Customization**
In the panel or component (or whatever) that needs the list, you retrieve it using `getCustomization`:
```js
const myList = customizationService.getCustomization('defaultList');
// If unmodified, this returns ['Item A', 'Item B']
```
This allows your component to always fetch the most current version (original default or overridden).
4. **Overriding from Outside**
To customize this list outside your extension, call `setCustomizations` with the identifier (`'defaultList'`). For example, a mode can modify the list to add or change items:
```js
// From within a mode (or globally)
customizationService.setCustomizations({
'defaultList': {
$set: ['New Item 1', 'New Item 2'],
},
});
```
The next time any panel calls `getCustomization('defaultList')`, it will get the updated list.
Don't worry we will go over the `$set` syntax in more detail later.
---
#### Scope of Customization
Customizations can be declared at three different scopes, each with its own priority and lifecycle. These scopes determine how and when customizations are applied.
#### 1. **Default Scope**
- **Purpose**: Establish baseline or "fallback" values that extensions provide.
- **Options**:
1. **Via Extensions**:
- Implement a `getCustomizationModule` function in your extension and name it `default`.
```tsx
function getCustomizationModule() {
return [
{
name: 'default',
value: {
'studyBrowser.sortFunctions': {
$set: [
{
label: 'Default Sort Function',
sortFunction: (a, b) => a.SeriesDate - b.SeriesDate,
},
],
},
},
},
];
}
```
2. **Using the `setCustomizations` Method**:
- Call `setCustomizations` in your application and specify `CustomizationScope.Default` as the second argument:
```tsx
customizationService.setCustomizations(
{
'studyBrowser.sortFunctions': {
$set: [
{
label: 'Default Sort Function',
sortFunction: (a, b) => a.SeriesDate - b.SeriesDate,
},
],
},
},
CustomizationScope.Default
);
```
#### 2. **Mode Scope**
- **Purpose**: Apply customizations specific to a particular mode.
- **Lifecycle**: These customizations are cleared or reset when switching between modes.
- **Example**: Use the `setCustomizations` method to define mode-specific behavior.
```tsx
customizationService.setCustomizations({
'studyBrowser.sortFunctions': {
$set: [
{
label: 'Mode-Specific Sort Function',
sortFunction: (a, b) => b.SeriesDate - a.SeriesDate,
},
],
},
});
```
#### 3. **Global Scope**
- **Purpose**: Apply system-wide customizations that override both default and mode-scoped values.
- **How to Configure**:
1. Add global customizations directly to the application's configuration file:
```jsx
window.config = {
name: 'config/default.js',
routerBasename: null,
customizationService: [
{
'studyBrowser.sortFunctions': {
$push: [
{
label: 'Global Sort Function',
sortFunction: (a, b) => b.SeriesDate - a.SeriesDate,
},
],
},
},
],
};
```
2. Use Namespaced Extensions:
- Instead of directly specifying customizations in the configuration, you can refer to a predefined customization module within an extension:
```jsx
window.config = {
name: 'config/default.js',
routerBasename: null,
customizationService: [
'@ohif/extension-cornerstone.customizationModule.newCustomization',
],
};
```
- In this example, the `newCustomization` module within the `@ohif/extension-cornerstone` extension contains the global customizations. The application will load and apply these settings globally.
```tsx
function getCustomizationModule() {
return [
{
name: 'newCustomization',
value: {
'studyBrowser.sortFunctions': {
$push: [
{
label: 'Global Namespace Sort Function',
sortFunction: (a, b) => b.SeriesDate - a.SeriesDate,
},
],
},
},
},
];
}
```
#### Priority of Scopes
When a customization is retrieved:
1. **Global Scope**: Takes precedence if defined.
2. **Mode Scope**: Used if no global customization is defined.
3. **Default Scope**: Fallback when neither global nor mode-specific values are available.
As you have guessed the `.setCustomizations` accept a second argument which is the scope. By default it is set to `mode`.
#### Customization Syntax
The customization syntax is designed to offer **flexibility** when modifying configurations. Instead of simply replacing values, you can perform granular updates like appending items to arrays, inserting at specific indices, updating deeply nested fields, or applying filters. This flexibility ensures that updates are efficient, targeted, and suitable for complex data structures.
Why a Special Syntax?
Traditional value replacement might not be ideal in scenarios such as:
- **Appending or prepending** to an existing list instead of overwriting it.
- **Selective updates** for specific fields in an object without affecting other fields.
- **Filtering or merging** nested items in arrays or objects while preserving other parts.
To address these needs, the customization service uses a **special syntax** inspired by [immutability-helper](https://github.com/kolodny/immutability-helper) commands. Below are examples of each operation.
---
#### 1. Replace a Value (`$set`)
Use `$set` to entirely replace a value. This is the simplest operation which would replace the entire value.
```js
// Before: someKey = 'Old Value'
customizationService.setCustomizations({
someKey: { $set: 'New Value' },
});
// After: someKey = 'New Value'
```
Example with study browser:
```js
// Before: studyBrowser.sortFunctions = []
customizationService.setCustomizations({
'studyBrowser.sortFunctions': {
$set: [
{
label: 'Sort by Patient ID',
sortFunction: (a, b) => a.PatientID.localeCompare(b.PatientID),
},
],
},
});
// After: studyBrowser.sortFunctions = [{label: 'Sort by Patient ID', sortFunction: ...}]
```
---
#### 2. Add to an Array (`$push` and `$unshift`)
- **`$push`**: Appends items to the end of an array.
- **`$unshift`**: Adds items to the beginning of an array.
```js
// Before: NumbersList = [1, 2, 3]
// Push items to the end
customizationService.setCustomizations({
'NumbersList': { $push: [5, 6] },
});
// After: NumbersList = [1, 2, 3, 5, 6]
// Unshift items to the front
customizationService.setCustomizations({
'NumbersList': { $unshift: [0] },
});
// After: NumbersList = [0, 1, 2, 3, 5, 6]
```
---
#### 3. Insert at Specific Index (`$splice`)
Use `$splice` to insert, replace, or remove items at a specific index in an array.
```js
// Before: NumbersList = [1, 2, 3]
customizationService.setCustomizations({
'NumbersList': {
$splice: [
[2, 0, 99], // Insert 99 at index 2
],
},
});
// After: NumbersList = [1, 2, 99, 3]
```
---
#### 4. Merge Object Properties (`$merge`)
Use `$merge` to update specific fields in an object without affecting other fields.
```js
// Before: SeriesInfo = { label: 'Original Label', sortFunction: oldFunc }
customizationService.setCustomizations({
'SeriesInfo': {
$merge: {
label: 'Updated Label',
extraField: true,
},
},
});
// After: SeriesInfo = { label: 'Updated Label', sortFunction: oldFunc, extraField: true }
```
Example with nested merge:
```js
// Before: SeriesInfo = { advanced: { subKey: 'oldValue' } }
customizationService.setCustomizations({
'SeriesInfo': {
advanced: {
$merge: {
subKey: 'updatedSubValue',
},
},
},
});
// After: SeriesInfo = { advanced: { subKey: 'updatedSubValue' } }
```
---
#### 5. Apply a Function (`$apply`)
Use `$apply` when you need to compute the new value dynamically.
```js
// Before: SeriesInfo = { label: 'Old Label', data: 123 }
customizationService.setCustomizations({
'SeriesInfo': {
$apply: oldValue => ({
...oldValue,
label: 'Computed Label',
}),
},
});
// After: SeriesInfo = { label: 'Computed Label', data: 123 }
```
---
#### 6. Filter and Modify (`$filter`)
Use `$filter` to find specific items in arrays (or objects) and apply changes.
```js
// Before: advanced = {
// functions: [
// { id: 'seriesDate', label: 'Original Label' },
// { id: 'other', label: 'Other Label' }
// ]
// }
customizationService.setCustomizations({
'advanced': {
$filter: {
match: { id: 'seriesDate' },
$merge: {
label: 'Updated via Filter',
},
},
},
});
// After: advanced = {
// functions: [
// { id: 'seriesDate', label: 'Updated via Filter' },
// { id: 'other', label: 'Other Label' }
// ]
// }
```
:::note
Note `$filter` will look recursively for
an object that matches the `match` criteria and then apply the `$merge` or `$set` operation to it.
Note in the example above we are not doing anything with the `functions` array.
:::
Example with deeply nested filter:
```js
// Before: advanced = {
// functions: [{
// id: 'seriesDate',
// viewFunctions: [
// { id: 'axial', label: 'Original Axial' }
// ]
// }]
// }
customizationService.setCustomizations({
'advanced': {
$filter: {
match: { id: 'axial' },
$merge: {
label: 'Axial (via Filter)',
},
},
},
});
// After: advanced = {
// functions: [{
// id: 'seriesDate',
// viewFunctions: [
// { id: 'axial', label: 'Axial (via Filter)' }
// ]
// }]
// }
```
---
#### Summary of Commands
| **Command** | **Purpose** | **Example** |
|-------------|-----------------------------------------------|---------------------------------------|
| `$set` | Replace a value entirely | Replace a list or object |
| `$push` | Append items to an array | Add to the end of a list |
| `$unshift` | Prepend items to an array | Add to the start of a list |
| `$splice` | Insert, remove, or replace at specific index | Modify specific indices in a list |
| `$merge` | Update specific fields in an object | Change a subset of fields |
| `$apply` | Compute the new value dynamically | Apply a function to transform values |
| `$filter` | Find and update specific items in arrays | Target nested structures |
| `$transform`| Apply a function to transform the customization | Apply a function to transform values |
#### Building Customizations Across Multiple Extensions
Sometimes it is useful to build customizations across multiple extensions. For example, you may want to build a default list of tools inside a vieweport. But then each extension may want to add their own tools to the list.
Lets say i have one default sorting function in my default extension.
```js
function getCustomizationModule() {
return [
{
name: 'default',
value: {
'studyBrowser.sortFunctions': [
{
label: 'Series Number',
sortFunction: (a, b) => {
return a?.SeriesNumber - b?.SeriesNumber;
},
},
],
},
},
];
}
```
This will result in having only series number as the default sorting function.
but now in another extension let's say dicom-seg extension we can add another sorting function.
```js
function getCustomizationModule() {
return [
{
name: "dicom-seg-sorts",
value: {
"studyBrowser.sortFunctions": {
$push: [
{
label: "Series Date",
sortFunction: (a, b) => {
return a?.SeriesDate - b?.SeriesDate;
},
},
],
},
},
},
];
}
```
But since the module is not `default` it will not get applied, but in my segmentation mode i can do
```js
onModeEnter() {
customizationService.setCustomizations([
'@ohif/extension-cornerstone-dicom-seg.customizationModule.dicom-seg-sorts',
]);
}
```
needless to say if you opted to choose `name: default` in the `getCustomizationModule` it was applied globally.
#### Customizable Parts of OHIF
Below we are providing the example configuration for global scenario (using the configuration file), however, you can also use the `setCustomizations` method to set the customizations.
{TableGenerator(customizations)}
---
### Viewport Overlay Customization
Source: https://docs.ohif.org/llm/platform/services/customization-service/viewportOverlay.md
import { viewportOverlayCustomizations , TableGenerator } from './sampleCustomizations';
#### Viewport Overlay
Viewport Overlays are the information that is displayed on the viewport.
There are 4 viewport overlays customization end points
- `viewportOverlay.topRight`
- `viewportOverlay.topLeft`
- `viewportOverlay.bottomLeft`
- `viewportOverlay.bottomRight`
{TableGenerator(viewportOverlayCustomizations)}
---
## Services/data
### DICOM Metadata Store
Source: https://docs.ohif.org/llm/platform/services/data/DicomMetadataStore.md
#### DICOM Metadata Store
#### Overview
`DicomMetaDataStore` is the central location that stores the metadata in `OHIF-v3`. There
are several APIs to add study/series/instance metadata and also for getting from the store.
DataSource utilize the `DicomMetaDataStore` to add the retrieved metadata to `OHIF Viewer`.
> In `OHIF-v3` we have significantly changed the architecture of the metadata storage to
> provide a much cleaner way of handling metadata-related tasks and services. Classes such as
> `OHIFInstanceMetadata`, `OHIFSeriesMetadata` and `OHIFStudyMetadata` has been removed and
> replaced with `DicomMetaDataStore`.
>
#### Events
There are two events that get publish in `DicomMetaDataStore`:
| Event | Description |
|-----------------|------------------------------------------------------------------------------------------------|
| SERIES_ADDED | Fires when all series of one study have added their summary metadata to the `DicomMetaDataStore` |
| INSTANCES_ADDED | Fires when all instances of one series have added their metadata to the `DicomMetaDataStore` |
#### API
Let's find out about the public API for `DicomMetaDataStore` service.
- `EVENTS`: Object including the events mentioned above. You can subscribe to these events
by calling DicomMetaDataStore.subscribe(EVENTS.SERIES_ADDED, myFunction). [Read more about pub/sub pattern here](../pubsub.md)
- `addInstances(instances, madeInClient = false)`: adds the instances' metadata to the store. madeInClient is explained in detail below. After
adding to the store it fires the EVENTS.INSTANCES_ADDED.
- `addSeriesMetadata(seriesSummaryMetadata, madeInClient = false)`: adds series summary metadata. After adding it fires EVENTS.SERIES_ADDED
- `addStudy(study)`: creates and add study-level metadata to the store.
- `getStudy(StudyInstanceUID)`: returns the study metadata from the store. It includes all the series and instance metadata in the requested study
- `getSeries(StudyInstanceUID, SeriesInstanceUID`: returns the series-level metadata for the requested study and series UIDs.
- `getInstance(StudyInstanceUID, SeriesInstanceUID, SOPInstanceUID)`: returns the instance metadata based on the study, series and sop instanceUIDs.
- `geteInstanceFromImageId`: returns the instance metadata based on the requested imageId. It searches the store for the instance that has the same imageId.
#### madeInClient
Since upon adding the metadata to the store, the relevant events are fired, and there are
other services that are subscribed to these events (`HangingProtocolService` or `DisplaySetService`), sometimes
we want to add instance metadata but don't want the events to get fired. For instance, when
you are caching the data for the next study in advance, you probably don't want to trigger hanging protocol
logic, so you set `madeInClient=true` to not fire events.
#### Storage
As discussed before, there are several API that enables getting metadata from the store and adding to the store.
However, it is good to have an understanding of where they get
stored and in what format and hierarchy. `_model` is a private variable in the store
which holds all the metadata for all studies, series, and instances, and it looks like:
```js title="platform/core/src/services/DicomMetadataStore/DicomMetadataStore.js"
const _model = {
studies: [
{
/** Study Metadata **/
seriesLists: [
{
// Series in study from dicom web server 1 (or different backend 1)
series: [
{
// Series 1 Metadata
instances: [
{
// Instance 1 metadata of Series 1
},
{
// Instance 2 metadata of Series 1
},
/** Other instances metadata **/
],
},
{
// Series 2 Metadata
instances: [
{
// Instance 1 metadata of Series 2
},
{
// Instance 2 metadata of Series 1
},
/** Other instances metadata **/
],
},
],
},
{
// Series in study from dicom web server 2 (or different backend 2)
/** ... **/
},
],
},
],
}
```
---
### DisplaySet Service
Source: https://docs.ohif.org/llm/platform/services/data/DisplaySetService.md
#### DisplaySet Service
#### Overview
`DisplaySetService` handles converting the `instanceMetadata` into `DisplaySet` that `OHIF` uses for the visualization. `DisplaySetService` gets initialized at service startup time, but is then cleared in the `Mode.jsx`. During the initialization `SOPClassHandlerIds` of the `modes` gets registered with the `DisplaySetService`.
:::tip
DisplaySet is a general set of entities and contains links to bunch of displayable objects (images, etc.) Some series might get split up into different displaySets e.g., MG might have mixed views in a single series, but users might want to have separate LCC, RCC, etc. for hanging protocol usage. A viewport renders a display set into a displayable object.
An imageSet is a particular implementation of image displays.
- Learn more about Study (https://www.dicomstandard.org/standards/view/information-object-definitions#sect_A.1.2.2)
- Learn more about Series (https://www.dicomstandard.org/standards/view/information-object-definitions#sect_A.1.2.3)
:::
> Based on the instanceMetadata's `SOPClassHandlerId`, the correct module from the registered extensions is found by `OHIF` and its `getDisplaySetsFromSeries` runs to create a DisplaySet for the Series. Note
that this is an ordered operation, and consumes the instances as it proceeds, with the first registered
handlers being able to consume instances first.
DisplaySets are created synchronously when the instances metadata is retrieved and added to the [DicomMetaDataStore](../data//DicomMetadataStore.md). They are ALSO updated when
the DicommetaDataStore receives new data. This update first checks the addInstances
of existing `DisplaySet` values to see if the new instance belongs in an existing set.
Then, the same process is used as was originally done to create new display sets.
NOTE: Any instances not matched are NOT added to any display set and will not be displayed.
:::::info[Clarification of Terminology]
Display Sets, which are custom to OHIF, are often confused with different DICOM terms, including study, series, and instances. The following are definitions for these terms to alleviate confusion.
}
}
)
```
#### Segmentation Management
```typescript
setActiveSegmentation(viewportId, segmentationId)
getSegmentations()
getSegmentation(segmentationId)
jumpToSegmentCenter(segmentationId, segmentIndex, viewportId)
highlightSegment(segmentationId, segmentIndex, viewportId)
```
#### Segment Operations
```typescript
addSegment(segmentationId, {
segmentIndex?: number,
label?: string,
color?: [number, number, number, number], // RGBA
visibility?: boolean,
isLocked?: boolean,
active?: boolean
})
setSegmentColor(viewportId, segmentationId, segmentIndex, color)
setSegmentVisibility(viewportId, segmentationId, segmentIndex, visibility)
```
#### Data Structures
#### Segmentation Object
```typescript
interface Segmentation {
segmentationId: string;
label: string;
segments: {
[segmentIndex: number]: {
segmentIndex: number;
label: string;
locked: boolean;
cachedStats: { [key: string]: unknown };
active: boolean;
}
};
representationData: RepresentationsData;
}
```
#### Code Examples
#### Creating a Segmentation
```typescript
const displaySet = displaySetService.getDisplaySetByUID(displaySetUID);
const segmentationId = await segmentationService.createLabelmapForDisplaySet(
displaySet,
{
label: 'New Segmentation',
segments: {
1: {
label: 'First Segment',
active: true
}
}
}
);
```
#### Managing Active Segmentations
```typescript
segmentationService.setActiveSegmentation('viewport-1', segmentationId);
```
#### Adding Segments
```typescript
segmentationService.addSegment(segmentationId, {
label: 'Tumor',
color: [255, 0, 0, 255], // RGBA format
active: true
});
```
#### Visibility Management
```typescript
// Set segment visibility
segmentationService.setSegmentVisibility(
'viewport-1',
segmentationId,
1, // segmentIndex
true // visible
);
// Get viewport IDs with segmentation
const viewportIds = segmentationService.getViewportIdsWithSegmentation(segmentationId);
```
#### Segment Styling
```typescript
// Set segment color
segmentationService.setSegmentColor(
'viewport-1',
segmentationId,
1, // segmentIndex
[255, 0, 0, 255] // RGBA
);
```
---
### SyncGroup Service
Source: https://docs.ohif.org/llm/platform/services/data/SyncGroupService.md
#### Sync Group Service
#### Overview
The `SyncGroupService` is responsible for managing synchronization groups in the OHIF Viewer. Synchronization groups allow multiple viewports to be synchronized based on various criteria, such as camera position, window level, zoom/pan, and image slice position. This service provides a centralized way to create, update, and manage synchronization groups.
Right now, synchronization groups can be defined in the hanging protocols or manually assigning buttons.
#### API
- `getSyncCreatorForType(type)`: Returns the synchronizer creator function for the specified type.
- `addSynchronizerType(type, creator)`: Adds a new synchronizer type with a custom creator function.
- `getSynchronizer(id)`: Retrieves a synchronizer by its ID.
- `getSynchronizersOfType(type)`: Retrieves an array of synchronizers of the specified type.
- `addViewportToSyncGroup(viewportId, renderingEngineId, syncGroups)`: Adds a viewport to one or more synchronization groups.
- `destroy()`: Destroys all synchronizers.
- `getSynchronizersForViewport(viewportId)`: Retrieves an array of synchronizers associated with the specified viewport.
- `removeViewportFromSyncGroup(viewportId, renderingEngineId, syncGroupId?)`: Removes a viewport from a specific synchronization group or all synchronization groups if no group ID is provided.
#### Usage
#### Via hanging protocols
You can set up different types of synchronization groups for your viewports. For example, in the TMTV hanging protocol (`extensions/tmtv/src/getHangingProtocolModule.js`), we can see how different synchronization groups are defined for various viewports:
```javascript
const ptAXIAL = {
viewportOptions: {
// ...
syncGroups: [
{
type: 'cameraPosition',
id: 'axialSync',
source: true,
target: true,
},
{
type: 'voi',
id: 'ptWLSync',
source: true,
target: true,
},
{
type: 'voi',
id: 'ptFusionWLSync',
source: true,
target: false,
options: {
syncInvertState: false,
},
},
],
},
// ...
};
```
In this example, the `ptAXIAL` viewport is part of three synchronization groups:
1. `cameraPosition` group with the ID `'axialSync'`: This group synchronizes the camera position across viewports that are both source and target.
2. `voi` (Window Level) group with the ID `'ptWLSync'`: This group synchronizes the window level settings across viewports that are both source and target.
3. `voi` group with the ID `'ptFusionWLSync'`: This group synchronizes the window level settings, but the `ptAXIAL` viewport is only a source, not a target.
:::tip
You can control the state of the synchronizer via a toolbar button after you define the synchronization group in the hanging protocol.
```js
{
id: 'SyncToggle',
uiType: 'ohif.radioGroup',
props: {
icon: 'tool-info',
label: 'toggle',
commands: {
commandName: 'toggleSynchronizer',
commandOptions: {
syncId: 'axialSync'
}
}
},
},
```
as you can see by using the `toggleSynchronizer` command you can toggle the state of the synchronizer for the specified syncId.
:::
#### Manually through a button
You can create a button on the toolbar that you provice the synchronization group type,
and it applys it to all viewports.
:::note
Currently we don't have a proper way to select viewports to apply the synchronization group to. It is applied to all applicable viewports
:::
For instance look at `imageSliceSync` button in the longitudinal mode (`modes/longitudinal/src/moreTools.ts`) and how it runs a command
```js
ToolbarService.createButton({
id: 'ImageSliceSync',
icon: 'link',
label: 'Image Slice Sync',
tooltip: 'Enable position synchronization on stack viewports',
commands: [
{
commandName: 'toggleSynchronizer',
commandOptions: {
type: 'imageSlice',
},
},
],
})
```
You can create another button to toggle 'voi' synchronization. Currently we group
viewports by modality and apply the voi synchronization to all viewports of the same modality.
```js
ToolbarService.createButton({
id: 'VoiSync',
icon: 'link',
label: 'VOI Sync',
tooltip: 'Enable VOI synchronization on viewports',
commands: [
{
commandName: 'toggleSynchronizer',
commandOptions: {
type: 'voi',
},
},
],
})
```
:::tip
For your custom synchronization groups, you can create a new synchronizer type and follow the
same pattern as the existing synchronizers.
:::
---
### ToolGroup Service
Source: https://docs.ohif.org/llm/platform/services/data/ToolGroupService.md
#### Tool Group Service
#### Overview
The `ToolGroupService` is responsible for managing tool groups in the OHIF Viewer.
:::tip
Read more about toolGroups [here](https://www.cornerstonejs.org/docs/concepts/cornerstone-tools/toolGroups)
:::
It allows you to create, update, and manage tool groups and the tools associated with them. Tool groups are used to organize and control the behavior of various tools in the viewer, such as window level, pan, zoom, measurements, and annotations.
#### Events
The `ToolGroupService` emits the following events:
| Event | Description |
| ---------------------------------- | ----------------------------------------------- |
| `VIEWPORT_ADDED` | Fires when a viewport is added to a tool group |
| `TOOLGROUP_CREATED` | Fires when a new tool group is created |
#### API
- `getToolGroup(toolGroupId?)`: Retrieves a tool group by its ID. If no ID is provided, it returns the tool group for the active viewport.
- `getToolGroupIds()`: Returns an array of all tool group IDs.
- `getToolGroupForViewport(viewportId)`: Returns the tool group associated with the specified viewport.
- `getActiveToolForViewport(viewportId)`: Returns the active tool for the specified viewport.
- `destroy()`: Destroys all tool groups.
- `destroyToolGroup(toolGroupId)`: Destroys the specified tool group.
- `removeViewportFromToolGroup(viewportId, renderingEngineId, deleteToolGroupIfEmpty?)`: Removes a viewport from a tool group. If `deleteToolGroupIfEmpty` is true and the tool group becomes empty after removing the viewport, it will be destroyed.
- `addViewportToToolGroup(viewportId, renderingEngineId, toolGroupId?)`: Adds a viewport to a tool group. If `toolGroupId` is not provided, the viewport will be added to all tool groups.
- `createToolGroup(toolGroupId)`: Creates a new tool group with the specified ID.
- `addToolsToToolGroup(toolGroupId, tools, configs?)`: Adds tools to the specified tool group with optional configurations.
- `createToolGroupAndAddTools(toolGroupId, tools)`: Creates a new tool group and adds the specified tools to it.
- `getToolConfiguration(toolGroupId, toolName)`: Retrieves the configuration for the specified tool in the given tool group.
- `setToolConfiguration(toolGroupId, toolName, config)`: Sets the configuration for the specified tool in the given tool group.
#### Usage
Here's an example of how to create a new tool group and add tools to it in our basic viewer mode (modes/longitudinal/src/initToolGroups.js)
```js
import { initToolGroups } from '@ohif/extension-cornerstone';
import { ToolGroupService } from '@ohif/core';
const toolGroupService = new ToolGroupService();
// Create a new tool group
const defaultToolGroup = toolGroupService.createToolGroup('default');
// Define tools for the tool group
const tools = {
active: [
{ toolName: 'WindowLevel', bindings: [{ mouseButton: 1 }] },
{ toolName: 'Pan', bindings: [{ mouseButton: 2 }] },
{ toolName: 'Zoom', bindings: [{ mouseButton: 3 }] },
],
passive: [
{ toolName: 'Length' },
{ toolName: 'ArrowAnnotate' },
{ toolName: 'Bidirectional' },
],
};
// Add tools to the tool group
toolGroupService.addToolsToToolGroup('default', tools);
```
In this example, we create a new `ToolGroupService` instance and use it to create a new tool group with the ID `'default'`. We then define an object `tools` that contains the active and passive tools we want to add to the tool group. Finally, we call the `addToolsToToolGroup` method to add the tools to the newly created tool group.
:::tip
You can begin the viewer with certain toggle tools already active. For example, if you have your 'referencelines' tool enabled, it will be active when the viewer starts, and the icon state will be correctly set to active as well.
:::
```js
const tools = {
// the reset
// enabled
enabled: [{ toolName: toolNames.ImageOverlayViewer }, { toolName: toolNames.ReferenceLines }],
};
```
---
### Toolbar Service
Source: https://docs.ohif.org/llm/platform/services/data/ToolbarService.md
#### Toolbar **Service**
#### Overview
The `ToolBarService` is a straightforward service designed to handle the toolbar. Its main tasks include adding buttons, configuring them, and organizing button sections. When a button is clicked, it executes the designated commands. In the past, this service was more intricate, managing button states and logic. However, all that functionality has now been transferred to the `ToolBarModule` and evaluators.
#### Events
| Event | Description |
| ----------------------- | ---------------------------------------------------------------------- |
| TOOL_BAR_MODIFIED | Fires when a button is added/removed to the toolbar |
| TOOL_BAR_STATE_MODIFIED | Fires when an interaction happens and ToolBarService state is modified |
#### API
- `createButtonSection(key, buttons)` : creates a section of buttons in the toolbar with the given key and button Ids
- `addButtons`: add the button definition to the service.
[See below for button definition](#button-definitions).
- `removeButton(key)` : remove a button from the toolbar.
- `setButtons`: sets the buttons defined in the service. It overrides all the
previous buttons
#### Button Definitions
#### Basic
The simplest toolbarButtons definition has the following properties:
```js
{
id: 'Zoom',
uiType: 'ohif.radioGroup',
props: {
icon: 'tool-zoom',
label: 'Zoom',
"commands": [
{
"commandName": "setToolActive",
"commandOptions": {
"toolName": "Zoom"
},
"context": "CORNERSTONE"
}
]
evaluate: 'evaluate.cornerstoneTool',
},
},
```
| property | description | values |
| ---------------- | ----------------------------------------------------------------- | ------------------------------------------- |
| `id` | Unique string identifier for the definition | \* |
| `icon` | A string name for an icon supported by the consuming application. | \* |
| `label` | User/display friendly to show in UI | \* |
| `commands` | (optional) The commands to run when the button is used. It include a commandName, commandOptions, and/or a context | Any command registered by a `CommandModule` |
#### Nested (dropdown)
You can use the `ohif.splitButton` type to build a button with extra tools in
the dropdown.
- First you need to give your `primary` tool definition to the split button
- the `secondary` properties can be a simple arrow down (`chevron-down` icon)
- For adding the extra tools add them to the `items` list.
You can see below how `longitudinal` mode is using the available toolbarModule
to create `MeasurementTools` nested button
```js title="modes/longitudinal/src/toolbarButtons.js"
{
id: 'MeasurementTools',
uiType: 'ohif.splitButton',
props: {
groupId: 'MeasurementToolsGroupId',
// group evaluate to determine which item should move to the top
evaluate: 'evaluate.group.promoteToPrimaryIfCornerstoneToolNotActiveInTheList',
primary: ToolbarService.createButton({
id: 'Length',
icon: 'tool-length',
label: 'Length',
tooltip: 'Length Tool',
commands: _createSetToolActiveCommands('Length'),
evaluate: 'evaluate.cornerstoneTool',
}),
secondary: {
icon: 'chevron-down',
tooltip: 'More Measure Tools',
},
items: [
ToolbarService.createButton({
id: 'Length',
icon: 'tool-length',
label: 'Length',
tooltip: 'Length Tool',
commands: [
{
commandName: 'setToolActive',
commandOptions: {
toolName: 'Length',
},
context: 'CORNERSTONE',
},
{
commandName: 'setToolActive',
commandOptions: {
toolName: 'SRLength',
toolGroupId: 'SRToolGroup',
},
// we can use the setToolActive command for this from Cornerstone commandsModule
context: 'CORNERSTONE',
},
],
evaluate: 'evaluate.cornerstoneTool',
}),
ToolbarService.createButton({
id: 'Bidirectional',
icon: 'tool-bidirectional',
label: 'Bidirectional',
tooltip: 'Bidirectional Tool',
commands: [
{
commandName: 'setToolActive',
commandOptions: {
toolName: 'Bidirectional',
},
context: 'CORNERSTONE',
},
{
commandName: 'setToolActive',
commandOptions: {
toolName: 'SRBidirectional',
toolGroupId: 'SRToolGroup',
},
context: 'CORNERSTONE',
},
],
evaluate: 'evaluate.cornerstoneTool',
}),
],
},
},
```
:::tip
split buttons can have a group evaluator (in the above example `evaluate.group.promoteToPrimaryIfCornerstoneToolNotActiveInTheList`) which can decide what happens
when the user interacts with the buttons. In the above example, we are promoting the button to the primary section if the cornerstone tool is not active in the list of buttons.
There are other evaluators for instance `evaluate.group.promoteToPrimary`
which does not care about the cornerstone tool and promotes the button to the primary section anyway
:::
:::tip
If you don't provide a group evaluator nothing would happen and the button will stay in the secondary section.
:::
#### Listeners
Sometimes you need a tool to listen to specific events in order to react properly.
You can add `listeners` for this purpose. We use this pattern for referencelineTools
which should set its source of reference upon active viewport change
Currently you can subscribe to the following events:
- `ViewportGridService.EVENTS.ACTIVE_VIEWPORT_ID_CHANGED`: when the active viewport changes
- `ViewportGridService.EVENTS.VIEWPORTS_READY`: when the viewports are ready in the grid
```js
const ReferenceLinesListeners: RunCommand = [
{
commandName: 'setSourceViewportForReferenceLinesTool',
context: 'CORNERSTONE',
},
];
ToolbarService.createButton({
id: 'ReferenceLines',
icon: 'tool-referenceLines',
label: 'Reference Lines',
tooltip: 'Show Reference Lines',
commands: [
{
commandName: 'setToolEnabled',
commandOptions: {
toolName: 'ReferenceLines',
toggle: true,
},
context: 'CORNERSTONE',
},
],
listeners: {
[ViewportGridService.EVENTS.ACTIVE_VIEWPORT_ID_CHANGED]: ReferenceLinesListeners,
[ViewportGridService.EVENTS.VIEWPORTS_READY]: ReferenceLinesListeners,
},
evaluate: 'evaluate.cornerstoneTool.toggle',
}),
```
#### Button Sections
In order to organize the buttons, you can create button sections in the toolbar. And
assign buttons to each section separately.
OHIF provides a `primary` section by default. You can add more sections as needed in your UI
and use toolbarService to create and manage them. (You can look at the toolBox implementation
which take advantage of having a dedicated section for the tools with advanced options,
we use that in the segmentation mode).
#### Example
For instance in `longitudinal` mode we are using the `onModeEnter` hook to
add the buttons to the toolbarService and assign them to the primary section.
```js title="modes/longitudinal/src/index.js"
toolbarService.addButtons([...toolbarButtons, ...moreTools]);
toolbarService.createButtonSection('primary', [
'MeasurementTools',
'Zoom',
'info',
'WindowLevel',
'Pan',
'Capture',
'Layout',
'Crosshairs',
'MoreTools',
]);
```
as you see we creating the button section and assigning buttons based on their Ids.
:::tip
You can even duplicate the same button in different sections and the button will be
in sync in all sections (thanks to the evaluation system).
:::
:::tip
we will add more section in the toolbar (other than primary) in the future.
:::
:::note
Don't forget to set up your toolGroups to ensure that your buttons function correctly. Buttons serve as a visual interface. When you interact with them, they execute their commands, and evaluators determine their state post-interaction.
:::
---
### WorkflowStep Service
Source: https://docs.ohif.org/llm/platform/services/data/WorkflowStepService.md
#### Workflow Step Service
This service allows you to manage your workflow in smaller steps. It provides a structured way to define and navigate through different stages
or phases of a larger process or workflow. Each step can have its own configuration, layout, toolbar buttons, and other settings tailored to the specific requirements of that stage.
#### Anatomy of a Workflow Step
The anatomy of a workflow step refers to the different components or properties that define and configure each individual step within the workflow. Each step can be customized with various settings to tailor the user interface, available tools, and behavior of the application for that specific stage of the workflow. Here are the key components that make up a workflow step:
- `id`: A unique identifier for the step
- `name`: A human-readable name or title for the step, which can be displayed in the user interface to help users understand the current stage of the workflow.
- `hangingProtocol`: The hanging protocol configuration specifies the protocol and stage ID to be used for displaying the images. This ensures that the appropriate data viewports and presentation are used for the current workflow step.
- `layout`: The layout configuration defines the arrangement and visibility of various panels or viewports within the application's user interface for the specific step. This can include specifying which panels should be visible on the left or right side of the screen, as well as any options for panel visibility or behavior.
- `toolbarButtons`: Each step can define a set of toolbar buttons that should be available and displayed in the application's toolbar during that step. Remember the button definitions should already be registered to toolbarService beforehand, here we are just referencing the buttons id in each section.
- `info` : An optional description or additional information about the current workflow step can be provided. which
will be displayed as tooltip in the UI.
- Step Callbacks or Commands: Some workflow steps may require specific actions or commands to be executed when the step is entered or exited. These callbacks or commands can be defined within the step configuration and can be used to update the application's state, perform data processing, or trigger other relevant actions. For instance you have access to `onEnter` hook to run a command right after the step is entered.
For instance, a simplified example of our pre-clinical 4D workflow steps configuration might look like this:
```js
const dynamicVolume = {
sopClassHandler:
"@ohif/extension-cornerstone-dynamic-volume.sopClassHandlerModule.dynamic-volume",
leftPanel:
"@ohif/extension-cornerstone-dynamic-volume.panelModule.dynamic-volume",
toolBox:
"@ohif/extension-cornerstone-dynamic-volume.panelModule.dynamic-toolbox",
export:
"@ohif/extension-cornerstone-dynamic-volume.panelModule.dynamic-export",
}
const cs3d = {
segmentation:
"@ohif/extension-cornerstone-dicom-seg.panelModule.panelSegmentation",
}
const steps = [
{
id: "dataPreparation",
name: "Data Preparation",
layout: {
panels: {
left: [dynamicVolume.leftPanel],
},
},
toolbarButtons: {
buttonSection: "primary",
buttons: ["MeasurementTools", "Zoom", "WindowLevel", "Crosshairs", "Pan"],
},
hangingProtocol: {
protocolId: "default4D",
stageId: "dataPreparation",
},
info: "In the Data Preparation step...",
},
{
id: "roiQuantification",
name: "ROI Quantification",
layout: {
panels: {
left: [dynamicVolume.leftPanel],
right: [
[dynamicVolume.toolBox, cs3d.segmentation, dynamicVolume.export],
],
},
options: {
leftPanelClosed: false,
rightPanelClosed: false,
},
},
toolbarButtons: [
{
buttonSection: "primary",
buttons: [
"MeasurementTools",
"Zoom",
"WindowLevel",
"Crosshairs",
"Pan",
],
},
{
buttonSection: "dynamic-toolbox",
buttons: ["BrushTools", "RectangleROIStartEndThreshold"],
},
],
hangingProtocol: {
protocolId: "default4D",
stageId: "roiQuantification",
},
info: "The ROI quantification step ...",
},
{
id: "kineticAnalysis",
name: "Kinetic Analysis",
layout: {
panels: {
left: [dynamicVolume.leftPanel],
right: [],
},
},
toolbarButtons: {
buttonSection: "primary",
buttons: ["MeasurementTools", "Zoom", "WindowLevel", "Crosshairs", "Pan"],
},
hangingProtocol: {
protocolId: "default4D",
stageId: "kineticAnalysis",
},
onEnter: [
{
commandName: "updateSegmentationsChartDisplaySet",
options: { servicesManager },
},
],
info: "The Kinetic Analysis step ...",
},
]
```
#### Integration
After you have defined your workflow steps, you can integrate them into your application by using the `workflowStepsService`.
These steps should be called on `onSetupRouteComplete` in your mode factory.
Note: onModeEnter is too soon to call these steps as the mode is not yet fully initialized.
```js
onSetupRouteComplete: ({ servicesManager }) => {
workflowStepsService.addWorkflowSteps(workflowSettings.steps);
workflowStepsService.setActiveWorkflowStep(workflowSettings.steps[0].id);
},
```
check out the `modes/preclinical-4d/src/index.tsx` for a complete example.
#### User Interface
We have developed a simple dropdown UI element that you can use to navigate between the different steps of your workflow. This dropdown can be added to the toolbar like below:
```js
toolbarService.addButtons([
{
id: 'ProgressDropdown',
uiType: 'ohif.progressDropdown',
},
])
toolbarService.createButtonSection('secondary', ['ProgressDropdown']);
```
It will appear in the `secondary` location in the toolbar.
:::note
if you like to place the progressbar in a different location, you can use the Toolbox component
to create a button section and place the progress bar there.
Read more in the [Toolbar module](../../extensions//modules/toolbar.md)
:::
---
### Data Services Overview
Source: https://docs.ohif.org/llm/platform/services/data/index.md
#### Overview
Data services are the first category of services which deal with handling non-ui
related state Each service have their own internal state which they handle.
> We have replaced the _redux_ store. Instead, we have introduced various
> services and a pub/sub pattern to subscribe and run, which makes the `OHIF-v3`
> architecture nice and clean.
We maintain the following non-ui Services:
- [DicomMetadata Store](./../data/DicomMetadataStore.md)
- [DisplaySet Service](./../data/DisplaySetService.md)
- [Hanging Protocol Service](../data/HangingProtocolService.md)
- [Toolbar Service](./ToolbarService.md)
- [Measurement Service](../data/MeasurementService.md)
- [Customization Service](./../customization-service/customizationService.md)
- [Panel Service](../data/PanelService.md)
#### Service Architecture
> We have explained services and how to create a custom service in the
> [`ServicesManager`](../../managers/service.md) section of the docs
To recap: The simplest service return a new object that has a `name` property,
and `Create` method which instantiate the service class. The "Factory Function"
that creates the service is provided with the implementation (this is slightly
different for UI Services).
```js
// extensions/customExtension/src/services/backEndService/index.js
import backEndService from './backEndService';
export default function WrappedBackEndService(servicesManager) {
return {
name: 'myService',
create: ({ configuration = {} }) => {
return new backEndService(servicesManager);
},
};
}
```
A service, once created, can be registered with the `ServicesManager` to make it
accessible to extensions. Similarly, the application code can access named
services from the `ServicesManager`.
[Read more of how to design a new custom service and register it](../../managers/service.md)
---
## Services/ui
### CINE Service
Source: https://docs.ohif.org/llm/platform/services/ui/cine-service.md
#### CINE Service
TODO...
---
### UI Services Overview
Source: https://docs.ohif.org/llm/platform/services/ui/index.md
#### Overview
A typical web application will have components and state for common UI like
modals, notifications, dialogs, etc. A UI service makes it possible to leverage
these components from an extension.
We maintain the following UI Services:
- [UI Notification Service](ui-notification-service.md)
- [UI Modal Service](ui-modal-service.md)
- [UI Dialog Service](ui-dialog-service.md)
- [UI Viewport Dialog Service](ui-viewport-dialog-service.md)
- [CINE Service](cine-service.md)
- [Viewport Grid Service](viewport-grid-service.md)
#### Providers for UI services
**There are several context providers that wraps the application routes. This
makes the context values exposed in the app, and service's `setImplementation`
can get run to override the implementation of the service.**
```js title="platform/app/src/App.jsx"
function App({ config, defaultExtensions }) {
/**...**/
/**...**/
return (
/**...**/
{appRoutes}
/**...**/
);
}
```
#### Example
For instance `UIModalService` has the following Public API:
```js title="platform/core/src/services/UIModalService/index.js"
const publicAPI = {
name,
hide: _hide,
show: _show,
setServiceImplementation,
};
function setServiceImplementation({
hide: hideImplementation,
show: showImplementation,
}) {
/** ... **/
serviceImplementation._hide = hideImplementation;
serviceImplementation._show = showImplementation;
/** ... **/
}
export default {
name: 'UIModalService',
create: ({ configuration = {} }) => {
return publicAPI;
},
};
```
`UIModalService` implementation can be set (override) in its context provider.
For instance in `ModalProvider` we have:
```js title="platform/ui/src/contextProviders/ModalProvider.jsx"
import { Modal } from '@ohif/ui';
const ModalContext = createContext(null);
const { Provider } = ModalContext;
export const useModal = () => useContext(ModalContext);
const ModalProvider = ({ children, modal: Modal, service }) => {
const DEFAULT_OPTIONS = {
content: null,
contentProps: null,
shouldCloseOnEsc: true,
isOpen: true,
closeButton: true,
title: null,
customClassName: '',
};
const show = useCallback(props => setOptions({ ...options, ...props }), [
options,
]);
const hide = useCallback(() => setOptions(DEFAULT_OPTIONS), [
DEFAULT_OPTIONS,
]);
useEffect(() => {
if (service) {
service.setServiceImplementation({ hide, show });
}
}, [hide, service, show]);
const {
content: ModalContent,
contentProps,
isOpen,
title,
customClassName,
shouldCloseOnEsc,
closeButton,
} = options;
return (
{ModalContent && (
)}
{children}
);
};
export default ModalProvider;
export const ModalConsumer = ModalContext.Consumer;
```
Therefore, anywhere in the app that we have access to react context we can use
it by calling the `useModal` from `@ohif/ui`. As a matter of fact, we are
utilizing the modal for the preference window which shows the hotkeys after
clicking on the gear button on the right side of the header.
A `simplified` code for our worklist is:
```js title="platform/app/src/routes/WorkList/WorkList.jsx"
import { useModal, Header } from '@ohif/ui';
function WorkList({
history,
data: studies,
dataTotal: studiesTotal,
isLoadingData,
dataSource,
hotkeysManager,
}) {
const { show, hide } = useModal();
/** ... **/
const menuOptions = [
{
title: t('Header:About'),
icon: 'info',
onClick: () => show({ content: AboutModal, title: 'About OHIF Viewer' }),
},
{
title: t('Header:Preferences'),
icon: 'settings',
onClick: () =>
show({
title: t('UserPreferencesModal:User Preferences'),
content: UserPreferences,
contentProps: {
hotkeyDefaults: hotkeysManager.getValidHotkeyDefinitions(
hotkeyDefaults
),
hotkeyDefinitions,
onCancel: hide,
currentLanguage: currentLanguage(),
availableLanguages,
defaultLanguage,
onSubmit: state => {
i18n.changeLanguage(state.language.value);
hotkeysManager.setHotkeys(state.hotkeyDefinitions);
hide();
},
onReset: () => hotkeysManager.restoreDefaultBindings(),
},
}),
},
];
/** ... **/
return (
/** ... **/
/** ... **/
);
}
```
#### Tips & Tricks
It's important to remember that all we're doing is making it possible to control
bits of the application's UI from an extension. Here are a few non-obvious
takeaways worth mentioning:
- Your application code should continue to use React context
(consumers/providers) as it normally would
- You can substitute our "out of the box" UI implementations with your own
- You can create and register your own UI services
- You can choose not to register a service or provide a service implementation
- In extensions, you can provide fallback/alternative behavior if an expected
service is not registered
- No `UIModalService`? Use the `UINotificationService` to notify users.
- You can technically register a service in an extension and expose it to the
core application
> Note: These are recommended patterns, not hard and fast rules. Following them
> will help reduce confusion and interoperability with the larger OHIF
> community, but they're not silver bullets. Please speak up, create an issue,
> if you would like to discuss new services or improvements to this pattern.
---
### UI Dialog Service
Source: https://docs.ohif.org/llm/platform/services/ui/ui-dialog-service.md
#### UI Dialog Service
Dialogs have similar characteristics to that of Modals, but often with a
streamlined focus. They can be helpful when:
- We need to grab the user's attention
- We need user input
- We need to show additional information
If you're curious about the DOs and DON'Ts of dialogs and modals, check out this
article: ["Best Practices for Modals / Overlays / Dialog Windows"][ux-article]
#### Interface
For a more detailed look on the options and return values each of these methods
is expected to support, [check out it's interface in `@ohif/core`][interface]
| API Member | Description |
| -------------- | ------------------------------------------------------ |
| `create()` | Creates a new Dialog that is displayed until dismissed |
| `dismiss()` | Dismisses the specified dialog |
| `dismissAll()` | Dismisses all dialogs |
#### Implementations
| Implementation | Consumer |
| ------------------------------------ | -------------------------- |
| [Dialog Provider][dialog-provider]\* | Baked into Dialog Provider |
`*` - Denotes maintained by OHIF
> 3rd Party implementers may be added to this table via pull requests.
[interface]: https://github.com/OHIF/Viewers/blob/master/platform/core/src/services/UIDialogService/index.js
[dialog-provider]: https://github.com/OHIF/Viewers/blob/master/platform/ui/src/contextProviders/DialogProvider.js
[ux-article]: https://uxplanet.org/best-practices-for-modals-overlays-dialog-windows-c00c66cddd8c
---
### UI Modal Service
Source: https://docs.ohif.org/llm/platform/services/ui/ui-modal-service.md
#### UI Modal Service
Modals have similar characteristics to that of Dialogs, but are often larger,
and only allow for a single instance to be viewable at once. They also tend to
be centered, and not draggable. They're commonly used when:
- We need to grab the user's attention
- We need user input
- We need to show additional information
If you're curious about the DOs and DON'Ts of dialogs and modals, check out this
article: ["Best Practices for Modals / Overlays / Dialog Windows"][ux-article]
#### Interface
For a more detailed look on the options and return values each of these methods
is expected to support, [check out it's interface in `@ohif/core`][interface]
| API Member | Description |
| ---------- | ------------------------------------- |
| `hide()` | Hides the open modal |
| `show()` | Shows the provided content in a modal |
| `customComponent()` | Overrides the default Modal component |
#### Implementations
| Implementation | Consumer |
| ---------------------------------- | --------- |
| [Modal Provider][modal-provider]\* | Modal.jsx |
| customComponent | user extensions via `setServiceImplementation({customComponent: Modal})` |
#### Custom Component
If you would like to customize the modal component that OHIF uses, you can register your own
component with the `customComponent` property.
```js
setServiceImplementation({customComponent: Modal})
```
> 3rd Party implementers may be added to this table via pull requests.
[interface]: https://github.com/OHIF/Viewers/blob/master/platform/core/src/services/UIModalService/index.js
[modal-provider]: https://github.com/OHIF/Viewers/blob/master/platform/ui/src/contextProviders/ModalProvider.js
[modal-consumer]: https://github.com/OHIF/Viewers/tree/master/platform/ui/src/components/ohifModal
[ux-article]: https://uxplanet.org/best-practices-for-modals-overlays-dialog-windows-c00c66cddd8c
---
### UI Notification Service
Source: https://docs.ohif.org/llm/platform/services/ui/ui-notification-service.md
#### UI Notification Service
Notifications can be annoying and disruptive. They can also deliver timely
helpful information, or expedite the user's workflow. Here is some high level
guidance on when and how to use them:
- Notifications should be non-interfering (timely, relevant, important)
- We should only show small/brief notifications
- Notifications should be contextual to current behavior/actions
- Notifications can serve warnings (acting as a confirmation)
If you're curious about the DOs and DON'Ts of notifications, check out this
article: ["How To Design Notifications For Better UX"][ux-article]
#### Interface
For a more detailed look on the options and return values each of these methods
is expected to support, [check out it's interface in `@ohif/core`][interface]
| API Member | Description |
| ---------- | --------------------------------------- |
| `hide()` | Hides the specified notification |
| `show()` | Creates and displays a new notification |
#### Implementations
| Implementation | Consumer |
| ---------------------------------------- | ----------------------------------------- |
| [Snackbar Provider][snackbar-provider]\* | [SnackbarContainer][snackbar-container]\* |
`*` - Denotes maintained by OHIF
> 3rd Party implementers may be added to this table via pull requests.
[interface]: https://github.com/OHIF/Viewers/blob/master/platform/core/src/services/UINotificationService/index.js
[snackbar-provider]: https://github.com/OHIF/Viewers/blob/master/platform/ui/src/contextProviders/SnackbarProvider.js
[snackbar-container]: https://github.com/OHIF/Viewers/blob/master/platform/ui/src/components/snackbar/SnackbarContainer.js
[ux-article]: https://uxplanet.org/how-to-design-notifications-for-better-ux-6fb0711be54d
---
### UI Viewport Dialog Service
Source: https://docs.ohif.org/llm/platform/services/ui/ui-viewport-dialog-service.md
#### UI Viewport Dialog Service
#### Overview
This is a new UI service, that creates a modal inside the viewport.
Dialogs have similar characteristics to that of Modals, but often with a
streamlined focus. They can be helpful when:
- We need to grab the user's attention
- We need user input
- We need to show additional information
If you're curious about the DOs and DON'Ts of dialogs and modals, check out this
article: ["Best Practices for Modals / Overlays / Dialog Windows"][ux-article]
#### Interface
For a more detailed look on the options and return values each of these methods
is expected to support, [check out it's interface in `@ohif/core`][interface]
| API Member | Description |
| -------------- | ------------------------------------------------------ |
| `create()` | Creates a new Dialog that is displayed until dismissed |
| `dismiss()` | Dismisses the specified dialog |
| `dismissAll()` | Dismisses all dialogs |
#### Implementations
| Implementation | Consumer |
| ------------------------ | -------------------------- |
| [ViewportDialogProvider] | Baked into Dialog Provider |
`*` - Denotes maintained by OHIF
#### State
```js
const DEFAULT_STATE = {
viewportId: null,
message: undefined,
type: 'info', // "error" | "warning" | "info" | "success"
actions: undefined, // array of { type, text, value }
onSubmit: () => {
console.log('btn value?');
},
onOutsideClick: () => {
console.warn('default: onOutsideClick')
},
onDismiss: () => {
console.log('dismiss? -1');
},
};
```
---
### Viewport Action Corners Service
Source: https://docs.ohif.org/llm/platform/services/ui/viewport-action-menu.md
#### Viewport Action Corners Service
The Viewport Action Corners Service is a powerful tool for managing interactive components in the corners of viewports within the OHIF viewer. This service allows developers to dynamically add, remove, and organize various UI elements such as menus, buttons, or custom components in specific locations around the viewport.
#### Overview
The Viewport Action Corners Service extends the PubSubService and provides methods to:
- Add single or multiple components to viewport corners
- Clear components from a specific viewport
- Manage the state of viewport corner components
#### Key Features
- **Flexible Positioning**: Components can be placed in top-left, top-right, bottom-left, or bottom-right corners of the viewport.
- **Priority Ordering**: Components can be assigned priority indices for ordering within a corner.
- **Viewport-Specific**: Actions are associated with specific viewports, allowing for individualized control.
- **Dynamic Updates**: Components can be added or removed at runtime, enabling context-sensitive UI elements.
#### Usage
To use the Viewport Action Corners Service, you typically interact with it through the `servicesManager`. Here's a basic example of how to add a component:
Take a look at how we add window level menu to the top right corner of the viewport in the `OHIFCornerstoneViewport` component.
---
### Viewport Grid Service
Source: https://docs.ohif.org/llm/platform/services/ui/viewport-grid-service.md
#### Viewport Grid Service
#### Overview
This is a new UI service, that handles the grid layout of the viewer.
#### Events
There are seven events that get publish in `ViewportGridService `:
| Event | Description |
| ----------------------------- | --------------------------------------------------|
| ACTIVE_VIEWPORT_ID_CHANGED | Fires the Id of the active viewport is changed |
| LAYOUT_CHANGED | Fires the layout is changed |
| GRID_STATE_CHANGED | Fires when the entire grid state is changed |
| VIEWPORTS_READY | Fires when the viewports are ready in the grid |
#### Interface
For a more detailed look on the options and return values each of these methods
is expected to support, [check out it's interface in `@ohif/core`][interface]
| API Member | Description |
| --------------------------------------------------------------------- | --------------------------------------------------- |
| `setActiveViewportId(viewportId)` | Sets the active viewport Id in the app |
| `getState()` | Gets the states of the viewport (see below) |
| `setDisplaySetsForViewport({ viewportId, displaySetInstanceUID })` | Sets displaySet for viewport based on displaySet Id |
| `setLayout({numCols, numRows, keepExtraViewports})` | Sets rows and columns. When the total number of viewports decreases, optionally keep the extra/offscreen viewports. |
| `reset()` | Resets the default states |
| `getNumViewportPanes()` | Gets the number of visible viewport panes |
| `getLayoutOptionsFromState(gridState)` | Utility method that produces a `ViewportLayoutOptions` based on the passed in state|
| `getActiveViewportId()` | Returns the viewport Id of the active viewport in the grid|
| `getActiveViewportOptionByKey(key)` | Gets the specified viewport option field (key) for the active viewport |
#### Implementations
| Implementation | Consumer |
| ---------------------- | -------------------------- |
| [ViewportGridProvider] | Baked into Dialog Provider |
`*` - Denotes maintained by OHIF
#### State
```js
const DEFAULT_STATE = {
// starting from null, hanging
// protocol will defined number of rows and cols
numRows: null,
numCols: null,
viewports: [
/*
* {
* displaySetInstanceUID: string,
* }
*/
],
activeViewportId: null,
};
```
---
# User-guide
## Study List
Source: https://docs.ohif.org/llm/user-guide/index.md
#### Study List
#### Overview
The first page you will see when the viewer is loaded is the `Study List`. In
this page you can explore all the studies that are stored on the configured
server for the `OHIF Viewer`.
#### Sorting
When the Study List is opened, the application queries the PACS for 101 studies
by default. If there are greater than 100 studies returned, the default sort for
the study list is dictated by the image archive that hosts these studies for the
viewer and study list sorting will be disabled. If there are less than or equal
to 100 studies returned, they will be sorted by study date (most recent to
oldest) and study list sorting will be enabled. Whenever a query returns greater
than 100 studies, use filters to narrow results below 100 studies to enable
Study List sorting.
#### Filters
There are certain filters that can be used to limit the study list to the
desired criteria.
- Patient Name: Searches between patients names
- MRN: Searches between patients Medical Record Number
- Study Date: Filters the date of the acquisition
- Description: Searches between study descriptions
- Modality: Filters the modalities
- Accession: Searches between patients accession number
An example of using study list filter is shown below:
Below the study list are pagination options for 25, 50, or 100 studies per page.
For static wado servers, you can enable fuzzy matching by setting the `supportsFuzzyMatching` property to true, after enabling it, fuzzy matching will be peformed on the patient name field, for example, if PatientName is "John^Doe", then "jo", "Do" and "John Doe" will all match. However "ohn" will not match.
#### Study Summary
Click on a study to expand the study summary panel.
A summary of series available in the study is shown, which contains the series
description, series number, modality of the series, instances in the series, and
buttons to launch viewer modes to display the study.
#### Study Specific Modes
All available modes are seen in the study expanded view. Modes can be enabled or
disabled for a study based on the modalities contained within the study.
In the screenshot below, there are two modes shown for the selected study
- Basic Viewer: Default mode that enables rendering and measurement tracking
- PET/CT Fusion: Mode for visualizing the PET CT study in a 3x3 format.
Based on the mode configurations (e.g., available modalities), PET/CT mode is
disabled for studies that do not contain PET AND CT images.
The previous screenshot shows a study containing PET and CT images and both
Basic Viewer and PET/CT Mode are available.
#### View Study
The `Basic Viewer` mode is available for all studies by default. Click on the
mode button to launch the viewer.
---
## Viewer
### Language
Source: https://docs.ohif.org/llm/user-guide/viewer/Language.md
#### Language
OHIF supports internationalization capabilities and setting the general language
of the Viewer.
It should be noted that we don't have complete translations for all the components
and all the languages; however, you can easily add the key value translation pairs
following developer guides.
Summary of language changing usage can be seen below:
#### Overview Video
---
### Hotkeys
Source: https://docs.ohif.org/llm/user-guide/viewer/hotkeys.md
#### Hotkeys
To open the hotkey assignment panel, you can click on the Preferences gear on the
top right side of the viewer.
Below, you can see the default hotkeys key bindings:
Hotkeys can be assigned to custom bindings that persist for the duration of the browser session.
---
### Overview
Source: https://docs.ohif.org/llm/user-guide/viewer/index.md
#### Overview
When you open a mode, viewport, toolbar and panels of the mode get shown.
It is important to note that each mode has a different UI, which serves its purpose.
Here we explain various components of `Basic Viewer` mode which includes measurement
tracking functionalities.
Basic viewer mode (longitudinal):
Let's break different aspects of the viewer to the main components:
- Left Panel (study panel): displays series thumbnails with series details
- Viewport: renders the image and displays annotations
- Right Panel (measurements): displays annotations details
- Toolbar: displays tools and logo
Now, we explain each component and its sub-elements in detail.
---
### Measurement Panel
Source: https://docs.ohif.org/llm/user-guide/viewer/measurement-panel.md
#### Measurement Panel
#### Introduction
In `Basic Viewer` mode, the right panel is the `Measurement Panel`. The Measurement Panel can be expanded or hidden by clicking on the arrow to the left of `Measurements`.
Select a measurement tool and mark an image to initiate measurement tracking. A pop-up will ask if you want to track measurements for the series on which the annotation was drawn.
If you select `Yes`, the series becomes a `tracked series`, and the current drawn measurement and next measurements are shown on the measurement panel on the right.
If you select `No`, the measurement becomes temporary. The next annotation made will repeat the measurement tracking prompt.
If you select `No, do not ask again`, all annotations made on the study will be temporary.
#### Labeling Measurements
You can edit the measurement name by hovering over the measurement and selecting the edit icon. You can also label or relabel a measurement by right-clicking on it in the viewport.
#### Deleting a Measurement
A measurement can be deleting by dragging it outside the image in the viewport or by right-clicking on the measurement in the viewport and selecting 'Delete'.
#### Jumping to a Measurement
Measurement navigation inside the top viewport can be used to move to previous and next measurement.
If a series containing a measurement is currently being displayed in a viewport, you can jump to display the measurement in the viewport by clicking on it in the Measurement Panel.
#### Export Measurements
You can export the measurements by clicking on the `Export`. A CSV file will get downloaded to your local computer containing the drawn measurements.
If you have set up your DICOM server to be able to store instances from the viewer, then you are able to create a report by clicking on the `Create Report`.
This will create a DICOM Structured Report (SR) from the measurements and push it
to the server.
For instance, running the Viewer on a local DCM4CHEE:
#### Overview Video
An overview of measurement drawing and exporting can be seen below:
---
### Measurement Tracking
Source: https://docs.ohif.org/llm/user-guide/viewer/measurement-tracking.md
#### Measurement Tracking
#### Introduction
OHIF-V3's `Basic Viewer` implements a `Measurement Tracking` workflow. Measurement
tracking allows you to:
- Draw annotations and have them shown in the measurement panel
- Create a report from the tracked measurement and export them as DICOM SR
- Use already exported DICOM SR to re-hydrate the measurements in the viewer
#### Status Icon
Each viewport has a left icon indicating whether the series within the viewport
contains:
- tracked measurement OR
- untracked measurement OR
- Structured Report OR
- Locked (uneditable) Structured Report
In the following, we will discuss each category.
#### Tracked vs Untracked Measurements
`OHIF-v3` implements a workflow for measurement tracking that can be seen below.
In summary, when you create an annotation, a prompt will be shown whether to start tracking or not. If you start the tracking, the annotation style will change to a solid line, and annotation details get displayed on the measurement panel.
On the other hand, if you decline the tracking prompt, the measurement will be considered "temporary," and annotation style remains as a dashed line and not shown on the right panel, and cannot be exported.
Below, you can see different icons that appear for a tracked vs. untracked series in
`OHIF-v3`.
#### Overview video for starting the tracking for measurements:
#### Reading and Writing DICOM SR
`OHIF-v3` provides full support for reading, writing and mapping the DICOM Structured
Report (SR) to interactable `Cornerstone Tools`. When you load an already exported
DICOM SR into the viewer, you will be prompted whether to track the measurements
for the series or not.
If you click Yes, DICOM SR measurements gets re-hydrated into the viewer and
the series become a tracked series. However, If you say no and later decide to say track the measurements, you can always click on the SR button that will prompt you
with the same message again.
The full workflow for saving measurements to SR and loading SR into the viewer is shown below.
#### Overview video for loading DICOM SR and making a tracked series:
#### Loading DICOM SR into an Already Tracked Series
If you have an already tracked series and try to load a DICOM SR measurements,
you will be shown the following lock icon. This means that, you can review the
DICOM SR measurement, manipulate image and draw "temporary" measurements; however,
you cannot edit the DICOM SR measurement.
---
### Multiplanar Reconstruction
Source: https://docs.ohif.org/llm/user-guide/viewer/mpr.md
#### Multiplanar Reconstruction
#### Crosshairs
VIDEO
#### MPR Slab Oblique
VIDEO
---
### Study Panel
Source: https://docs.ohif.org/llm/user-guide/viewer/study-panel.md
#### Study Panel
In `Basic Viewer` mode, the left panel includes Studies related to the current
patient. You can see three main type of studies below
- Primary: The opened study from the study list. This study is always expanded
by default.
- Recent: All studies for the patient that contain study dates within 1 year of
the primary study
- All: All studies available for the patient contained within the source
repository
The `Study Panel` displays the measurement tracking status of each series within
a study. As you can see in the first picture, the dashed circle on the left side
of each series demonstrates whether the series is being tracked for measurement
or not.
Studies can be expanded or collapsed by clicking on the study information in the
Study Panel. If a series is being tracking within a study, the Measurement Panel
will display this information while the study is collapsed.
---
### Toolbar
Source: https://docs.ohif.org/llm/user-guide/viewer/toolbar.md
#### Toolbar
The four main components of the toolbar are:
- Navigation back to the [Study List](../index.md)
- Logo and white labelling
- [Tools](#tools)
- [Preferences](#preferences)
#### Tools
This section displays all the available tools inside the mode.
#### Measurement tools
The basic viewer comes with the following default measurement tools:
- Length Tool: Calculates the linear distance between two points in *mm*
- Bidirectional Tool: Creates a measurement of the longest diameter (LD) and longest perpendicular diameter (LPD) in *mm*
- Annotation: Used to create a qualitative marker with a freetext label
- Ellipse: Measures an elliptical area in *mm2 * and Hounsfield Units (HU)
- Calibration Tool: Calibrate (or override) the Pixel Spacing Attribute (Physical distance in the patient between the center of each pixel, specified by a numeric pair - adjacent row spacing (delimiter) adjacent column spacing in mm)
When a measurement tool is selected from the toolbar, it becomes the `active` tool. Use the caret to expand the measurement tools and select another tool.
#### Window/Level
The `Window/Level` tool enables manipulating the window level and window width of the rendered image. Click on the tool to enable freeform adjustment, then click and drag on the viewport to freely adjust the window/level.
Click on the caret to expand the tool and choose from predefined W/L settings for common imaging scenarios.
#### Pan and Zoom
With the Zoom tool selected, click and drag the cursor on an image to adjust the zoom. The magnification level is displayed in the viewport.
With the Pan tool selected, click and drag the cursor on an image to adjust the image position.
#### Image Capture
Click on the Camera icon to download a high quality image capture using common image formats (png, jpg)
In the opened modal, the filename, image's width and height, and filetype and can be configured before downloading the image to your local computer.
#### Layout Selector
Please see the `Viewport` section for details.
#### More Tools Menu
- Reset View: Resets all image manipulation such as position, zoom, and W/L
- Rotate Right: Flips the image 90 degrees clockwise
- Flip Horizontally: Flips the image 180 degrees horizontally
- Stack Scroll: Links all viewports containing images to scroll together
- Magnify: Click on an image to magnify a particular area of interest
- Invert: Inverts the color scale
- Cine: Toggles the Cine player control in the currently selected viewport. Click the `x` on the Cine player or click the tool again to toggle off.
- Angle: Measures an adjustable angle on an image
- Probe: Drag the probe to see pixel values
- Rectangle: Measures a rectangular area in mm^2 and HU
When a tool is selected from the `More Tools` menu, it becomes the active tool until it is replaced by clicking on a different tool in the More Tools menu or main toolbar.
#### Overview Video
An overview of tool usage can been seen below:
---
### Viewport
Source: https://docs.ohif.org/llm/user-guide/viewer/viewport.md
#### Viewport
Image visualization happens at the viewport which contains canvas or canvases that
renders series.
By default, you can modify:
- Zoom: right click dragging up or down
- Contrast/brightness: left click dragging up/down to change contrast, and left/right for changing brightness
- Pan: middle click dragging
#### Changing Series for display
To change the displayed series, you can drag and drop the desired series from the left panel. Start, by dragging the thumbnail of the series, and drop it on the viewport.
#### Changing Layout
If you click on the layout icon on the toolbar, you can use the layout selector UI. After changing the layout, you can select studies for each new viewport by dragging and dropping in to the viewport.
After changing the layout from 1x1, you will see each viewport gets tagged by a letter,
which matches its series section in the study list.
#### Overview Video
An overview of viewport layout change, and manipulation can be seen below:
---
| Measurement Tracking | [Demo](https://viewer.ohif.org/viewer?StudyInstanceUIDs=1.3.6.1.4.1.25403.345050719074.3824.20170125095438.5) |
| 
| Labelmap Segmentations | [Demo](https://viewer.ohif.org/viewer?StudyInstanceUIDs=1.3.12.2.1107.5.2.32.35162.30000015050317233592200000046) |
| 
| Fusion and Custom Hanging protocols | [Demo](https://viewer.ohif.org/tmtv?StudyInstanceUIDs=1.3.6.1.4.1.14519.5.2.1.7009.2403.334240657131972136850343327463) |
| 
| Volume Rendering | [Demo](https://viewer.ohif.org/viewer?StudyInstanceUIDs=1.3.6.1.4.1.25403.345050719074.3824.20170125095438.5&hangingprotocolId=mprAnd3DVolumeViewport) |
| 
| PDF | [Demo](https://viewer.ohif.org/viewer?StudyInstanceUIDs=2.25.317377619501274872606137091638706705333) |
| 
| RT STRUCT | [Demo](https://viewer.ohif.org/viewer?StudyInstanceUIDs=1.3.6.1.4.1.5962.99.1.2968617883.1314880426.1493322302363.3.0) |
| 
| 4D | [Demo](https://viewer.ohif.org/dynamic-volume?StudyInstanceUIDs=2.25.232704420736447710317909004159492840763) |
| 
| Video | [Demo](https://viewer.ohif.org/viewer?StudyInstanceUIDs=2.25.96975534054447904995905761963464388233) |
| 
| Slide Microscopy | [Demo](https://viewer.ohif.org/microscopy?StudyInstanceUIDs=2.25.141277760791347900862109212450152067508) |
#### Where to next?
The Open Health Imaging Foundation intends to provide an imaging viewer
framework which can be easily extended for specific uses. If you find yourself
unable to extend the viewer for your purposes, please reach out via our [GitHub
issues][gh-issues]. We are actively seeking feedback on ways to improve our
integration and extension points.
Check out these helpful links:
- Ready to dive into some code? Check out our
[Getting Started Guide](./development/getting-started.md).
- We're an active, vibrant community.
[Learn how you can be more involved.](./development/contributing.md)
- Feeling lost? Read our [help page](/help).
#### Citing OHIF
To cite the OHIF Viewer in an academic publication, please cite
> _Open Health Imaging Foundation Viewer: An Extensible Open-Source Framework
> for Building Web-Based Imaging Applications to Support Cancer Research_
>
> Erik Ziegler, Trinity Urban, Danny Brown, James Petts, Steve D. Pieper, Rob
> Lewis, Chris Hafey, and Gordon J. Harris _JCO Clinical Cancer Informatics_, no. 4 (2020), 336-345, DOI:
> [10.1200/CCI.19.00131](https://www.doi.org/10.1200/CCI.19.00131)
This article is freely available on Pubmed Central: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC7259879/
or, for Lesion Tracker of OHIF v1, please cite:
> _LesionTracker: Extensible Open-Source Zero-Footprint Web Viewer for Cancer
> Imaging Research and Clinical Trials_
>
> Trinity Urban, Erik Ziegler, Rob Lewis, Chris Hafey, Cheryl Sadow, Annick D.
> Van den Abbeele and Gordon J. Harris _Cancer Research_, November 1 2017 (77) (21) e119-e122 DOI:
> [10.1158/0008-5472.CAN-17-0334](https://www.doi.org/10.1158/0008-5472.CAN-17-0334)
This article is freely available on Pubmed Central.
https://pubmed.ncbi.nlm.nih.gov/29092955/
**Note:** If you use or find this repository helpful, please take the time to
star this repository on Github. This is an easy way for us to assess adoption,
and it can help us obtain future funding for the project.
#### License
MIT © [OHIF](https://github.com/OHIF)
[ohif-org]: https://www.ohif.org
[ohif-demo]: http://viewer.ohif.org/
[dicom-web]: https://en.wikipedia.org/wiki/DICOMweb
[gh-issues]: https://github.com/OHIF/Viewers/issues
---
## DICOM Conformance Statement
Source: https://docs.ohif.org/llm/conformance
You can find a version that has been open sourced by Radical Imaging [in this link](https://docs.google.com/document/d/1hbDlUApX4svX33gAUGxGfD7fXXZNaBsX0hSePbc-hNA/edit?usp=sharing)
---
## OHIF Viewer Release Notes
Source: https://docs.ohif.org/llm/release-notes
#### Release Notes
You can find the detailed release notes on the OHIF website. Please visit [https://ohif.org/release-notes](https://ohif.org/release-notes)
---
## OHIF Viewer Educational Resources
Source: https://docs.ohif.org/llm/resources
#### Resources
Throughout the development of the OHIF Viewer, we have participated in various
conferences and "hackathons". In this page, we will provide the presentations
and other resources that we have provided to the community in the past:
#### 2025
#### Machine Learning in Medical Imaging Consortium (MaLMIC) | January 2025
We presented two talks at the Machine Learning in Medical Imaging Consortium (MaLMIC) 2025 conference.
- Advanced Medical Imaging Visualization [Slides](https://docs.google.com/presentation/d/1HZDL-72nNe4BPawDxR3XnSFLB3oLo72RjExc-KHDZfo/edit?usp=sharing)
- Introducing Advanced Segmentation Tools in the OHIF Viewer and Cornerstone3D [Slides](https://docs.google.com/presentation/d/146oJ24PPsFZaDPHeFudRF1dmbL42K9yHzQdXXAXdWxk/edit?usp=sharing)
#### 2024
#### ITCR Sustainment Session 2024
Dr. Gordon Harris presented at ITCR sustainment session about the future of OHIF.
- OHIF Sustainability [Slides](https://docs.google.com/presentation/d/15380mjCzBKBj9PuysCW1Q9ODnyoypJrCDpj3atTtK6I/edit?usp=sharing)
#### ITCR Sustainment Panel 2024
- Advanced Medical Imaging Visualization [Slides](https://docs.google.com/presentation/d/1alUp9uJpoJs3aAUE0KqrufGo6e6HHvXYmOAdJp-Rlkc/edit?usp=sharing)
#### IMNO 2024 - March 19-20, 2024
We participated in the Imaging Network Ontario (ImNO) 2024 symposium, presenting three posters. One of our presentations received the best talk award during the session.
- Advancing Medical Imaging on the Web: Implementation of Hanging Protocols for Automated Image Display Configuration in OHIF V3 [Poster](https://www.dropbox.com/scl/fi/z4h86bmsxi0c62e1n6h9l/P7-9-Alireza-Sedghi-Final.pdf?rlkey=v5pm0p5ygkbq41x9bz3hr5yi8&dl=0)
- Advancing Medical Imaging on the Web: Optimizing the Dicomweb Server Architecture with Static Dicomweb [Poster](https://www.dropbox.com/scl/fi/ep0lxjp90kbxhjoffe4kh/P7-10-Bill-Wallace-Final.pdf?rlkey=xl2u6tdnh9j9hgvkajxv3b02o&dl=0)
- (**🏆🏆 BEST PRESENTATION AWARD in the Session 7 Pitches: Devices, HW, SW Development 🏆🏆**) Advancing Medical Imaging on the Web: Integrating High Throughput JPEG 2000 (HTJ2K) in Cornerstone3D for Streamlined Progressive Loading and Visualization [Poster](https://www.dropbox.com/scl/fi/srs2rxgtv2r69ver9ub1j/P7-8-Bill-Wallace-Final.pdf?rlkey=k9mmraw76r9q2s3b9w9s0793w&dl=0)
#### 2023
#### ITCR 2023 Conference | September 11-13, 2023
Dr. Gordon Harris presented an update on OHIF in [NCI Informatics Technology for Cancer Research Annual Meeting](https://www.itcr2023.org/). You can find the slides and poster here:
[[Slides]](https://docs.google.com/presentation/d/1R38s95db_yZj0WoYdlUbaWGZsWVb3H-3u_hXBZXiTaE/edit?usp=sharing)[[Poster]](https://ohif-assets.s3.us-east-2.amazonaws.com/presentations/OHIF-ITCR-2023-FINAL-PRINT.pdf)
#### SIIM 2023 Tech Tools Webinar | April 12th, 2023
Free, Open Source Tools for Research: MONAI and OHIF Viewer
[[Slides](https://docs.google.com/presentation/d/1afJ5Y9Tzukgn7eAbaO1oiCtN7XvIimFdmZP-HcOUofA/edit?usp=sharing)][[Video](https://www.youtube.com/watch?v=lo8J5w5jUJI)]
#### NA-MIC Project Week 38th 2023 - Remote
We participated in the 38th Project Week with three projects around OHIF. [[Website](https://projectweek.na-mic.org/PW38_2023_GranCanaria/)]
- PolySeg representations for OHIF Viewer ([link](https://projectweek.na-mic.org/PW38_2023_GranCanaria/Projects/OHIF_PolySeg/))
- Cross study synchronizer for OHIF Crosshair ([link](https://projectweek.na-mic.org/PW38_2023_GranCanaria/Projects/OHIF_SyncCrosshair/))
- DATSCAN Viewer implementation in OHIF ([link](https://projectweek.na-mic.org/PW38_2023_GranCanaria/Projects/OHIF_DATSCAN/))
#### 2022
#### OHIF Demo to Interns
[[Slides]](https://docs.google.com/presentation/d/1a2PkUnqkVMaXaBsuFn7-PPlBJULU3dBwzI_44gKFeYI/edit?usp=sharing)
#### SIIM 2022 - Updates from the Imaging Informatics Community
We participated in the SIIM 2022 conference to give update for the imaging
informatics community.
[[Slides]](https://docs.google.com/presentation/d/1EUGaUzQtGhZbZWpGLe6ONqChpVMw9Qr9l3KHODevMow/edit?usp=sharing)
[[Video]](https://vimeo.com/734463662/dbd5a88371)
#### The Imaging Network Ontario - Remote
The Imaging Network Ontario (ImNO) is an annual symposium that brings together
medical imaging researchers and scientists from across Canada to share
knowledge, ideas, and experiences.
[[Slides]](https://docs.google.com/presentation/d/18XZDon4-Sitc2a70V5sFyhyUVZI_mIgfXHGtdxhZMjE/edit?usp=sharing)
[[Video]](https://vimeo.com/843234581/ad7d308a44)
#### [NA-MIC Project Week 36th 2022 - Remote](https://github.com/NA-MIC/ProjectWeek/blob/master/PW36_2022_Virtual/README.md)
The Project Week is a week-long hackathon of hands-on activity in which medical
image computing researchers. OHIF team participated and gave a talk on OHIF and
Cornerstone in the 36th Project Week:
[[Slides]](https://docs.google.com/presentation/d/1-GtOKmr2cQi-r3OFyseSmgLeurtB3KXUkGMx2pVLh1I/edit?usp=sharing)
[[Video]](https://vimeo.com/668339696/63a2c48de8)
#### 2021
#### [NA-MIC Project Week 35th 2021 - Remote](https://github.com/NA-MIC/ProjectWeek/tree/master/PW35_2021_Virtual)
The Project Week is a week-long hackathon of hands-on activity in which medical
image computing researchers. OHIF team participated in the 35th Project Week
in 2021.
[[Slides]](https://docs.google.com/presentation/d/1KYNjuiI8lT1foQ4P9TGNV0lBhM6H-5KBs0wkYj4JJbk/edit?usp=sharing)
#### Chan Zuckerberg Initiative (CZI)
Project presentations and demonstrations of Essential Open Source Software for
Science (EOSS) grantees
[[Slides]](https://docs.google.com/presentation/d/1_CLtG2hsL3ZxOtV2olVnzBOzq-TMLrHLomOy3FiU4NE/edit?usp=sharing)
[[Video]](https://youtu.be/0FjKkTJO0Rc?t=3737)
#### Google Cloud Tech
Healthcare Imaging with Cloud Healthcare API
[[Video]](https://www.youtube.com/watch?v=2MiX9ScHFhY)
#### 2020
#### OHIF ITCR Pitch
OHIF pitch for Informatics Technology for Cancer Research (ITCR)
[[Slides]](https://docs.google.com/presentation/d/1MZXnZrVAnjmhVIWqC-aRSvJOoMMRLhLddACdCa1TybM/edit?usp=sharing)
[[Video]](https://vimeo.com/843234613/625bdb8793)
#### 2019
#### OHIF and VTK.js Training Course
OHIF and Kitware collaboration to create a training course for OHIF and VTK.js
developers. Funding for this work was provided by Kitware (NIH NINDS
R44NS081792, NIH NINDS R42NS086295, NIH NIBIB and NIGMS R01EB021396, NIH NIBIB
R01EB014955), Isomics (NIH P41 EB015902), and Massachusetts General Hospital
(NIH U24 CA199460).
1. Introduction to VTK.js and OHIF
[[Slides]](https://docs.google.com/presentation/d/1NCJxpfx_qUGJI_2DhbECzaOg0k-Z6b65QlUptCofN-A/edit#slide=id.p)
[[Video]](https://vimeo.com/375520781)
2. Developing with VTK.js
[[Slides]](https://docs.google.com/presentation/d/17TCS6EhFi6SWFIrcAJ-DFdFzFFL-WD9BBTv-owmMdDU/edit#slide=id.p)
[[Video]](https://vimeo.com/375521036)
3. VTK.js Architecture and Tooling
[[Slides]](https://docs.google.com/presentation/d/1Sr1OGxMSw0oCt46koKQbmwSIE11Kqq8MGtyW3W0ASpk/edit?usp=gmail_thread)
[[Video]](https://vimeo.com/375521810)
4. OHIF + VTK.js Integration
[[Slides]](https://docs.google.com/presentation/d/1Iwg-u01HGVf1CgC6NbcBD3gm3uHN9WhjU59FSz55TN8/edit?ts=5d9c9ce4#slide=id.g59aa99cda4_0_131)
[[Video]](https://vimeo.com/375521206)
#### 2017
#### Lesion Tracker
LesionTracker: Extensible Open-Source Zero-Footprint Web Viewer for Cancer
Imaging Research and Clinical Trials. This project was supported in part by
grant U24 CA199460 from the National Cancer Institute (NCI) Informatics
Technology for Cancer Research (ITCR) Program.
[[Video]](https://www.youtube.com/watch?v=gUIPtoSBL-Q)
#### OHIF Community Meeting - June
[[Slides]](https://docs.google.com/presentation/d/1K9Y6eP5DYTXoDlfwCZE6GkCUp83AK4_40YQS0dlzVBo/edit?usp=sharing)
#### 2016
#### Imaging Community Call
Open Source Oncology Web Viewer; Presentation by Gordon J. Harris
[[Slides]](https://www.slideshare.net/imgcommcall/lesiontracker)
#### OHIF Community Meeting - June
[[Slides]](https://docs.google.com/presentation/d/1Ai25mBG0ZWUPhaadp3VnbCVmkYs9K51sQ8osMixrvJ0/edit?usp=sharing)
#### OHIF Community Meeting - September
[[Slides]](https://docs.google.com/presentation/d/1iYZoU7v7KHSLHiKwH1_9_wweAkG7RGnyxrWeeHva4zQ/edit?usp=sharing)
---
## OHIF Viewer Test Coverage
Source: https://docs.ohif.org/llm/test-coverage
#### Test Coverage
#### Playwright
Here's the test coverage report for our Playwright tests. Keep in mind that this doesn't include our Cypress tests, so our actual test coverage is likely higher than what's shown. We're focusing on Playwright for future OHIF testing, and we're really pushing to improve that coverage number.
You can view our latest test coverage report here:
- [OHIF Playwright Test Coverage Report](https://docs.ohif.org/coverage)
---
# Configuration
## Configuration Files
Source: https://docs.ohif.org/llm/configuration/configurationFiles.md
#### Config files
After following the steps outlined in
[Getting Started](./../development/getting-started.md), you'll notice that the
OHIF Viewer has data for several studies and their images. You didn't add this
data, so where is it coming from?
By default, the viewer is configured to connect to a Amazon S3 bucket that is hosting
a Static WADO server (see [Static WADO DICOMWeb](https://github.com/RadicalImaging/static-dicomweb)).
By default we use `default.js` for the configuration file. You can change this by setting the `APP_CONFIG` environment variable
and select other options such as `config/local_orthanc.js` or `config/google.js`.
#### Configuration Files
The configuration for our viewer is in the `