fix/migration 3p11 (#5370)
This commit is contained in:
Alireza authored and GitHub committed
1 parent
df0593aac9
commit
6a1838bf0d
391 files changed
+2322
-215
No files matched your search
@@ -0,0 +1,4 @@
|
||||
{
|
||||
"label": "Data Sources",
|
||||
"position": 2
|
||||
}
|
||||
+179
@@ -0,0 +1,179 @@
|
||||
---
|
||||
sidebar_position: 6
|
||||
sidebar_label: Configuration UI
|
||||
title: Configuration UI
|
||||
summary: Describes interfaces for implementing configurable data sources in OHIF, with details on BaseDataSourceConfigurationAPI and BaseDataSourceConfigurationAPIItem to enable generic UIs for hierarchical data source configuration.
|
||||
---
|
||||
|
||||
# Configuration UI
|
||||
|
||||
OHIF provides for a generic mechanism for configuring a data source. This is
|
||||
most useful for those organizations with several data sources
|
||||
that share common (path) hierarchies. For example, an organization may have several DICOM stores
|
||||
in the Google Cloud Healthcare realm where each is organized into various projects,
|
||||
location, data sets and DICOM stores.
|
||||
|
||||
By implementing the `BaseDataSourceConfigurationAPI` and
|
||||
`BaseDataSourceConfigurationAPIItem` in an [OHIF extension](../../platform/extensions/index.md), a data source can
|
||||
be made configurable via the generic UI as is depicted below for a
|
||||
Google Cloud Healthcare data source.
|
||||
|
||||
|
||||
|
||||
:::tip
|
||||
A datasource root URI can be [fully or partially specified](../../deployment/google-cloud-healthcare.md#configuring-google-cloud-healthcare-as-a-datasource-in-ohif)
|
||||
in the OHIF configuration file.
|
||||
:::
|
||||
|
||||
## `BaseDataSourceConfigurationAPIItem` interface
|
||||
|
||||
Each (path) item of a data source is represented by an instance of this interface.
|
||||
At the very least each of these items must expose two properties:
|
||||
|
||||
|Property |Description|
|
||||
|---------|-----------|
|
||||
|id|a string that uniquely identifies the item|
|
||||
|name|a human readable name for the item|
|
||||
|
||||
Note that information such as where in the path hierarchy the item exists
|
||||
has been omitted, but can be added in any concrete class that might implement this
|
||||
interface. For example, the the Google Cloud Healthcare implementation of this
|
||||
interface (`GoogleCloudDataSourceConfigurationAPIItem`) adds an `itemType`
|
||||
(i.e. projects, locations, datasets, or dicomStores) and `url`.
|
||||
|
||||
## `BaseDataSourceConfigurationAPI` interface
|
||||
|
||||
The implementation of this interface is at the heart of the configuration process.
|
||||
It possesses several methods for building up a data source path based on various
|
||||
`BaseDataSourceConfigurationAPIItem` objects that are set via calls to the `setCurrentItem`
|
||||
method.
|
||||
|
||||
The constructor for the concrete class implementation should accept whatever
|
||||
parameters are necessary for configuring the data source. One argument
|
||||
to the constructor must be the string identifying the name of the data source
|
||||
to be configured. Furthermore, considering that the `ExtensionManager` possesses
|
||||
API to configure and update data sources, it too will likely be an argument to
|
||||
the constructor. See [Creation via Customization Module](#creation-via-customization-module)
|
||||
for more information on how the constructor is invoked via a factory method.
|
||||
|
||||
For an example implementation of this interface see `GoogleCloudDataSourceConfigurationAPI`.
|
||||
|
||||
### Interface Methods
|
||||
|
||||
Each of the following subsections lists a method of the interface with a description
|
||||
detailing what the method should do.
|
||||
|
||||
#### `getItemLabels`
|
||||
|
||||
Gets the i18n labels (i.e. the i18n lookup keys) for each of the configurable items
|
||||
of the data source configuration API. For example, for the Google Cloud Healthcare
|
||||
API, this would be `['Project', 'Location', 'Data set', 'DICOM store']`.
|
||||
|
||||
Besides the configurable item labels themselves, several other string look ups
|
||||
are used base on EACH of the labels returned by this method.
|
||||
For instance, for the label `{itemLabel}`, the following strings are fetched for
|
||||
translation...
|
||||
1. No `{itemLabel}` available
|
||||
- used to indicate no such items are available
|
||||
- for example, for Google, No Project available would be 'No projects available'
|
||||
2. Select `{itemLabel}`
|
||||
- used to direct selection of the item
|
||||
- for example, for Google, Select Project would be 'Select a project'
|
||||
3. Error fetching `{itemLabel}` list
|
||||
- used to indicate an error occurred fetching the list of items
|
||||
- usually accompanied by the error itself
|
||||
- for example, for Google, Error fetching Project list would be 'Error fetching projects'
|
||||
4. Search `{itemLabel}` list
|
||||
- used as the placeholder text for filtering a list of items
|
||||
- for example, for Google, Search Project list would be 'Search projects'
|
||||
|
||||
#### `initialize`
|
||||
|
||||
Initializes the cloud server API and returns the top-level sub-items
|
||||
that can be chosen to begin the process of configuring a data source.
|
||||
For example, for the Google Cloud Healthcare API, this would perform the initial request
|
||||
to fetch the top level projects for the logged in user account.
|
||||
|
||||
#### `setCurrentItem`
|
||||
|
||||
Sets the current path item that is passed as an argument to the method and
|
||||
returns the sub-items of that item
|
||||
that can be further chosen to configure a data source.
|
||||
When setting the last configurable item of the data source (path), this method
|
||||
returns an empty list AND configures the active data source with the selected
|
||||
items path.
|
||||
|
||||
For example, for the Google Cloud Healthcare API, this would take the current item
|
||||
(say a data set) and queries and returns its sub-items (i.e. all of the DICOM stores
|
||||
contained in that data set). Furthermore, whenever the item to set is a DICOM store,
|
||||
the Google Cloud Healthcare API implementation would update the OHIF data source
|
||||
associated with this instance to point to that DICOM store.
|
||||
|
||||
#### `getConfiguredItems`
|
||||
|
||||
Gets the list of items currently configured for the data source associated with
|
||||
this API instance. The resultant array must be the same length as the result of
|
||||
`getItemLabels`. Furthermore the items returned should correspond (index-wise)
|
||||
with the labels returned from `getItemLabels`.
|
||||
|
||||
## Creation via Customization Module
|
||||
|
||||
The generic UI (i.e. `DataSourceConfigurationComponent`) uses the
|
||||
[OHIF UI customization service](../../platform/services/customization-service/customizationService.md) to
|
||||
instantiate the `BaseDataSourceConfigurationAPI` instance to configure a data source.
|
||||
|
||||
A UI configurable data source should have a `configurationAPI` field as part of
|
||||
its `configuration` in the OHIF config file. The `configurationAPI` value is the
|
||||
customization id of the customization module that provides the factory method
|
||||
to instantiate the `BaseDataSourceConfigurationAPI` instance.
|
||||
|
||||
For example, the following is a snippet of a Google Cloud Healthcare data source configuration.
|
||||
|
||||
```js
|
||||
dataSources: [
|
||||
{
|
||||
namespace: '@ohif/extension-default.dataSourcesModule.dicomweb',
|
||||
sourceName: 'google-dicomweb',
|
||||
configuration: {
|
||||
name: 'GCP',
|
||||
wadoUriRoot: 'https://healthcare.googleapis.com/v1/projects/ohif-cloud-healthcare/locations/us-east4/...',
|
||||
...
|
||||
configurationAPI: 'ohif.dataSourceConfigurationAPI.google',
|
||||
...
|
||||
},
|
||||
},
|
||||
]
|
||||
```
|
||||
|
||||
This suggests that the factory method is provided by the `'ohif.dataSourceConfigurationAPI.google'`
|
||||
customization module. That customization module is provided by the `default` extension's
|
||||
`getCustomizationModule` and looks something like the following snippet of code. Notice that
|
||||
the factory method's name MUST be `factory` and accept one argument - the data source name.
|
||||
Furthermore note how the constructor is invoked with anything required by the concrete configuration
|
||||
API class.
|
||||
|
||||
```js
|
||||
export default function getCustomizationModule({
|
||||
servicesManager,
|
||||
extensionManager,
|
||||
}) {
|
||||
return [
|
||||
{
|
||||
name: 'default',
|
||||
value: [
|
||||
{
|
||||
// The factory for creating an instance of a BaseDataSourceConfigurationAPI for Google Cloud Healthcare
|
||||
id: 'ohif.dataSourceConfigurationAPI.google',
|
||||
factory: (dataSourceName: string) =>
|
||||
new GoogleCloudDataSourceConfigurationAPI(
|
||||
dataSourceName,
|
||||
servicesManager,
|
||||
extensionManager
|
||||
),
|
||||
},
|
||||
],
|
||||
},
|
||||
];
|
||||
}
|
||||
|
||||
```
|
||||
@@ -0,0 +1,196 @@
|
||||
---
|
||||
sidebar_position: 3
|
||||
sidebar_label: DICOM JSON
|
||||
title: DICOM JSON
|
||||
summary: Explains how to configure and use the DICOM JSON data source format in OHIF, including structure of the JSON file with study/series/instance metadata, implementation examples, and local deployment instructions.
|
||||
---
|
||||
|
||||
# DICOM JSON
|
||||
|
||||
You can launch the OHIF Viewer with a JSON file which points to a DICOMWeb
|
||||
server as well as a list of study and series instance UIDs along with metadata.
|
||||
|
||||
An example would look like
|
||||
|
||||
`https://viewer.ohif.org/viewer/dicomjson?url=https://ohif-dicom-json-example.s3.amazonaws.com/LIDC-IDRI-0001.json`
|
||||
|
||||
As you can see the url to the location of the JSON file is passed in the query
|
||||
after the `dicomjson` string, which is
|
||||
`https://ohif-dicom-json-example.s3.amazonaws.com/LIDC-IDRI-0001.json` (this
|
||||
json file has been generated by OHIF team and stored in an amazon s3 bucket for
|
||||
the purpose of the guide).
|
||||
|
||||
## DICOM JSON sample
|
||||
|
||||
Here we are using the LIDC-IDRI-0001 case which is a sample of the LIDC-IDRI
|
||||
dataset. Let's have a look at the JSON file:
|
||||
|
||||
### Metadata
|
||||
|
||||
JSON file stores the metadata for the study level, series level and instance
|
||||
level. A JSON launch file should follow the same structure as the one below.
|
||||
|
||||
:::tip
|
||||
You can use our script to generate the JSON file from a hosted endpoint. See
|
||||
`.scripts/dicom-json-generator.js`
|
||||
|
||||
You could run it like this:
|
||||
|
||||
```bash
|
||||
node .scripts/dicom-json-generator.js '/path/to/study/folder' 'url/to/dicom/server/folder' 'json/output/file.json'
|
||||
```
|
||||
|
||||
Some modalities require additional metadata to be added to the JSON file. You can read more about the minimum amount of metadata required for the viewer to work [here](../../faq/technical#what-are-the-list-of-required-metadata-for-the-ohif-viewer-to-work). We will handle this in the script. For example, the script will add the CodeSequences for SR in order to display the measurements in the viewer.
|
||||
:::
|
||||
|
||||
|
||||
Note that at the instance level metadata we are storing both the `metadata` and
|
||||
also the `url` for the dicom file on the dicom server. In this case we are
|
||||
referring to
|
||||
`dicomweb:https://ohif-dicom-json-example.s3.amazonaws.com/LIDC-IDRI-0001/01-01-2000-30178/3000566.000000-03192/1-001.dcm`
|
||||
which is stored in another directory in our s3. (You can actually try
|
||||
downloading the dicom file by opening the url in your browser).
|
||||
|
||||
The URL to the script in the given example is `https://ohif-dicom-json-example.s3.amazonaws.com/LIDC-IDRI-0001/01-01-2000-30178`. This URL serves as the parent directory that contains all the series within their respective folders.
|
||||
|
||||
```json
|
||||
{
|
||||
"studies": [
|
||||
// first study metadata
|
||||
{
|
||||
"StudyInstanceUID": "1.3.6.1.4.1.14519.5.2.1.6279.6001.298806137288633453246975630178",
|
||||
"StudyDate": "20000101",
|
||||
"StudyTime": "",
|
||||
"PatientName": "",
|
||||
"PatientID": "LIDC-IDRI-0001",
|
||||
"AccessionNumber": "",
|
||||
"PatientAge": "",
|
||||
"PatientSex": "",
|
||||
"series": [
|
||||
// first series metadata
|
||||
{
|
||||
"SeriesInstanceUID": "1.3.6.1.4.1.14519.5.2.1.6279.6001.179049373636438705059720603192",
|
||||
"SeriesNumber": 3000566,
|
||||
"Modality": "CT",
|
||||
"SliceThickness": 2.5,
|
||||
"instances": [
|
||||
// first instance metadata
|
||||
{
|
||||
"metadata": {
|
||||
"Columns": 512,
|
||||
"Rows": 512,
|
||||
"InstanceNumber": 1,
|
||||
"SOPClassUID": "1.2.840.10008.5.1.4.1.1.2",
|
||||
"PhotometricInterpretation": "MONOCHROME2",
|
||||
"BitsAllocated": 16,
|
||||
"BitsStored": 16,
|
||||
"PixelRepresentation": 1,
|
||||
"SamplesPerPixel": 1,
|
||||
"PixelSpacing": [0.703125, 0.703125],
|
||||
"HighBit": 15,
|
||||
"ImageOrientationPatient": [1, 0, 0, 0, 1, 0],
|
||||
"ImagePositionPatient": [-166, -171.699997, -10],
|
||||
"FrameOfReferenceUID": "1.3.6.1.4.1.14519.5.2.1.6279.6001.229925374658226729607867499499",
|
||||
"ImageType": ["ORIGINAL", "PRIMARY", "AXIAL"],
|
||||
"Modality": "CT",
|
||||
"SOPInstanceUID": "1.3.6.1.4.1.14519.5.2.1.6279.6001.262721256650280657946440242654",
|
||||
"SeriesInstanceUID": "1.3.6.1.4.1.14519.5.2.1.6279.6001.179049373636438705059720603192",
|
||||
"StudyInstanceUID": "1.3.6.1.4.1.14519.5.2.1.6279.6001.298806137288633453246975630178",
|
||||
"WindowCenter": -600,
|
||||
"WindowWidth": 1600,
|
||||
"SeriesDate": "20000101"
|
||||
},
|
||||
"url": "dicomweb:https://ohif-dicom-json-example.s3.amazonaws.com/LIDC-IDRI-0001/01-01-2000-30178/3000566.000000-03192/1-001.dcm"
|
||||
},
|
||||
// second instance metadata
|
||||
{
|
||||
"metadata": {
|
||||
"Columns": 512,
|
||||
"Rows": 512,
|
||||
"InstanceNumber": 2,
|
||||
"SOPClassUID": "1.2.840.10008.5.1.4.1.1.2",
|
||||
"PhotometricInterpretation": "MONOCHROME2",
|
||||
"BitsAllocated": 16,
|
||||
"BitsStored": 16,
|
||||
"PixelRepresentation": 1,
|
||||
"SamplesPerPixel": 1,
|
||||
"PixelSpacing": [0.703125, 0.703125],
|
||||
"HighBit": 15,
|
||||
"ImageOrientationPatient": [1, 0, 0, 0, 1, 0],
|
||||
"ImagePositionPatient": [-166, -171.699997, -12.5],
|
||||
"FrameOfReferenceUID": "1.3.6.1.4.1.14519.5.2.1.6279.6001.229925374658226729607867499499",
|
||||
"ImageType": ["ORIGINAL", "PRIMARY", "AXIAL"],
|
||||
"Modality": "CT",
|
||||
"SOPInstanceUID": "1.3.6.1.4.1.14519.5.2.1.6279.6001.512235483218154065970649917292",
|
||||
"SeriesInstanceUID": "1.3.6.1.4.1.14519.5.2.1.6279.6001.179049373636438705059720603192",
|
||||
"StudyInstanceUID": "1.3.6.1.4.1.14519.5.2.1.6279.6001.298806137288633453246975630178",
|
||||
"WindowCenter": -600,
|
||||
"WindowWidth": 1600,
|
||||
"SeriesDate": "20000101"
|
||||
},
|
||||
"url": "dicomweb:https://ohif-dicom-json-example.s3.amazonaws.com/LIDC-IDRI-0001/01-01-2000-30178/3000566.000000-03192/1-002.dcm"
|
||||
}
|
||||
// ..... other instances metadata
|
||||
]
|
||||
}
|
||||
// ... other series metadata
|
||||
],
|
||||
"NumInstances": 133,
|
||||
"Modalities": "CT"
|
||||
}
|
||||
// second study metadata
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
|
||||
|
||||
### Local Demo
|
||||
|
||||
You can run OHIF with a JSON data source against you local datasets (given that
|
||||
their JSON metadata is extracted).
|
||||
|
||||
First you need to put the JSON file and the folder containing the dicom files
|
||||
inside your `public` folder. Since files are served from your local server the
|
||||
`url` for the JSON file will be `http://localhost:3000/LIDC-IDRI-0001.json` and
|
||||
the dicom files will be
|
||||
`dicomweb:http://localhost:3000/LIDC-IDRI-0001/01-01-2000-30178/3000566.000000-03192/1-001.dcm`.
|
||||
|
||||
After `yarn install` and running `yarn dev` and opening the browser at
|
||||
`http://localhost:3000/viewer/dicomjson?url=http://localhost:3000/LIDC-IDRI-0001.json`
|
||||
will display the viewer.
|
||||
|
||||
Download JSON file from
|
||||
[here](https://www.dropbox.com/sh/zvkv6mrhpdze67x/AADLGK46WuforD2LopP99gFXa?dl=0)
|
||||
|
||||
Sample DICOM files can be downloaded from
|
||||
[TCIA](https://wiki.cancerimagingarchive.net/display/Public/LIDC-IDRI) or
|
||||
directly from
|
||||
[here](https://www.dropbox.com/sh/zvkv6mrhpdze67x/AADLGK46WuforD2LopP99gFXa?dl=0)
|
||||
|
||||
Your public folder should look like this:
|
||||
|
||||
|
||||
|
||||
:::tip
|
||||
It is important to URL encode the `url` query parameter especially if the `url`
|
||||
parameter itself also contains query parameters. So for example,
|
||||
|
||||
`http://localhost:3000/viewer/dicomjson?url=http://localhost:3000/LIDC-IDRI-0001.json?key0=val0&key1=val1`
|
||||
|
||||
should be...
|
||||
|
||||
`http://localhost:3000/viewer/dicomjson?url=http://localhost:3000/LIDC-IDRI-0001.json?key0=val0%26key1=val1`
|
||||
|
||||
Notice the ampersand (`&`) is encoded as `%26`.
|
||||
:::
|
||||
|
||||
:::note
|
||||
When hosting the DICOM JSON files, it is important to be aware that certain providers
|
||||
do not automatically handle the 404 error and fallback to index.html. For example, Netlify
|
||||
handles this, but Azure does not. Consequently, when you attempt to access a link with a
|
||||
specific URL, a 404 error will be displayed.
|
||||
|
||||
This issue also occurs locally, where the http-server does not handle it. However,
|
||||
if you utilize the `serve` package (npx serve ./dist -c ../public/serve.json), it effectively addresses this problem.
|
||||
:::
|
||||
+56
@@ -0,0 +1,56 @@
|
||||
---
|
||||
sidebar_position: 4
|
||||
sidebar_label: DICOMweb Proxy
|
||||
title: DICOMweb Proxy
|
||||
summary: Documents the DICOMweb Proxy data source which constructs a dynamic DICOMweb datasource from a configuration JSON file, allowing OHIF to delegate subsequent requests for metadata and images to the configured server.
|
||||
---
|
||||
|
||||
# DICOMweb Proxy
|
||||
|
||||
You can launch the OHIF Viewer with a url that returns a JSON file which
|
||||
contains a DICOMWeb configuration. The DICOMweb Proxy constructs a DICOMweb
|
||||
datasource and delegates subsequent requests for metadata and images to that.
|
||||
|
||||
Usage is similar to that of the [DICOM JSON](./dicom-json.md) datasource and
|
||||
might look like
|
||||
|
||||
`https://viewer.ohif.org/viewer/dicomwebproxy?url=https://ohif-dicom-json-example.s3.amazonaws.com/dicomweb.json`
|
||||
|
||||
The url to the location of the JSON file is passed in the query
|
||||
after the `dicomwebproxy` string, which is
|
||||
`https://ohif-dicom-json-example.s3.amazonaws.com/dicomweb.json` (this json file
|
||||
does not exist at the moment of this writing).
|
||||
|
||||
## DICOMweb JSON configuration sample
|
||||
|
||||
The json returned by the url in this example contains a dicomweb configuration
|
||||
(see [DICOMweb](dicom-web.md)), in a "servers" object, which is then used to
|
||||
construct a dynamic DICOMweb datasource to delegate requests to. Here is an
|
||||
example configuration that might be returned using the url parameter.
|
||||
|
||||
```json
|
||||
{
|
||||
"servers": {
|
||||
"dicomWeb": [
|
||||
{
|
||||
"name": "DCM4CHEE",
|
||||
"wadoUriRoot": "https://server.dcmjs.org/dcm4chee-arc/aets/DCM4CHEE/wado",
|
||||
"qidoRoot": "https://server.dcmjs.org/dcm4chee-arc/aets/DCM4CHEE/rs",
|
||||
"wadoRoot": "https://server.dcmjs.org/dcm4chee-arc/aets/DCM4CHEE/rs",
|
||||
"qidoSupportsIncludeField": true,
|
||||
"supportsReject": true,
|
||||
"imageRendering": "wadors",
|
||||
"thumbnailRendering": "wadors",
|
||||
"enableStudyLazyLoad": true,
|
||||
"supportsFuzzyMatching": true,
|
||||
"supportsWildcard": true
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
The DICOMweb Proxy expects the json returned by the url parameter it is invoked
|
||||
with to include a servers object which contains a "dicomWeb" configuration array
|
||||
as above. It will only consider the first array item in the dicomWeb
|
||||
configuration.
|
||||
@@ -0,0 +1,256 @@
|
||||
---
|
||||
sidebar_position: 2
|
||||
sidebar_label: DICOMweb
|
||||
title: DICOMweb
|
||||
summary: Comprehensive guide to configuring DICOMweb data sources in OHIF, including setting up local DICOM servers (Orthanc, DCM4CHEE), configurations for PDF, video, and bulkdata handling, and detailed instructions for development environments.
|
||||
---
|
||||
|
||||
# DICOMweb
|
||||
|
||||
## Set up a local DICOM server
|
||||
|
||||
ATTENTION! Already have a remote or local server? Skip to the
|
||||
[configuration section](#configuration-learn-more) below.
|
||||
|
||||
While the OHIF Viewer can work with any data source, the easiest to configure
|
||||
are the ones that follow the [DICOMWeb][dicom-web] spec.
|
||||
|
||||
1. Choose and install an Image Archive
|
||||
2. Upload data to your archive (e.g. with DCMTK's [storescu][storescu] or your
|
||||
archive's web interface)
|
||||
3. Keep the server running
|
||||
|
||||
For our purposes, we will be using `Orthanc`, but you can see a list of
|
||||
[other Open Source options](#open-source-dicom-image-archives) below.
|
||||
|
||||
### Requirements
|
||||
|
||||
- Docker
|
||||
- [Docker for Mac](https://docs.docker.com/docker-for-mac/)
|
||||
- [Docker for Windows (recommended)](https://docs.docker.com/docker-for-windows/)
|
||||
- [Docker Toolbox for Windows](https://docs.docker.com/toolbox/toolbox_install_windows/)
|
||||
|
||||
_Not sure if you have `docker` installed already? Try running `docker --version`
|
||||
in command prompt or terminal_
|
||||
|
||||
> If you are using `Docker Toolbox` you need to change the _PROXY_DOMAIN_
|
||||
> parameter in _platform/app/package.json_ to http://192.168.99.100:8042 or
|
||||
> the ip docker-machine ip throws. This is the value [`WebPack`][webpack-proxy]
|
||||
> uses to proxy requests
|
||||
|
||||
## Open Source DICOM Image Archives
|
||||
|
||||
There are a lot of options available to you to use as a local DICOM server. Here
|
||||
are some of the more popular ones:
|
||||
|
||||
| Archive | Installation |
|
||||
| --------------------------------------------- | ---------------------------------- |
|
||||
| [DCM4CHEE Archive 5.x][dcm4chee] | [W/ Docker][dcm4chee-docker] |
|
||||
| [Orthanc][orthanc] | [W/ Docker][orthanc-docker] |
|
||||
| [DICOMcloud][dicomcloud] (**DICOM Web only**) | [Installation][dicomcloud-install] |
|
||||
| [OsiriX][osirix] (**Mac OSX only**) | Desktop Client |
|
||||
| [Horos][horos] (**Mac OSX only**) | Desktop Client |
|
||||
|
||||
_Feel free to make a Pull Request if you want to add to this list._
|
||||
|
||||
Below, we will focus on `DCM4CHEE` and `Orthanc` usage:
|
||||
|
||||
### Running Orthanc
|
||||
|
||||
_Start Orthanc:_
|
||||
|
||||
```bash
|
||||
# Runs orthanc so long as window remains open
|
||||
yarn run orthanc:up
|
||||
```
|
||||
|
||||
_Upload your first Study:_
|
||||
|
||||
1. Navigate to
|
||||
[Orthanc's web interface](http://localhost:8042/ui/app/index.html#/) at
|
||||
`http://localhost:8042/ui/app/index.html#/` in a web browser.
|
||||
2. In the left you can see the upload button where you can drag and drop your DICOM files
|
||||
|
||||
#### Orthanc: Learn More
|
||||
|
||||
You can see the `docker-compose.yml` file this command runs at
|
||||
[`<project-root>/platform/app/.recipes/Nginx-Orthanc`][orthanc-docker-compose], and more on
|
||||
Orthanc for Docker in [Orthanc's documentation][orthanc-docker].
|
||||
|
||||
#### Connecting to Orthanc
|
||||
|
||||
Now that we have a local Orthanc instance up and running, we need to configure
|
||||
our web application to connect to it. Open a new terminal window, navigate to
|
||||
this repository's root directory, and run:
|
||||
|
||||
```bash
|
||||
# If you haven't already, enable yarn workspaces
|
||||
yarn config set workspaces-experimental true
|
||||
|
||||
# Restore dependencies
|
||||
yarn install
|
||||
|
||||
# Run our dev command, but with the local orthanc config
|
||||
yarn run dev:orthanc
|
||||
```
|
||||
|
||||
#### Configuration: Learn More
|
||||
|
||||
> For more configuration fun, check out the
|
||||
> [Essentials Configuration](../configurationFiles.md) guide.
|
||||
|
||||
Let's take a look at what's going on under the hood here. `yarn run dev:orthanc`
|
||||
is running the `dev:orthanc` script in our project's `package.json` (inside
|
||||
`platform/app`). That script is:
|
||||
|
||||
```js
|
||||
cross-env NODE_ENV=development PROXY_TARGET=/dicom-web PROXY_DOMAIN=http://localhost:8042 APP_CONFIG=config/docker-nginx-orthanc.js webpack-dev-server --config .webpack/webpack.pwa.js -w
|
||||
```
|
||||
|
||||
- `cross-env` sets three environment variables
|
||||
- PROXY_TARGET: `/dicom-web`
|
||||
- PROXY_DOMAIN: `http://localhost:8042`
|
||||
- APP_CONFIG: `config/docker-nginx-orthanc.js`
|
||||
- `webpack-dev-server` runs using the `.webpack/webpack.pwa.js` configuration
|
||||
file. It will watch for changes and update as we develop.
|
||||
|
||||
`PROXY_TARGET` and `PROXY_DOMAIN` tell our development server to proxy requests
|
||||
to `Orthanc`. This allows us to bypass CORS issues that normally occur when
|
||||
requesting resources that live at a different domain.
|
||||
|
||||
The `APP_CONFIG` value tells our app which file to load on to `window.config`.
|
||||
By default, our app uses the file at
|
||||
`<project-root>/platform/app/public/config/default.js`. Here is what that
|
||||
configuration looks like:
|
||||
|
||||
```js
|
||||
window.config = {
|
||||
routerBasename: null,
|
||||
extensions: [],
|
||||
modes: [],
|
||||
showStudyList: true,
|
||||
dataSources: [
|
||||
{
|
||||
namespace: '@ohif/extension-default.dataSourcesModule.dicomweb',
|
||||
sourceName: 'dicomweb',
|
||||
configuration: {
|
||||
friendlyName: 'dcmjs DICOMWeb Server',
|
||||
name: 'DCM4CHEE',
|
||||
wadoUriRoot: 'https://server.dcmjs.org/dcm4chee-arc/aets/DCM4CHEE/wado',
|
||||
qidoRoot: 'https://server.dcmjs.org/dcm4chee-arc/aets/DCM4CHEE/rs',
|
||||
wadoRoot: 'https://server.dcmjs.org/dcm4chee-arc/aets/DCM4CHEE/rs',
|
||||
qidoSupportsIncludeField: true,
|
||||
supportsReject: true,
|
||||
imageRendering: 'wadors',
|
||||
thumbnailRendering: 'wadors',
|
||||
enableStudyLazyLoad: true,
|
||||
supportsFuzzyMatching: true,
|
||||
supportsWildcard: true,
|
||||
},
|
||||
},
|
||||
],
|
||||
defaultDataSourceName: 'dicomweb',
|
||||
};
|
||||
```
|
||||
|
||||
### Data Source Configuration Options
|
||||
|
||||
The following properties can be added to the `configuration` property of each data source.
|
||||
|
||||
##### `dicomUploadEnabled`
|
||||
A boolean indicating if the DICOM upload to the data source is permitted/accepted or not. A value of true provides a link on the OHIF work list page that allows for DICOM files from the local file system to be uploaded to the data source
|
||||
|
||||
:::tip
|
||||
The [OHIF plugin for Orthanc](https://book.orthanc-server.com/plugins/ohif.html) by default utilizes the DICOM JSON data
|
||||
source and it has been discovered that only those studies uploaded to Orthanc AFTER the plugin has been installed are
|
||||
available as DICOM JSON. As such, if the OHIF plugin for Orthanc is desired for studies uploaded prior to installing the plugin,
|
||||
then consider switching to using [DICOMweb instead](https://book.orthanc-server.com/plugins/ohif.html#using-dicomweb).
|
||||
:::
|
||||
|
||||
|
||||
|
||||
Don't forget to add the customization to the config as well
|
||||
|
||||
```js
|
||||
customizationService: {
|
||||
dicomUploadComponent:
|
||||
'@ohif/extension-cornerstone.customizationModule.cornerstoneDicomUploadComponent',
|
||||
},
|
||||
```
|
||||
|
||||
|
||||
#### `singlepart`
|
||||
A comma delimited string specifying which payloads the data source responds with as single part. Those not listed are considered multipart. Values that can be included here are `pdf`, `video`, `bulkdata`, `thumbnail` and `image`.
|
||||
|
||||
For DICOM video and PDF it has been found that Orthanc delivers multipart, while DCM4CHEE delivers single part. Consult the DICOM conformance statement for your particular data source to determine which payload types it delivers.
|
||||
|
||||
To learn more about how you can configure the OHIF Viewer, check out our
|
||||
[Configuration Guide](../configurationFiles.md).
|
||||
|
||||
|
||||
### DICOM PDF
|
||||
See the [`singlepart`](#singlepart) data source configuration option.
|
||||
|
||||
### DICOM Video
|
||||
See the [`singlepart`](#singlepart) data source configuration option.
|
||||
|
||||
### BulkDataURI
|
||||
|
||||
The `bulkDataURI` configuration option alters how the datasource uses the
|
||||
bulkdata end points for retrieving metadata if the data was originally not included in the
|
||||
response from the server. This is useful for the metadata information that
|
||||
are big and can/should be retrieved in a separate request. In case the bulkData URI
|
||||
is relative (instead of absolute) the `relativeResolution` option can be used to
|
||||
specify the resolution of the relative URI. The possible values are `studies`, `series`.
|
||||
|
||||
The default value is shown below (this will be added if not included in the config).
|
||||
|
||||
```js
|
||||
bulkDataURI: {
|
||||
enabled: true,
|
||||
relativeResolution: 'series',
|
||||
},
|
||||
```
|
||||
|
||||
The other options allowed are:
|
||||
|
||||
* transform - to take the string and return an updated string
|
||||
* startsWith and prefixWith - to remove a standard prefix and add an optional prefix
|
||||
* Used primarily for a reverse proxy or change in URL naming
|
||||
* relativeResolution - used to set bulkdata paths to studies resolution for incorrect bulkdata paths
|
||||
|
||||
### Running DCM4CHEE
|
||||
|
||||
dcm4che is a collection of open source applications for healthcare enterprise
|
||||
written in Java programming language which implements DICOM standard. dcm4chee
|
||||
(extra 'e' at the end) is dcm4che project for an Image Manager/Image Archive
|
||||
which provides storage, retrieval and other functionalities. You can read more
|
||||
about dcm4chee in their website [here](https://www.dcm4che.org/)
|
||||
|
||||
DCM4chee installation is out of scope for these tutorials and can be found
|
||||
[here](https://github.com/dcm4che/dcm4chee-arc-light/wiki/Run-minimum-set-of-archive-services-on-a-single-host)
|
||||
|
||||
An overview of steps for running OHIF Viewer using a local DCM4CHEE is shown
|
||||
below:
|
||||
|
||||
<div style={{padding:"56.25% 0 0 0", position:"relative"}}>
|
||||
<iframe src="https://player.vimeo.com/video/843233881?badge=0&autopause=0&player_id=0&app_id=58479" frameBorder="0" allow="autoplay; fullscreen; picture-in-picture" allowFullScreen style= {{ position:"absolute",top:0,left:0,width:"100%",height:"100%"}} title="measurement-report"></iframe>
|
||||
</div>
|
||||
|
||||
[dcm4chee]: https://github.com/dcm4che/dcm4chee-arc-light
|
||||
[dcm4chee-docker]:
|
||||
https://github.com/dcm4che/dcm4chee-arc-light/wiki/Running-on-Docker
|
||||
[orthanc]: https://www.orthanc-server.com/
|
||||
[orthanc-docker]: http://book.orthanc-server.com/users/docker.html
|
||||
[dicomcloud]: https://github.com/DICOMcloud/DICOMcloud
|
||||
[dicomcloud-install]: https://github.com/DICOMcloud/DICOMcloud#running-the-code
|
||||
[osirix]: http://www.osirix-viewer.com/
|
||||
[horos]: https://www.horosproject.org/
|
||||
[default-config]:
|
||||
https://github.com/OHIF/Viewers/blob/master/platform/app/public/config/default.js
|
||||
[html-templates]:
|
||||
https://github.com/OHIF/Viewers/tree/master/platform/app/public/html-templates
|
||||
[config-files]:
|
||||
https://github.com/OHIF/Viewers/tree/master/platform/app/public/config
|
||||
[storescu]: http://support.dcmtk.org/docs/storescu.html
|
||||
[webpack-proxy]: https://webpack.js.org/configuration/dev-server/#devserverproxy
|
||||
@@ -0,0 +1,21 @@
|
||||
---
|
||||
sidebar_position: 1
|
||||
sidebar_label: Introduction
|
||||
title: Data Source Introduction
|
||||
summary: Introduces OHIF's data structure based on naturalized DICOM JSON format, providing an overview of common data sources available in OHIF and how custom data sources can be implemented.
|
||||
---
|
||||
|
||||
# Data Source
|
||||
|
||||
The internal data structure of OHIF’s metadata follows naturalized DICOM JSON, a
|
||||
format pioneered by `dcmjs`. In short DICOM metadata headers with DICOM Keywords
|
||||
instead of tags and sequences as arrays, for easy development and clear code.
|
||||
|
||||
Here in this section we will discuss couple of data sources that are commonly used
|
||||
and OHIF has provided the implementation for them.
|
||||
|
||||
## Custom Data Source
|
||||
Do you have a custom data source? or a custom data that you want to use in OHIF?
|
||||
You can easily write a data source to map your data to OHIF’s native format.
|
||||
|
||||
You can read more in the [Data Source Module](../../platform/extensions/modules/data-source.md)
|
||||
@@ -0,0 +1,102 @@
|
||||
---
|
||||
sidebar_position: 5
|
||||
sidebar_label: Static Files
|
||||
title: Static DICOMweb Files
|
||||
summary: Details how to use the static-wado project to generate and serve optimized static DICOMweb files for enhanced OHIF Viewer performance, with step-by-step instructions for installation, file generation, and viewer configuration.
|
||||
---
|
||||
|
||||
|
||||
# Static DICOMweb Files for Enhanced Performance
|
||||
|
||||
This section describes how to generate and serve static DICOMweb files, significantly improving the performance of your OHIF Viewer setup. These files are pre-processed and compressed, minimizing storage space and reducing serving time to the bare minimum (disk read and HTTP stream write).
|
||||
|
||||
## Static-DICOMWeb Project
|
||||
|
||||
The core tool for this process is the `static-wado` project, available on GitHub:
|
||||
|
||||
[static-wado]: https://github.com/RadicalImaging/Static-DICOMWeb
|
||||
|
||||
This project contains two main components:
|
||||
|
||||
* **`static-wado-creator`:** Converts raw DICOM files into a DICOMweb-compliant directory structure, optimizing them for efficient serving.
|
||||
* **`static-wado-webserver`:** A simple web server specifically designed to serve the generated static DICOMweb files.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- Node.js and npm (or yarn) installed on your system.
|
||||
|
||||
## Installation
|
||||
|
||||
1. **Clone the Repository:**
|
||||
|
||||
```bash
|
||||
git clone https://github.com/RadicalImaging/Static-DICOMWeb
|
||||
cd Static-DICOMWeb
|
||||
```
|
||||
|
||||
2. **Install Dependencies:**
|
||||
|
||||
```bash
|
||||
yarn install
|
||||
```
|
||||
|
||||
## Generating Static DICOMweb Files
|
||||
|
||||
1. **Prepare your DICOM data:** Organize your DICOM files into a directory. For example `/Users/alireza/dicom/test-static-script/ACRIN-CT`.
|
||||
|
||||
2. **Convert to DICOMweb Structure:**
|
||||
Use the `mkdicomweb.js` script from the `static-wado-creator` package to create the DICOMweb directory:
|
||||
|
||||
```bash
|
||||
node packages/static-wado-creator/bin/mkdicomweb.js '/Users/alireza/dicom/test-static-script/ACRIN-CT' -o '/Users/alireza/dicom/test-static-script/output'
|
||||
```
|
||||
|
||||
* **Replace:**
|
||||
* `/Users/alireza/dicom/test-static-script/ACRIN-CT` with the path to your directory of DICOM files.
|
||||
* `/Users/alireza/dicom/test-static-script/output` with your desired output directory for the DICOMweb structure.
|
||||
|
||||
This command will generate a directory structure similar to this in your output location:
|
||||
|
||||
|
||||
|
||||
## Serving Static Files with the Web Server
|
||||
|
||||
1. **Start the Server:**
|
||||
|
||||
Run the `dicomwebserver.mjs` script from the `static-wado-webserver` package, specifying the port and the DICOMweb directory:
|
||||
|
||||
```bash
|
||||
node packages/static-wado-webserver/bin/dicomwebserver.mjs -p 3001 -o /Users/alireza/dicom/test-static-script/output
|
||||
```
|
||||
|
||||
* **`-p 3001`:** Sets the server to listen on port 3001. You can change this if needed.
|
||||
* **`-o /Users/alireza/dicom/test-static-script/output`:** Specifies the path to your generated DICOMweb directory.
|
||||
|
||||
:::info
|
||||
The `-p` (port) and `-o` (output directory) flags are used to configure the server.
|
||||
:::
|
||||
|
||||
## Running OHIF Viewer with Static Data
|
||||
|
||||
1. **Use the `local_static.js` Configuration:**
|
||||
|
||||
Start the OHIF Viewer in development mode using the provided `local_static.js` configuration file:
|
||||
|
||||
```bash
|
||||
yarn dev:static
|
||||
```
|
||||
|
||||
2. **Configuration Details:**
|
||||
|
||||
The `local_static.js` configuration file is pre-configured to point to:
|
||||
|
||||
```js
|
||||
qidoRoot: 'http://localhost:3001/dicomweb',
|
||||
wadoRoot: 'http://localhost:3001/dicomweb',
|
||||
```
|
||||
|
||||
This matches the default port (3001) used by the `static-wado-webserver`.
|
||||
|
||||
:::info
|
||||
If you change the port or output directory when running the `static-wado-webserver`, you **must** also update the `qidoRoot` and `wadoRoot` values in your `local_static.js` configuration file accordingly to ensure the OHIF Viewer can access the data.
|
||||
:::
|
||||
Reference in new issue
Block a user