Overview
After following the steps outlined in Getting Started, 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 remote server hosted by the nice folks over at dcmjs.org. While convenient for getting started, the time may come when you want to develop using your own data either locally or remotely.
#
Configuration FilesThe configuration for our viewer is in the <root>platform/viewer/public/config
directory. Our build process knows which configuration file to use based on the
APP_CONFIG
environment variable. By default, its value is
config/default.js
. The majority of the viewer's features,
and registered extension's features, are configured using this file.
The simplest way is to update the existing default config:
window.config = { routerBasename: '/', extensions: [], modes: [], showStudyList: true, dataSources: [ { friendlyName: 'dcmjs DICOMWeb Server', namespace: 'org.ohif.default.dataSourcesModule.dicomweb', sourceName: 'dicomweb', configuration: { 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',};
As you can see a new change in
OHIF-v3
is the addition ofdataSources
. You can build your own datasource and map it to the internal data structure of OHIFโs > metadata and enjoy using other peoples developed mode on your own data!You can read more about data sources at Data Source section in Modes
The configuration can also be written as a JS Function in case you need to inject dependencies like external services:
window.config = ({ servicesManager } = {}) => { const { UIDialogService } = servicesManager.services; return { cornerstoneExtensionConfig: { tools: { ArrowAnnotate: { configuration: { getTextCallback: (callback, eventDetails) => UIDialogService.create({... } } }, }, routerBasename: '/', dataSources: [ { friendlyName: 'dcmjs DICOMWeb Server', namespace: 'org.ohif.default.dataSourcesModule.dicomweb', sourceName: 'dicomweb', configuration: { 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', };};
#
Environment VariablesWe use environment variables at build and dev time to change the Viewer's
behavior. We can update the HTML_TEMPLATE
to easily change which extensions
are registered, and specify a different APP_CONFIG
to connect to an
alternative data source (or even specify different default hotkeys).
Environment Variable | Description | Default |
---|---|---|
HTML_TEMPLATE | Which HTML template to use as our web app's entry point. Specific to PWA builds. | index.html |
PUBLIC_URL | The route relative to the host that the app will be served from. Specific to PWA builds. | / |
APP_CONFIG | Which [configuration file][config-file] to copy to output as app-config.js | config/default.js |
PROXY_TARGET | When developing, proxy requests that match this pattern to PROXY_DOMAIN | undefined |
PROXY_DOMAIN | When developing, proxy requests from PROXY_TARGET to PROXY_DOMAIN | undefined |
You can also create a new config file and specify its path relative to the build
output's root by setting the APP_CONFIG
environment variable. You can set the
value of this environment variable a few different ways:
- ~Add a temporary environment variable in your shell~
- Previous
react-scripts
functionality that we need to duplicate withdotenv-webpack
- Previous
- ~Add environment specific variables in
.env
file(s)~- Previous
react-scripts
functionality that we need to duplicate withdotenv-webpack
- Previous
- Using the
cross-env
package in an npm script:"build": "cross-env APP_CONFIG=config/my-config.js react-scripts build"
After updating the configuration, yarn run build
to generate updated build
output.