diff --git a/.webpack/webpack.base.js b/.webpack/webpack.base.js index ec8ec5291eb..e1b531461da 100644 --- a/.webpack/webpack.base.js +++ b/.webpack/webpack.base.js @@ -73,15 +73,6 @@ module.exports = (env, argv, { SRC_DIR, ENTRY }) => { children: false, warnings: true, }, - devServer: { - open: true, - port: 3000, - historyApiFallback: true, - headers: { - 'Cross-Origin-Embedder-Policy': 'require-corp', - 'Cross-Origin-Opener-Policy': 'same-origin', - }, - }, cache: { type: 'filesystem', }, diff --git a/extensions/cornerstone-dicom-sr/package.json b/extensions/cornerstone-dicom-sr/package.json index 0ab1e03d81e..c820986c34f 100644 --- a/extensions/cornerstone-dicom-sr/package.json +++ b/extensions/cornerstone-dicom-sr/package.json @@ -44,9 +44,9 @@ }, "dependencies": { "@babel/runtime": "^7.20.13", - "@cornerstonejs/adapters": "^1.1.8", - "@cornerstonejs/core": "^1.1.8", - "@cornerstonejs/tools": "^1.1.8", + "@cornerstonejs/adapters": "^1.2.4", + "@cornerstonejs/core": "^1.2.4", + "@cornerstonejs/tools": "^1.2.4", "classnames": "^2.3.2" } } diff --git a/extensions/cornerstone/package.json b/extensions/cornerstone/package.json index 92d5cb8d005..8240cf5982a 100644 --- a/extensions/cornerstone/package.json +++ b/extensions/cornerstone/package.json @@ -36,7 +36,7 @@ "@cornerstonejs/codec-libjpeg-turbo-8bit": "^1.2.2", "@cornerstonejs/codec-openjpeg": "^1.2.2", "@cornerstonejs/codec-openjph": "^2.4.2", - "@cornerstonejs/dicom-image-loader": "^1.1.8", + "@cornerstonejs/dicom-image-loader": "^1.2.4", "@ohif/core": "3.7.0-beta.11", "@ohif/ui": "3.7.0-beta.11", "dcmjs": "^0.29.6", @@ -52,10 +52,10 @@ }, "dependencies": { "@babel/runtime": "^7.20.13", - "@cornerstonejs/adapters": "^1.1.8", - "@cornerstonejs/core": "^1.1.8", - "@cornerstonejs/streaming-image-volume-loader": "^1.1.8", - "@cornerstonejs/tools": "^1.1.8", + "@cornerstonejs/adapters": "^1.2.4", + "@cornerstonejs/core": "^1.2.4", + "@cornerstonejs/streaming-image-volume-loader": "^1.2.4", + "@cornerstonejs/tools": "^1.2.4", "@kitware/vtk.js": "27.3.1", "html2canvas": "^1.4.1", "lodash.debounce": "4.0.8", diff --git a/extensions/measurement-tracking/package.json b/extensions/measurement-tracking/package.json index 53b9445432a..5302d7076f8 100644 --- a/extensions/measurement-tracking/package.json +++ b/extensions/measurement-tracking/package.json @@ -30,8 +30,8 @@ "start": "yarn run dev" }, "peerDependencies": { - "@cornerstonejs/core": "^1.1.8", - "@cornerstonejs/tools": "^1.1.8", + "@cornerstonejs/core": "^1.2.4", + "@cornerstonejs/tools": "^1.2.4", "@ohif/core": "3.7.0-beta.11", "@ohif/extension-cornerstone-dicom-sr": "3.7.0-beta.11", "@ohif/ui": "3.7.0-beta.11", diff --git a/package.json b/package.json index d710148376c..dd370c7c909 100644 --- a/package.json +++ b/package.json @@ -149,7 +149,7 @@ ] }, "resolutions": { - "@cornerstonejs/core": "^1.1.8", + "@cornerstonejs/core": "^1.2.4", "**/@babel/runtime": "^7.20.13", "commander": "8.3.0", "nth-check": "^2.1.1", diff --git a/platform/app/netlify.toml b/platform/app/netlify.toml index 4af3dd5977b..5942b9a58b7 100644 --- a/platform/app/netlify.toml +++ b/platform/app/netlify.toml @@ -43,3 +43,5 @@ # COMMENT: For sharedArrayBuffer, see https://developer.chrome.com/blog/enabling-shared-array-buffer/ Cross-Origin-Embedder-Policy = "require-corp" Cross-Origin-Opener-Policy = "same-origin" + # set CORP to cross-origin for anyone who wants to use the viewer in an iframe + Cross-Origin-Resource-Policy = "cross-origin" diff --git a/platform/app/package.json b/platform/app/package.json index 8a1f367f2e0..eeabf0a9c9a 100644 --- a/platform/app/package.json +++ b/platform/app/package.json @@ -51,7 +51,7 @@ "@cornerstonejs/codec-libjpeg-turbo-8bit": "^1.2.2", "@cornerstonejs/codec-openjpeg": "^1.2.2", "@cornerstonejs/codec-openjph": "^2.4.2", - "@cornerstonejs/dicom-image-loader": "^1.1.8", + "@cornerstonejs/dicom-image-loader": "^1.2.4", "@ohif/core": "3.7.0-beta.11", "@ohif/extension-cornerstone": "3.7.0-beta.11", "@ohif/extension-cornerstone-dicom-rt": "3.7.0-beta.11", diff --git a/platform/core/package.json b/platform/core/package.json index acaeebb2f2b..dcccdf99781 100644 --- a/platform/core/package.json +++ b/platform/core/package.json @@ -35,7 +35,7 @@ "@cornerstonejs/codec-libjpeg-turbo-8bit": "^1.2.2", "@cornerstonejs/codec-openjpeg": "^1.2.2", "@cornerstonejs/codec-openjph": "^2.4.2", - "@cornerstonejs/dicom-image-loader": "^1.1.8", + "@cornerstonejs/dicom-image-loader": "^1.2.4", "@ohif/ui": "3.7.0-beta.11", "cornerstone-math": "0.1.9", "dicom-parser": "^1.8.21" diff --git a/platform/docs/docs/assets/img/iframe-basic.png b/platform/docs/docs/assets/img/iframe-basic.png new file mode 100644 index 00000000000..25ea20708bf Binary files /dev/null and b/platform/docs/docs/assets/img/iframe-basic.png differ diff --git a/platform/docs/docs/assets/img/iframe-headers.png b/platform/docs/docs/assets/img/iframe-headers.png new file mode 100644 index 00000000000..27d649d22f3 Binary files /dev/null and b/platform/docs/docs/assets/img/iframe-headers.png differ diff --git a/platform/docs/docs/deployment/authorization.md b/platform/docs/docs/deployment/authorization.md index daba7454e7b..6de334c7c3b 100644 --- a/platform/docs/docs/deployment/authorization.md +++ b/platform/docs/docs/deployment/authorization.md @@ -1,5 +1,5 @@ --- -sidebar_position: 8 +sidebar_position: 7 sidebar_label: Authorization --- diff --git a/platform/docs/docs/deployment/build-for-production.md b/platform/docs/docs/deployment/build-for-production.md index b1fa6999ccc..7c061a89eb9 100644 --- a/platform/docs/docs/deployment/build-for-production.md +++ b/platform/docs/docs/deployment/build-for-production.md @@ -70,7 +70,7 @@ and registered extension's features, are configured using this file. The easiest way to apply your own configuration is to modify the `default.js` file. For more advanced configuration options, check out our -[configuration essentials guide](../configuration/index.md). +[configuration essentials guide](../configuration/configurationFiles.md). ## Next Steps @@ -108,6 +108,10 @@ yarn global add http-server npx http-server ./dist ``` +:::caution +In the video below notice that there is `platform/viewer` which has been renamed to `platform/app` in the latest version +::: +
@@ -127,6 +131,6 @@ web application. For a starting point, check out this repository's own use of: [circleci]: https://circleci.com/gh/OHIF/Viewers [circleci-config]: https://github.com/OHIF/Viewers/blob/master/.circleci/config.yml [netlify]: https://app.netlify.com/sites/ohif/deploys -[netlify.toml]: https://github.com/OHIF/Viewers/blob/master/netlify.toml +[netlify.toml]: https://github.com/OHIF/Viewers/blob/master/platform/app/netlify.toml [build-deploy-preview.sh]: https://github.com/OHIF/Viewers/blob/master/.netlify/build-deploy-preview.sh diff --git a/platform/docs/docs/deployment/google-cloud-healthcare.md b/platform/docs/docs/deployment/google-cloud-healthcare.md deleted file mode 100644 index 0484bbdfb7a..00000000000 --- a/platform/docs/docs/deployment/google-cloud-healthcare.md +++ /dev/null @@ -1,7 +0,0 @@ ---- -sidebar_position: 7 ---- - -# Google Cloud Healthcare - -> Coming soon - We are working on bringing Google Cloud Healthcare to OHIF-v3 diff --git a/platform/docs/docs/deployment/iframe.md b/platform/docs/docs/deployment/iframe.md new file mode 100644 index 00000000000..4aef3b96d46 --- /dev/null +++ b/platform/docs/docs/deployment/iframe.md @@ -0,0 +1,163 @@ +--- +sidebar_position: 7 +sidebar_label: iframe +--- + +# iframe + +With the transition to more advanced visualization, loading, and rendering techniques using WebWorkers, WASM, and WebGL, the script tag usage of the OHIF viewer v3 has been deprecated. +An alternative option for script tag usage is to employ an iframe. You can utilize the iframe element to load the OHIF viewer and establish communication with it using the postMessage API if needed. + +We recommend utilizing modern development practices and incorporating OHIF viewer within your application using a more modular and integrated approach, such as leveraging bundlers, other UI +components, and frameworks. + +## Static Build + +You can use the iframe element to load the OHIF viewer as a child element of your application if you need the +viewer to be embedded within your application. The iframe element can be used as follows (use your own custom styles) + +```html + - - -[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/viewer/public/config/default.js -[html-templates]: - https://github.com/OHIF/Viewers/tree/master/platform/viewer/public/html-templates -[config-files]: - https://github.com/OHIF/Viewers/tree/master/platform/viewer/public/config diff --git a/platform/docs/versioned_docs/version-3.0/configuration/dataSources/static-files.md b/platform/docs/versioned_docs/version-3.0/configuration/dataSources/static-files.md deleted file mode 100644 index 62c53d69b93..00000000000 --- a/platform/docs/versioned_docs/version-3.0/configuration/dataSources/static-files.md +++ /dev/null @@ -1,45 +0,0 @@ ---- -sidebar_position: 2 -sidebar_label: Static Files ---- - -# Static Files - -There is a binary DICOM to static file generator, which provides easily served -binary files. The files are all compressed in order to reduce space -significantly, and are pre-computed for the files required for OHIF, so that the -performance of serving the files is just the read from disk/write to http stream -time, without any extra processing time. - -The project for the static wado files is located here: [static-wado]: -https://github.com/wayfarer3130/static-wado - -It can be compiled with Java and Gradle, and then run against a set of dicom, in -the example located in /dicom/study1 outputting to /dicomweb, and then a server -run against that data, like this: - -``` -git clone https://github.com/wayfarer3130/static-wado.git -cd static-wado -./gradlew installDist -StaticWado/build/install/StaticWado/bin/StaticWado -d /dicomweb /dicom/study1 -cd /dicomweb -npx http-server -p 5000 --cors -g -``` - -There is then a dev environment in the platform/viewer directory which can be -run against those files, like this: - -``` -cd platform/viewer -yarn dev:static -``` - -Additional studies can be added to the dicomweb by re-running the StaticWado -command. It will create a single studies.gz index file (JSON DICOM file, -compressed) containing an index of all studies created. There is then a small -extension to OHIF which performs client side indexing. - -The StaticWado command also knows how to deploy a client and dicomweb directory -to Amazon s3, which can then server files up directly. There is another build -setup build:aws in the viewer package.json to create such a deployment. diff --git a/platform/docs/versioned_docs/version-3.0/configuration/index.md b/platform/docs/versioned_docs/version-3.0/configuration/index.md deleted file mode 100644 index f51abd3d3ac..00000000000 --- a/platform/docs/versioned_docs/version-3.0/configuration/index.md +++ /dev/null @@ -1,168 +0,0 @@ ---- -sidebar_position: 1 -sidebar_label: Overview ---- - -# Overview - -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 remote server hosted by the -nice folks over at [dcmjs.org][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 Files - -The configuration for our viewer is in the `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`][default-config]. 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: - -```js title="platform/viewer/public/config/default.js" -window.config = { - routerBasename: '/', - extensions: [], - modes: [], - showStudyList: true, - dataSources: [ - { - friendlyName: 'dcmjs DICOMWeb Server', - namespace: '@ohif/extension-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 of `dataSources`. 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](../platform/modes/index.md) - -The configuration can also be written as a JS Function in case you need to -inject dependencies like external services: - -```js -window.config = ({ servicesManager } = {}) => { - const { UIDialogService } = servicesManager.services; - return { - cornerstoneExtensionConfig: { - tools: { - ArrowAnnotate: { - configuration: { - getTextCallback: (callback, eventDetails) => UIDialogService.create({... - } - } - }, - }, - routerBasename: '/', - dataSources: [ - { - friendlyName: 'dcmjs DICOMWeb Server', - namespace: '@ohif/extension-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 Variables - -We 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][html-templates] 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](https://facebook.github.io/create-react-app/docs/adding-custom-environment-variables#adding-temporary-environment-variables-in-your-shell)~ - - Previous `react-scripts` functionality that we need to duplicate with - `dotenv-webpack` -- ~[Add environment specific variables in `.env` file(s)](https://facebook.github.io/create-react-app/docs/adding-custom-environment-variables#adding-development-environment-variables-in-env)~ - - Previous `react-scripts` functionality that we need to duplicate with - `dotenv-webpack` -- Using the `cross-env` package in a 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. - - - - -[dcmjs-org]: https://server.dcmjs.org/dcm4chee-arc/aets/DCM4CHEE/wado -[dicom-web]: https://en.wikipedia.org/wiki/DICOMweb -[storescu]: https://support.dcmtk.org/docs/storescu.html -[webpack-proxy]: https://webpack.js.org/configuration/dev-server/#devserverproxy -[orthanc-docker-compose]: https://github.com/OHIF/Viewers/tree/master/.docker/Nginx-Orthanc - -[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]: https://book.orthanc-server.com/users/docker.html -[dicomcloud]: https://github.com/DICOMcloud/DICOMcloud -[dicomcloud-install]: https://github.com/DICOMcloud/DICOMcloud#running-the-code -[osirix]: https://www.osirix-viewer.com/ -[horos]: https://www.horosproject.org/ -[default-config]: https://github.com/OHIF/Viewers/blob/master/platform/viewer/public/config/default.js -[html-templates]: https://github.com/OHIF/Viewers/tree/master/platform/viewer/public/html-templates -[config-files]: https://github.com/OHIF/Viewers/tree/master/platform/viewer/public/config - diff --git a/platform/docs/versioned_docs/version-3.0/deployment/_category_.json b/platform/docs/versioned_docs/version-3.0/deployment/_category_.json deleted file mode 100644 index 534be1dfb6d..00000000000 --- a/platform/docs/versioned_docs/version-3.0/deployment/_category_.json +++ /dev/null @@ -1,4 +0,0 @@ -{ - "label": "Deployment", - "position": 3 -} diff --git a/platform/docs/versioned_docs/version-3.0/deployment/build-for-production.md b/platform/docs/versioned_docs/version-3.0/deployment/build-for-production.md deleted file mode 100644 index b23463237a4..00000000000 --- a/platform/docs/versioned_docs/version-3.0/deployment/build-for-production.md +++ /dev/null @@ -1,132 +0,0 @@ ---- -sidebar_position: 2 ---- - -# Build for Production - -### Build Machine Requirements - -- [Node.js & NPM](https://nodejs.org/en/download/) -- [Yarn](https://yarnpkg.com/lang/en/docs/install/) -- [Git](https://www.atlassian.com/git/tutorials/install-git) - -### Getting the Code - -_With Git:_ - -```bash -# Clone the remote repository to your local machine -git clone https://github.com/OHIF/Viewers.git -``` - -More on: _[`git clone`](https://git-scm.com/docs/git-clone), -[`git checkout`](https://git-scm.com/docs/git-checkout)_ - -_From .zip:_ - -[OHIF/Viewers: master.zip](https://github.com/OHIF/Viewers/archive/master.zip) - -### Restore Dependencies & Build - -Open your terminal, and navigate to the directory containing the source files. -Next run these commands: - -```bash -# If you haven't already, enable yarn workspaces -yarn config set workspaces-experimental true - -# Restore dependencies -yarn install - -# Build source code for production -yarn run build -``` - -If everything worked as expected, you should have a new `dist/` directory in the -`platform/viewer/dist` folder. It should roughly resemble the following: - -```bash title="platform/viewer/dist/" -β”œβ”€β”€ app-config.js -β”œβ”€β”€ app.bundle.js -β”œβ”€β”€ app.css -β”œβ”€β”€ index.html -β”œβ”€β”€ manifest.json -β”œβ”€β”€ service-worker.js -└── ... -``` - -By default, the build output will connect to OHIF's publicly accessible PACS. If -this is your first time setting up the OHIF Viewer, it is recommended that you -test with these default settings. After testing, you can find instructions on -how to configure the project for your own imaging archive below. - -### Configuration - -The configuration for our viewer is in the `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`][default-config]. The majority of the viewer's features, -and registered extension's features, are configured using this file. - -The easiest way to apply your own configuration is to modify the `default.js` -file. For more advanced configuration options, check out our -[configuration essentials guide](../configuration/index.md). - -## Next Steps - -### Deploying Build Output - -_Drag-n-drop_ - -- [Netlify: Drop](./static-assets#netlify-drop) - -_Easy_ - -- [Surge.sh](./static-assets#surgesh) -- [GitHub Pages](./static-assets#github-pages) - -_Advanced_ - -- [AWS S3 + Cloudfront](./static-assets#aws-s3--cloudfront) -- [GCP + Cloudflare](./static-assets#gcp--cloudflare) -- [Azure](./static-assets#azure) - -### Testing Build Output Locally - -A quick way to test your build output locally is to spin up a small webserver. -You can do this by running the following commands in the `dist/` output -directory: - -```bash -# Install http-server as a globally available package -yarn global add http-server - -# Change the directory to the platform/viewer - -# Serve the files in our current directory -# Accessible at: `http://localhost:8080` -npx http-server ./dist -``` - -
- -
- -### Automating Builds and Deployments - -If you found setting up your environment and running all of these steps to be a -bit tedious, then you are in good company. Thankfully, there are a large number -of tools available to assist with automating tasks like building and deploying -web application. For a starting point, check out this repository's own use of: - -- [CircleCI][circleci]: [config.yaml][circleci-config] -- [Netlify][netlify]: [netlify.toml][netlify.toml] | - [build-deploy-preview.sh][build-deploy-preview.sh] - - -[circleci]: https://circleci.com/gh/OHIF/Viewers -[circleci-config]: https://github.com/OHIF/Viewers/blob/master/.circleci/config.yml -[netlify]: https://app.netlify.com/sites/ohif/deploys -[netlify.toml]: https://github.com/OHIF/Viewers/blob/master/netlify.toml -[build-deploy-preview.sh]: https://github.com/OHIF/Viewers/blob/master/.netlify/build-deploy-preview.sh - diff --git a/platform/docs/versioned_docs/version-3.0/deployment/google-cloud-healthcare.md b/platform/docs/versioned_docs/version-3.0/deployment/google-cloud-healthcare.md deleted file mode 100644 index 532bf4cc636..00000000000 --- a/platform/docs/versioned_docs/version-3.0/deployment/google-cloud-healthcare.md +++ /dev/null @@ -1,7 +0,0 @@ ---- -sidebar_position: 6 ---- - -# Google Cloud Healthcare - -> Coming soon - We are working on bringing Google Cloud Healthcare to OHIF-v3 diff --git a/platform/docs/versioned_docs/version-3.0/deployment/index.md b/platform/docs/versioned_docs/version-3.0/deployment/index.md deleted file mode 100644 index 384aefc777d..00000000000 --- a/platform/docs/versioned_docs/version-3.0/deployment/index.md +++ /dev/null @@ -1,335 +0,0 @@ ---- -sidebar_position: 1 -sidebar_label: Overview ---- - -# Deployment - -The OHIF Viewer can be embedded in other web applications via it's [packaged -script source][viewer-npm], or served up as a stand-alone PWA ([progressive web -application][pwa-url]) by building and hosting a collection of static assets. In -either case, you will need to configure your instance of the Viewer so that it -can connect to your data source (the database or PACS that provides the data -your Viewer will display). - -## Overview - -Our goal is to make deployment as simple and painless as possible; however, -there is an inherent amount of complexity in configuring and deploying web -applications. If you find yourself a little lost, please don't hesitate to -[reach out for help](/help) - -## Deployment Scenarios - -### Embedded Viewer (deprecated) - -`OHIF-v3` has deprecated deploying the viewer as an embedded viewer the number -of underlying libraries that run web workers are increasing for OHIF. An example -of these libraries is OHIF's 3D rendering functionality that is provided by -`vtk-js`. - -### Stand-alone Viewer - -Deploying the OHIF Viewer as a stand-alone web application provides many -benefits, but comes at the cost of time and complexity. Some benefits include: - -_Today:_ - -- Leverage [extensions](../platform/extensions/index.md) and - [modes](../platform/modes/index.md) to drop-in powerful new features -- Add routes and customize the viewer's workflow -- Finer control over styling and whitelabeling - -_In the future:_ - -- The ability to package the viewer for [App Store distribution][app-store] -- Leverage `service-workers` for offline support and speed benefits from caching - -#### Hosted Static Assets - -At the end of the day, a production OHIF Viewer instance is a collection of -HTML, CSS, JS, Font Files, and Images. We "build" those files from our -`source code` with configuration specific to our project. We then make those -files publicly accessible by hosting them on a Web Server. - -If you have not deployed a web application before, this may be a good time to -[reach out for help](/help), as these steps assume prior web development and -deployment experience. - -##### Part 1 - Build Production Assets - -"Building", or creating, the files you will need is the same regardless of the -web host you choose. You can find detailed instructions on how to configure and -build the OHIF Viewer in our -["Build for Production" guide](./build-for-production.md). - -##### Part 2 - Host Your App - -There are a lot of [benefits to hosting static assets][host-static-assets] over -dynamic content. You can find instructions on how to host your build's output -via one of these guides: - -_Drag-n-drop_ - -- [Netlify: Drop](./static-assets.md#netlify-drop) - -_Easy_ - -- [Surge.sh](./static-assets.md#surgesh) -- [GitHub Pages](./static-assets.md#github-pages) - -_Advanced_ - -- [AWS S3 + Cloudfront](./static-assets.md#aws-s3--cloudfront) -- [GCP + Cloudflare](./static-assets.md#gcp--cloudflare) -- [Azure](./static-assets.md#azure) - -## Data - -The OHIF Viewer is able to connect to any data source that implements the [DICOM -Web Standard][dicom-web-standard]. [DICOM Web][dicom-web] refers to RESTful -DICOM Services -- a recently standardized set of guidelines for exchanging -medical images and imaging metadata over the internet. Not all archives fully -support it yet, but it is gaining wider adoption. - -### Configure Connection - -If you have an existing archive and intend to host the OHIF Viewer at the same -domain name as your archive, then connecting the two is as simple as following -the steps layed out in our -[Configuration Essentials Guide](./../configuration/index.md). - -#### What if I don't have an imaging archive? - -We provide some guidance on configuring a local image archive in our -[Data Source Essentials](./../configuration/index.md#set-up-a-local-DICOM-server) -guide. Hosting an archive remotely is a little trickier. You can check out some -of our [advanced recipes](#recipes) for modeled setups that may work for you. - -#### What if I intend to host the OHIF Viewer at a different domain? - -There are two important steps to making sure this setup works: - -1. Your Image Archive needs to be exposed, in some way, to the open web. This - can be directly, or through a `reverse proxy`, but the Viewer needs _some - way_ to request its data. -2. \* Your Image Archive needs to have appropriate CORS (Cross-Origin Resource - Sharing) Headers - -> \* Cross-Origin Resource Sharing (CORS) is a mechanism that uses additional -> HTTP headers to tell a browser to let a web application running at one origin -> (domain) have permission to access selected resources from a server at a -> different origin. - [MDN Web Docs: Web - Http - CORS][cors] - -Most image archives do not provide either of these features "out of the box". -It's common to use IIS, Nginx, or Apache to route incoming requests and append -appropriate headers. You can find an example of this setup in our -[Nginx + Image Archive Deployment Recipe](./nginx--image-archive.md). - -#### What if my archive doesn't support DicomWeb? - -It's possible to supply all Study data via JSON format, in the event you do not -have a DicomWeb endpoint. You can host all of the relevant files on any web -accessible server (Amazon S3, Azure Blob Storage, Local file server etc.) - -This JSON is supplied via the '?url=' query parameter. It should reference an -endpoint that returns **application/json** formatted text. - -If you do not have an API, you can simply return a text file containing the JSON -from any web server. - -You tell the OHIF viewer to use JSON by using the `dicomjson` datasource and -appending `'?url='` query to your mode's route: - -e.g. -`https://my-test-ohif-server/myMode/dicomjson?url=https://my-json-server/study-uid.json` - -The returned JSON object must contain a single root object with a 'studies' -array. - -You can read more about using different data sources for mode's routes -[here](../platform/modes/routes.md#route-path) - -_Sample JSON format:_ - -```json -{ - "studies": [ - { - "StudyInstanceUID": "1.2.840.113619.2.5.1762583153.215519.978957063.78", - "StudyDescription": "BRAIN SELLA", - "StudyDate": "20010108", - "StudyTime": "120022", - "PatientName": "MISTER^MR", - "PatientId": "832040", - "series": [ - { - "SeriesDescription": "SAG T-1", - "SeriesInstanceUID": "1.2.840.113619.2.5.1762583153.215519.978957063.121", - "SeriesNumber": 2, - "SeriesDate": "20010108", - "SeriesTime": "120318", - "Modality": "MR", - "instances": [ - { - "metadata": { - "Columns": 512, - "Rows": 512, - "InstanceNumber": 3, - "AcquisitionNumber": 0, - "PhotometricInterpretation": "MONOCHROME2", - "BitsAllocated": 16, - "BitsStored": 16, - "PixelRepresentation": 1, - "SamplesPerPixel": 1, - "PixelSpacing": [0.390625, 0.390625], - "HighBit": 15, - "ImageOrientationPatient": [0, 1, 0, 0, 0, -1], - "ImagePositionPatient": [11.6, -92.5, 98.099998], - "FrameOfReferenceUID": "1.2.840.113619.2.5.1762583153.223134.978956938.470", - "ImageType": ["ORIGINAL", "PRIMARY", "OTHER"], - "Modality": "MR", - "SOPInstanceUID": "1.2.840.113619.2.5.1762583153.215519.978957063.124", - "SeriesInstanceUID": "1.2.840.113619.2.5.1762583153.215519.978957063.121", - "StudyInstanceUID": "1.2.840.113619.2.5.1762583153.215519.978957063.78" - }, - "url": "dicomweb://s3.amazonaws.com/lury/MRStudy/1.2.840.113619.2.5.1762583153.215519.978957063.124.dcm" - } - ] - } - ] - } - ] -} -``` - -More info on this JSON format can be found here -[Issue #1500](https://github.com/OHIF/Viewers/issues/1500) - -**Implementation Notes:** - - - -1. For each instance url (dicom object) in the returned JSON, you must prefix - the `url` with `dicomjson:` in order for the cornerstone image loader to - retrieve it correctly. eg. `https://image-server/my-image.dcm` ---> - `dicomjson:https://image-server/my-image.dcm` -2. The JSON format above is compatible with >= v3.7.8 of the application in `V2` - version. Older versions of the viewer used a different JSON format. As of - 20/04/20 the public [https://viewer.ohif.org/] is a pre 3.0 version that does - not support this format yet. -3. The JSON format is case-sensitive. Please ensure you have matched casing with - the naturalised Dicom format referenced in - [Issue #1500](https://github.com/OHIF/Viewers/issues/1500). - -_CORS Issues (Cross-Origin Resource Sharing)_ - -If you host a JSON API or Images on a different domain from the app itself, -you will likely have CORS issues. This will also happen when testing from -Localhost and reaching out to remote servers. Even if the domain is the same, -different ports, subdomains or protocols (https vs http) will also cause CORS -errors. You will to need add a configuration on each server hosting these assets -to allow your App server origin. - -For example: - -Let's assume your application is hosted on `https://my-ohif-server.com`. - -Your JSON API is hosted on `https://my-json-api.aws.com` - -And your images are stored on Amazon S3 at `https://my-s3-bucket.aws.com` - -When you first start your application, browsing to -`https://my-ohif-server.com/myMode/dicomjson?url=https://my-json-api.aws.com/api/my-json-study-info.json`, -you will likely get a CORS error in the browser console as it tries to connect -to `https://my-json-api.aws.com`. - -Adding a setting on the JSON server to allow the CORS origin = -`https://my-ohif-server.com` should solve this. - -Next, you will likely get a similar CORS error, as the browser tries to go to -`https://my-s3-bucket.aws.com`. You will need to go to the S3 bucket -configuration, and add a CORS setting to allow origin = -`https://my-ohif-server.com`. - -Essentially, whenever the application connects to a remote resource, you will -need to add the applications url to the allowed CORS Origins on that resource. -Adding an origin similar to https://localhost:3000 will also allow for local -testing. - -### Securing Your Data - -Coming soon - - - -### Recipes - -We've included a few recipes for common deployment scenarios. There are many, -many possible configurations, so please don't feel limited to these setups. -Please feel free to suggest or contribute your own recipes. - -- [Build for Production](./build-for-production.md) -- [Static](./static-assets.md) -- [Nginx + Image Archive](./nginx--image-archive.md) -- [User Account Control](./user-account-control.md) - - - - -[viewer-npm]: https://www.npmjs.com/package/@ohif/viewer -[pwa-url]: https://developers.google.com/web/progressive-web-apps/ -[static-assets-url]: https://www.maxcdn.com/one/visual-glossary/static-content/ -[app-store]: https://medium.freecodecamp.org/i-built-a-pwa-and-published-it-in-3-app-stores-heres-what-i-learned-7cb3f56daf9b -[dicom-web-standard]: https://www.dicomstandard.org/dicomweb/ -[dicom-web]: https://en.wikipedia.org/wiki/DICOMweb -[host-static-assets]: https://www.netlify.com/blog/2016/05/18/9-reasons-your-site-should-be-static/ -[cors]: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS -[code-flows]: https://medium.com/@darutk/diagrams-of-all-the-openid-connect-flows-6968e3990660 -[code-sandbox]: https://codesandbox.io/s/viewer-script-tag-tprch - diff --git a/platform/docs/versioned_docs/version-3.0/deployment/nginx--image-archive.md b/platform/docs/versioned_docs/version-3.0/deployment/nginx--image-archive.md deleted file mode 100644 index 79f729d2fb5..00000000000 --- a/platform/docs/versioned_docs/version-3.0/deployment/nginx--image-archive.md +++ /dev/null @@ -1,273 +0,0 @@ ---- -sidebar_position: 4 ---- - -# Nginx + Image Archive - -> DISCLAIMER! We make no claims or guarantees of this approach's security. If in -> doubt, enlist the help of an expert and conduct proper audits. - -At a certain point, you may want others to have access to your instance of the -OHIF Viewer and its medical imaging data. This post covers one of many potential -setups that accomplish that. Please note, noticeably absent is user account -control. - -Do not use this recipe to host sensitive medical data on the open web. Depending -on your company's policies, this may be an appropriate setup on an internal -network when protected with a server's basic authentication. For a more robust -setup, check out our [user account control recipe](./user-account-control) -that builds on the lessons learned here. - -## Overview - -Our two biggest hurdles when hosting our image archive and web client are: - -- Risks related to exposing our PACS to the network -- Cross-Origin Resource Sharing (CORS) requests - -### Handling Web Requests - -We mitigate our first issue by allowing [Nginx][nginx] to handle incoming web -requests. Nginx is open source software for web serving, reverse proxying, -caching, and more. It's designed for maximum performance and stability -- -allowing us to more reliably serve content than Orthanc's built-in server can. - -More specifically, we accomplish this by using a -[`reverse proxy`](https://en.wikipedia.org/wiki/Reverse_proxy) to retrieve -resources from our image archive (Orthanc), and when accessing its web admin. - -> A reverse proxy is a type of proxy server that retrieves resources on behalf -> of a client from one or more servers. These resources are then returned to the -> client, appearing as if they originated from the proxy server itself. - -### CORS Issues - -Cross-Origin Resource Sharing (CORS) is a mechanism that uses HTTP headers to -tell a browser which web applications have permission to access selected -resources from a server at a different origin (domain, protocol, port). IE. By -default, a Web App located at `http://my-website.com` can't access resources -hosted at `http://not-my-website.com` - -We can solve this one of two ways: - -1. Have our Image Archive located at the same domain as our Web App -2. Add appropriate `Access-Control-Allow-*` HTTP headers - -**This solution uses the first approach.** - -You can read more about CORS in this Medium article: [Understanding -CORS][understanding-cors] - -### Diagram - -This setup allows us to create a setup similar to the one pictured below: - - -![nginX](../assets/img/nginx-image-archive.png) - - -- All web requests are routed through `nginx` on our `OpenResty` image -- `/pacs` is a reverse proxy for `orthanc`'s `DICOM Web` endpoints -- `/pacs-admin` is a reverse proxy for `orthanc`'s Web Admin -- All static resources for OHIF Viewer are served up by `nginx` when a matching - route for that resource is requested - -## Getting Started - -### Requirements - -- Docker - - [Docker for Mac](https://docs.docker.com/docker-for-mac/) - - [Docker for Windows](https://docs.docker.com/docker-for-windows/) - -_Not sure if you have `docker` installed already? Try running `docker --version` -in command prompt or terminal_ - -### Setup - -- Navigate to `viewer` folder inside `platform` -- then: `cd .recipes/OpenResty-Orthanc` -- run: `docker-compose up --build` -- Navigate to `127.0.0.1` for the viewer -- Navigate to `127.0.0.1/pacs-admin` for uploading studies - - -You can see the overview of the mentioned steps: - - - -
- -
- - - -### Troubleshooting - -_Exit code 137_ - -This means Docker ran out of memory. Open Docker Desktop, go to the `advanced` -tab, and increase the amount of Memory available. - -_Cannot create container for service X_ - -Use this one with caution: `docker system prune` - -_X is already running_ - -Stop running all containers: - -- Win: `docker ps -a -q | ForEach { docker stop $_ }` -- Linux: `docker stop $(docker ps -a -q)` - - -_Traceback (most recent call last):_ - _File "urllib3/connectionpool.py", line 670, in urlopen_ - _...._ - -Are you sure your docker is running? see explanation [here](https://github.com/docker/compose/issues/7896) - - -### Configuration - -After verifying that everything runs with default configuration values, you will -likely want to update: - -- The domain: `http://127.0.0.1` - -#### OHIF Viewer - -The OHIF Viewer's configuration is imported from a static `.js` file. The -configuration we use is set to a specific file when we build the viewer, and -determined by the env variable: `APP_CONFIG`. You can see where we set its value -in the `dockerfile` for this solution: - -`ENV APP_CONFIG=config/docker_openresty-orthanc.js` - -You can find the configuration we're using here: -`/public/config/docker_openresty-orthanc.js` - -To rebuild the `webapp` image created by our `dockerfile` after updating the -Viewer's configuration, you can run: - -- `docker-compose build` OR -- `docker-compose up --build` - -#### Other - -All other files are found in: `/docker/OpenResty-Orthanc/` - -| Service | Configuration | Docs | -| ----------------- | --------------------------------- | ------------------------------------------- | -| OHIF Viewer | [dockerfile][dockerfile] | You're reading them now! | -| OpenResty (Nginx) | [`/nginx.conf`][config-nginx] | [lua-resty-openidc][lua-resty-openidc-docs] | -| Orthanc | [`/orthanc.json`][config-orthanc] | [Here][orthanc-docs] | - -## Next Steps - -### Deploying to Production - -While these configuration and docker-compose files model an environment suitable -for production, they are not easy to deploy "as is". You can either: - -- Manually recreate this environment and deploy built application files **OR** -- Deploy to a cloud kubernetes provider like - [Digital Ocean](https://www.digitalocean.com/products/kubernetes/) **OR** - - [See a full list of cloud providers here](https://landscape.cncf.io/category=cloud&format=card-mode&grouping=category) -- Find and follow your preferred provider's guide on setting up - [swarms and stacks](https://docs.docker.com/get-started/) - -### Adding SSL - -Adding SSL registration and renewal for your domain with Let's Encrypt that -terminates at Nginx is an incredibly important step toward securing your data. -Here are some resources, specific to this setup, that may be helpful: - -- [lua-resty-auto-ssl](https://github.com/GUI/lua-resty-auto-ssl) -- [Let's Encrypt + Nginx](https://www.nginx.com/blog/using-free-ssltls-certificates-from-lets-encrypt-with-nginx/) - -While we terminate SSL at Nginx, it may be worth using self-signed certificates -for communication between services. - -- [SSL Termination for TCP Upstream Servers](https://docs.nginx.com/nginx/admin-guide/security-controls/terminating-ssl-tcp/) - -### Use PostgresSQL w/ Orthanc - -Orthanc can handle a large amount of data and requests, but if you find that -requests start to slow as you add more and more studies, you may want to -configure your Orthanc instance to use PostgresSQL. Instructions on how to do -that can be found in the -[`Orthanc Server Book`](http://book.orthanc-server.com/users/docker.html), under -"PostgreSQL and Orthanc inside Docker" - -### Improving This Guide - -Here are some improvements this guide would benefit from, and that we would be -more than happy to accept Pull Requests for: - -- SSL Support -- Complete configuration with `.env` file (or something similar) -- Any security issues -- One-click deploy to a cloud provider - -## Resources - -### Misc. Helpful Commands - -_Check if `nginx.conf` is valid:_ - -```bash -docker run --rm -t -a stdout --name my-openresty -v $PWD/config/:/usr/local/openresty/nginx/conf/:ro openresty/openresty:alpine-fat openresty -c /usr/local/openresty/nginx/conf/nginx.conf -t -``` - -_Interact w/ running container:_ - -`docker exec -it CONTAINER_NAME bash` - -_List running containers:_ - -`docker ps` - -### Referenced Articles - -For more documentation on the software we've chosen to use, you may find the -following resources helpful: - -- [Orthanc for Docker](http://book.orthanc-server.com/users/docker.html) -- [OpenResty Guide](http://www.staticshin.com/programming/definitely-an-open-resty-guide/) -- [Lua Ngx API](https://openresty-reference.readthedocs.io/en/latest/Lua_Nginx_API/) - -For a different take on this setup, check out the repositories our community -members put together: - -- [mjstealey/ohif-orthanc-dimse-docker](https://github.com/mjstealey/ohif-orthanc-dimse-docker) -- [trypag/ohif-orthanc-postgres-docker](https://github.com/trypag/ohif-orthanc-postgres-docker) - - - - - -[nginx]: https://www.nginx.com/resources/glossary/nginx/ -[understanding-cors]: https://medium.com/@baphemot/understanding-cors-18ad6b478e2b -[orthanc-docs]: http://book.orthanc-server.com/users/configuration.html#configuration -[lua-resty-openidc-docs]: https://github.com/zmartzone/lua-resty-openidc - -[dockerfile]: https://github.com/OHIF/Viewers/blob/master/platform/viewer/.recipes/OpenResty-Orthanc/dockerfile -[config-nginx]: https://github.com/OHIF/Viewers/blob/master/platform/viewer/.recipes/OpenResty-Orthanc/config/nginx.conf -[config-orthanc]: https://github.com/OHIF/Viewers/blob/master/platform/viewer/.recipes/OpenResty-Orthanc/config/orthanc.json - diff --git a/platform/docs/versioned_docs/version-3.0/deployment/static-assets.md b/platform/docs/versioned_docs/version-3.0/deployment/static-assets.md deleted file mode 100644 index 767ad692802..00000000000 --- a/platform/docs/versioned_docs/version-3.0/deployment/static-assets.md +++ /dev/null @@ -1,160 +0,0 @@ ---- -sidebar_position: 3 ---- - -# Deploy Static Assets - -> WARNING! All of these solutions stand-up a publicly accessible web viewer. Do -> not hook your hosted viewer up to a sensitive source of data without -> implementing authentication. - -There are a lot of options for deploying static assets. Some services, like -`netlify` and `surge.sh`, specialize in static websites. You'll notice that -deploying with them requires much less time and effort, but comes at the cost of -less product offerings. - -While not required, it can simplify things to host your Web Viewer alongside -your image archive. Services with more robust product offerings, like -`Google Cloud`, `Microsoft's Azure`, and `Amazon Web Services (AWS)`, are able -to accommodate this setup. - -_Drag-n-drop_ - -- [Netlify: Drop](#netlify-drop) - -_Easy_ - -- [Surge.sh](#surgesh) -- [GitHub Pages](#github-pages) - -_Advanced_ - -- [Deploy Static Assets](#deploy-static-assets) - - [Drag-n-drop](#drag-n-drop) - - [Netlify Drop](#netlify-drop) - - [Easy](#easy) - - [Surge.sh](#surgesh) - - [GitHub Pages](#github-pages) - - [Advanced](#advanced) - - [AWS S3 + Cloudfront](#aws-s3--cloudfront) - - [GCP + Cloudflare](#gcp--cloudflare) - - [Azure](#azure) - -## Drag-n-drop - -### Netlify Drop - - -
- -
- - -_GIF demonstrating deployment with Netlify Drop_ - -1. https://app.netlify.com/drop -2. Drag your `build/` folder on to the drop target -3. ... -4. _annnd you're done_ - -**Features:** - -- Custom domains & HTTPS -- Instant Git integration -- Continuous deployment -- Deploy previews -- Access to add-ons - -(Non-free tiers include identity, FaaS, Forms, etc.) - -Learn more about [Netlify on their website](https://www.netlify.com/) - -## Easy - -### Surge.sh - -> Static web publishing for Front-End Developers. Simple, single-command web -> publishing. Publish HTML, CSS, and JS for free, without leaving the command -> line. - -![surge.sh deploy example](../assets/img/surge-deploy.gif) - -_GIF demonstrating deployment with surge_ - -```shell -# Add surge command -yarn global add surge - -# In the build directory -surge -``` - -**Features:** - -- Free custom domain support -- Free SSL for surge.sh subdomains -- pushState support for single page apps -- Custom 404.html pages -- Barrier-free deployment through the CLI -- Easy integration into your Grunt toolchain -- Cross-origin resource support -- And more… - -Learn more about [surge.sh on their website](https://surge.sh/) - -### GitHub Pages - -> WARNING! While great for project sites and light use, it is not advised to use -> GitHub Pages for production workloads. Please consider using a different -> service for mission critical applications. - -> Websites for you and your projects. Hosted directly from your GitHub -> repository. Just edit, push, and your changes are live. - -This deployment strategy makes more sense if you intend to maintain your project in -a GitHub repository. It allows you to specify a `branch` or `folder` as the -target for a GitHub Page's website. As you push code changes, the hosted content -updates to reflect those changes. - -1. Head over to GitHub.com and create a new repository, or go to an existing - one. Click on the Settings tab. -2. Scroll down to the GitHub Pages section. Choose the `branch` or `folder` you - would like as the "root" of your website. -3. Fire up a browser and go to `http://username.github.io/repository` - -Configuring Your Site: - -- [Setting up a custom domain](https://help.github.com/en/articles/using-a-custom-domain-with-github-pages) -- [Setting up SSL](https://help.github.com/en/articles/securing-your-github-pages-site-with-https) - -Learn more about [GitHub Pages on its website](https://pages.github.com/) - -## Advanced - -All of these options, while using providers with more service offerings, -demonstrate how to host the viewer with their respective file storage and CDN -offerings. While you can serve your static assets this way, if you're going -through the trouble of using AWS/GCP/Azure, it's more likely you're doing so to -avoid using a proxy or to simplify authentication. - -If that is the case, check out some of our more advanced `docker` deployments -that target these providers from the left-hand sidepanel. - -These guides can be a bit longer and an update more frequently. To provide -accurate documentation, we will link to each provider's own recommended steps: - -### AWS S3 + Cloudfront - -- [Host a Static Website](https://docs.aws.amazon.com/AmazonS3/latest/dev/website-hosting-custom-domain-walkthrough.html) -- [Speed Up Your Website with Cloudfront](https://docs.aws.amazon.com/AmazonS3/latest/dev/website-hosting-cloudfront-walkthrough.html) - -### GCP + Cloudflare - -- [Things to Know Before Getting Started](https://code.luasoftware.com/tutorials/google-cloud-storage/things-to-know-before-hosting-static-website-on-google-cloud-storage/) -- [Hosting a Static Website on GCP](https://cloud.google.com/storage/docs/hosting-static-website) - -### Azure - -- [Host a Static Website](https://docs.microsoft.com/en-us/azure/storage/blobs/storage-blob-static-website) -- [Add SSL Support](https://docs.microsoft.com/en-us/azure/storage/blobs/storage-https-custom-domain-cdn) -- [Configure a Custom Domain](https://docs.microsoft.com/en-us/azure/storage/blobs/storage-custom-domain-name) diff --git a/platform/docs/versioned_docs/version-3.0/deployment/user-account-control.md b/platform/docs/versioned_docs/version-3.0/deployment/user-account-control.md deleted file mode 100644 index e411cc7d535..00000000000 --- a/platform/docs/versioned_docs/version-3.0/deployment/user-account-control.md +++ /dev/null @@ -1,7 +0,0 @@ ---- -sidebar_position: 5 ---- - -# User Account Control - -> Coming soon - We are working on bringing the User Account Control to OHIF-v3 diff --git a/platform/docs/versioned_docs/version-3.0/development/_category_.json b/platform/docs/versioned_docs/version-3.0/development/_category_.json deleted file mode 100644 index 8627cac4920..00000000000 --- a/platform/docs/versioned_docs/version-3.0/development/_category_.json +++ /dev/null @@ -1,4 +0,0 @@ -{ - "label": "Development", - "position": 5 -} diff --git a/platform/docs/versioned_docs/version-3.0/development/architecture.md b/platform/docs/versioned_docs/version-3.0/development/architecture.md deleted file mode 100644 index 4bcebb0175e..00000000000 --- a/platform/docs/versioned_docs/version-3.0/development/architecture.md +++ /dev/null @@ -1,203 +0,0 @@ ---- -sidebar_position: 2 -sidebar_label: Architecture ---- - -# Architecture - -In order to achieve a platform that can support various workflows and be -extensible for the foreseeable future we went through extensive planning of -possible use cases and decided to significantly change and improve the -architecture. - -Below, we aim to demystify that complexity by providing insight into how -`OHIF Platform` is architected, and the role each of its dependent libraries -plays. - -## Overview - -The [OHIF Medical Image Viewing Platform][viewers-project] is maintained as a -[`monorepo`][monorepo]. This means that this repository, instead of containing a -single project, contains many projects. If you explore our project structure, -you'll see the following: - -```bash -β”‚ -β”œβ”€β”€ extensions -β”‚ β”œβ”€β”€ _example # Skeleton of example extension -β”‚ β”œβ”€β”€ default # default functionalities -β”‚ β”œβ”€β”€ cornerstone # 2D images w/ Cornerstone.js -β”‚ β”œβ”€β”€ measurement-tracking # measurement tracking -β”‚ β”œβ”€β”€ dicom-sr # Structured reports -β”‚ └── dicom-pdf # View DICOM wrapped PDFs in viewport -β”‚ -β”œβ”€β”€ modes -β”‚ └── longitudinal # longitudinal measurement tracking mode -β”‚ -β”œβ”€β”€ platform -β”‚ β”œβ”€β”€ core # Business Logic -β”‚ β”œβ”€β”€ i18n # Internationalization Support -β”‚ β”œβ”€β”€ ui # React component library -β”‚ └── viewer # Connects platform and extension projects -β”‚ -β”œβ”€β”€ ... # misc. shared configuration -β”œβ”€β”€ lerna.json # MonoRepo (Lerna) settings -β”œβ”€β”€ package.json # Shared devDependencies and commands -└── README.md -``` - -OHIF v3 is composed of the following components, described in detail in further -sections: - -- `@ohif/viewer`: The core framework that controls extension registration, mode - composition and routing. -- `@ohif/core`: A library of useful and reusable medical imaging functionality - for the web. -- `@ohif/ui`: A library of reusable components to build OHIF-styled applications - with. -- `Extensions`: A set of building blocks for building applications. The OHIF org - maintains a few core libraries. -- `Modes`: Configuration objects that tell @ohif/viewer how to compose - extensions to build applications on different routes of the platform. - -## Extensions - -The `extensions` directory contains many packages that provide essential -functionalities such as rendering, study/series browsers, measurement tracking -that modes can consume to enable a certain workflow. Extensions have had their -behavior changed in `OHIF-v3` and their api is expanded. In summary: - -> In `OHIF-v3`, extensions no longer automatically hook themselves to the app. -> Now, registering an extension makes its component available to `modes` that -> wish to use them. Basically, extensions in `OHIF-v3` are **building blocks** -> for building applications. - -OHIF team maintains several high value and commonly used functionalities in its -own extensions. For a list of extensions maintained by OHIF, -[check out this helpful table](../platform/extensions/index.md#maintained-extensions). -As an example `default` extension provides a default viewer layout, a -study/series browser and a datasource that maps to a DICOMWeb compliant backend. - -[Click here to read more about extensions!](../platform/extensions/index.md) - -## Modes - -The `modes` directory contains workflows that can be registered with OHIF within -certain `routes`. The mode will get used once the user opens the viewer on the -registered route. - -OHIF extensions were designed to provide certain core functionalities for -building your viewer. However, often in medical imaging we face a specific use -case in which we are using some core functionalities, adding our specific UI, -and use it in our workflows. Previously, to achieve this you had to create an -extension to add have such feature. `OHIF-v3` introduces `Modes` to enable -building such workflows by re-using the core functionalities from the -extensions. - -Some common workflows may include: - -- Measurement tracking for lesions -- Segmentation of brain abnormalities -- AI probe mode for detecting prostate cancer - -In the mentioned modes above, they will share the same core rendering module -that the `default` extension provides. However, segmentation mode will require -segmentation tools which is not needed for the other two. As you can see, modes -are a layer on top of extensions, that you can configure in order to achieve -certain workflows. - -To summarize the difference between extensions and modes in `OHIF-v3` and -extensions in `OHIF-v2` - -> - `Modes` are configuration objects that tell _@ohif/viewer_ how to compose -> extensions to build applications on different routes of the platform. -> - In v2 extensions are β€œplugins” that add functionality to a core viewer. -> - In v3 extensions are building blocks that a mode uses to build an entire -> viewer layout. - -[Click here to read more about modes!](../platform/modes/index.md) - -## Platform - -### `@ohif/viewer` - -This library is the core library which consumes modes and extensions and builds -an application. Extensions can be passed in as app configuration and will be -consumed and initialized at the appropriate time by the application. 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. - -Upon release modes will also be plugged into the app via configuration, but this -is still an area which is under development/discussion, and they are currently -pulled from the window in beta. - -Future ideas for this framework involve only adding modes and fetching the -required extension versions at either runtime or build time, but this decision -is still up for discussion. - -### `@ohif/core` - -OHIF core is a carefully maintained and tested set of web-based medical imaging -functions and classes. This library includes managers and services used from -within the viewer app. - -OHIF core is largely similar to the @ohif/core library in v2, however a lot of -logic has been moved to extensions: however all logic about DICOMWeb and other -data fetching mechanisms have been pulled out, as these now live in extensions, -described later. - -### `@ohif/ui` - -Firstly, a large time-consumer/barrier for entry we discovered was building new -UI in a timely manner that fit OHIF’s theme. For this reason we have built a new -UI component library which contains all the components one needs to build their -own viewer. - -These components are presentational only, so you can reuse them with whatever -logic you desire. As the components are presentational, you may swap out -@ohif/ui for a custom UI library with conforming API if you wish to white label -the viewer. The UI library is here to make development easier and quicker, but -it is not mandatory for extension components to use. - -[Check out our component library!](https://react.ohif.org/) - -## Overview of the architecture - -OHIF-v3 architecture can be seen in the following figure. We will explore each -piece in more detail. - -![mode-archs](../assets/img/mode-archs.png) - -## Common Questions - -> Can I create my own Viewer using Vue.js or Angular.js? - -You can, but you will not be able to leverage as much of the existing code and -components. `@ohif/core` could still be used for business logic, and to provide -a model for extensions. `@ohif/ui` would then become a guide for the components -you would need to recreate. - -> When I want to implement a functionality, should it be in the mode or in an -> extension? - -This is a great question. Modes are designed to consume extensions, so you -should implement your functionality in one of the modules of your new extension, -and let the mode consume it. This way, in the future, if you needed another mode -that utilizes the same functionality, you can easily hook the extension to the -new mode as well. - - - - -[monorepo]: https://github.com/OHIF/Viewers/issues/768 -[viewers-project]: https://github.com/OHIF/Viewers -[viewer-npm]: https://www.npmjs.com/package/@ohif/viewer -[pwa]: https://developers.google.com/web/progressive-web-apps/ -[configuration]: ../configuration/index.md -[extensions]: ../platform/extensions/index.md -[core-github]: https://github.com/OHIF/viewers/platform/core -[ui-github]: https://github.com/OHIF/Viewers/tree/master/platform/ui - diff --git a/platform/docs/versioned_docs/version-3.0/development/continous-integration.md b/platform/docs/versioned_docs/version-3.0/development/continous-integration.md deleted file mode 100644 index 3c3124af83b..00000000000 --- a/platform/docs/versioned_docs/version-3.0/development/continous-integration.md +++ /dev/null @@ -1,90 +0,0 @@ ---- -sidebar_position: 7 -sidebar_label: Continous Integration ---- - -# Continous Integration (CI) - -This repository uses `CircleCI` and `Netlify` for continous integration. - -## Deploy Previews - -[Netlify Deploy previews][deploy-previews] are generated for every pull request. -They allow pull request authors and reviewers to "Preview" the OHIF Viewer as if -the changes had been merged. - -Deploy previews can be configured by modifying the `netlify.toml` file in the -root of the repository. Some additional scripts/assets for netlify are included -in the root `.netlify` directory. - -## Workflows - -[CircleCI Workflows][circleci-workflows] are a set of rules for defining a -collection of jobs and their run order. They are self-documenting and their -configuration can be found in our CircleCI configuration file: -`.circleci/config.yml`. - -### Workflow: PR_CHECKS - -The PR_CHECKS workflow (Pull Request Checks) runs our automated unit and -end-to-end tests for every code check-in. These tests must all pass before code -can be merged to our `master` branch. - -![PR_CHECKS](../assets/img/WORKFLOW_PR_CHECKS.png) - -### Workflow: PR_OPTIONAL_DOCKER_PUBLISH - -The PR_OPTIONAL_DOCKER_PUBLISH workflow allows for "manual approval" to publish -the pull request as a tagged docker image. This is helpful when changes need to -be tested with the Google Adapter before merging to `master`. - -![PR_Workflow](../assets/img/WORKFLOW_PR_OPTIONAL_DOCKER_PUBLISH.png) - -> NOTE: This workflow will fail unless it's for a branch on our `upstream` -> repository. If you need this functionality, but the branch is from a fork, -> merge the changes to a short-lived `feature/` branch on `upstream` - -### Workflow: DEPLOY - -The DEPLOY workflow deploys the OHIF Viewer when changes are merged to master. -It uses the Netlify CLI to deploy assets created as part of the repository's PWA -Build process (`yarn run build`). The workflow allows for "Manual Approval" to -promote the build to `STAGING` and `PRODUCTION` environments. - -![WORKFLOW_DEPLOY](../assets/img/WORKFLOW_DEPLOY.png) - -| Environment | Description | URL | -| ----------- | ---------------------------------------------------------------------------------- | --------------------------------------------- | -| Development | Always reflects latest changes on `master` branch. | [Netlify][netlify-dev] / [OHIF][ohif-dev] | -| Staging | For manual testing before promotion to prod. Keeps development workflow unblocked. | [Netlify][netlify-stage] / [OHIF][ohif-stage] | -| Production | Stable, tested, updated less frequently. | [Netlify][netlify-prod] / [OHIF][ohif-prod] | - -### Workflow: RELEASE - -The RELEASE workflow publishes our `npm` packages, updated documentation, and -`docker` image when changes are merged to master. `Lerna` and "Semantic Commit -Syntax" are used to independently version and publish the many packages in our -monorepository. If a new version is cut/released, a Docker image is created. -Documentation is generated with `gitbook` and pushed to our `gh-pages` branch. -GitHub hosts the `gh-pages` branch with GitHub Pages. - -- Platform Packages: https://github.com/ohif/viewers/#platform -- Extension Packages: https://github.com/ohif/viewers/#extensions -- Documentation: https://docs.ohif.org/ - -![WORKFLOW_RELEASE](../assets/img/WORKFLOW_RELEASE.png) - - - - -[deploy-previews]: https://www.netlify.com/blog/2016/07/20/introducing-deploy-previews-in-netlify/ -[circleci-workflows]: https://circleci.com/docs/2.0/workflows/ -[netlify-dev]: https://ohif-dev.netlify.com -[netlify-stage]: https://ohif-stage.netlify.com -[netlify-prod]: https://ohif-prod.netlify.com -[ohif-dev]: https://viewer-dev.ohif.org -[ohif-stage]: https://viewer-stage.ohif.org -[ohif-prod]: https://viewer-prod.ohif.org - diff --git a/platform/docs/versioned_docs/version-3.0/development/contributing.md b/platform/docs/versioned_docs/version-3.0/development/contributing.md deleted file mode 100644 index 763be20dd08..00000000000 --- a/platform/docs/versioned_docs/version-3.0/development/contributing.md +++ /dev/null @@ -1,152 +0,0 @@ ---- -sidebar_position: 4 -sidebar_label: Contributing ---- - -# Contributing - -## How can I help? - -Fork the repository, make your change and submit a pull request. If you would -like to discuss the changes you intend to make to clarify where or how they -should be implemented, please don't hesitate to create a new issue. At a -minimum, you may want to read the following documentation: - -- [Getting Started](/development/getting-started.md) -- [Architecture](./architecture.md) - -Pull requests that are: - -- Small -- [Well tested](./testing.md) -- Decoupled - -Are much more likely to get reviewed and merged in a timely manner. - -## When changes impact multiple repositories - -While this can be tricky, we've tried to reduce how often this situation crops -up this with our [recent switch to a monorepo][monorepo]. Our maintained -extensions, ui components, internationalization library, and business logic can -all be developed by simply running `yarn run dev` from the repository root. - -Testing the viewer with locally developed, unpublished package changes from a -package outside of the monorepo is most common with extension development. Let's -demonstrate how to accomplish this with two commonly forked extension -dependencies: - -### `cornerstone-tools` - -On your local file system: - -```bash title="/my-projects/" -β”œβ”€β”€ cornerstonejs/cornerstone-tools -└── ohif/viewers -``` - -- Open a terminal/shell -- Navigate to `cornerstonejs/cornerstone-tools` - - `yarn install` - - [`yarn link`](https://yarnpkg.com/en/docs/cli/link) - - `yarn run dev` - -* Open a new terminal/shell -* Navigate to `ohif/viewers` (the root of ohif project) - - `yarn install` - - [`yarn link cornerstone-tools`](https://yarnpkg.com/en/docs/cli/link) - - `yarn run dev` - -As you make changed to `cornerstone-tools`, and it's output is rebuilt, you -should see the following behavior: - -![tools](..//assets/img/cornerstone-tools-link.gif) - -If you wish to stop using your local package, run the following commands in the -`ohif/viewers` repository root: - -- `yarn unlink cornerstone-tools` -- `yarn install --force` - - - -#### Other linkage notes - -We're still working out some of the kinks with local package development as -there are a lot of factors that can influence the behavior of our development -server and bundler. If you encounter issues not addressed here, please don't -hesitate to reach out on GitHub. - -Sometimes you might encounter a situation where the linking doesn't work as -expected. This might happen when there are multiple linked packages with the -same name. You can [remove][unlink] the linked packages inside yarn and try -again. - -## Any guidance on submitting changes? - -While we do appreciate code contributions, triaging and integrating contributed -code changes can be very time consuming. Please consider the following tips when -working on your pull requests: - -- Functionality is appropriate for the repository. Consider creating a GitHub - issue to discuss your suggested changes. -- The scope of the pull request is not too large. Please consider separate pull - requests for each feature as big pull requests are very time consuming to - understand. - -We will provide feedback on your pull requests as soon as possible. Following -the tips above will help ensure your changes are reviewed. - - - - - - -[example-url]: https://deploy-preview-237--ohif.netlify.com/viewer/?url=https://s3.eu-central-1.amazonaws.com/ohif-viewer/sampleDICOM.json -[pr-237]: https://github.com/OHIF/Viewers/pull/237 -[monorepo]: https://github.com/OHIF/Viewers/issues/768 -[unlink]: https://stackoverflow.com/questions/58459698/is-there-a-command-to-unlink-all-yarn-packages-yarn-unlink-all - diff --git a/platform/docs/versioned_docs/version-3.0/development/getting-started.md b/platform/docs/versioned_docs/version-3.0/development/getting-started.md deleted file mode 100644 index b9b3bc5d51a..00000000000 --- a/platform/docs/versioned_docs/version-3.0/development/getting-started.md +++ /dev/null @@ -1,111 +0,0 @@ ---- -sidebar_position: 1 -sidebar_label: Getting Started ---- - -# Getting Started - -## Setup - -### Fork & Clone - -If you intend to contribute back changes, or if you would like to pull updates -we make to the OHIF Viewer, then follow these steps: - -- [Fork][fork-a-repo] the [OHIF/Viewers][ohif-viewers-repo] repository -- [Create a local clone][clone-a-repo] of your fork - - `git clone https://github.com/YOUR-USERNAME/Viewers` -- Add OHIF/Viewers as a [remote repository][add-remote-repo] labeled `upstream` - - Navigate to the cloned project's directory - - `git remote add upstream https://github.com/OHIF/Viewers.git` - -With this setup, you can now [sync your fork][sync-changes] to keep it -up-to-date with the upstream (original) repository. This is called a "Triangular -Workflow" and is common for Open Source projects. The GitHub blog has a [good -graphic that illustrates this setup][triangular-workflow]. - -### Private - -Alternatively, if you intend to use the OHIF Viewer as a starting point, and you -aren't as concerned with syncing updates, then follow these steps: - -1. Navigate to the [OHIF/Viewers][ohif-viewers] repository -2. Click `Clone or download`, and then `Download ZIP` -3. Use the contents of the `.zip` file as a starting point for your viewer - -> NOTE: It is still possible to sync changes using this approach. However, -> submitting pull requests for fixes and features are best done with the -> separate, forked repository setup described in "Fork & Clone" - -## Developing - -### Requirements - -- [Node.js & NPM](https://nodejs.org/en/) -- [Yarn](https://yarnpkg.com/en/) -- Yarn workspaces should be enabled: - - `yarn config set workspaces-experimental true` - -### Kick the tires - -Navigate to the root of the project's directory in your terminal and run the -following commands: - -```bash -# Switch to the v3 branch -git switch v3-stable - -# Restore dependencies -yarn install - -# Start local development server -yarn run dev -``` - -You should see the following output: - -```bash -@ohif/viewer: i ο½’wdsο½£: Project is running at http://localhost:3000/ -@ohif/viewer: i ο½’wdsο½£: webpack output is served from / -@ohif/viewer: i ο½’wdsο½£: Content not from webpack is served from D:\code\ohif\Viewers\platform\viewer -@ohif/viewer: i ο½’wdsο½£: 404s will fallback to /index.html - -# And a list of all generated files -``` - -### πŸŽ‰ Celebrate πŸŽ‰ - -
- -
- -### Building for Production - -> More comprehensive guides for building and publishing can be found in our -> [deployment docs](./../deployment/index.md) - -```bash -# Build static assets to host a PWA -yarn run build -``` - -## Troubleshooting - -- If you receive a _"No Studies Found"_ message and do not see your studies, try - changing the Study Date filters to a wider range. -- If you see a 'Loading' message which never resolves, check your browser's - JavaScript console inside the Developer Tools to identify any errors. - - - - -[fork-a-repo]: https://help.github.com/en/articles/fork-a-repo -[clone-a-repo]: https://help.github.com/en/articles/fork-a-repo#step-2-create-a-local-clone-of-your-fork -[add-remote-repo]: https://help.github.com/en/articles/fork-a-repo#step-3-configure-git-to-sync-your-fork-with-the-original-spoon-knife-repository -[sync-changes]: https://help.github.com/en/articles/syncing-a-fork -[triangular-workflow]: https://github.blog/2015-07-29-git-2-5-including-multiple-worktrees-and-triangular-workflows/#improved-support-for-triangular-workflows -[ohif-viewers-repo]: https://github.com/OHIF/Viewers -[ohif-viewers]: https://github.com/OHIF/Viewers - diff --git a/platform/docs/versioned_docs/version-3.0/development/ohif-cli.md b/platform/docs/versioned_docs/version-3.0/development/ohif-cli.md deleted file mode 100644 index cf8af80f581..00000000000 --- a/platform/docs/versioned_docs/version-3.0/development/ohif-cli.md +++ /dev/null @@ -1,291 +0,0 @@ ---- -sidebar_position: 3 -sidebar_label: OHIF CLI ---- - -# OHIF Command Line Interface - -OHIF-v3 architecture has been re-designed to enable building applications that -are easily extensible to various use cases (Modes) that behind the scene would -utilize desired functionalities (Extensions) to reach the goal of the use case. -Now, the question is _how to create/remove/install/uninstall an extension and/or -mode?_ - -You can use the `cli` script that comes with the OHIF monorepo to achieve these -goals. - -:::note Info -In the long-term, we envision our `cli` tool to be a separate installable -package that you can invoke anywhere on your local system to achieve the same -goals. In the meantime, `cli` will remain as part of the OHIF monorepo and needs -to be invoked using the `yarn` command. -::: - - -## CLI Installation - -You don't need to install the `cli` currently. You can use `yarn` to invoke its -commands. - -## Commands - -:::note Important -All commands should run from the root of the monorepo. -::: - - -There are various commands that can be used to interact with the OHIF-v3 CLI. If -you run the following command, you will see a list of available commands. - -``` -yarn run cli --help -``` - -which will output - -``` -OHIF CLI - -Options: - -V, --version output the version number - -h, --help display help for command - -Commands: - create-extension Create a new template extension - create-mode Create a new template Mode - add-extension [version] Adds an ohif extension - remove-extension removes an ohif extension - add-mode [version] Removes an ohif mode - remove-mode Removes an ohif mode - link-extension Links a local OHIF extension to the Viewer to be used for development - unlink-extension Unlinks a local OHIF extension from the Viewer - link-mode Links a local OHIF mode to the Viewer to be used for development - unlink-mode Unlinks a local OHIF mode from the Viewer - list List Added Extensions and Modes - search [options] Search NPM for the list of Modes and Extensions - help [command] display help for command -``` - -As seen there are commands for you such as: `create-extension`, `create-mode`, -`add-extension`, `remove-extension`, `add-mode`, `remove-mode`, -`link-extension`, `unlink-extension`, `link-mode`, `unlink-mode`, `list`, -`search`, and `help`. Here we will go through each of the commands and describe -them. - -### create-mode - -If you need to create a new mode, you can use the `create-mode` command. This -command will create a new mode template in the directory that you specify. -The command will ask you couple of information/questions in order -to properly create the mode metadata in the `package.json` file. - -```bash -yarn run cli create-mode -``` - -
- -![image](../assets/img/create-mode.png) - - -
- -Note 1: Some questions have a default answer, which is indicated inside the -parenthesis. If you don't want to answer the question, just hit enter. It will -use the default answer. - -Note 2: As you see in the questions, you can initiate a git repository for the -new mode right away by answering `Y` (default) to the question. - -Note 3: Finally, as indicated by the green lines at the end, `create-mode` command only -create the mode template. You will need to link the mode to the Viewer in order -to use it. See the [`link-mode`](#link-mode) command. - -If we take a look at the directory that we created, we will see the following -files: - -
- -![image](../assets/img/mode-template.png) - -
- - -### create-extension - -Similar to the `create-extension` command, you can use the `create-extension` -command to create a new extension template. This command will create a new -extension template in the directory that you specify the path. - -```bash -yarn run cli create-extension -``` - - -Note: again similar to the `create-extension` command, you need to manually link -the extension to the Viewer in order to use it. See the -[`link-mode`](#link-mode) command. - - -### link-extension - -`link-extension` command will link a local OHIF extension to the Viewer. This -command will utilize `yarn link` to achieve so. - -```bash -yarn run cli link-extension -``` - -### unlink-extension - -There might be situations where you want to unlink an extension from the Viewer -after some developments. `unlink-extension` command will do so. - -```bash -ohif-cli unlink-extension -``` - - - -### link-mode - -Similar to the `link-extension` command, `link-mode` command will link a local -OHIF mode to the Viewer. - -```bash -yarn run cli link-mode -``` - -### unlink-mode - -Similar to the `unlink-extension` command, `unlink-mode` command will unlink a -local OHIF mode from the Viewer. - -```bash -ohif-cli unlink-mode -``` - -### add-mode - -OHIF is a modular viewer. This means that you can install (add) different modes -to the viewer if they are published online . `add-mode` command will add a new mode to -the viewer. It will look for the mode in the NPM registry and installs it. This -command will also add the extension dependencies that the mode relies on to the -Viewer (if specified in the peerDependencies section of the package.json). - -:::note Important -`cli` will validate the npm package before adding it to the Viewer. An OHIF mode -should have `ohif-mode` as one of its keywords. -::: - -Note: If you don't specify the version, the latest version will be used. - -```bash -yarn run cli add-mode [version] -``` - -For instance `@ohif-test/mode-clock` is an example OHIF mode that we have -published to NPM. This mode basically has a panel that shows the clock :) - -We can add this mode to the Viewer by running the following command: - -```bash -yarn run cli add-mode @ohif-test/mode-clock -``` - -After installation, the Viewer has a new mode! - - -![image](../assets/img/add-mode.png) - - -Note: If the mode has an extension peerDependency (in this case @ohif-test/extension-clock), -`cli` will automatically add the extension to the Viewer too. - -The result - -![image](../assets/img/clock-mode.png) -![image](../assets/img/clock-mode1.png) - -### add-extension - -This command will add an OHIF extension to the Viewer. It will look for the -extension in the NPM registry and install it. - -```bash -yarn run cli add-extension [version] -``` - - -### remove-mode - -This command will remove the mode from the Viewer and also remove the extension -dependencies that the mode relies on from the Viewer. - -```bash -yarn run cli remove-mode -``` - - -### remove-extension - -Similar to the `remove-mode` command, this command will remove the extension -from the Viewer. - -```bash -yarn run cli remove-extension -``` - -### list - -`list` command will list all the installed extensions and modes in -the Viewer. It uses the `PluginConfig.json` file to list the installed -extensions and modes. - -```bash -yarn run cli list -``` - -an output would look like this: - -
- -![image](../assets/img/ohif-cli-list.png) - -
- -### search - -Using `search` command, you can search for OHIF extensions and modes -in the NPM registry. This tool can accept a `--verbose` flag to show more -information about the results. - -```bash -yarn run cli search [--verbose] -``` - -
- -![image](../assets/img/cli-search-no-verbose.png) - -
- -with the verbose flag `ohif-cli search --verbose` you will achieve the following -output: - -
- -![image](../assets/img/cli-search-with-verbose.png) - -
- - -## PluginConfig.json - -To make all the above commands work, we have created a new file called `PluginConfig.json` which contains the -information needed to run the commands. You **don't need to (and should not)** -edit/update/modify this file as it is automatically generated by the CLI. You -can take a look at what this file contains by going to -`platform/viewer/PluginConfig.json` in your project's root directory. In short, -this file tracks and stores all the extensions/modes and the their version that -are currently being used by the viewer. diff --git a/platform/docs/versioned_docs/version-3.0/development/our-process.md b/platform/docs/versioned_docs/version-3.0/development/our-process.md deleted file mode 100644 index d8b8ed86217..00000000000 --- a/platform/docs/versioned_docs/version-3.0/development/our-process.md +++ /dev/null @@ -1,156 +0,0 @@ ---- -sidebar_position: 5 -sidebar_label: Issue & PR Triage Process ---- - -# Our Process - -Our process is a living, breathing thing. We strive to have regular -[retrospectives][retrospective] that help us shape and adapt our process to our -team's current needs. This document attempts to capture the broad strokes of -that process in an effort to: - -- Strengthen community member involvement and understanding -- Welcome feedback and helpful suggestions - -## Issue Triage - -[GitHub issues][gh-issues] are the best way to provide feedback, ask questions, -and suggest changes to the OHIF Viewer's core team. Community issues generally -fall into one of three categories, and are marked with a `triage` label when -created. - -| Issue Template Name | Description | -| ---------------------- | ---------------------------------------------------------------------------------------- | -| Community: Report πŸ› | Describe a new issue; Provide steps to reproduce; Expected versus actual result? | -| Community: Request βœ‹ | Describe a proposed new feature. Why should it be implemented? What is the impact/value? | -| Community: Question ❓ | Seek clarification or assistance relevant to the repository. | - -_table 1. issue template names and descriptions_ - -Issues that require `triage` are akin to support tickets. As this is often our -first contact with would-be adopters and contributors, it's important that we -strive for timely responses and satisfactory resolutions. We attempt to -accomplish this by: - -1. Responding to issue requiring `triage` at least once a week -2. Create new "official issues" from "community issues" -3. Provide clear guidance and next steps (when applicable) -4. Regularly clean up old (stale) issues - -> πŸ–‹ Less obviously, patterns in the issues being reported can highlight areas -> that need improvement. For example, users often have difficulty navigating -> CORS issues when deploying the OHIF Viewer -- how do we best reduce our ticket -> volume for this issue? - -### Backlogged Issues - -Community issues serve as vehicles of discussion that lead us to "backlogged -issues". Backlogged issues are the distilled and actionable information -extracted from community issues. They contain the scope and requirements -necessary for hand-off to a core-team (or community) contributor ^\_^ - -| Category | Description | Labels | -| -------- | ---------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ | -| Bugs | An issue with steps that produce a bug (an unexpected result). | [Bug: Verified πŸ›][label-bug] | -| Stories | A feature/enhancement with a clear benefit, boundaries, and requirements. | [Story πŸ™Œ][label-story] | -| Tasks | Changes that improve [UX], [DX], or test coverage; but don't impact application behavior | [Task: CI/Tooling πŸ€–][label-tooling], [Task: Docs πŸ“–][label-docs], [Task: Refactor πŸ› ][label-refactor], [Task: Tests πŸ”¬][label-tests] | - -_table 2. backlogged issue types ([full list of labels][gh-labels])_ - -## Issue Curation (["backlog grooming"][groom-backlog]) - -If a [GitHub issue][gh-issues] has a `bug`, `story`, or `task` label; it's on -our backlog. If an issue is on our backlog, it means we are, at the very least, -committed to reviewing any community drafted Pull Requests to complete the -issue. If you're interested in seeing an issue completed but don't know where to -start, please don't hesitate to leave a comment! - -While we don't yet have a long-term or quarterly road map, we do regularly add -items to our ["Active Development" GitHub Project Board][gh-board]. Items on -this project board are either in active development by Core Team members, or -queued up for development as in-progress items are completed. - -> πŸ–‹ Want to contribute but not sure where to start? Check out [Up for -> grabs][label-grabs] issues and our [Contributing -> documentation][contributing-docs] - -## Contributions (Pull Requests) - -Incoming Pull Requests (PRs) are triaged using the following labels. Code review -is performed on all PRs where the bug fix or added functionality is deemed -appropriate: - -| Labels | Description | -| ---------------------------------------------- | ----------------------------------------------------------------------------------------------------------- | -| **Classification** | | -| [PR: Bug Fix][label-bug] | Filed to address a Bug. | -| [PR: Draft][draft] | Filed to gather early feedback from the core team, but which is not intended for merging in the short term. | -| **Review Workflow** | | -| [PR: Awaiting Response πŸ’¬][awaiting-response] | The core team is waiting for additional information from the author. | -| [PR: Awaiting Review πŸ‘€][awaiting-review] | The core team has not yet performed a code review. | -| [PR: Awaiting Revisions πŸ–Š][awaiting-revisions] | Following code review, this label is applied until the author has made sufficient changes. | -| **QA** | | -| [PR: Awaiting User Cases πŸ’ƒ][awaiting-stories] | The PR code changes need common language descriptions of impact to end users before the review can start | -| [PR: No UX Impact πŸ™ƒ][no-ux-impact] | The PR code changes do not impact the user's experience | - -We rely on GitHub Checks and integrations with third party services to evaluate -changes in code quality and test coverage. Tests must pass and User cases must -be present (when applicable) before a PR can be merged to master, and code -quality and test coverage must not be changed by a significant margin. For some -repositories, visual screenshot-based tests are also included, and video -recordings of end-to-end tests are stored for later review. - -[You can read more about our continous integration efforts here](/development/continous-integration.md) - -## Releases - -Releases are made automatically based on the type of commits which have been -merged (major.minor.patch). Releases are automatically pushed to NPM. Release -notes are automatically generated. Users can subscribe to GitHub and NPM -releases. - -We host development, staging, and production environments for the Progressive -Web Application version of the OHIF Viewer. [Development][ohif-dev] always -reflects the latest changes on our master branch. [Staging][ohif-stage] is used -to regression test a release before a bi-weekly deploy to our [Production -environment][ohif-prod]. - -Important announcements are made on GitHub, tagged as Announcement, and pinned -so that they remain at the top of the Issue page. - -The Core team occasionally performs full manual testing to begin the process of -releasing a Stable version. Once testing is complete, the known issues are -addressed and a Stable version is released. - - - - -[groom-backlog]: https://www.agilealliance.org/glossary/backlog-grooming -[retrospective]: https://www.atlassian.com/team-playbook/plays/retrospective -[gh-issues]: https://github.com/OHIF/Viewers/issues/new/choose -[gh-labels]: https://github.com/OHIF/Viewers/labels - -[label-story]: https://github.com/OHIF/Viewers/labels/Story%20%3Araised_hands%3A -[label-tooling]: https://github.com/OHIF/Viewers/labels/Task%3A%20CI%2FTooling%20%3Arobot%3A -[label-docs]: https://github.com/OHIF/Viewers/labels/Task%3A%20Docs%20%3Abook%3A -[label-refactor]: https://github.com/OHIF/Viewers/labels/Task%3A%20Refactor%20%3Ahammer_and_wrench%3A -[label-tests]: https://github.com/OHIF/Viewers/labels/Task%3A%20Tests%20%3Amicroscope%3A -[label-bug]: https://github.com/OHIF/Viewers/labels/Bug%3A%20Verified%20%3Abug%3A - -[draft]: https://github.com/OHIF/Viewers/labels/PR%3A%20Draft -[awaiting-response]: https://github.com/OHIF/Viewers/labels/PR%3A%20Awaiting%20Response%20%3Aspeech_balloon%3A -[awaiting-review]: https://github.com/OHIF/Viewers/labels/PR%3A%20Awaiting%20Review%20%3Aeyes%3A -[awaiting-stories]: https://github.com/OHIF/Viewers/labels/PR%3A%20Awaiting%20UX%20Stories%20%3Adancer%3A -[awaiting-revisions]: https://github.com/OHIF/Viewers/labels/PR%3A%20Awaiting%20Revisions%20%3Apen%3A -[no-ux-impact]: https://github.com/OHIF/Viewers/labels/PR%3A%20No%20UX%20Impact%20%3Aupside_down_face%3A - -[ohif-dev]: https://viewer-dev.ohif.org -[ohif-stage]: https://viewer-stage.ohif.org -[ohif-prod]: https://viewer.ohif.org -[gh-board]: https://github.com/OHIF/Viewers/projects/4 -[label-grabs]: https://github.com/OHIF/Viewers/issues?q=is%3Aissue+is%3Aopen+label%3A%22Up+For+Grabs+%3Araising_hand_woman%3A%22 -[contributing-docs]: ./development/contributing.md - diff --git a/platform/docs/versioned_docs/version-3.0/development/testing.md b/platform/docs/versioned_docs/version-3.0/development/testing.md deleted file mode 100644 index c7c846aaa3d..00000000000 --- a/platform/docs/versioned_docs/version-3.0/development/testing.md +++ /dev/null @@ -1,217 +0,0 @@ ---- -sidebar_position: 6 -sidebar_label: Testing ---- - -# Running Tests for OHIF - -We introduce here various test types that is available for OHIF, and how to run -each test in order to make sure your contribution hasn't broken any existing -functionalities. Idea and philosophy of each testing category is discussed in -the second part of this page. - -## Unit test - -To run the unit test: - -```bash -yarn run test:unit:ci -``` - -Note: You should have already installed all the packages with `yarn install`. - -Running unit test will generate a report at the end showing the successful and -unsuccessful tests with detailed explanations. - -## End-to-end test -For running the OHIF e2e test you need to run the following steps: - -- Open a new terminal, and from the root of the OHIF mono repo, run the following command: - - ```bash - yarn test:data - ``` - - This will download the required data to run the e2e tests (it might take a while). - The `test:data` only needs to be run once and checks the data out. Read more about - test data [below](#test-data). - -- Run the viewer with e2e config - - ```bash - APP_CONFIG=config/e2e.js yarn start - ``` - - You should be able to see test studies in the study list - - ![OHIF-e2e-test-studies](../assets/img/OHIF-e2e-test-studies.png) - -- Open a new terminal inside the OHIF project, and run the e2e cypress test - - ```bash - yarn test:e2e - ``` - - You should be able to see the cypress window open - - ![e2e-cypress](../assets/img/e2e-cypress.png) - - Run the tests by clicking on the `Run #number integration tests` . - - A new window will open, and you will see e2e tests being executed one after - each other. - - ![e2e-cypress-final](../assets/img/e2e-cypress-final.png) - - ## Test Data - The testing data is stored in two OHIF repositories. The first contains the - binary DICOM data, at [viewer-testdata](https://github.com/OHIF/viewer-testdata.git) - while the second module contains data in the DICOMweb format, installed as a submodule - into OHIF in the `testdata` directory. This is retrieved via the command - ```bash - yarn test:data - ``` - or the equivalent command `git submodule update --init` - When adding new data, run: - ``` - npm install -g dicomp10-to-dicomweb - mkdicomweb -d dicomweb dcm - ``` - to update the local dicomweb submodule in viewer-testdata. Then, commit - that data and update the submodules used in OHIF and in the viewer-testdata - parent modules. - - All data MUST be fully anonymized and allowed to be used for open access. - Any attributions should be included in the DCM directory. - -## Testing Philosophy - -> Testing is an opinionated topic. Here is a rough overview of our testing -> philosophy. See something you want to discuss or think should be changed? Open -> a PR and let's discuss. - -You're an engineer. You know how to write code, and writing tests isn't all that -different. But do you know why we write tests? Do you know when to write one, or -what kind of test to write? How do you know if a test is a _"good"_ test? This -document's goal is to give you the tools you need to make those determinations. - -Okay. So why do we write tests? To increase our... **CONFIDENCE** - -- If I do a large refactor, does everything still work? -- If I changed some critical piece of code, is it safe to push to production? - -Gaining the confidence we need to answer these questions after every change is -costly. Good tests allow us to answer them without manual regression testing. -What and how we choose to test to increase that confidence is nuanced. - -## Further Reading: Kinds of Tests - -Test's buy us confidence, but not all tests are created equal. Each kind of test -has a different cost to write and maintain. An expensive test is worth it if it -gives us confidence that a payment is processed, but it may not be the best -choice for asserting an element's border color. - -| Test Type | Example | Speed | Cost | -| ----------- | ------------------------------------------------------------------------ | ---------------- | ------------------------------------------------------------------------ | -| Static | `addNums(1, '2')` called with `string`, expected `int`. | :rocket: Instant | :money_with_wings: | -| Unit | `addNums(1, 2)` returns expected result `3` | :airplane: Fast | :money_with_wings::money_with_wings: | -| Integration | Clicking "Sign In", navigates to the dashboard (mocked network requests) | :running: Okay | :money_with_wings::money_with_wings::money_with_wings: | -| End-to-end | Clicking "Sign In", navigates to the dashboard (no mocks) | :turtle: Slow | :money_with_wings::money_with_wings::money_with_wings::money_with_wings: | - -- :rocket: Speed: How quickly tests run -- :money_with_wings: Cost: Time to write, and to debug when broken (more points - of failure) - -### Static Code Analysis - -Modern tooling gives us this "for free". It can catch invalid regular -expressions, unused variables, and guarantee we're calling methods/functions -with the expected parameter types. - -Example Tooling: - -- [ESLint][eslint-rules] -- [TypeScript][typescript-docs] or [Flow][flow-org] - -### Unit Tests - -The building blocks of our libraries and applications. For these, you'll often -be testing a single function or method. Conceptually, this equates to: - -_Pure Function Test:_ - -- If I call `sum(2, 2)`, I expect the output to be `4` - -_Side Effect Test:_ - -- If I call `resetViewport(viewport)`, I expect `cornerstone.reset` to be called - with `viewport` - -#### When to use - -Anything that is exposed as public API should have unit tests. - -#### When to avoid - -You're actually testing implementation details. You're testing implementation -details if: - -- Your test does something that the consumer of your code would never do. - - IE. Using a private function -- A refactor can break your tests - -### Integration Tests - -We write integration tests to gain confidence that several units work together. -Generally, we want to mock as little as possible for these tests. In practice, -this means only mocking network requests. - -### End-to-End Tests - -These are the most expensive tests to write and maintain. Largely because, when -they fail, they have the largest number of potential points of failure. So why -do we write them? Because they also buy us the most confidence. - -#### When to use - -Mission critical features and functionality, or to cover a large breadth of -functionality until unit tests catch up. Unsure if we should have a test for -feature `X` or scenario `Y`? Open an issue and let's discuss. - -### General - -- [Assert(js) Conf 2018 Talks][assert-js-talks] - - [Write tests. Not too many. Mostly integration.][kent-talk] - Kent C. Dodds - - [I see your point, but…][gleb-talk] - Gleb Bahmutov -- [Static vs Unit vs Integration vs E2E Testing][kent-blog] - Kent C. Dodds - (Blog) - -### End-to-end Testing w/ Cypress - -- [Getting Started](https://docs.cypress.io/guides/overview/why-cypress.html) - - Be sure to check out `Getting Started` and `Core Concepts` -- [Best Practices](https://docs.cypress.io/guides/references/best-practices.html) -- [Example Recipes](https://docs.cypress.io/examples/examples/recipes.html) - - - - -[eslint-rules]: https://eslint.org/docs/rules/ -[mini-pacs]: https://github.com/OHIF/viewer-testdata -[typescript-docs]: https://www.typescriptlang.org/docs/home.html -[flow-org]: https://flow.org/ - -[assert-js-talks]: https://www.youtube.com/playlist?list=PLZ66c9_z3umNSrKSb5cmpxdXZcIPNvKGw -[kent-talk]: https://www.youtube.com/watch?v=Fha2bVoC8SE -[gleb-talk]: https://www.youtube.com/watch?v=5FnalKRjpZk -[kent-blog]: https://kentcdodds.com/blog/unit-vs-integration-vs-e2e-tests - -[testing-trophy]: https://twitter.com/kentcdodds/status/960723172591992832?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E960723172591992832&ref_url=https%3A%2F%2Fkentcdodds.com%2Fblog%2Fwrite-tests -[aaron-square]: https://twitter.com/Carofine247/status/966727489274961920 -[gleb-pyramid]: https://twitter.com/Carofine247/status/966764532046684160/photo/3 -[testing-pyramid]: https://dojo.ministryoftesting.com/dojo/lessons/the-mobile-test-pyramid -[testing-dorito]: https://twitter.com/denvercoder/status/960752578198843392 -[testing-dorito-img]: https://pbs.twimg.com/media/DVVHXycUMAAcN-F?format=jpg&name=4096x4096 - diff --git a/platform/docs/versioned_docs/version-3.0/faq.md b/platform/docs/versioned_docs/version-3.0/faq.md deleted file mode 100644 index 67b7d30b2e8..00000000000 --- a/platform/docs/versioned_docs/version-3.0/faq.md +++ /dev/null @@ -1,81 +0,0 @@ ---- -sidebar_position: 8 -sidebar_label: FAQ ---- - -# Frequently Asked Questions - -## Index - -- [Report a bug][report-bug] -- [Request a feature][new-feature] -- [Commercial Support & Consulting][commercial-support] -- [Academic collaborations][academic] -- [FDA Clearance or CE Marking][fda-clearance] -- [HIPAA Compliance][hipaa] - -### How do I report a bug? - -Navigate to our [GitHub Repository][new-issue], and submit a new bug report. -Follow the steps outlined in the [Bug Report Template][bug-report-template]. - -### How can I request a new feature? - -At the moment we are in the process of defining our roadmap and will do our best -to communicate this to the community. If your requested feature is on the -roadmap, then it will most likely be built at some point. If it is not, you are -welcome to build it yourself and [contribute it](development/contributing.md). -If you have resources and would like to fund the development of a feature, -please [contact us](https://www.ohif.org) or work with community members that -offer [consulting services][commercial-support]. - -### Who should I contact about Academic Collaborations? - -[Gordon J. Harris](https://www.dfhcc.harvard.edu/insider/member-detail/member/gordon-j-harris-phd/) -at Massachusetts General Hospital is the primary contact for any academic -collaborators. We are always happy to hear about new groups interested in using -the OHIF framework, and may be able to provide development support if the -proposed collaboration has an impact on cancer research. - -### Does OHIF offer commercial support? - -The Open Health Imaging Foundation does not offer commercial support, however, -some community members do offer consulting services. You can search our -[Community Forum](https://community.ohif.org/) for more information. - -### Does The OHIF Viewer have [510(k) Clearance][501k-clearance] from the U.S. F.D.A or [CE Marking][ce-marking] from the European Commission? - -**NO.** The OHIF Viewer is **NOT** F.D.A. cleared or CE Marked. It is the users' -responsibility to ensure compliance with applicable rules and regulations. The -[License](https://github.com/OHIF/Viewers/blob/master/LICENSE) for the OHIF -Platform does not prevent your company or group from seeking F.D.A. clearance -for a product built using the platform. - -If you have gone this route (or are going there), please let us know because we -would be interested to hear about your experience. - -### Is The OHIF Viewer [HIPAA][hipaa-def] Compliant? - -**NO.** The OHIF Viewer **DOES NOT** fulfill all of the criteria to become HIPAA -Compliant. It is the users' responsibility to ensure compliance with applicable -rules and regulations. - - - - - -[report-bug]: #how-do-i-report-a-bug -[new-feature]: #how-can-i-request-a-new-feature -[commercial-support]: #does-ohif-offer-commercial-support -[academic]: #who-should-i-contact-about-academic-collaborations -[fda-clearance]: #does-the-ohif-viewer-have-510k-clearance-from-the-us-fda-or-ce-marking-from-the-european-commission -[hipaa]: #is-the-ohif-viewer-hipaa-compliant - -[501k-clearance]: https://www.fda.gov/MedicalDevices/DeviceRegulationandGuidance/HowtoMarketYourDevice/PremarketSubmissions/PremarketNotification510k/ -[ce-marking]: https://ec.europa.eu/growth/single-market/ce-marking_en -[hipaa-def]: https://en.wikipedia.org/wiki/Health_Insurance_Portability_and_Accountability_Act -[new-issue]: https://github.com/OHIF/Viewers/issues/new/choose -[bug-report-template]: https://github.com/OHIF/Viewers/issues/new?assignees=&labels=Bug+Report+%3Abug%3A&template=---bug-report.md&title= - diff --git a/platform/docs/versioned_docs/version-3.0/platform/_category_.json b/platform/docs/versioned_docs/version-3.0/platform/_category_.json deleted file mode 100644 index 842e4abf4a1..00000000000 --- a/platform/docs/versioned_docs/version-3.0/platform/_category_.json +++ /dev/null @@ -1,4 +0,0 @@ -{ - "label": "Platform", - "position": 6 -} diff --git a/platform/docs/versioned_docs/version-3.0/platform/browser-support.md b/platform/docs/versioned_docs/version-3.0/platform/browser-support.md deleted file mode 100644 index f717432aedc..00000000000 --- a/platform/docs/versioned_docs/version-3.0/platform/browser-support.md +++ /dev/null @@ -1,50 +0,0 @@ ---- -sidebar_position: 2 ---- -# Browser Support - -The browsers that we support are specified in the `.browserlistrc` file located -in the `platform/viewer` project. While we leverage the latest language features -when writing code, we rely on `babel` to _transpile_ our code so that it can run -in the browsers that we support. - -## In Practice - -The OHIF Viewer is capable of _running_ on: - -- IE 11 -- FireFox -- Chrome -- Safari -- Edge - -However, we do not have the resources to adequately test and maintain bug free -functionality across all of these. In order to push web based medical imaging -forward, we focus our development efforts on recent version of modern evergreen -browsers. - -Our support of older browsers equates to our willingness to review PRs for bug -fixes, and target their minimum JS support whenever possible. - -### Polyfills - -> A polyfill, or polyfiller, is a piece of code (or plugin) that provides the -> technology that you, the developer, expect the browser to provide natively. - -An example of a polyfill is that you expect `Array.prototype.filter` to exist, -but for some reason, the browser that's being used has not implemented that -language feature yet. Our earlier transpilation will rectify _syntax_ -discrepancies, but unimplemented features require a "temporary" implementation. -That's where polyfills step in. - -You can utilize a service like [polyfill.io](https://polyfill.io/v3/) to -auto-detect and apply polyfills as needed, or you can update the PWA build to -include polyfill's in your bundle by incorporating [core-js][core-js] - - - - -[core-js]: https://github.com/zloirock/core-js/blob/master/docs/2019-03-19-core-js-3-babel-and-a-look-into-the-future.md - diff --git a/platform/docs/versioned_docs/version-3.0/platform/environment-variables.md b/platform/docs/versioned_docs/version-3.0/platform/environment-variables.md deleted file mode 100644 index 4fd2691a4aa..00000000000 --- a/platform/docs/versioned_docs/version-3.0/platform/environment-variables.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -sidebar_position: 3 -sidebar_label: Environment Variables ---- -# Environment Variables - -There are a number of environment variables we use at build time to influence the output application's behavior. - -```bash -# Application -NODE_ENV=< production | development > -DEBUG=< true | false > -APP_CONFIG=< relative path to application configuration file > -PUBLIC_URL=<> -VERSION_NUMBER= -BUILD_NUM= -# i18n -USE_LOCIZE= -LOCIZE_PROJECTID= -LOCIZE_API_KEY= -``` - -## Setting Environment Variables - -- `npx cross-env` -- `.env` files -- env variables on build machine, or for terminal session diff --git a/platform/docs/versioned_docs/version-3.0/platform/extensions/_category_.json b/platform/docs/versioned_docs/version-3.0/platform/extensions/_category_.json deleted file mode 100644 index b7a30d960fb..00000000000 --- a/platform/docs/versioned_docs/version-3.0/platform/extensions/_category_.json +++ /dev/null @@ -1,4 +0,0 @@ -{ - "label": "Extensions", - "position": 9 -} diff --git a/platform/docs/versioned_docs/version-3.0/platform/extensions/extension.md b/platform/docs/versioned_docs/version-3.0/platform/extensions/extension.md deleted file mode 100644 index 148b82a9faf..00000000000 --- a/platform/docs/versioned_docs/version-3.0/platform/extensions/extension.md +++ /dev/null @@ -1,55 +0,0 @@ ---- -sidebar_position: 4 -sidebar_label: Extension Manager ---- - -# Extension Manager - -## Overview - -The `ExtensionManager` is a class made available to us via the `@ohif/core` -project (platform/core). Our application instantiates a single instance of it, -and provides a `ServicesManager` and `CommandsManager` along with the -application's configuration through the appConfig key (optional). - -```js -const commandsManager = new CommandsManager(); -const servicesManager = new ServicesManager(); -const extensionManager = new ExtensionManager({ - commandsManager, - servicesManager, - appConfig, -}); -``` - -The `ExtensionManager` only has a few public members: - -- `setActiveDataSource` - Sets the active data source for the application -- `getDataSources` - Returns the registered data sources -- `getActiveDataSource` - Returns the currently active data source -- `getModuleEntry` - Returns the module entry by the give id. - -## Accessing Modules - -We use `getModuleEntry` in our `ViewerLayout` logic to find the panels based on -the provided IDs in the mode's configuration. - -For instance: -`extensionManager.getModuleEntry("@ohif/extension-measurement-tracking.panelModule.seriesList")` -accesses the `seriesList` panel from `panelModule` of the -`@ohif/extension-measurement-tracking` extension. - -```js -const getPanelData = id => { - const entry = extensionManager.getModuleEntry(id); - const content = entry.component; - - return { - iconName: entry.iconName, - iconLabel: entry.iconLabel, - label: entry.label, - name: entry.name, - content, - }; -}; -``` diff --git a/platform/docs/versioned_docs/version-3.0/platform/extensions/index.md b/platform/docs/versioned_docs/version-3.0/platform/extensions/index.md deleted file mode 100644 index b1920b52104..00000000000 --- a/platform/docs/versioned_docs/version-3.0/platform/extensions/index.md +++ /dev/null @@ -1,325 +0,0 @@ ---- -sidebar_position: 1 -sidebar_label: Introduction ---- - -# Introduction - -We have re-designed the architecture of the `OHIF-v3` to enable building -applications that are easily extensible to various use cases (modes) that behind -the scene would utilize desired functionalities (extensions) to reach the goal -of the use case. - -Previously, extensions were β€œadditive” and could not easily be mixed and matched -within the same viewer for different use cases. Previous `OHIF-v2` architecture -meant that any minor extension alteration usually would require the user to hard -fork. E.g. removing some tools from the toolbar of the cornerstone -extension meant you had to hard fork it, which was frustrating if the -implementation was otherwise the same as master. - -> - Developers should make packages of _reusable_ functionality as extensions, -> and can consume publicly available extensions. -> - Any conceivable radiological workflow or viewer setup will be able to be -> built with the platform through _modes_. - -Practical examples of extensions include: - -- A set of segmentation tools that build on top of the `cornerstone` viewport -- A set of rendering functionalities to volume render the data -- [See our maintained extensions for more examples of what's possible](#maintained-extensions) - -**Diagram showing how extensions are configured and accessed.** - - - -## Extension Skeleton - -An extension is a plain JavaScript object that has `id` and `version` properties, and one or -more [modules](#modules) and/or [lifecycle hooks](#lifecycle-hooks). - -```js -// prettier-ignore -export default { - /** - * Required properties. Should be a unique value across all extensions. - */ - id, - - // Lifecyle - preRegistration() { /* */ }, - onModeEnter() { /* */ }, - onModeExit() { /* */ }, - // Modules - getLayoutTemplateModule() { /* */ }, - getDataSourcesModule() { /* */ }, - getSopClassHandlerModule() { /* */ }, - getPanelModule() { /* */ }, - getViewportModule() { /* */ }, - getCommandsModule() { /* */ }, - getContextModule() { /* */ }, - getToolbarModule() { /* */ }, - getHangingProtocolModule() { /* */ }, -} -``` - -## OHIF-Maintained Extensions - -A small number of powerful extensions for popular use cases are maintained by -OHIF. They're co-located in the [`OHIF/Viewers`][viewers-repo] repository, in -the top level [`extensions/`][ext-source] directory. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
ExtensionDescriptionModules
- - Default - - - Default extension provides default viewer layout, a study/series - browser, and a datasource that maps to a DICOMWeb compliant backend - commandsModule, ContextModule, DataSourceModule, HangingProtocolModule, LayoutTemplateModule, PanelModule, SOPClassHandlerModule, ToolbarModule
- - Cornerstone - - - Provides rendering functionalities for 2D images. - ViewportModule, CommandsModule
- DICOM PDF - - Renders PDFs for a specific SopClassUID. - Viewport, SopClassHandler
- DICOM SR - - Maintained extensions for cornerstone and visualization of DICOM Structured Reports - ViewportModule, CommandsModule, SOPClassHandlerModule
- Measurement tracking - - Tracking measurements in the measurement panel - ContextModule,PanelModule,ViewportModule,CommandsModule
- -## Registering of Extensions - -`viewer` starts by registering all the extensions specified inside the -`pluginConfig.json`, by default we register all extensions in the repo. - - -```js title=platform/viewer/pluginConfig.json -// Simplified version of the `pluginConfig.json` file -{ - "extensions": [ - { - "packageName": "@ohif/extension-cornerstone", - "version": "3.0.0" - }, - { - "packageName": "@ohif/extension-measurement-tracking", - "version": "3.0.0" - }, - // ... - ], - "modes": [ - { - "packageName": "@ohif/mode-longitudinal", - "version": "0.0.1" - } - ] -} -``` - -:::note Important -You SHOULD NOT directly register extensions in the `pluginConfig.json` file. -Use the provided `cli` to add/remove/install/uninstall extensions. Read more [here](../../development/ohif-cli.md) -::: - -The final registration and import of the extensions happen inside a non-tracked file `pluginImport.js` (this file is also for internal use only). - -After an extension gets registered withing the `viewer`, -each [module](#modules) defined by the extension becomes available to the modes -via the `ExtensionManager` by requesting it via its id. -[Read more about Extension Manager](#extension-manager) - -## Lifecycle Hooks - -Currently, there are three lifecycle hook for extensions: - -[`preRegistration`](./lifecycle/#preRegistration) This hook is called once on -initialization of the entire viewer application, used to initialize the -extensions state, and consume user defined extension configuration. If an -extension defines the [`preRegistration`](./lifecycle/#preRegistration) -lifecycle hook, it is called before any modules are registered in the -`ExtensionManager`. It's most commonly used to wire up extensions to -[services](./../services/index.md) and [commands](./modules/commands.md), and to -bootstrap 3rd party libraries. - -[`onModeEnter`](./lifecycle#onModeEnter): This hook is called whenever a new -mode is entered, or a mode’s data or datasource is switched. This hook can be -used to initialize data. - -[`onModeExit`](./lifecycle#onModeExit): Similarly to onModeEnter, this hook is -called when navigating away from a mode, or before a mode’s data or datasource -is changed. This can be used to clean up data (e.g. remove annotations that do -not need to be persisted) - -## Modules - -Modules are the meat of extensions, the `blocks` that we have been talking about -a lot. They provide "definitions", components, and filtering/mapping logic that -are then made available to modes and services. - -Each module type has a special purpose, and is consumed by our viewer -differently. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Types - Description
- - LayoutTemplate (NEW) - - Control Layout of a route
- - DataSource (NEW) - - Control the mapping from DICOM metadata to OHIF-metadata
- - SOPClassHandler - - Determines how retrieved study data is split into "DisplaySets"
- - Panel - - Adds left or right hand side panels
- - Viewport - - Adds a component responsible for rendering a "DisplaySet"
- - Commands - - Adds named commands, scoped to a context, to the CommandsManager
- - Toolbar - - Adds buttons or custom components to the toolbar
- - Context - - Shared state for a workflow or set of extension module definitions
- - HangingProtocol - - Adds hanging protocol rules
- -Tbl. Module types -with abridged descriptions and examples. Each module links to a dedicated -documentation page. - -### Contexts - -The `@ohif/viewer` tracks "active contexts" that extensions can use to scope -their functionality. Some example contexts being: - -- Route: `ROUTE:VIEWER`, `ROUTE:STUDY_LIST` -- Active Viewport: `ACTIVE_VIEWPORT:CORNERSTONE`, `ACTIVE_VIEWPORT:VTK` - -An extension module can use these to say "Only show this Toolbar Button if the -active viewport is a Cornerstone viewport." This helps us use the appropriate UI -and behaviors depending on the current contexts. - -For example, if we have hotkey that "rotates the active viewport", each Viewport -module that supports this behavior can add a command with the same name, scoped -to the appropriate context. When the `command` is fired, the "active contexts" -are used to determine the appropriate implementation of the rotation behavior. - - - - -[viewers-repo]: https://github.com/OHIF/Viewers -[ext-source]: https://github.com/OHIF/Viewers/tree/master/extensions -[module-types]: https://github.com/OHIF/Viewers/blob/master/platform/core/src/extensions/MODULE_TYPES.js - diff --git a/platform/docs/versioned_docs/version-3.0/platform/extensions/installation.md b/platform/docs/versioned_docs/version-3.0/platform/extensions/installation.md deleted file mode 100644 index 2e5fb81c2a1..00000000000 --- a/platform/docs/versioned_docs/version-3.0/platform/extensions/installation.md +++ /dev/null @@ -1,12 +0,0 @@ ---- -sidebar_position: 5 -sidebar_label: Installation ---- - -# Extension: Installation - -OHIF-v3 provides the ability to utilize external extensions. - - -You can use ohif `cli` tool to install both local and publicly published -extensions on NPM. You can read more [here](../../development/ohif-cli.md) diff --git a/platform/docs/versioned_docs/version-3.0/platform/extensions/lifecycle.md b/platform/docs/versioned_docs/version-3.0/platform/extensions/lifecycle.md deleted file mode 100644 index 422bce794cd..00000000000 --- a/platform/docs/versioned_docs/version-3.0/platform/extensions/lifecycle.md +++ /dev/null @@ -1,128 +0,0 @@ ---- -sidebar_position: 3 -sidebar_label: Lifecycle Hooks ---- - -# Extensions: Lifecycle Hooks - -## Overview - -Extensions can implement specific lifecycle methods. - -- preRegistration -- onModeEnter -- onModeExit - -## preRegistration - -If an extension defines the `preRegistration` lifecycle hook, it is called -before any modules are registered in the `ExtensionManager`. This hook can be -used to: - -- initialize 3rd party libraries -- register event listeners -- add or call services -- add or call commands - -The `preRegistration` hook receives an object containing the -`ExtensionManager`'s associated `ServicesManager`, `CommandsManager`, and any -`configuration` that was provided with the extension at time of registration. - -Example `preRegistration` implementation that register a new service and make it -available in the app. We will talk more in details for creating a new service -for `OHIF-v3`. - -```js -// new service inside new extension -import MyNewService from './MyNewService'; - -export default function MyNewServiceWithServices(serviceManager) { - return { - name: 'MyNewService', - create: ({ configuration = {} }) => { - return new MyNewService(serviceManager); - }, - }; -} -``` - -and - -```js -import MyNewService from './MyNewService' - -export default { - id, - - /** - * @param {object} params - * @param {object} params.configuration - * @param {ServicesManager} params.servicesManager - * @param {CommandsManager} params.commandsManager - * @returns void - */ - preRegistration({ servicesManager, commandsManager, configuration }) { - console.log('Wiring up important stuff.'); - - window.importantStuff = () => { - console.log(configuration); - }; - - console.log('Important stuff has been wired.'); - window.importantStuff(); - - // Registering new services - servicesManager.registerService(MyNewService(servicesManager)); - }, - }, -}; -``` - -## onModeEnter - -If an extension defines the `onModeEnter` lifecycle hook, it is called when a -new mode is enters, or a mode's data or datasource is switched. - -For instance, in DICOM structured report extension (`dicom-sr`), we are using -`onModeEnter` to re-create the displaySets after a new mode is entered. - -_Example `onModeEnter` hook implementation_ - -```js -export default { - id: '@ohif/extension-cornerstone-dicom-sr', - - onModeEnter({ servicesManager }) { - const { DisplaySetService } = servicesManager.services; - const displaySetCache = DisplaySetService.getDisplaySetCache(); - - const srDisplaySets = displaySetCache.filter( - ds => ds.SOPClassHandlerId === SOPClassHandlerId - ); - - srDisplaySets.forEach(ds => { - // New mode route, allow SRs to be hydrated again - ds.isHydrated = false; - }); - }, -}; -``` - -## onModeExit - -If an extension defines the `onModeExit` lifecycle hook, it is called when -navigating away from a mode. This hook can be used to clean up data tasks such -as unregistering services, removing annotations that do not need to be -persisted. - -_Example `onModeExit` hook implementation_ - -```js -export default { - id: 'myExampleExtension', - - onModeExit({ servicesManager, commandsManager }) { - myCacheService.purge(); - }, -}; -``` diff --git a/platform/docs/versioned_docs/version-3.0/platform/extensions/modules/_category_.json b/platform/docs/versioned_docs/version-3.0/platform/extensions/modules/_category_.json deleted file mode 100644 index c131ccdd7e3..00000000000 --- a/platform/docs/versioned_docs/version-3.0/platform/extensions/modules/_category_.json +++ /dev/null @@ -1,4 +0,0 @@ -{ - "label": "Modules", - "position": 3 -} diff --git a/platform/docs/versioned_docs/version-3.0/platform/extensions/modules/commands.md b/platform/docs/versioned_docs/version-3.0/platform/extensions/modules/commands.md deleted file mode 100644 index b37202bf61e..00000000000 --- a/platform/docs/versioned_docs/version-3.0/platform/extensions/modules/commands.md +++ /dev/null @@ -1,121 +0,0 @@ ---- -sidebar_position: 2 -sidebar_label: Commands ---- -# Module: Commands - - -## Overview -`CommandsModule` includes list of arbitrary functions. These may activate tools, communicate with a server, open a modal, etc. -The significant difference between `OHIF-v3` and `OHIF-v2` is that in `v3` a `mode` defines -its toolbar, and which commands each tool call is inside in its toolDefinition - -An extension can register a Commands Module by defining a `getCommandsModule` -method. The Commands Module allows us to register one or more commands scoped to -specific [contexts](./../index.md#contexts). Commands have several unique -characteristics that make them tremendously powerful: - -- Multiple implementations for the same command can be defined -- Only the correct command's implementation will be run, dependent on the - application's "context" -- Commands are used by hotkeys, toolbar buttons and render settings - -Here is a simple example commands module: - -```js -const getCommandsModule = () => ({ - definitions: { - exampleActionDef: { - commandFn: ({ param1 }) => { - console.log(`param1's value is: ${param1}`); - }, - // storeContexts: ['viewports'], - options: { param1: 'param1' }, - context: 'VIEWER', // optional - }, - }, - defaultContext: 'ACTIVE_VIEWPORT::DICOMSR', -}); -``` - - -Each definition returned by the Commands Module is registered to the -`ExtensionManager`'s `CommandsManager`. - -> `storeContexts` has been removed in `OHIF-v3` and now modules have access to all commands and services. This change enables support for user-registered services. - -## Command Definitions - -The command definition consists of a named command (`exampleActionDef` below) and a -`commandFn`. The command name is used to call the command, and the `commandFn` -is the "command" that is actioned. - -```js -exampleActionDef: { - commandFn: ({ param1, options }) => { }, - options: { param1: 'measurement' }, - context: 'DEFAULT', -} -``` - -| Property | Type | Description | -| --------------- | ------------------ | --------------------------------------------------------------------------------------------------------------------------------------- | -| `commandFn` | func | The function to call when command is run. Receives `options` and `storeContexts`. | -| `options` | object | (optional) Arguments to pass at the time of calling to the `commandFn` | -| `context` | string[] or string | (optional) Overrides the `defaultContext`. Let's us know if command is currently "available" to be run. | - -## Command Behavior - - - -**If there are multiple valid commands for the application's active contexts** - -- What happens: all commands are run -- When to use: A `clearData` command that cleans up state for multiple - extensions - -**If no commands are valid for the application's active contexts** - -- What happens: a warning is printed to the console -- When to use: a `hotkey` (like "invert") that doesn't make sense for the - current viewport (PDF or HTML) - -## `CommandsManager` Public API - -If you would like to run a command in the consuming app or an extension, you can -use `CommandsManager.runCommand(commandName, options = {}, contextName)` - - -```js -// Returns all commands for a given context -commandsManager.getContext('string'); - -// Run a command, it will run all the `speak` commands in all contexts -commandsManager.runCommand('speak', { command: 'hello' }); - -// Run command, from Default context -commandsManager.runCommand('speak', { command: 'hello' }, ['DEFAULT']); -``` - -The `ExtensionManager` handles registering commands and creating contexts, so -most consumer's won't need these methods. If you find yourself using these, ask -yourself "why can't I register these commands via an extension?" - -```js -// Used by the `ExtensionManager` to register new commands -commandsManager.registerCommand('context', 'name', commandDefinition); - -// Creates a new context; clears the context if it already exists -commandsManager.createContext('string'); -``` - -### Contexts - -It is up to the consuming application to define what contexts are possible, and -which ones are currently active. As extensions depend heavily on these, we will -likely publish guidance around creating contexts, and ways to override extension -defined contexts in the near future. If you would like to discuss potential -changes to how contexts work, please don't hesitate to create a new GitHub -issue. - -[Some additional information on Contexts can be found here.](./../index.md#contexts) diff --git a/platform/docs/versioned_docs/version-3.0/platform/extensions/modules/contextModule.md b/platform/docs/versioned_docs/version-3.0/platform/extensions/modules/contextModule.md deleted file mode 100644 index 35de381a3da..00000000000 --- a/platform/docs/versioned_docs/version-3.0/platform/extensions/modules/contextModule.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -sidebar_position: 9 -sidebar_label: Context ---- -# Module: Context - -## Overview -This new module type allows you to connect components via a shared context. You can create a context that two components, e.g. a viewport and a panel can use to synchronize and communicate. An extensive example of this can be seen in the longitudinal mode’s custom extensions. - - - -```jsx -const ExampleContext = React.createContext(); - -function ExampleContextProvider({ children }) { - return ( - - {children} - - ); -} - -const getContextModule = () => [ - { - name: 'ExampleContext', - context: ExampleContext, - provider: ExampleContextProvider, - }, -]; -``` diff --git a/platform/docs/versioned_docs/version-3.0/platform/extensions/modules/data-source.md b/platform/docs/versioned_docs/version-3.0/platform/extensions/modules/data-source.md deleted file mode 100644 index 381d7ea7e1e..00000000000 --- a/platform/docs/versioned_docs/version-3.0/platform/extensions/modules/data-source.md +++ /dev/null @@ -1,106 +0,0 @@ ---- -sidebar_position: 3 -sidebar_label: Data Source ---- - -# Module: Data Source - -## Overview - -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. - -We have built a standard for fetching and mapping data into OHIF’s native -format, which we call DataSources, and have provided one implementation of this -standard. - -You can make another datasource implementation which communicates to your -backend and maps to OHIF’s native format, then use any existing mode on your -platform. Your data doesn’t even need to be DICOM if you can map some -proprietary data to the correct format. - -The DataSource is also a place to add easy helper methods that platform-specific -extensions can call in order to interact with the backend, meaning proprietary -data interactions can be wrapped in extensions. - -```js -const getDataSourcesModule = () => [ - { - name: 'exampleDataSource', - type: 'webApi', // 'webApi' | 'local' | 'other' - createDataSource: dataSourceConfig => { - return IWebApiDataSource.create(/* */); - }, - }, -]; -``` - -Default extension provides two main data sources that are commonly used: -`dicomweb` and `dicomjson` - -```js -import { createDicomWebApi } from './DicomWebDataSource/index.js'; -import { createDicomJSONApi } from './DicomJSONDataSource/index.js'; - -function getDataSourcesModule() { - return [ - { - name: 'dicomweb', - type: 'webApi', - createDataSource: createDicomWebApi, - }, - { - name: 'dicomjson', - type: 'jsonApi', - createDataSource: createDicomJSONApi, - }, - ]; -} -``` - -## Custom DataSource - -You can add your custom datasource by creating the implementation using -`IWebApiDataSource.create` from `@ohif/core`. This factory function creates a -new "Web API" data source that fetches data over HTTP. - -You need to make sure, you implement the following functions for the data -source. - -```js title="platform/core/src/DataSources/IWebApiDataSource.js" -function create({ - query, - retrieve, - store, - reject, - parseRouteParams, - deleteStudyMetadataPromise, - getImageIdsForDisplaySet, - getImageIdsForInstance, -}) { - /* */ -} -``` - -You can take a look at `dicomweb` data source implementation to get an idea -`extensions/default/src/DicomWebDataSource/index.js` - -## Static WADO Client - -If the configuration for the data source has the value staticWado set, then it -is assumed that queries for the studies return a super-set of the studies, as it -is assumed to be returning a static list. The StaticWadoClient performs the -search functionality manually, by interpreting the query parameters and then -applying them to the returned response. This functionality may be useful for -other types of DICOMweb back ends, where they are capable of performing queries, -but don't allow for querying certain types of fields. However, that only works -as long as the size of the studies list isn't too large that client side -selection isn't too expensive. - -## DicomMetadataStore - -In `OHIF-v3` we have a central location for the metadata of studies, and they are -located in `DicomMetadataStore`. Your custom datasource can communicate with -`DicomMetadataStore` to store, and fetch Study/Series/Instance metadata. We will -learn more about `DicomMetadataStore` in services. diff --git a/platform/docs/versioned_docs/version-3.0/platform/extensions/modules/hpModule.md b/platform/docs/versioned_docs/version-3.0/platform/extensions/modules/hpModule.md deleted file mode 100644 index 649d6644eec..00000000000 --- a/platform/docs/versioned_docs/version-3.0/platform/extensions/modules/hpModule.md +++ /dev/null @@ -1,58 +0,0 @@ ---- -sidebar_position: 8 -sidebar_label: Hanging Protocol ---- -# Module: Hanging Protocol - -## Overview -`hangingProtocolModule` provides the protocols for hanging the displaySets in the viewer. -This module can be as simple as loading a list of pre-defined protocols, or it can be more complex -and `fetch` the protocols from a server. - -You can read more about hanging protocols in HangingProtocolService. - -```js -const deafultProtocol = { - id: 'defaultProtocol', - locked: true, - hasUpdatedPriorsInformation: false, - name: 'Default', - createdDate: '2021-02-23T19:22:08.894Z', - modifiedDate: '2021-02-23T19:22:08.894Z', - availableTo: {}, - editableBy: {}, - protocolMatchingRules: [], - stages: [ - { - id: 'nwzau7jDkEkL8djfr', - name: 'oneByOne', - viewportStructure: { - type: 'grid', - properties: { - rows: 1, - columns: 1, - }, - }, - viewports: [ - { - viewportSettings: [], - imageMatchingRules: [], - seriesMatchingRules: [], - studyMatchingRules: [], - }, - ], - createdDate: '2021-02-23T19:22:08.894Z', - }, - ], - numberOfPriorsReferenced: -1, -}; - -function getHangingProtocolModule() { - return [ - { - name: hangingProtocolName, - protocols: [deafultProtocol], - }, - ]; -} -``` diff --git a/platform/docs/versioned_docs/version-3.0/platform/extensions/modules/layout-template.md b/platform/docs/versioned_docs/version-3.0/platform/extensions/modules/layout-template.md deleted file mode 100644 index 66c839dae1b..00000000000 --- a/platform/docs/versioned_docs/version-3.0/platform/extensions/modules/layout-template.md +++ /dev/null @@ -1,139 +0,0 @@ ---- -sidebar_position: 7 -sidebar_label: Layout Template ---- - -# Module: Layout Template - -## Overview - -`LayoutTemplates` are a new concept in v3 that modes use to control the layout -of a route. A layout template is a React component that is given a set of -managers that define apis to access toolbar state, commands, and hotkeys, as -well as props defined by the layout template. - -For instance the default LayoutTemplate takes in leftPanels, rightPanels and -viewports as props, which it uses to build its view. - -In addition, `layout template` has complete control over the structure of the -application. You could have tools down the left side, or a strict guided -workflow with tools set programmatically, the choice is yours for your use case. - -```jsx -const getLayoutTemplateModule = (/* ... */) => [ - { - id: 'exampleLayout', - name: 'exampleLayout', - component: ExampleLayoutComponent, - }, -]; -``` - -The `props` that are passed to `layoutTemplate` are managers and service, along -with the defined mode left/right panels, mode's defined viewports and OHIF -`ViewportGridComp`. LayoutTemplate leverages extensionManager to grab typed -extension module entries: `*.getModuleEntry(id)` - -A simplified code for `Default extension`'s layout template is: - -```jsx title="extensions/default/src/ViewerLayout/index.jsx" -import React from 'react'; -import { SidePanel } from '@ohif/ui'; - -function Toolbar({ servicesManager }) { - const { ToolBarService } = servicesManager.services; - - return ( - <> - // ToolBarService.getButtonSection('primary') to get toolbarButtons - {toolbarButtons.map((toolDef, index) => { - const { id, Component, componentProps } = toolDef; - return ( - ToolBarService.recordInteraction(args)} - /> - ); - })} - - ); -} - -function ViewerLayout({ - // From Extension Module Params - extensionManager, - servicesManager, - hotkeysManager, - commandsManager, - // From Modes - leftPanels, - rightPanels, - viewports, - ViewportGridComp, -}) { - const getPanelData = id => { - const entry = extensionManager.getModuleEntry(id); - const content = entry.component; - - return { - iconName: entry.iconName, - iconLabel: entry.iconLabel, - label: entry.label, - name: entry.name, - content, - }; - }; - - const getViewportComponentData = viewportComponent => { - const entry = extensionManager.getModuleEntry(viewportComponent.namespace); - - return { - component: entry.component, - displaySetsToDisplay: viewportComponent.displaySetsToDisplay, - }; - }; - - const leftPanelComponents = leftPanels.map(getPanelData); - const rightPanelComponents = rightPanels.map(getPanelData); - const viewportComponents = viewports.map(getViewportComponentData); - - return ( -
- - -
- {/* LEFT SIDEPANELS */} - - - {/* TOOLBAR + GRID */} - - - {/* Rigth SIDEPANELS */} - -
-
- ); -} -``` - -## Overview Video - -
- -
diff --git a/platform/docs/versioned_docs/version-3.0/platform/extensions/modules/panel.md b/platform/docs/versioned_docs/version-3.0/platform/extensions/modules/panel.md deleted file mode 100644 index 1ad0d8c0813..00000000000 --- a/platform/docs/versioned_docs/version-3.0/platform/extensions/modules/panel.md +++ /dev/null @@ -1,115 +0,0 @@ ---- -sidebar_position: 6 -sidebar_label: Panel ---- - -# Module: Panel - -## Overview - -The default LayoutTemplate has panels on the left and right sides, however one -could make a template with panels at the top or bottom and make extensions with -panels intended for such slots. - -An extension can register a Panel Module by defining a `getPanelModule` method. -The panel module provides the ability to define `menuOptions` and `components` -that can be used by the consuming application. `components` are React Components -that can be displayed in the consuming application's "Panel" Component. - -![panel-module-v3](../../../assets/img/panel-module-v3.png) - -The `menuOptions`'s `target` key, points to a registered `components`'s `id`. A -`defaultContext` is applied to all `menuOption`s; however, each `menuOption` can -optionally provide its own `context` value. - -The `getPanelModule` receives an object containing the `ExtensionManager`'s -associated `ServicesManager` and `CommandsManager`. - -```jsx -import PanelMeasurementTable from './PanelMeasurementTable.js'; - -function getPanelModule({ - commandsManager, - extensionManager, - servicesManager, -}) { - const wrappedMeasurementPanel = () => { - return ( - - ); - }; - - return [ - { - name: 'measure', - iconName: 'list-bullets', - iconLabel: 'Measure', - label: 'Measurements', - isDisabled: studies => {}, // optional - component: wrappedMeasurementPanel, - }, - ]; -} -``` - -## Consuming Panels Inside Modes - -As explained earlier, extensions make the functionalities and components -available and `modes` utilize them to build an app. So, as seen above, we are -not actually defining which side the panel should be opened. Our extension is -providing the component with its. - -New: You can easily add multiple panels to the left/right side of the viewer -using the mode configuration. As seen below, the `leftPanels` and `rightPanels` -accept an `Array` of the `IDs`. - -```js - -const extensionDependencies = { - '@ohif/extension-default': '^3.0.0', - '@ohif/extension-cornerstone': '^3.0.0', - '@ohif/extension-measurement-tracking': '^3.0.0', - '@ohif/extension-cornerstone-dicom-sr': '^3.0.0', -}; - -const id = 'viewer' -const version = '3.0.0 - -function modeFactory({ modeConfiguration }) { - return { - id, - routes: [ - { - path: 'longitudinal', - layoutTemplate: ({ location, servicesManager }) => { - return { - id, - props: { - leftPanels: [ - '@ohif/extension-measurement-tracking.panelModule.seriesList', - ], - rightPanels: [ - '@ohif/extension-measurement-tracking.panelModule.trackedMeasurements', - ], - viewports, - }, - }; - }, - }, - ], - extensions: extensionDependencies - }; -} - -const mode = { - id, - modeFactory, - extensionDependencies, -}; - -export default mode; - -``` diff --git a/platform/docs/versioned_docs/version-3.0/platform/extensions/modules/sop-class-handler.md b/platform/docs/versioned_docs/version-3.0/platform/extensions/modules/sop-class-handler.md deleted file mode 100644 index eb1b7a46410..00000000000 --- a/platform/docs/versioned_docs/version-3.0/platform/extensions/modules/sop-class-handler.md +++ /dev/null @@ -1,108 +0,0 @@ ---- -sidebar_position: 4 -sidebar_label: SOP Class Handler ---- -# Module: SOP Class Handler - -## Overview -This module defines how a specific DICOM SOP class should be processed to make a displaySet, something that can be hung in a viewport. An extension can register a [SOP Class][sop-class-link] Handler Module by defining a `getSopClassHandlerModule` method. The [SOP Class][sop-class-link]. - -The mode chooses what SOPClassHandlers to use, so you could process a series in a different way depending on mode within the same application. - - -SOPClassHandler is a bit different from the other modules, as it doesn't provide a `1:1` -schema for UI or provide its own components. It instead defines: - -- `sopClassUIDs`: an array of string SOP Class UIDs that the - `getDisplaySetFromSeries` method should be applied to. -- `getDisplaySetFromSeries`: a method that maps series and study metadata to a - display set - -A `displaySet` has the following shape: - -```js -return { - Modality: 'MR', - displaySetInstanceUIDD - SeriesDate, - SeriesTime, - SeriesInstanceUID, - StudyInstanceUID, - SeriesNumber, - FrameRate, - SeriesDescription, - isMultiFrame, - numImageFrames, - SOPClassHandlerId, -} -``` - -## Example SOP Class Handler Module - -```js -import ImageSet from '@ohif/core/src/classes/ImageSet'; - - -const sopClassDictionary = { - CTImageStorage: "1.2.840.10008.5.1.4.1.1.2", - MRImageStorage: "1.2.840.10008.5.1.4.1.1.4", -}; - - -// It is important to note that the used SOPClassUIDs in the modes are in the order that is specified in the array. -const sopClassUids = [ - sopClassDictionary.CTImageStorage, - sopClassDictionary.MRImageStorage, -; - -const makeDisplaySet = (instances) => { - const instance = instances[0]; - const imageSet = new ImageSet(instances); - - imageSet.setAttributes({ - displaySetInstanceUID: imageSet.uid, - SeriesDate: instance.SeriesDate, - SeriesTime: instance.SeriesTime, - SeriesInstanceUID: instance.SeriesInstanceUID, - StudyInstanceUID: instance.StudyInstanceUID, - SeriesNumber: instance.SeriesNumber, - FrameRate: instance.FrameTime, - SeriesDescription: instance.SeriesDescription, - Modality: instance.Modality, - isMultiFrame: isMultiFrame(instance), - numImageFrames: instances.length, - SOPClassHandlerId: `${id}.sopClassHandlerModule.${sopClassHandlerName}`, - }); - - return imageSet; -}; - -getSopClassHandlerModule = () => { - return [ - { - name: 'stack, - sopClassUids, - getDisplaySetsFromSeries: makeDisplaySet, - }, - ]; -}; - -``` - -### More examples : -You can find another example for this mapping between raw metadata and displaySet for -`DICOM-SR` extension. - -## `@ohif/viewer` usage - -We use the `sopClassHandlerModule`s in `DisplaySetService` where we -transform instances from the raw metadata format to a OHIF displaySet format. -You can read more about DisplaySetService here. - - -[sop-class-link]: http://dicom.nema.org/dicom/2013/output/chtml/part04/sect_B.5.html -[dicom-html-sop]: https://github.com/OHIF/Viewers/blob/master/extensions/dicom-html/src/OHIFDicomHtmlSopClassHandler.js#L4-L12 -[dicom-pdf-sop]: https://github.com/OHIF/Viewers/blob/master/extensions/dicom-pdf/src/OHIFDicomPDFSopClassHandler.js#L4-L6 -[dicom-micro-sop]: https://github.com/OHIF/Viewers/blob/master/extensions/dicom-microscopy/src/DicomMicroscopySopClassHandler.js#L5-L7 -[dicom-seg-sop]: https://github.com/OHIF/Viewers/blob/master/extensions/dicom-segmentation/src/OHIFDicomSegSopClassHandler.js#L5-L7 - diff --git a/platform/docs/versioned_docs/version-3.0/platform/extensions/modules/toolbar.md b/platform/docs/versioned_docs/version-3.0/platform/extensions/modules/toolbar.md deleted file mode 100644 index 98e0d91a7a2..00000000000 --- a/platform/docs/versioned_docs/version-3.0/platform/extensions/modules/toolbar.md +++ /dev/null @@ -1,250 +0,0 @@ ---- -sidebar_position: 1 -sidebar_label: Toolbar ---- - -# Module: Toolbar - -An extension can register a Toolbar Module by defining a `getToolbarModule` -method. `OHIF-v3`'s `default` extension (`"@ohif/extension-default"`) provides 5 main -toolbar button types: - -![toolbarModule](../../../assets/img/toolbar-module.png) - -## Example Toolbar Module - -The Toolbar Module should return an array of `objects`. There are currently a -few different variations of definitions, each one is detailed further down. - -```js -export default function getToolbarModule({ commandsManager, servicesManager }) { - return [ - { - name: 'ohif.divider', - defaultComponent: ToolbarDivider, - clickHandler: () => {}, - }, - { - name: 'ohif.action', - defaultComponent: ToolbarButton, - clickHandler: () => {}, - }, - { - name: 'ohif.radioGroup', - defaultComponent: ToolbarButton, - clickHandler: () => {}, - }, - { - name: 'ohif.splitButton', - defaultComponent: ToolbarSplitButton, - clickHandler: () => {}, - }, - { - name: 'ohif.layoutSelector', - defaultComponent: ToolbarLayoutSelector, - clickHandler: (evt, clickedBtn, btnSectionName) => {}, - }, - ]; -} -``` - -## Toolbar buttons consumed in modes - -Below we can see a simplified version of the `longitudinal` mode that shows how -a mode can add buttons to the toolbar by calling -`ToolBarService.addButtons(toolbarButtons)`. `toolbarButtons` is an array of -`toolDefinitions` which we will learn next. - -```js -function modeFactory({ modeConfiguration }) { - return { - id: 'viewer', - displayName: 'Basic Viewer', - - onModeEnter: ({ servicesManager, extensionManager }) => { - const { ToolBarService } = servicesManager.services; - - ToolBarService.init(extensionManager); - ToolBarService.addButtons(toolbarButtons); - }, - routes: [ - { - path: 'longitudinal', - layoutTemplate: ({ location, servicesManager }) => { - return { - /* */ - }; - }, - }, - ], - }; -} -``` - -## Button Definitions - -The simplest toolbarButtons definition has the following properties: - -![toolbarModule-zoom](../../../assets/img/toolbarModule-zoom.png) - -```js -{ - id: 'Zoom', - type: 'ohif.radioGroup', - props: { - type: 'tool', - icon: 'tool-zoom', - label: 'Zoom', - commandOptions: { toolName: 'Zoom' }, - }, -}, -``` - -| property | description | values | -| ---------------- | ----------------------------------------------------------------- | ------------------------------------------- | -| `id` | Unique string identifier for the definition | \* | -| `label` | User/display friendly to show in UI | \* | -| `icon` | A string name for an icon supported by the consuming application. | \* | -| `type` | Used to determine the button's behaviour | "tool", "toggle", "action" | -| `commandName` | (optional) The command to run when the button is used. | Any command registered by a `CommandModule` | -| `commandOptions` | (optional) Options to pass the target `commandName` | \* | - -There are three main types of toolbar buttons: - -- `tool`: buttons that enable a tool by running the `setToolActive` command with - the `commandOptions` -- `toggle`: buttons that acts as a toggle: e.g., linking viewports -- `action`: buttons that executes an action: e.g., capture button to save - screenshot - -## Nested Buttons - -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 - -![toolbarModule-nested-buttons](../../../assets/img/toolbarModule-nested-buttons.png) - -```js title="modes/longitudinal/src/toolbarButtons.js" -{ - id: 'MeasurementTools', - type: 'ohif.splitButton', - props: { - groupId: 'MeasurementTools', - isRadio: true, - primary: { - id: 'Length', - icon: 'tool-length', - label: 'Length', - type: 'tool', - commandOptions: { - toolName: 'Length', - } - }, - secondary: { - icon: 'chevron-down', - label: '', - isActive: true, - tooltip: 'More Measure Tools', - }, - items: [ - // Length tool - { - id: 'Length', - icon: 'tool-length', - label: 'Length', - type: 'tool', - commandOptions: { - toolName: 'Length', - } - }, - // Bidirectional tool - { - id: 'Bidirectional', - icon: 'tool-bidirectional', - label: 'Length', - type: 'tool', - commandOptions: { - toolName: 'Bidirectional', - } - }, - // Ellipse tool - { - id: 'EllipticalRoi', - icon: 'tool-elipse', - label: 'Ellipse', - type: 'tool', - commandOptions: { - toolName: 'EllipticalRoi', - } - }, - // Circle tool - { - id: 'CircleROI', - icon: 'tool-circle', - label: 'Circle', - type: 'tool', - commandOptions: { - toolName: 'CircleROI', - } - }, - ], - }, -} -``` - -
- -
- -## Layout Template - -Layout selector button and logic is also provided by the OHIF-v3 `default` -extension. To use it, you can just add the following definition to the list of -`toolDefinitions` - -![toolbarModule-layout](../../../assets/img/toolbarModule-layout.png) - -```js -{ - id: 'Layout', - type: 'ohif.layoutSelector', -} -``` - -
- -
- -## Custom Button - -You can also create your own extension, and add your new custom tool appearance -(e.g., split horizontally instead of vertically for split tool). Simply add -`getToolbarModule` to your extension, and pass your tool react component to its -`defaultComponent` property in the returned object. You can use `@ohif/ui` -components such as `IconButton, Icon, Tooltip, ToolbarButton` to build your own -component. - -```js -import myToolComponent from './myToolComponent'; - -export default function getToolbarModule({ commandsManager, servicesManager }) { - return [ - { - name: 'new-tool-type', - defaultComponent: myToolComponent, - clickHandler: () => {}, - }, - ]; -} -``` - -## Custom tool - -**I want to create a new tool** diff --git a/platform/docs/versioned_docs/version-3.0/platform/extensions/modules/viewport.md b/platform/docs/versioned_docs/version-3.0/platform/extensions/modules/viewport.md deleted file mode 100644 index c3e07aa3464..00000000000 --- a/platform/docs/versioned_docs/version-3.0/platform/extensions/modules/viewport.md +++ /dev/null @@ -1,96 +0,0 @@ ---- -sidebar_position: 5 -sidebar_label: Viewport ---- - -# Module: Viewport - -## Overview - -Viewports consume a displaySet and display/allow the user to interact with data. -An extension can register a Viewport Module by defining a `getViewportModule` -method that returns a React component. Currently, we use viewport components to -add support for: - -- 2D Medical Image Viewing (cornerstone ext.) -- Structured Reports as SR (DICOM SR ext.) -- Structured Reports as HTML (DICOM html ext.) -- Encapsulated PDFs as PDFs (DICOM pdf ext.) -- Whole Slide Microscopy Viewing (whole slide ext.) -- etc. - -The general pattern is that a mode can define which `Viewport` to use for which -specific `SOPClassHandlerUID`, so if you want to fork just a single Viewport -component for a specialized mode, this is possible. - -```jsx -// displaySet, viewportIndex, dataSource -const getViewportModule = () => { - const wrappedViewport = props => { - return ( - { - commandsManager.runCommand('commandName', data); - }} - /> - ); - }; - - return [{ name: 'example', component: wrappedViewport }]; -}; -``` - -## Example Viewport Component - -A simplified version of the tracked CornerstoneViewport is shown below, which -creates a cornerstone viewport and action bar on top of it. - -```jsx -function TrackedCornerstoneViewport({ - children, - dataSource, - displaySet, - viewportIndex, - servicesManager, - extensionManager, - commandsManager, -}) { - const renderViewport = () => { - const { component: Component } = extensionManager.getModuleEntry( - '@ohif/extension-cornerstone.viewportModule.cornerstone' - ); - return ( - - ); - }; - - return ( - <> - -
- {renderViewport()} -
- - ); -} -``` - -![viewportModule](../../../assets/img/viewportModule.png) - -### `@ohif/viewer` - -Viewport components are managed by the `ViewportGrid` Component. Which Viewport -component is used depends on: - -- Hanging Protocols -- The Layout Configuration -- Registered SopClassHandlers - -![viewportModule-layout](../../../assets/img/viewportModule-layout.png) - -
An example of three cornerstone Viewports
diff --git a/platform/docs/versioned_docs/version-3.0/platform/internationalization.md b/platform/docs/versioned_docs/version-3.0/platform/internationalization.md deleted file mode 100644 index 1bb32de5ba5..00000000000 --- a/platform/docs/versioned_docs/version-3.0/platform/internationalization.md +++ /dev/null @@ -1,396 +0,0 @@ ---- -sidebar_position: 4 -sidebar_label: Internationalization ---- - -# Viewer: Internationalization - -OHIF supports internationalization using [i18next](https://www.i18next.com/) -through the npm package [@ohif/i18n](https://www.npmjs.com/package/@ohif/i18n), -where is the main instance of i18n containing several languages and tools. - -
-

Our translation management is powered by - Locize - through their generous support of open source.

- - Locize Translation Management Logo - -
- -## How to change language for the viewer? - -You can take a look into user manuals to see how to change the viewer's -language. In summary, you can change the language: - -- In the preference modals -- Using the language query in the URL: `lng=Test-LNG` - -## Installing - -```bash -yarn add @ohif/i18n - -# OR - -npm install --save @ohif/i18n -``` - -## How it works - -After installing `@ohif/i18n` npm package, the translation function -[t](https://www.i18next.com/overview/api#t) can be used [with](#with-react) or -[without](#without-react) React. - -A translation will occur every time a text match happens in a -[t](https://www.i18next.com/overview/api#t) function. - -The [t](https://www.i18next.com/overview/api#t) function is responsible for -getting translations using all the power of i18next. - -E.g. - -Before: - -```html -
my translated text
-``` - -After: - -```html -
{t('my translated text')}
-``` - -If the translation.json file contains a key that matches the HTML content e.g. -`my translated text`, it will be replaced automatically by the -[t](https://www.i18next.com/overview/api#t) function. - ---- - -### With React - -This section will introduce you to [react-i18next](https://react.i18next.com/) -basics and show how to implement the [t](https://www.i18next.com/overview/api#t) -function easily. - -#### Using Hooks - -You can use `useTranslation` hooks that is provided by `react-i18next` - -You can read more about this -[here](https://react.i18next.com/latest/usetranslation-hook). - -```js -import React from 'react'; -import { useTranslation } from 'react-i18next'; - -function MyComponent() { - const { t } = useTranslation(); - - return

{t('my translated text')}

; -} -``` - -### Using outside of OHIF viewer - -OHIF Viewer already sets a main -[I18nextProvider](https://react.i18next.com/latest/i18nextprovider) connected to -the shared i18n instance from `@ohif/i18n`, all extensions inside OHIF Viewer -will share this same provider at the end, you don't need to set new providers at -all. - -But, if you need to use it completely outside of OHIF viewer, you can set the -I18nextProvider this way: - -```jsx -import i18n from '@ohif/i18n'; -import { I18nextProvider } from 'react-i18next'; -import App from './App'; - - - -; -``` - -After setting `I18nextProvider` in your React App, all translations from -`@ohif/i18n` should be available following the basic [With React](#with-react) -usage. - ---- - -### Without React - -When needed, you can also use available translations _without React_. - -E.g. - -```js -import { T } from '@ohif/i18n'; -console.log(T('my translated text')); -console.log(T('$t(Common:Play) my translated text')); -``` - ---- - -## Main Concepts While Translating - -## Namespaces - -Namespaces are being used to organize translations in smaller portions, combined -semantically or by use. Each `.json` file inside `@ohif/i18n` npm package -becomes a new namespace automatically. - -- Buttons: All buttons translations -- CineDialog: Translations for the tool tips inside the Cine Player Dialog -- Common: all common jargons that can be reused like `t('$t(common:image)')` -- Header: translations related to OHIF's Header Top Bar -- MeasurementTable - Translations for the `@ohif/ui` Measurement Table -- UserPreferencesModal - Translations for the `@ohif/ui` Preferences Modal -- Modals - Translations available for other modals -- PatientInfo - Translations for patients info hover -- SidePanel - Translations for side panels -- ToolTip - Translations for tool tips - -### How to use another NameSpace inside the current NameSpace? - -i18next provides a parsing feature able to get translations strings from any -NameSpace, like this following example getting data from `Common` NameSpace: - -``` -$t('Common:Reset') -``` - -## Extending Languages in @ohif/i18n - -Sometimes, even using the same language, some nouns or jargons can change -according to the country, states or even from Hospital to Hospital. - -In this cases, you don't need to set an entire language again, you can extend -languages creating a new folder inside a pre existent language folder and -@ohif/i18n will do the hard work. - -This new folder must to be called with a double character name, like the `UK` in -the following file tree: - -```bash - |-- src - |-- locales - index.js - |-- en - |-- Buttons.json - index.js - | UK - |-- Buttons.js - indes.js - | US - |-- Buttons.js - index.js - ... -``` - -All properties inside a Namespace will be merged in the new sub language, e.g -`en-US` and `en-UK` will merge the props with `en`, using i18next's fallback -languages tool. - -You will need to export all Json files in your `index.js` file, mounting an -object like this: - -```js - { - en: { - NameSpace: { - keyWord1: 'keyWord1Translation', - keyWord2: 'keyWord2Translation', - keyWord3: 'keyWord3Translation', - } - }, - 'en-UK': { - NameSpace: { - keyWord1: 'keyWord1DifferentTranslation', - } - } - } -``` - -Please check the `index.js` files inside locales folder for an example of this -exporting structure. - -### Extending languages dynamically - -You have access to the i18next instance, so you can use the -[addResourceBundle](https://www.i18next.com/how-to/add-or-load-translations#add-after-init) -method to add and change language resources as needed. - -E.g. - -```js -import { i18n } from '@ohif/i18n'; -i18next.addResourceBundle('pt-BR', 'Buttons', { - Angle: 'Γ‚ngulo', -}); -``` - ---- - -### How to set a whole new language - -To set a brand new language you can do it in two different ways: - -- Opening a pull request for `@ohif/i18n` and sharing the translation with the - community. 😍 Please see [Contributing](#contributing-with-new-languages) - section for further information. - -- Setting it only in your project or extension: - -You'll need a final object like the following, what is setting French as -language, and send it to `addLocales` method. - -```js -const newLanguage = - { - fr: { - Commons: { - "Reset": "RΓ©initialiser", - "Previous": "PrΓ©cΓ©dent", - }, - Buttons: { - "Rectangle": "Rectangle", - "Circle": "Cercle", - } - } -``` - -To make it easier to translate, you can copy the .json files in the /locales -folder and theirs index.js exporters, keeping same keys and NameSpaces. -Importing the main index.js file, will provide you an Object as expected by the -method `addlocales`; - -E.g. of `addLocales` usage - -```js -import { addLocales } from '@ohif/i18n'; -import locales from './locales/index.js'; -addLocales(locales); -``` - -You can also set them manually, one by one, using this -[method](#extending-languages-dynamically). - ---- - -## Test Language - -We have created a test language that its translations can be seen in the locales -folder. You can copy paste the folder and its `.json` namespaces and add your -custom language translations. - -> If you apply the test-LNG you can see all the elements get appended with 'Test -> {}'. For instance `Study list` becomes `Test Study list`. - -## Language Detections - -@ohif/i18n uses -[i18next-browser-languageDetector](https://github.com/i18next/i18next-browser-languageDetector) -to manage detections, also exports a method called initI18n that accepts a new -detector config as parameter. - -### Changing the language - -OHIF Viewer accepts a query param called `lng` in the url to change the -language. - -E.g. - -``` -https://docs.ohif.org/demo/?lng=es-MX -``` - -### Language Persistence - -The user's language preference is kept automatically by the detector and stored -at a cookie called 'i18next', and in a localstorage key called 'i18nextLng'. -These names can be changed with a new -[Detector Config](https://github.com/i18next/i18next-browser-languageDetector). - -## Debugging translations - -There is an environment variable responsible for debugging the translations, -called `REACT_APP_I18N_DEBUG`. - -Run the project as following to get full debug information: - -```bash -REACT_APP_I18N_DEBUG=true yarn run dev -``` - -## Contributing with new languages - -We have integrated `i18next` into the OHIF Viewer and hooked it up with Locize -for translation management. Now we need your help to get the app translated into -as many languages as possible, and ensure that we haven't missed pieces of the -app that need translation. Locize has graciously offered to provide us with free -usage of their product. - -Once each crowd-sourcing project is completed, we can approve it and merge the -changes into the main project. At that point, the language will be immediately -available on https://viewer.ohif.org/ for testing, and can be used in any OHIF -project. We will support usage through both the Locize CDN and by copying the -language directly into the `@ohif/i18n` package, so that end users can serve the -content from their own domains. - -Here are a couple examples: - -Spanish: -https://viewer.ohif.org/viewer/1.2.840.113619.2.5.1762583153.215519.978957063.78?lng=es - -Chinese: -https://viewer.ohif.org/viewer/1.2.840.113619.2.5.1762583153.215519.978957063.78?lng=zh - -Portugese: -https://viewer.ohif.org/viewer/1.2.840.113619.2.5.1762583153.215519.978957063.78?lng=pt-BR - -Here are some links you can use to sign up to help translate. All you have to do -is sign up, translate the strings, and click Save. On our side, we have a -dashboard to see how many strings are translated and by whom. - -This is a pretty random set of languages, so please post below if you'd like a -new language link to be added: - -Languages: - -[French](https://www.locize.io/register?invitation=Nj8jRPaFKYwtIfNZ6Y5GVOJOpeiXNAdVuSiOg9ceaiveP6uF6y1wVXM9lgfKoYZX) - -[German](https://www.locize.io/register?invitation=gChNiVi66YINTPpbKESVAVYPapwg3DkpvMSSomLTvVqBJTXrdmPvxi0WZYHER11q) - -[Dutch](https://www.locize.io/register?invitation=2PGe7I184aN0cazM4GXMhzeLtGTf9Zen5uyOEFhHQ8vYkfKHkgR0mJ8dwbNlIeCG) - -[Turkish](https://www.locize.io/register?invitation=NOMIXsfneqPbFDqjce5wI7Z6p2swXSjc0rHOH4KLcM6qXSNA4LGyJaLxS7nqWAe3) - -[Chinese](https://www.locize.io/register?invitation=lrcUbt7DvV4aJmQeEA4SMAj5xNWr3rltOcaZW1cFc6eod0nvzSPFU4V383tDHGGn) - -[Japanese](https://www.locize.io/register?invitation=AaRq2S22o5FsxArwgVuw1gZcQjoe2ffyxarqlAXOpN7JnR2sf2mfamc5qV6LG1Mn) - -[Arabic](https://www.locize.io/register?invitation=BiqI6fOm1sC84N3YJLbImXmaOCk8Hc3TMGpXg7NH2R0b0OKuPCp9wlCHLoqMRpfQ) - -[Hindi](https://www.locize.io/register?invitation=ph7JmOGTV95DF3EFaI1kvK5Hx98dV9w2wj9h9UhUCWnkBNAwWEdWMcyjnF94zkWb) - -[Malay](https://www.locize.io/register?invitation=HsV9F5mKZyeUZYrC3XFRzNI2l0EsIh6hK0MUIKP8IYZA3GxuzfgkvWBLCFwCpDik) - -[Russian](https://www.locize.io/register?invitation=da4V9Q8DVO3M1FIlvfT50ZiS8NDNgvC0dE5hHUEAp47FXy6pLXmf1cp2lgLBfLmb) - -[Swedish](https://www.locize.io/register?invitation=uR4kzBZC1vhJe6jyMwYXgGPj84QDMulQRlt2s6rONU6ljUh5dgwuUyhJEtZ4REA3) - -[Italian](https://www.locize.io/register?invitation=viAS1NC5q342OxtuIv3JFX9DJ3KoR4SmGoElkBlRMphsDKt4hy9bW8JfBjHlfnd7) - -[Spanish](https://www.locize.io/register?invitation=ZikXW3KI4w4eo5Cf6L1aQMWaR69XAQ0a9Va3NGorH7mAPvEPXp8w8NLkPNLs5nG8) - -[Ukrainian](https://www.locize.io/register?invitation=TY0s6onqH3Asl05Bh1qB44SNSABL2pTYoturwxAmcNKRnzBZFK7bGfn7kVi23Vpg) - -[Vietnamese](https://www.locize.io/register?invitation=eqfHDm0vaqxGfQ5TGt6SeV0dx9b2dCp1RrMRdIRavqzOCOAfD3IElzUsyIT689cK) - -[Portugese-Brazil](https://www.locize.io/register?invitation=Qc5Dq449xbblQqLTpWeMfsyFiu3gACcgpj0EIucQjjs9Ph9pzPLpq3MnZupF9t6N) - -Don't see your language in the above list? Add a request -[here](https://github.com/OHIF/Viewers/issues/618) so that we can create the -language for your translation contribution. diff --git a/platform/docs/versioned_docs/version-3.0/platform/managers/_category_.json b/platform/docs/versioned_docs/version-3.0/platform/managers/_category_.json deleted file mode 100644 index 30940779278..00000000000 --- a/platform/docs/versioned_docs/version-3.0/platform/managers/_category_.json +++ /dev/null @@ -1,4 +0,0 @@ -{ - "label": "Managers", - "position": 11 -} diff --git a/platform/docs/versioned_docs/version-3.0/platform/managers/commands.md b/platform/docs/versioned_docs/version-3.0/platform/managers/commands.md deleted file mode 100644 index fab666dacad..00000000000 --- a/platform/docs/versioned_docs/version-3.0/platform/managers/commands.md +++ /dev/null @@ -1,180 +0,0 @@ ---- -sidebar_position: 4 -sidebar_label: Commands Manager ---- -# Commands Manager - -## Overview - - -The `CommandsManager` is a class defined in the `@ohif/core` project. The Commands Manager tracks named commands (or functions) that are scoped to -a context. When we attempt to run a command with a given name, we look for it -in our active contexts. If found, we run the command, passing in any application -or call specific data specified in the command's definition. - -> Note: A single instance of `CommandsManager` should be defined in the consuming application, and it is used when constructing the `ExtensionManager`. - -A `simplified skeleton` of the `CommandsManager` is shown below: - -```js -export class CommandsManager { - constructor({ getActiveContexts } = {}) { - this.contexts = {}; - this._getActiveContexts = getActiveContexts; - } - - getContext(contextName) { - const context = this.contexts[contextName]; - return context; - } - - /**...**/ - - createContext(contextName) { - /** ... **/ - this.contexts[contextName] = {}; - } - - - registerCommand(contextName, commandName, definition) { - /**...**/ - const context = this.getContext(contextName); - /**...**/ - context[commandName] = definition; - } - - runCommand(commandName, options = {}, contextName) { - const definition = this.getCommand(commandName, contextName); - /**...**/ - const { commandFn } = definition; - const commandParams = Object.assign( - {}, - definition.options, // "Command configuration" - options // "Time of call" info - ); - /**...**/ - return commandFn(commandParams); - } - /**...**/ -} -``` - - - - -### Instantiating - -When we instantiate the `CommandsManager`, we are passing two methods: - -- `getAppState` - Should return the application's state when called (Not implemented in `v3`) -- `getActiveContexts` - Should return the application's active contexts when - called - -These methods are used internally to help determine which commands are currently -valid, and how to provide them with any state they may need at the time they are -called. - -```js title="platform/viewer/src/appInit.js" -const commandsManagerConfig = { - getAppState: () => {}, - /** Used by commands to determine active context */ - getActiveContexts: () => [ - 'VIEWER', - 'DEFAULT', - 'ACTIVE_VIEWPORT::CORNERSTONE', - ], -}; - -const commandsManager = new CommandsManager(commandsManagerConfig); -``` - - -## Commands/Context Registration -The `ExtensionManager` handles registering commands and creating contexts, so you don't need to register all your commands manually. Simply, create a `commandsModule` in your extension, and it will get automatically registered in the `context` provided. - -A *simplified version* of this registration is shown below to give an idea about the process. - - -```js -export default class ExtensionManager { - constructor({ commandsManager }) { - this._commandsManager = commandsManager - } - /** ... **/ - registerExtension = (extension, configuration = {}, dataSources = []) => { - let extensionId = extension.id - /** ... **/ - - // Register Modules provided by the extension - moduleTypeNames.forEach((moduleType) => { - const extensionModule = this._getExtensionModule( - moduleType, - extension, - extensionId, - configuration - ) - - if (moduleType === 'commandsModule') { - this._initCommandsModule(extensionModule) - } - /** registering other modules **/ - }) - } - - _initCommandsModule = (extensionModule) => { - let { definitions, defaultContext } = extensionModule - defaultContext = defaultContext || 'VIEWER' - - if (!this._commandsManager.getContext(defaultContext)) { - this._commandsManager.createContext(defaultContext) - } - - Object.keys(definitions).forEach((commandName) => { - const commandDefinition = definitions[commandName] - const commandHasContextThatDoesNotExist = - commandDefinition.context && - !this._commandsManager.getContext(commandDefinition.context) - - if (commandHasContextThatDoesNotExist) { - this._commandsManager.createContext(commandDefinition.context) - } - - this._commandsManager.registerCommand( - commandDefinition.context || defaultContext, - commandName, - commandDefinition - ) - }) - } -} - -``` - - -If you find yourself in a situation where you want to register a command/context manually, ask -yourself "why can't I register these commands via an extension?", but if you insist, you can use the `CommandsManager` API to do so: - -```js -// Command Registration -commandsManager.registerCommand('context', 'name', commandDefinition); - -// Context Creation -commandsManager.createContext('string'); -``` - -## `CommandsManager` Public API - -If you would like to run a command in the consuming app or an extension, you can -use `runCommand(commandName, options = {}, contextName)`. - - -```js -// Run a command, it will run all the `speak` commands in all contexts -commandsManager.runCommand('speak', { command: 'hello' }); - -// Run command, from Default context -commandsManager.runCommand('speak', { command: 'hello' }, ['DEFAULT']); - -// Returns all commands for a given context -commandsManager.getContext('string'); -``` diff --git a/platform/docs/versioned_docs/version-3.0/platform/managers/extension.md b/platform/docs/versioned_docs/version-3.0/platform/managers/extension.md deleted file mode 100644 index 9fb5196f840..00000000000 --- a/platform/docs/versioned_docs/version-3.0/platform/managers/extension.md +++ /dev/null @@ -1,55 +0,0 @@ ---- -sidebar_position: 2 -sidebar_label: Extension Manager ---- - -# Extension Manager - -## Overview - -The `ExtensionManager` is a class made available to us via the `@ohif/core` -project (platform/core). Our application instantiates a single instance of it, -and provides a `ServicesManager` and `CommandsManager` along with the -application's configuration through the appConfig key (optional). - -```js -const commandsManager = new CommandsManager(); -const servicesManager = new ServicesManager(); -const extensionManager = new ExtensionManager({ - commandsManager, - servicesManager, - appConfig, -}); -``` - -The `ExtensionManager` only has a few public members: - -- `setActiveDataSource` - Sets the active data source for the application -- `getDataSources` - Returns the registered data sources -- `getActiveDataSource` - Returns the currently active data source -- `getModuleEntry` - Returns the module entry by the give id. - -## Accessing Modules - -We use `getModuleEntry` in our `ViewerLayout` logic to find the panels based on -the provided IDs in the mode's configuration. - -For instance: -`extensionManager.getModuleEntry("@ohif/extension-measurement-tracking.panelModule.seriesList")` -accesses the `seriesList` panel from `panelModule` of the -`@ohif/extension-measurement-tracking` extension. - -```js -const getPanelData = id => { - const entry = extensionManager.getModuleEntry(id); - const content = entry.component; - - return { - iconName: entry.iconName, - iconLabel: entry.iconLabel, - label: entry.label, - name: entry.name, - content, - }; -}; -``` diff --git a/platform/docs/versioned_docs/version-3.0/platform/managers/hotkeys.md b/platform/docs/versioned_docs/version-3.0/platform/managers/hotkeys.md deleted file mode 100644 index ebdd2bd1334..00000000000 --- a/platform/docs/versioned_docs/version-3.0/platform/managers/hotkeys.md +++ /dev/null @@ -1,79 +0,0 @@ ---- -sidebar_position: 5 -sidebar_label: Hotkeys Manager ---- -# Hotkeys Managers - -## Overview -`HotkeysManager` handles all the logics for adding, setting and enabling/disabling -the hotkeys. - - - -## Instantiation -`HotkeysManager` is instantiated in the `appInit` similar to the other managers. - -```js -const commandsManager = new CommandsManager(commandsManagerConfig); -const servicesManager = new ServicesManager(commandsManager); -const hotkeysManager = new HotkeysManager(commandsManager, servicesManager); -const extensionManager = new ExtensionManager({ - commandsManager, - servicesManager, - hotkeysManager, - appConfig, -}); -``` - - - - -## Hotkeys Manager API - -- `setHotkeys`: The most important method in the `HotkeysManager` which binds the keys with commands. -- `setDefaultHotKeys`: set the defaultHotkeys **property**. Note that, this method **does not** bind the provided hotkeys; however, when `restoreDefaultBindings` -is called, the provided defaultHotkeys will get bound. -- `destroy`: reset the HotkeysManager, and remove the set hotkeys and empty out the `defaultHotkeys` - - - -## Structure of a Hotkey Definition -A hotkey definition should have the following properties: - -- `commandName`: name of the registered command -- `commandOptions`: extra arguments to the commands -- `keys`: an array defining the key to get bound to the command -- `label`: label to be shown in the hotkeys preference panel -- `isEditable`: whether the key can be edited by the user in the hotkey panel - - -### Default hotkeysBindings -The default key bindings can be find in `hotkeyBindings.js` - -```js -// platform/core/src/defaults/hotkeyBindings.js - -export default [ - /**..**/ - { - commandName: 'setToolActive', - commandOptions: { toolName: 'Zoom' }, - label: 'Zoom', - keys: ['z'], - isEditable: true, - }, - - { - commandName: 'flipViewportHorizontal', - label: 'Flip Vertically', - keys: ['v'], - isEditable: true, - }, - /**..**/ -] -``` - - -## Behind the Scene -When you `setHotkeys`, the `commandName` gets registered with the `commandsManager` and -get run after the key is pressed. diff --git a/platform/docs/versioned_docs/version-3.0/platform/managers/index.md b/platform/docs/versioned_docs/version-3.0/platform/managers/index.md deleted file mode 100644 index ee6d6b2fc8c..00000000000 --- a/platform/docs/versioned_docs/version-3.0/platform/managers/index.md +++ /dev/null @@ -1,76 +0,0 @@ ---- -sidebar_position: 1 -sidebar_label: Introduction ---- - -# Managers - -## Overview - -`OHIF` uses `Managers` to accomplish various purposes such as registering new -services, dependency injection, and aggregating and exposing `extension` -features. - -`OHIF-v3` provides the following managers which we will discuss in depth. - - - - - - - - - - - - - - - - - - - - - - - - - - -
ManagerDescription
- - 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 - diff --git a/platform/docs/versioned_docs/version-3.0/platform/managers/service.md b/platform/docs/versioned_docs/version-3.0/platform/managers/service.md deleted file mode 100644 index 2cacda412e8..00000000000 --- a/platform/docs/versioned_docs/version-3.0/platform/managers/service.md +++ /dev/null @@ -1,162 +0,0 @@ ---- -sidebar_position: 3 -sidebar_label: Service Manager ---- - -# 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/viewer/src/appInit.js" -servicesManager.registerServices([ - 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 - -## 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" -import backEndService from './backEndService'; - -export default function WrappedBackEndService(serviceManager) { - return { - name: 'myService', - create: ({ configuration = {} }) => { - return new backEndService(serviceManager); - }, - }; -} -``` - -with implementation of - -```js -export default class backEndService { - constructor(serviceManager) { - this.serviceManager = serviceManager; - } - - putAnnotations() { - return post(/*...*/); - } -} -``` diff --git a/platform/docs/versioned_docs/version-3.0/platform/modes/_category_.json b/platform/docs/versioned_docs/version-3.0/platform/modes/_category_.json deleted file mode 100644 index 80702b9e54e..00000000000 --- a/platform/docs/versioned_docs/version-3.0/platform/modes/_category_.json +++ /dev/null @@ -1,4 +0,0 @@ -{ - "label": "Modes", - "position": 10 -} diff --git a/platform/docs/versioned_docs/version-3.0/platform/modes/index.md b/platform/docs/versioned_docs/version-3.0/platform/modes/index.md deleted file mode 100644 index b01049b0f19..00000000000 --- a/platform/docs/versioned_docs/version-3.0/platform/modes/index.md +++ /dev/null @@ -1,383 +0,0 @@ ---- -sidebar_position: 1 -sidebar_label: Introduction ---- - -# 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: - -![mode-archs](../../assets/img/mode-archs.png) - -> 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. - -![user-study-summary](../../assets/img/user-study-summary.png) - -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; -``` - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
PropertyDescription
- 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 re-usable 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 ( - - ); - }; - - return [ - { - name: 'AIPanel', - iconName: 'list-bullets', - iconLabel: '', - label: 'AI Panel', - isDisabled: studies => {}, // optional - component: wrappedAIPanel, - }, - ]; -} -``` - -Now, let's look at a simplified code of the `basic viewer` mode which consumes various functionalities -from different extensions. - -```js - -const extensionDependencies = { - '@ohif/extension-default': '^3.0.0', - '@ohif/extension-cornerstone': '^3.0.0', - '@ohif/extension-measurement-tracking': '^3.0.0', -}; - -const id = 'viewer'; -const version = '3.0.0'; - -function modeFactory({ modeConfiguration }) { - return { - id, - // ... - routes: [ - { - // ... - layoutTemplate: ({ location, servicesManager }) => { - return { - id: ohif.layout, - props: { - leftPanels: ['@ohif/extension-measurement-tracking.panelModule.seriesList'], - rightPanels: ['@ohif/extension-measurement-tracking.panelModule.trackedMeasurements'], - viewports: [ - { - namespace: '@ohif/extension-measurement-tracking.viewportModule.cornerstone-tracked', - displaySetsToDisplay: ['@ohif/extension-default.sopClassHandlerModule.stack'], - }, - ], - }, - }; - }, - }, - ], - extensions: extensionDependencies, - hangingProtocol: ['@ohif/extension-default.hangingProtocolModule.petCT'], - sopClassHandlers: ['@ohif/extension-default.sopClassHandlerModule.stack'], - // ... - }; -} - -const mode = { - id, - modeFactory, - extensionDependencies, -} - -export default mode -``` - -### Routes - -routes config is an array of route settings, and the overall look and behavior -of the viewer at the designated route is defined by the `layoutTemplate` and -`init` functions for the route. We will learn more about each of the above -properties inside the [route documentation](./routes.md) - - -### HangingProtocols - -Currently, you can pass your defined hanging protocols inside the -`hangingProtocols` property of the mode's config. This will get registered -inside `HangingProtocolService`. - -### SopClassHandlers - -Mode's configuration also accepts the `sopClassHandler` modules that have been -added by the extensions. This information will get used to initialize `DisplaySetService` with the provided SOPClass modules which -handles creation of the displaySets. - - -### Hotkeys - -`hotkeys` is another property in the configuration of a mode that can be defined -to add the specific hotkeys to the viewer at all routes. - -```js -// default hotkeys -import { utils } from '@ohif/ui'; - -const { hotkeys } = utils; - -const myHotkeys = [ - { - commandName: 'setToolActive', - commandOptions: { toolName: 'Zoom' }, - label: 'Zoom', - keys: ['z'], - isEditable: true, - }, - { - commandName: 'scaleUpViewport', - label: 'Zoom In', - keys: ['+'], - isEditable: true, - }, -] - -function modeFactory() { - return { - id: '', - id: '', - displayName: '', - /* - ... - */ - hotkeys: [..hotkeys.defaults.hotkeyBindings, ...myHotkeys], - } -} - -// exports -``` - -## Registration - -Similar to extension registration, `viewer` will look inside the `pluginConfig.json` to -find the `modes` to register. - - -```js title=platform/viewer/pluginConfig.json -// Simplified version of the `pluginConfig.json` file -{ - "extensions": [ - { - "packageName": "@ohif/extension-cornerstone", - "version": "3.0.0" - }, - // ... - ], - "modes": [ - { - "packageName": "@ohif/mode-longitudinal", - "version": "0.0.1" - } - ] -} -``` - -:::note Important -You SHOULD NOT directly register modes in the `pluginConfig.json` file. -Use the provided `cli` to add/remove/install/uninstall modes. Read more [here](../../development/ohif-cli.md) -::: - -The final registration and import of the modes happen inside a non-tracked file `pluginImport.js` (this file is also for internal use only). diff --git a/platform/docs/versioned_docs/version-3.0/platform/modes/installation.md b/platform/docs/versioned_docs/version-3.0/platform/modes/installation.md deleted file mode 100644 index 08c456d29e1..00000000000 --- a/platform/docs/versioned_docs/version-3.0/platform/modes/installation.md +++ /dev/null @@ -1,12 +0,0 @@ ---- -sidebar_position: 5 -sidebar_label: Installation ---- - -# Modes: Installation - -OHIF-v3 provides the ability to utilize external modes. - - -You can use ohif `cli` tool to install both local and publicly published -modes on NPM. You can read more [here](../../development/ohif-cli.md) diff --git a/platform/docs/versioned_docs/version-3.0/platform/modes/lifecycle.md b/platform/docs/versioned_docs/version-3.0/platform/modes/lifecycle.md deleted file mode 100644 index 32ea77cb352..00000000000 --- a/platform/docs/versioned_docs/version-3.0/platform/modes/lifecycle.md +++ /dev/null @@ -1,86 +0,0 @@ ---- -sidebar_position: 2 -sidebar_label: Lifecycle Hooks ---- - -# Modes: Lifecycle Hooks - -## Overview - -Currently, there are two hooks that are called for modes: - -- onModeEnter -- onModeExit - -## onModeEnter - -This hook gets run after the defined route has been entered by the mode. This -hook can be used to initialize the data, services and appearance of the viewer -upon the first render. - -For instance, in `longitudinal` mode we are using this hook to initialize the -`ToolBarService` and set the window level/width tool to be active and add -buttons to the toolbar. - -```js -function modeFactory() { - return { - id: '', - version: '', - displayName: '', - onModeEnter: ({ servicesManager, extensionManager }) => { - const { ToolBarService } = servicesManager.services; - - const interaction = { - groupId: 'primary', - itemId: 'WindowLevel', - interactionType: 'tool', - commandOptions: undefined, - }; - - ToolBarService.recordInteraction(interaction); - - ToolBarService.init(extensionManager); - ToolBarService.addButtons(toolbarButtons); - ToolBarService.createButtonSection('primary', [ - 'MeasurementTools', - 'Zoom', - 'WindowLevel', - 'Pan', - 'Capture', - 'Layout', - 'MoreTools', - ]); - }, - /* - ... - */ - }; -} -``` - -## onModeExit - -This hook is called when the viewer navigate away from the route in the url. -This is the place for cleaning up data, and services by unsubscribing to the -events. - -For instance, it can be used to reset the `ToolBarService` which reset the -toggled buttons. - -```js -function modeFactory() { - return { - id: '', - displayName: '', - onModeExit: ({ servicesManager, extensionManager }) => { - // Turn of the toggled states on exit - const { ToolBarService } = servicesManager.services; - ToolBarService.reset(); - }, - /* - ... - */ - }; -} -``` diff --git a/platform/docs/versioned_docs/version-3.0/platform/modes/routes.md b/platform/docs/versioned_docs/version-3.0/platform/modes/routes.md deleted file mode 100644 index 2204bd77ae7..00000000000 --- a/platform/docs/versioned_docs/version-3.0/platform/modes/routes.md +++ /dev/null @@ -1,315 +0,0 @@ ---- -sidebar_position: 3 -sidebar_label: Routes ---- - -# Mode: Routes - -## Overview - -Modes are tied to a specific route in the viewer, and multiple modes/routes can -be present within a single application. This makes `routes` config, THE most -important part of the mode configuration. - -## Route - -`@ohif/viewer` **compose** extensions to build applications on different routes -for the platform. - -Below, you can see a simplified version of the `longitudinal` mode and the -`routes` section which has defined one `route`. Each route has three different -configuration: - -- **route path**: defines the route path to access the built application for - that route -- **route init**: hook that runs when application enters the defined route path, - if not defined the default init function will run for the mode. -- **route layout**: defines the layout of the application for the specified - route (panels, viewports) - -```js -function modeFactory() { - return { - id: 'viewer', - version: '3.0.0', - displayName: '', - routes: [ - { - path: 'longitudinal', - /*init: ({ servicesManager, extensionManager }) => { - //defaultViewerRouteInit - },*/ - layoutTemplate: ({ location, servicesManager }) => { - return { - id: ohif.layout, - props: { - leftPanels: [ - '@ohif/extension-measurement-tracking.panelModule.seriesList', - ], - rightPanels: [ - '@ohif/extension-measurement-tracking.panelModule.trackedMeasurements', - ], - viewports: [ - { - namespace: - '@ohif/extension-measurement-tracking.viewportModule.cornerstone-tracked', - displaySetsToDisplay: [ - '@ohif/extension-default.sopClassHandlerModule.stack', - ], - }, - { - namespace: '@ohif/extension-cornerstone-dicom-sr.viewportModule.dicom-sr', - displaySetsToDisplay: [ - '@ohif/extension-cornerstone-dicom-sr.sopClassHandlerModule.dicom-sr', - ], - }, - ], - }, - }; - }, - }, - ], - /* - ... - */ - }; -} -``` - -### Route: path - -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. - -> Note: Currently, only one route is built for each mode, but we will enhance -> route creation to create separate routes based on the `path` config for each -> `route` object. - -There are two types of `routes` that are created by the mode. - -- Routes with dataSourceName `/${mode.id}/${dataSourceName}` -- Routes without dataSourceName `/${mode.id}` - -Therefore, navigating to -`http://localhost:3000/viewer/?StudyInstanceUIDs=1.3.6.1.4.1.25403.345050719074.3824.20170125113417.1` -will run the app with the layout and functionalities of the `viewer` mode using -the `defaultDataSourceName` which is defined in the -[App Config](../../configuration/index.md) - -You can use the same exact mode using a different registered data source (e.g., -`dicomjson`) by navigating to -`http://localhost:3000/viewer/dicomjson/?StudyInstanceUIDs=1.3.6.1.4.1.25403.345050719074.3824.20170125113417.1` - -### Route: init - -The mode also has an init hook, which initializes the mode. If you don't define -an `init` function the `default init` function will get run (logic is located -inside `Mode.jsx`). However, you can define you own init function following -certain steps which we will discuss next. - -#### Default init - -Default init function will: - -- `retriveSeriesMetaData` for the `studyInstanceUIDs` that are defined in the - URL. -- Subscribe to `instanceAdded` event, to make display sets after a series have - finished retrieving its instances' metadata. -- Subscribe to `seriesAdded` event, to run the `HangingProtocolService` on the - retrieves series from the study. - -A _simplified_ "pseudocode" for the `defaultRouteInit` is: - -```jsx -async function defaultRouteInit({ - servicesManager, - studyInstanceUIDs, - dataSource, -}) { - const { - DisplaySetService, - HangingProtocolService, - } = servicesManager.services; - - // subscribe to run the function after the event happens - DicomMetadataStore.subscribe( - 'instancesAdded', - ({ StudyInstanceUID, SeriesInstanceUID }) => { - const seriesMetadata = DicomMetadataStore.getSeries( - StudyInstanceUID, - SeriesInstanceUID - ); - DisplaySetService.makeDisplaySets(seriesMetadata.instances); - } - ); - - studyInstanceUIDs.forEach(StudyInstanceUID => { - dataSource.retrieve.series.metadata({ StudyInstanceUID }); - }); - - DicomMetadataStore.subscribe('seriesAdded', ({ StudyInstanceUID }) => { - const studyMetadata = DicomMetadataStore.getStudy(StudyInstanceUID); - HangingProtocolService.run(studyMetadata); - }); - - return unsubscriptions; -} -``` - -#### Writing a custom init - -You can add your custom init function to enhance the default initialization for: - -- Fetching annotations from a server for the current study -- Changing the initial image index of the series to be displayed at first -- Caching the next study in the work list -- Adding a custom sort for the series to be displayed on the study browser panel - -and lots of other modifications. - -You just need to make sure, the mode `dataSource.retrieve.series.metadata`, -`makeDisplaySets` and `run` the HangingProtocols at some point. There are -various `events` that you can subscribe to and add your custom logic. **point to -events** - -For instance for jumping to the slice where a measurement is located at the -initial render, you need to follow a pattern similar to the following: - -```jsx -init: async ({ - servicesManager, - extensionManager, - hotkeysManager, - dataSource, - studyInstanceUIDs, -}) => { - const { DisplaySetService } = servicesManager.services; - - /** - ... - **/ - - const onDisplaySetsAdded = ({ displaySetsAdded, options }) => { - const displaySet = displaySetsAdded[0]; - const { SeriesInstanceUID } = displaySet; - - const toolData = myServer.fetchMeasurements(SeriesInstanceUID); - - if (!toolData.length) { - return; - } - - toolData.forEach(tool => { - const instance = displaySet.images.find( - image => image.SOPInstanceUID === tool.SOPInstanceUID - ); - }); - - MeasurementService.addMeasurement(/**...**/); - }; - - // subscription to the DISPLAY_SETS_ADDED - const { unsubscribe } = DisplaySetService.subscribe( - DisplaySetService.EVENTS.DISPLAY_SETS_ADDED, - onDisplaySetsAdded - ); - - /** - ... - **/ - - return unsubscriptions; -}; -``` - -### Route: layoutTemplate - -`layoutTemplate` is the last configuration for a certain route in a `mode`. -`layoutTemplate` is a function that returns an object that configures the -overall layout of the application. The returned object has two properties: - -- `id`: the id of the `layoutTemplate` being used (it should have been - registered via an extension) -- `props`: the required properties to be passed to the `layoutTemplate`. - -For instance `default extension` provides a layoutTemplate that builds the app -using left/right panels and viewports. Therefore, the `props` include -`leftPanels`, `rightPanels` and `viewports` sections. Note that the -`layoutTemplate` defines the properties it is expecting. So, if you write a -`layoutTemplate-2` that accepts a footer section, its logic should be written in -the extension, and any mode that is interested in using `layoutTemplate-2` -**should** provide the `id` for the footer component. - -**What module should the footer be registered?** - -```js -/* -... -*/ -layoutTemplate: ({ location, servicesManager }) => { - return { - id: '@ohif/extension-default.layoutTemplateModule.viewerLayout', - props: { - leftPanels: [ - 'myExtension.panelModule.leftPanel1', - 'myExtension.panelModule.leftPanel2', - ], - rightPanels: ['myExtension.panelModule.rightPanel'], - viewports: [ - { - namespace: 'myExtension.viewportModule.viewport1', - displaySetsToDisplay: ['myExtension.sopClassHandlerModule.sop1'], - }, - { - namespace: 'myExtension.viewportModule.viewport2', - displaySetsToDisplay: ['myExtension.sopClassHandlerModule.sop2'], - }, - ], - }, - }; -}; -/* -... -*/ -``` - -## FAQ - -> What is the difference between `onModeEnter` and `route.init` - -`onModeEnter` gets run first than `route.init`; however, each route can have -their own `init`, but they share the `onModeEnter`. - -> How can I change the `workList` appearance or add a new login page? - -This is where `OHIF-v3` shines! Since the default `layoutTemplate` is written -for the viewer part, you can simply add a new `layoutTemplate` and use the -component you have written for that route. `Mode` handle showing the correct -component for the specified route. - -```js -function modeFactory() { - return { - id: 'viewer', - displayName: '', - routes: [ - { - path: 'worklist', - init, - layoutTemplate: ({ location, servicesManager }) => { - return { - id: 'worklistLayout', - props: { - component: 'myNewWorkList', - }, - }; - }, - }, - ], - /* - ... - */ - }; -} -``` diff --git a/platform/docs/versioned_docs/version-3.0/platform/modes/validity.md b/platform/docs/versioned_docs/version-3.0/platform/modes/validity.md deleted file mode 100644 index e3f70af7668..00000000000 --- a/platform/docs/versioned_docs/version-3.0/platform/modes/validity.md +++ /dev/null @@ -1,37 +0,0 @@ ---- -sidebar_position: 4 -sidebar_label: Validity ---- -# Mode: Validity - - -## Overview -There are two mechanism for checking the validity of a mode for a study. - -- `isValidMode`: which is called on a selected study in the workList. -- `validTags` - - - -## isValidMode -This hook can be used to define a function that return a `boolean` which decided the -validity of the mode based on `StudyInstanceUID` and `modalities` that are in the study. - -For instance, for pet-ct mode, both `PT` and 'CT' modalities should be available inside the study. - -```js -function modeFactory() { - return { - id: '', - displayName: '', - isValidMode: ({ modalities, StudyInstanceUID }) => { - const modalities_list = modalities.split('\\'); - const validMode = ['CT', 'PT'].every(modality => modalities_list.includes(modality)); - return validMode; - }, - /* - ... - */ - } -} -``` diff --git a/platform/docs/versioned_docs/version-3.0/platform/pwa-vs-packaged.md b/platform/docs/versioned_docs/version-3.0/platform/pwa-vs-packaged.md deleted file mode 100644 index bdc411e6cb1..00000000000 --- a/platform/docs/versioned_docs/version-3.0/platform/pwa-vs-packaged.md +++ /dev/null @@ -1,34 +0,0 @@ ---- -sidebar_position: 3 ---- - -# PWA vs Packaged - -It's important to know that the OHIF Viewer project provides two different build -processes: - -```bash -# Static Asset output: For deploying PWAs -yarn run build -``` - -## Progressive Web Application (PWA) - -> [Progressive Web Apps][pwa] are a new breed of web applications that meet the -> [following requirements][pwa-checklist]. Notably, targeting a PWA allows us -> provide a reliable, fast, and engaging experience across different devices and -> network conditions. - -The OHIF Viewer is maintained as a [monorepo][monorepo]. We use WebPack to build -the many small static assets that comprise our application. Also generated is an -`index.html` that will serve as an entry point for loading configuration and the -application, as well as a `service-worker` that can intelligently cache files so -that subsequent requests are from the local file system instead of over the -network. - -You can read more about this particular strategy in our -[Build for Production Deployment Guide](./../deployment/build-for-production.md) - -## Commonjs Bundle (Packaged Script) - -We are not supporting `Commonjs` bundling inside `OHIF-v3`. diff --git a/platform/docs/versioned_docs/version-3.0/platform/scope-of-project.md b/platform/docs/versioned_docs/version-3.0/platform/scope-of-project.md deleted file mode 100644 index 4ac68daa60e..00000000000 --- a/platform/docs/versioned_docs/version-3.0/platform/scope-of-project.md +++ /dev/null @@ -1,69 +0,0 @@ ---- -sidebar_position: 1 ---- -# Scope of Project - -The OHIF Viewer is a web based medical imaging viewer. This allows it to be used -on almost any device, anywhere. The OHIF Viewer is what is commonly referred to -as a ["Dumb Client"][simplicable] - -> A dumb client is software that fully depends on a connection to a server or -> cloud service for its functionality. Without a network connection, the -> software offers nothing useful. - [simplicable.com][simplicable] - -While the Viewer persists some data, it's scope is limited to caching things -like user preferences and previous query parameters. Because of this, the Viewer -has been built to be highly configurable to work with almost any web accessible -data source. - -![scope-of-project diagram](./../assets/img/scope-of-project.png) - -To be more specific, the OHIF Viewer is a collection of HTML, JS, and CSS files. -These can be delivered to your end users however you would like: - -- From the local network -- From a remote web server -- From a CDN (content delivery network) -- From a service-worker's cache -- etc. - -These "static asset" files are referred to collectively as a "Progressive Web -Application" (PWA), and have the same capabilities and limitations that all PWAs -have. - -All studies, series, images, imageframes, metadata, and the images themselves -must come from an external source. There are many, many ways to provide this -information, the OHIF Viewer's scope **DOES NOT** encompass providing _any_ -data; only the configuration necessary to interface with one or more of these -many data sources. The OHIF Viewer's scope **DOES** include configuration and -support for services that are protected with OpenID-Connect. - -In an effort to aid our users and contributors, we attempt to provide several -[deployment and hosting recipes](./deployment/index.md) as potential starting -points. These are not meant to be rock solid, production ready, solutions; like -most recipes, they should be augmented to best fit you and your organization's -taste, preferences, etc. - -## FAQ - -_Am I able to cache studies for offline viewing?_ - -Not currently. A web page's offline cache capabilities are limited and somewhat -volatile (mostly imposed at the browser vendor level). For more robust offline -caching, you may want to consider a server on the local network, or packaging -the OHIF Viewer as a desktop application. - -_Does the OHIF Viewer work with the local filesystem?_ - -It is possible to accomplish this through extensions; however, for a user -experience that accommodates a large number of studies, you would likely need to -package the OHIF Viewer as an [Electron app][electron]. - - - - -[simplicable]: https://simplicable.com/new/dumb-client -[electron]: https://electronjs.org/ - diff --git a/platform/docs/versioned_docs/version-3.0/platform/services/_category_.json b/platform/docs/versioned_docs/version-3.0/platform/services/_category_.json deleted file mode 100644 index 8b57449b24d..00000000000 --- a/platform/docs/versioned_docs/version-3.0/platform/services/_category_.json +++ /dev/null @@ -1,4 +0,0 @@ -{ - "label": "Services", - "position": 12 -} diff --git a/platform/docs/versioned_docs/version-3.0/platform/services/data/DicomMetadataStore.md b/platform/docs/versioned_docs/version-3.0/platform/services/data/DicomMetadataStore.md deleted file mode 100644 index 927b8b8e541..00000000000 --- a/platform/docs/versioned_docs/version-3.0/platform/services/data/DicomMetadataStore.md +++ /dev/null @@ -1,112 +0,0 @@ ---- -sidebar_position: 2 -sidebar_label: DICOM Metadata Store ---- -# 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) - /** ... **/ - }, - ], - }, - ], -} -``` diff --git a/platform/docs/versioned_docs/version-3.0/platform/services/data/DisplaySetService.md b/platform/docs/versioned_docs/version-3.0/platform/services/data/DisplaySetService.md deleted file mode 100644 index defc022c610..00000000000 --- a/platform/docs/versioned_docs/version-3.0/platform/services/data/DisplaySetService.md +++ /dev/null @@ -1,88 +0,0 @@ ---- -sidebar_position: 3 -sidebar_label: DisplaySet Service ---- -# DisplaySet Service - - -## Overview -`DisplaySetService` handles converting the `instanceMetadata` into `DisplaySet` that `OHIF` uses for the visualization. `DisplaySetService` gets initialized in the `Mode.jsx`. During the initialization `SOPClassHandlerIds` of the `modes` gets registered with the `DisplaySetService`. - -> 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. - - -```js title="platform/core/src/services/DisplaySetService/DisplaySetService.js" -init(extensionManager, SOPClassHandlerIds) { - this.extensionManager = extensionManager; - this.SOPClassHandlerIds = SOPClassHandlerIds; - this.activeDisplaySets = []; -} -``` - -in `Mode.jsx` - -```js title="platform/viewer/src/routes/Mode/Mode.jsx" -export default function ModeRoute(/** ... **/) { - /** ... **/ - const { DisplaySetService } = servicesManager.services - const { sopClassHandlers } = mode - /** ... **/ - useEffect( - () => { - /** ... **/ - - // Add SOPClassHandlers to a new SOPClassManager. - DisplaySetService.init(extensionManager, sopClassHandlers) - - /** ... **/ - } - /** ... **/ - ) - /** ... **/ - return <> /** ... **/ -} -``` - - - - -## Events -There are three events that get broadcasted in `DisplaySetService`: - - - -| Event | Description | -| -------------------- | ---------------------------------------------------- | -| DISPLAY_SETS_ADDED | Fires a displayset is added to the displaysets cache | -| DISPLAY_SETS_CHANGED | Fires when a displayset is changed | -| DISPLAY_SETS_REMOVED | Fires when a displayset is removed | - - - -## API -Let's find out about the public API for `DisplaySetService`. - -- `EVENTS`: Object including the events mentioned above. You can subscribe to these events - by calling DisplaySetService.subscribe(EVENTS.DISPLAY_SETS_CHANGED, myFunction). [Read more about pub/sub pattern here](../pubsub.md) - -- `makeDisplaySets(input, { batch, madeInClient, settings } = {}`): Creates displaySet for the provided - array of instances metadata. Each display set gets a random UID assigned. - - - `input`: Array of instances Metadata - - `batch = false`: If you need to pass array of arrays of instances metadata to have a batch creation - - `madeInClient = false`: Disables the events firing - - `settings = {}`: Hanging protocol viewport or rendering settings. For instance, setting the initial `voi`, or activating a tool upon - displaySet rendering. [Read more about hanging protocols settings here](./HangingProtocolService.md#Settings) - - -- `getDisplaySetByUID`: Returns the displaySet based on the DisplaySetUID. - -- `getDisplaySetForSOPInstanceUID`: Returns the displaySet that includes an image with the provided SOPInstanceUID - -- `getActiveDisplaySets`: Returns the active displaySets - -- `deleteDisplaySet`: Deletes the displaySets from the displaySets cache - -- `holdChangeEvents`: Prevents firing change events (currently only works on add event). - -- `fireHoldChangeEvents`: Causes the change event to be fired IF there were any changes. No longer holds events. diff --git a/platform/docs/versioned_docs/version-3.0/platform/services/data/HangingProtocolService.md b/platform/docs/versioned_docs/version-3.0/platform/services/data/HangingProtocolService.md deleted file mode 100644 index 006a5571218..00000000000 --- a/platform/docs/versioned_docs/version-3.0/platform/services/data/HangingProtocolService.md +++ /dev/null @@ -1,348 +0,0 @@ ---- -sidebar_position: 4 -sidebar_label: Hanging Protocol Service ---- - -# Hanging Protocol Service - -## Overview - -`HangingProtocolService` is a migration of the `OHIF-v1` hanging protocol -engine. This service handles the arrangement of the images in the viewport. In -short, the registered protocols will get matched with the DisplaySets that are -available for the study. Each protocol gets a score, and they are ranked. The -winning protocol gets applied and its settings run for the viewports. - -You can read more about hanging protocols -[here](http://dicom.nema.org/dicom/Conf-2005/Day-2_Selected_Papers/B305_Morgan_HangProto_v1.pdf). -In short with `OHIF-v3` hanging protocols you can: - -- Define what layout of the viewport should the viewer starts with (eg 2x2 layout) -- Define which series gets displayed in which position of the layout -- Apply certain initial viewport settings; e.g., inverting the contrast -- Enable certain tools based on what series are displayed: link prostate T2 and - ADC MRI. -- Apply synchronization settings between different viewports or between setting and viewports -- Register custom synchronization settings for viewports -- Register custom attribute extractors -- Select "next display set" from the matching display sets, both on navigation and initial view - -## Skeleton of A Hanging Protocol - -You can find the skeleton of the hanging protocols here: - -```js -const defaultProtocol = { - id: 'test', - locked: true, - hasUpdatedPriorsInformation: false, - name: 'Default', - createdDate: '2021-02-23T19:22:08.894Z', - modifiedDate: '2021-02-23T19:22:08.894Z', - availableTo: {}, - editableBy: {}, - toolGroupIds: [ - 'ctToolGroup', - 'ptToolGroup', - ], - imageLoadStrategy: 'interleaveTopToBottom', // "default" , "interleaveTopToBottom", "interleaveCenter" - protocolMatchingRules: [ - { - id: 'wauZK2QNEfDPwcAQo', - weight: 1, - attribute: 'StudyDescription', - constraint: { - contains: { - value: 'PETCT', - }, - }, - required: false, - }, - ], - stages: [ - { - id: 'hYbmMy3b7pz7GLiaT', - name: 'default', - viewportStructure: { - layoutType: 'grid', - properties: { - rows: 1, - columns: 1, - }, - }, - displaySets: [ - { - id: 'displaySet', - seriesMatchingRules: [ - { - id: 'GPEYqFLv2dwzCM322', - weight: 1, - attribute: 'Modality', - constraint: { - equals: 'CT', - }, - required: true, - }, - { - id: 'vSjk7NCYjtdS3XZAw', - weight: 1, - attribute: 'numImageFrames', - constraint: { - greaterThan: 10, - }, - }, - ], - studyMatchingRules: [], - }, - ], - viewports: [ - { - viewportOptions: { - viewportId: 'ctAXIAL', - viewportType: 'volume', - orientation: 'axial', - toolGroupId: 'ctToolGroup', - initialImageOptions: { - // index: 5, - preset: 'first', // 'first', 'last', 'middle' - }, - syncGroups: [ - { - type: 'cameraPosition', - id: 'axialSync', - source: true, - target: true, - }, - ], - }, - displaySets: [ - { - id: 'displaySet', - }, - ], - }, - ], - }, - ], - numberOfPriorsReferenced: -1, -} -``` - -Let's discuss each property in depth. - -- `id`: unique identifier for the protocol -- `name`: Name displayed to the user to select this protocol - -- `protocolMatchingRules`: A list of criteria for the protocol along with the - provided points for ranking. - - - `weight`: weight for the matching rule. Eventually, all the registered - protocols get sorted based on the weights, and the winning protocol gets - applied to the viewer. - - `attribute`: tag that needs to be matched against. This can be either - Study-level metadata or a custom attribute. - [Learn more about custom attribute matching](#custom-attribute) - - - `constraint`: the constraint that needs to be satisfied for the attribute. It accepts a `validator` which can be - [`equals`, `doesNotEqual`, `contains`, `doesNotContain`, `startsWith`, `endsWidth`] - - A sample of the matching rule is: - - ```js - { - weight: 1, - attribute: 'StudyInstanceUID', - constraint: { - equals: '1.3.6.1.4.1.25403.345050719074.3824.20170125112931.11', - }, - required: true, - } - ``` - - -- `stages`: Each protocol can define one or more stages. Each stage defines a certain layout and viewport rules. - Therefore, the `stages` property is array of objects, each object being one stage. - - - `displaySets`: Defines the matching rules for which display sets to use. - - `viewportStructure`: Defines the layout of the viewer. You can define the - number of `rows` and `columns`. - - `viewports` defines the actual viewports to display. There should be `rows * columns` number of - these `viewports` property, ordered rows first, then columns. - - - ```js - stages: [ - { - id: 'hYbmMy3b7pz7GLiaT', - name: 'oneByTwo', - viewportStructure: { - type: 'grid', - properties: { - rows: 1, - columns: 3, - }, - }, - viewports: [ - // viewport 1 - { - viewportOptions: { - viewportId: 'ctAXIAL', - viewportType: 'volume', - orientation: 'axial', - toolGroupId: 'ctToolGroup', - initialImageOptions: { - // index: 5, - preset: 'first', // 'first', 'last', 'middle' - }, - syncGroups: [ - { - type: 'cameraPosition', - id: 'axialSync', - source: true, - target: true, - }, - ], - }, - displaySets: [ - { - id: 'displaySet', - }, - ], - }, - ]; - ``` - -## Events - -There are two events that get publish in `HangingProtocolService`: - -| Event | Description | -| ------------ | -------------------------------------------------------------------- | -| NEW_LAYOUT | Fires when a new layout is requested by the `HangingProtocolService` | -| STAGE_CHANGE | Fires when the the stage is changed in the hanging protocols | - -## API - -- `getState`: returns an array: `[matchDetails, hpAlreadyApplied]`: - - - `matchDetails`: matching details for the series - - `hpAlreadyApplied`: An array which tracks whether HPServices has been - applied on each viewport. - -- `addProtocols`: adds provided protocols to the list of registered protocols - for matching - -- `run({ studies, displaySets }, protocol)`: runs the HPService with the provided - list of studies, display sets and optional protocol. - If protocol is not given, HP Matching - engine will search all the registered protocols for the best matching one - based on the constraints. - -- `addCustomAttribute`: adding a custom attribute for matching. (see below) - -Default initialization of the modes handles running the `HangingProtocolService` - -## Custom Attribute -In some situations, you might want to match based on a custom attribute and not the DICOM tags. For instance, -if you have assigned a `timepointId` to each study, and you want to match based on it. -Good news is that, in `OHIF-v3` you can define you custom attribute and use it for matching. - -In some situations, you might want to match based on a custom attribute and not -the DICOM tags. For instance, if you have assigned a `timepointId` to each study -and you want to match based on it. Good news is that, in `OHIF-v3` you can -define you custom attribute and use it for matching. - -There are various ways that you can let `HangingProtocolService` know of you -custom attribute. We will show how to add it inside the an extension. This extension -also shows how to register a sync group service which can be referenced -in the sync group settings. - -```js -const myCustomProtocol = { - id: 'myCustomProtocol', - /** ... **/ - protocolMatchingRules: [ - { - id: 'vSjk7NCYjtdS3XZAw', - attribute: 'timepointId', - constraint: { - equals: 'first', - }, - required: false, - }, - ], -... - -// Custom function for custom attribute -const getTimePointUID = metaData => { - // requesting the timePoint Id - return myBackEndAPI(metaData); -}; - - preRegistration: ({ - servicesManager, - }) => { - const { HangingProtocolService, SyncGroupService } = servicesManager.services; - HangingProtocolService.addCustomAttribute('timepointId', 'TimePoint ID', getTimePointUID); - SyncGroupService.setSynchronizer('initialzoompan', initialZoomPan); - } -``` - -## Viewport Settings - -You can define custom settings to be applied to each viewport. There are two -types of settings: - -- `viewport settings`: Currently we support two viewport settings - - - `voi`: applying an initial `voi` by setting the windowWidth and windowCenter - - `inverted`: inverting the viewport color (e.g., for PET images) - -- `props settings`: Running commands after the first render; e.g., enabling the - link tool - -Examples of each settings are : - -```js -viewportSettings: [ - { - options: { - itemId: 'SyncScroll', - interactionType: 'toggle', - commandName: 'toggleSynchronizer', - commandOptions: { toggledState: true }, - }, - commandName: 'setToolActive', - type: 'props', - }, -]; -``` - -and - -```js -viewportSettings: [ - { - options: { - voi: { - windowWidth: 400, - windowCenter: 40, - }, - }, - commandName: '', - type: 'viewport', - }, -]; -``` - -## Sync Groups -The sync groups are listeners to events that synchronize viewport settings to -some other settings. There are three default/provided sync groups: `zoomPan`, -`cameraPosition` and `voi`. These are defined in the `syncGroups` array. -Additionally, other synchronization types can be created and registered on the -`SyncGroupService.setSynchronizer`, by registering a new id, and a creator method. - -The sync group service is specific to the `cornerstone-extension` because the -actual behaviour of the synchronizers is dependent on the specific viewport. -Different viewport types could redifine the same synchronizer names in -different ways appropriate to that viewport. diff --git a/platform/docs/versioned_docs/version-3.0/platform/services/data/MeasurementService.md b/platform/docs/versioned_docs/version-3.0/platform/services/data/MeasurementService.md deleted file mode 100644 index 74605bce1c5..00000000000 --- a/platform/docs/versioned_docs/version-3.0/platform/services/data/MeasurementService.md +++ /dev/null @@ -1,161 +0,0 @@ ---- -sidebar_position: 6 -sidebar_label: Measurement Service ---- - -# Measurement Service - -## Overview - -`MeasurementService` handles the internal measurement representation inside -`OHIF` platform. Developers can add their custom `sources` with `mappers` to -enable adding measurements inside OHIF. Currently, we are maintaining -`CornerstoneTools` annotations and corresponding mappers can be found inside the -`cornerstone` extension. However, `MeasurementService` can be configured to work -with any custom tools given that its `mappers` is added to the -`MeasurementService`. We can see the overall architecture of the -`MeasurementService` below: - -![services-measurements](../../../assets/img/services-measurements.png) - -## Events - -There are seven events that get publish in `MeasurementService`: - -| Event | Description | -| --------------------- | ------------------------------------------------------ | -| MEASUREMENT_UPDATED | Fires when a measurement is updated | -| MEASUREMENT_ADDED | Fires when a new measurement is added | -| RAW_MEASUREMENT_ADDED | Fires when a raw measurement is added (e.g., dicom-sr) | -| MEASUREMENT_REMOVED | Fires when a measurement is removed | -| MEASUREMENTS_CLEARED | Fires when all measurements are deleted | -| JUMP_TO_MEASUREMENT | Fires when a measurement is requested to be jump to | - -## API - -- `getMeasurements`: returns array of measurements - -- `getMeasurement(id)`: returns the corresponding measurement based on the - provided Id. - -- `remove(id, source)`: removes a measurement and broadcasts the - `MEASUREMENT_REMOVED` event. - -- `clearMeasurements`: removes all measurements and broadcasts - `MEASUREMENTS_CLEARED` event. - -- `createSource(name, version)`: creates a new measurement source, generates a - uid and adds it to the `sources` property of the service. - -- `addMapping(source, definition, matchingCriteria, toSourceSchema, toMeasurementSchema)`: - adds a new measurement matching criteria along with mapping functions. We will - learn more about [source/mappers below](#source--mappers) - -- `update`: updates the measurement details and fires `MEASUREMENT_UPDATED` - -- `addRawMeasurement(source,definition,data,toMeasurementSchema,dataSource = {}` - : adds a raw measurement into a source so that it may be converted to/from - annotation in the same way. E.g. import serialized data of the same form as - the measurement source. Fires `MEASUREMENT_UPDATED` or `MEASUREMENT_ADDED`. - Note that, `MeasurementService` handles finding the correct mapper upon new - measurements; however, `addRawMeasurement` provides more flexibility. You can - take a look into its usage in `dicom-sr` extension. - - - `source`: The measurement source instance. - - `definition`: The source definition you want to add the measurement to. - - `data`: The data you wish to add to the source. - - `toMeasurementSchema`: A function to get the `data` into the same shape as - the source definition. - -- `jumpToMeasurement(viewportIndex, id)`: calls the listeners who have - subscribed to `JUMP_TO_MEASUREMENT`. - -## Source / Mappers - -To create a custom measurement source and relevant mappers for each tool, you -can take a look at the `init.js` inside the `cornerstone` extension. In which we -are registering our `CornerstoneTools-v4` measurement source to -MeasurementService. Let's take a peek at the _simplified_ implementation -together. To achieve this, for each tool, we need to provide three mappers: - -- `matchingCriteria`: criteria used for finding the correct mapper for the drawn - tool. -- `toAnnotation`: tbd -- `toMeasurement`: a function that converts the tool data to OHIF internal - representation of measurement data. - -```js title="extensions/cornerstone/src/utils/measurementServiceMappings/Length.js" -function toMeasurement( - csToolsAnnotation, - DisplaySetService, - getValueTypeFromToolType -) { - const { element, measurementData } = csToolsAnnotation; - - /** ... **/ - - const { - SOPInstanceUID, - FrameOfReferenceUID, - SeriesInstanceUID, - StudyInstanceUID, - } = getSOPInstanceAttributes(element); - - const displaySet = DisplaySetService.getDisplaySetForSOPInstanceUID( - SOPInstanceUID, - SeriesInstanceUID - ); - - /** ... **/ - return { - id: measurementData.id, - SOPInstanceUID, - FrameOfReferenceUID, - referenceSeriesUID: SeriesInstanceUID, - referenceStudyUID: StudyInstanceUID, - displaySetInstanceUID: displaySet.displaySetInstanceUID, - label: measurementData.label, - description: measurementData.description, - unit: measurementData.unit, - length: measurementData.length, - type: getValueTypeFromToolType(tool), - points: getPointsFromHandles(measurementData.handles), - }; -} - -////////////////////////////////////////// - -// extensions/cornerstone/src/init.js - -const Length = { - toAnnotation, - toMeasurement, - matchingCriteria: [ - { - valueType: MeasurementService.VALUE_TYPES.POLYLINE, - points: 2, - }, - ], -}; - -const _initMeasurementService = (MeasurementService, DisplaySetService) => { - /** ... **/ - - const csToolsVer4MeasurementSource = MeasurementService.createSource( - 'CornerstoneTools', - '4' - ); - - /* Mappings */ - MeasurementService.addMapping( - csToolsVer4MeasurementSource, - 'Length', - Length.matchingCriteria, - toAnnotation, - toMeasurement - ); - - /** Other tools **/ - return csToolsVer4MeasurementSource; -}; -``` diff --git a/platform/docs/versioned_docs/version-3.0/platform/services/data/ToolbarService.md b/platform/docs/versioned_docs/version-3.0/platform/services/data/ToolbarService.md deleted file mode 100644 index 92ab50048b2..00000000000 --- a/platform/docs/versioned_docs/version-3.0/platform/services/data/ToolbarService.md +++ /dev/null @@ -1,226 +0,0 @@ ---- -sidebar_position: 5 -sidebar_label: Toolbar Service ---- - -# Toolbar Service - -## Overview - -`ToolBarService` handles the toolbar section buttons, and what happens when a -button is clicked by the user. - -
- -
- -## 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 - -- `recordInteraction(interaction)`: executes the provided interaction which is - an object providing the following properties to the ToolBarService: - - - `interactionType`: can be `tool`, `toggle` and `action`. We will discuss - more each type below. - - `itemId`: tool name - - `groupId`: the Id for the tool button group; e.g., `Wwwc` which holds - presets. - - `commandName`: if tool has a command attached to run - - `commandOptions`: arguments for the command. - -- `reset`: reset the state of the toolbarService, set the primary tool to be - `Wwwc` and unsubscribe tools that have registered their functions. - -- `addButtons`: add the button definition to the service. - [See below for button definition](#button-definitions). - -- `setButtons`: sets the buttons defined in the service. It overrides all the - previous buttons - -- `getActiveTools`: returns the active tool + all the toggled-on tools - -## State - -ToolBarService has an internal state that gets updated per tool interaction and -tracks the active toolId, state of the buttons that have toggled state, and the -group buttons and which tool in each group is active. - -```js -state = { - primaryToolId: 'Wwwc', - toggles: { - /* id: true/false */ - }, - groups: { - /* track most recent click per group...*/ - }, -}; -``` - -## Interaction type - -There are three main types that a tool can have which is defined in the -interaction object. - -- `tool`: setting a tool to be active; e.g., measurement tools -- `toggle`: toggling state of a tool; e.g., viewport link (sync) -- `action`: performs a registered action outside of the ToolBarService; e.g., - capture - -A _simplified_ implementation of the ToolBarService is: - -```js -export default class ToolBarService { - /** ... **/ - recordInteraction(interaction) { - /** ... **/ - switch (interactionType) { - case 'action': { - break; - } - case 'tool': { - this.state.primaryToolId = itemId; - - commandsManager.runCommand('setToolActive', interaction.commandOptions); - break; - } - case 'toggle': { - this.state.toggles[itemId] = - this.state.toggles[itemId] === undefined - ? true - : !this.state.toggles[itemId]; - interaction.commandOptions.toggledState = this.state.toggles[itemId]; - break; - } - default: - throw new Error(`Invalid interaction type: ${interactionType}`); - } - /** ... **/ - } - /** ... **/ -} -``` - -## Button Definitions - -The simplest toolbarButtons definition has the following properties: - -![toolbarModule-zoom](../../../assets/img/toolbarModule-zoom.png) - -```js -{ - id: 'Zoom', - type: 'ohif.radioGroup', - props: { - type: 'tool', - icon: 'tool-zoom', - label: 'Zoom', - commandOptions: { toolName: 'Zoom' }, - }, -}, -``` - -| property | description | values | -| ---------------- | ----------------------------------------------------------------- | ------------------------------------------- | -| `id` | Unique string identifier for the definition | \* | -| `label` | User/display friendly to show in UI | \* | -| `icon` | A string name for an icon supported by the consuming application. | \* | -| `type` | Used to determine the button's behaviour | "tool", "toggle", "action" | -| `commandName` | (optional) The command to run when the button is used. | Any command registered by a `CommandModule` | -| `commandOptions` | (optional) Options to pass the target `commandName` | \* | - -There are three main types of toolbar buttons: - -- `tool`: buttons that enable a tool by running the `setToolActive` command with - the `commandOptions` -- `toggle`: buttons that acts as a toggle: e.g., linking viewports -- `action`: buttons that executes an action: e.g., capture button to save - screenshot - -## Nested Buttons - -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 - -![toolbarModule-nested-buttons](../../../assets/img/toolbarModule-nested-buttons.png) - -```js title="modes/longitudinal/src/toolbarButtons.js" -{ - id: 'MeasurementTools', - type: 'ohif.splitButton', - props: { - groupId: 'MeasurementTools', - isRadio: true, - primary: { - id: 'Length', - icon: 'tool-length', - label: 'Length', - type: 'tool', - commandOptions: { - toolName: 'Length', - } - }, - secondary: { - icon: 'chevron-down', - label: '', - isActive: true, - tooltip: 'More Measure Tools', - }, - items: [ - // Length tool - { - id: 'Length', - icon: 'tool-length', - label: 'Length', - type: 'tool', - commandOptions: { - toolName: 'Length', - } - }, - // Bidirectional tool - { - id: 'Bidirectional', - icon: 'tool-bidirectional', - label: 'Length', - type: 'tool', - commandOptions: { - toolName: 'Bidirectional', - } - }, - // Ellipse tool - { - id: 'EllipticalRoi', - icon: 'tool-elipse', - label: 'Ellipse', - type: 'tool', - commandOptions: { - toolName: 'EllipticalRoi', - } - }, - // Circle tool - { - id: 'CircleROI', - icon: 'tool-circle', - label: 'Circle', - type: 'tool', - commandOptions: { - toolName: 'CircleROI', - } - }, - ], - }, -} -``` diff --git a/platform/docs/versioned_docs/version-3.0/platform/services/data/_category_.json b/platform/docs/versioned_docs/version-3.0/platform/services/data/_category_.json deleted file mode 100644 index 984ac9a4208..00000000000 --- a/platform/docs/versioned_docs/version-3.0/platform/services/data/_category_.json +++ /dev/null @@ -1,4 +0,0 @@ -{ - "label": "Data Services", - "position": 2 -} diff --git a/platform/docs/versioned_docs/version-3.0/platform/services/data/index.md b/platform/docs/versioned_docs/version-3.0/platform/services/data/index.md deleted file mode 100644 index fa9128ae4da..00000000000 --- a/platform/docs/versioned_docs/version-3.0/platform/services/data/index.md +++ /dev/null @@ -1,53 +0,0 @@ ---- -sidebar_position: 1 -sidebar_label: Overview ---- - -# 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](../data/ToolBarService.md) -- [Measurement Service](../data/MeasurementService.md) - -## Service Architecture - -![services-data](../../../assets/img/services-data.png) - -> We have explained services and how to create a custom service in the -> [`ServiceManager`](../../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(serviceManager) { - return { - name: 'myService', - create: ({ configuration = {} }) => { - return new backEndService(serviceManager); - }, - }; -} -``` - -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) diff --git a/platform/docs/versioned_docs/version-3.0/platform/services/index.md b/platform/docs/versioned_docs/version-3.0/platform/services/index.md deleted file mode 100644 index 87d88e7ad2b..00000000000 --- a/platform/docs/versioned_docs/version-3.0/platform/services/index.md +++ /dev/null @@ -1,173 +0,0 @@ ---- -sidebar_position: 1 -sidebar_label: Introduction ---- - -# Services - -## Overview - -Services are "concern-specific" code modules that can be consumed across layers. -Services provide a set of operations, often tied to some shared state, and are -made available to through out the app via the `ServicesManager`. Services are -particularly well suited to address [cross-cutting -concerns][cross-cutting-concerns]. - -Each service should be: - -- self-contained -- able to fail and/or be removed without breaking the application -- completely interchangeable with another module implementing the same interface - -> In `OHIF-v3` we have added multiple non-UI services and have introduced -> **pub/sub** pattern to reduce coupling between layers. -> -> [Read more about Pub/Sub](./pubsub.md) - -## Services - -The following services is available in the `OHIF-v3`. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
ServiceTypeDescription
- - DicomMetadataStore (NEW) - - Data Service - DicomMetadataStore -
- - DisplaySetService (NEW) - - Data Service - DisplaySetService -
- - HangingProtocolService (NEW) - - Data Service - HangingProtocolService -
- - MeasurementService (MODIFIED) - - Data Service - MeasurementService -
- - ToolBarService (NEW) - - Data Service - ToolBarService -
- - ViewportGridService (NEW) - - UI Service - ViewportGridService -
- - Cine Service (NEW) - - UI Service - cine -
- - UIDialogService - - UI Service - UIDialogService -
- - UIModalService - - UI Service - UIModalService -
- - UINotificationService - - UI Service - UINotificationService -
- - UIViewportDialogService (NEW) - - UI Service - UIViewportDialogService -
- - - - - -[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 - diff --git a/platform/docs/versioned_docs/version-3.0/platform/services/pubsub.md b/platform/docs/versioned_docs/version-3.0/platform/services/pubsub.md deleted file mode 100644 index fae6978e6a8..00000000000 --- a/platform/docs/versioned_docs/version-3.0/platform/services/pubsub.md +++ /dev/null @@ -1,120 +0,0 @@ ---- -sidebar_position: 4 -sidebar_label: Pub Sub ---- - -# Pub sub - -## Overview - -Publish–subscribe pattern is a messaging pattern that is one of the fundamentals -patterns used in reusable software components. - -In short, services that implement this pattern, can have listeners subscribed -to their broadcasted events. After the event is fired, the corresponding -listener will execute the function that is registered. - -You can read more about this design pattern -[here](https://cloud.google.com/pubsub/docs/overview). - -## Example: Default Initialization - -In `Mode.jsx` we have a default initialization that demonstrates a series of -subscriptions to various events. - -```js -async function defaultRouteInit({ - servicesManager, - studyInstanceUIDs, - dataSource, -}) { - const { - DisplaySetService, - HangingProtocolService, - } = servicesManager.services; - - const unsubscriptions = []; - - const { - unsubscribe: instanceAddedUnsubscribe, - } = DicomMetadataStore.subscribe( - DicomMetadataStore.EVENTS.INSTANCES_ADDED, - ({ StudyInstanceUID, SeriesInstanceUID, madeInClient = false }) => { - const seriesMetadata = DicomMetadataStore.getSeries( - StudyInstanceUID, - SeriesInstanceUID - ); - - DisplaySetService.makeDisplaySets(seriesMetadata.instances, madeInClient); - } - ); - - unsubscriptions.push(instanceAddedUnsubscribe); - - studyInstanceUIDs.forEach(StudyInstanceUID => { - dataSource.retrieve.series.metadata({ StudyInstanceUID }); - }); - - const { unsubscribe: seriesAddedUnsubscribe } = DicomMetadataStore.subscribe( - DicomMetadataStore.EVENTS.SERIES_ADDED, - ({ StudyInstanceUID }) => { - const studyMetadata = DicomMetadataStore.getStudy(StudyInstanceUID); - HangingProtocolService.run(studyMetadata, DisplaySetService.getActiveDisplaySets()); - } - ); - unsubscriptions.push(seriesAddedUnsubscribe); - - return unsubscriptions; -} -``` - -## Unsubscription - -You need to be careful if you are adding custom subscriptions to the app. Each -subscription will return an unsubscription function that needs to be executed on -component destruction to avoid adding multiple subscriptions to the same -observer. - -Below, we can see `simplified` `Mode.jsx` and the corresponding `useEffect` -where the unsubscription functions are executed upon destruction. - -```js title="platform/viewer/src/routes/Mode/Mode.jsx" -export default function ModeRoute(/**..**/) { - /**...**/ - useEffect(() => { - /**...**/ - - DisplaySetService.init(extensionManager, sopClassHandlers); - - extensionManager.onModeEnter(); - mode?.onModeEnter({ servicesManager, extensionManager }); - - hangingProtocols.forEach(extentionProtocols => { - const { protocols } = extensionManager.getModuleEntry(extentionProtocols); - HangingProtocolService.addProtocols(protocols); - }); - - const setupRouteInit = async () => { - if (route.init) { - return await route.init(/**...**/); - } - - return await defaultRouteInit(/**...**/); - }; - - let unsubscriptions; - setupRouteInit().then(unsubs => { - unsubscriptions = unsubs; - }); - - return () => { - extensionManager.onModeExit(); - mode?.onModeExit({ servicesManager, extensionManager }); - unsubscriptions.forEach(unsub => { - unsub(); - }); - }; - }); - return <> /**...**/ ; -} -``` diff --git a/platform/docs/versioned_docs/version-3.0/platform/services/ui/_category_.json b/platform/docs/versioned_docs/version-3.0/platform/services/ui/_category_.json deleted file mode 100644 index 9c012134eb0..00000000000 --- a/platform/docs/versioned_docs/version-3.0/platform/services/ui/_category_.json +++ /dev/null @@ -1,4 +0,0 @@ -{ - "label": "UI Services", - "position": 3 -} diff --git a/platform/docs/versioned_docs/version-3.0/platform/services/ui/cine-service.md b/platform/docs/versioned_docs/version-3.0/platform/services/ui/cine-service.md deleted file mode 100644 index 707b5d97f7f..00000000000 --- a/platform/docs/versioned_docs/version-3.0/platform/services/ui/cine-service.md +++ /dev/null @@ -1,8 +0,0 @@ ---- -sidebar_position: 7 -sidebar_label: CINE Service ---- - -# CINE Service - -TODO... diff --git a/platform/docs/versioned_docs/version-3.0/platform/services/ui/index.md b/platform/docs/versioned_docs/version-3.0/platform/services/ui/index.md deleted file mode 100644 index 5ba4a539057..00000000000 --- a/platform/docs/versioned_docs/version-3.0/platform/services/ui/index.md +++ /dev/null @@ -1,304 +0,0 @@ ---- -sidebar_position: 1 -sidebar_label: Overview ---- - -# 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) - - - -![UIService](../../../assets/img/ui-services.png) - - - -## 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/viewer/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/viewer/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. diff --git a/platform/docs/versioned_docs/version-3.0/platform/services/ui/ui-dialog-service.md b/platform/docs/versioned_docs/version-3.0/platform/services/ui/ui-dialog-service.md deleted file mode 100644 index 152841ae625..00000000000 --- a/platform/docs/versioned_docs/version-3.0/platform/services/ui/ui-dialog-service.md +++ /dev/null @@ -1,48 +0,0 @@ ---- -sidebar_position: 4 -sidebar_label: UI Dialog Service ---- -# 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 - diff --git a/platform/docs/versioned_docs/version-3.0/platform/services/ui/ui-modal-service.md b/platform/docs/versioned_docs/version-3.0/platform/services/ui/ui-modal-service.md deleted file mode 100644 index cb36d7e6cf6..00000000000 --- a/platform/docs/versioned_docs/version-3.0/platform/services/ui/ui-modal-service.md +++ /dev/null @@ -1,56 +0,0 @@ ---- -sidebar_position: 3 -sidebar_label: UI Modal Service ---- -# 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 | - -## Implementations - -| Implementation | Consumer | -| ---------------------------------- | --------- | -| [Modal Provider][modal-provider]\* | Modal.jsx | - -`*` - 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/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 - diff --git a/platform/docs/versioned_docs/version-3.0/platform/services/ui/ui-notification-service.md b/platform/docs/versioned_docs/version-3.0/platform/services/ui/ui-notification-service.md deleted file mode 100644 index 96185943482..00000000000 --- a/platform/docs/versioned_docs/version-3.0/platform/services/ui/ui-notification-service.md +++ /dev/null @@ -1,55 +0,0 @@ ---- -sidebar_position: 2 -sidebar_label: UI Notification Service ---- -# 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 - diff --git a/platform/docs/versioned_docs/version-3.0/platform/services/ui/ui-viewport-dialog-service.md b/platform/docs/versioned_docs/version-3.0/platform/services/ui/ui-viewport-dialog-service.md deleted file mode 100644 index 7370428459d..00000000000 --- a/platform/docs/versioned_docs/version-3.0/platform/services/ui/ui-viewport-dialog-service.md +++ /dev/null @@ -1,65 +0,0 @@ ---- -sidebar_position: 5 -sidebar_label: UI Viewport Dialog Service ---- - -# 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 = { - viewportIndex: 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'); - }, -}; -``` diff --git a/platform/docs/versioned_docs/version-3.0/platform/services/ui/viewport-grid-service.md b/platform/docs/versioned_docs/version-3.0/platform/services/ui/viewport-grid-service.md deleted file mode 100644 index 39e2378a327..00000000000 --- a/platform/docs/versioned_docs/version-3.0/platform/services/ui/viewport-grid-service.md +++ /dev/null @@ -1,51 +0,0 @@ ---- -sidebar_position: 6 -sidebar_label: Viewport Grid Service ---- - -# Viewport Grid Service - -## Overview - -This is a new UI service, that handles the grid layout of the viewer. - -## 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 | -| --------------------------------------------------------------------- | --------------------------------------------------- | -| `setActiveViewportIndex(index)` | Sets the active viewport index in the app | -| `getState()` | Gets the states of the viewport (see below) | -| `setDisplaySetsForViewport({ viewportIndex, 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 | - -## 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, - * } - */ - ], - activeViewportIndex: 0, -}; -``` diff --git a/platform/docs/versioned_docs/version-3.0/platform/themeing.md b/platform/docs/versioned_docs/version-3.0/platform/themeing.md deleted file mode 100644 index 852c5d3982c..00000000000 --- a/platform/docs/versioned_docs/version-3.0/platform/themeing.md +++ /dev/null @@ -1,168 +0,0 @@ ---- -sidebar_position: 2 -sidebar_label: Theming ---- - -# Viewer: Theming - -`OHIF-v3` has introduced the -[`LayoutTemplateModule`](./extensions/modules/layout-template.md) which enables -addition of custom layouts. You can easily design your custom components inside -an extension and consume it via the layoutTemplate module you write. - -## Tailwind CSS - -[Tailwind CSS](https://tailwindcss.com/) is a utility-first CSS framework for -creating custom user interfaces. - -Below you can see a compiled version of the tailwind configs. Each section can -be edited accordingly. For instance screen size break points, primary and -secondary colors, etc. - -```js -module.exports = { - prefix: '', - important: false, - separator: ':', - theme: { - screens: { - sm: '640px', - md: '768px', - lg: '1024px', - xl: '1280px', - }, - colors: { - overlay: 'rgba(0, 0, 0, 0.8)', - transparent: 'transparent', - black: '#000', - white: '#fff', - initial: 'initial', - inherit: 'inherit', - - indigo: { - dark: '#0b1a42', - }, - aqua: { - pale: '#7bb2ce', - }, - - primary: { - light: '#5acce6', - main: '#0944b3', - dark: '#090c29', - active: '#348cfd', - }, - - secondary: { - light: '#3a3f99', - main: '#2b166b', - dark: '#041c4a', - active: '#1f1f27', - }, - - common: { - bright: '#e1e1e1', - light: '#a19fad', - main: '#fff', - dark: '#726f7e', - active: '#2c3074', - }, - - customgreen: { - 100: '#05D97C', - }, - - customblue: { - 100: '#c4fdff', - 200: '#38daff', - }, - }, - }, -}; -``` - -You can also use the color variable like before. For instance: - -```js -primary: { - default: β€˜var(--default-color)β€˜, - light: β€˜#5ACCE6’, - main: β€˜#0944B3’, - dark: β€˜#090C29’, - active: β€˜#348CFD’, -} -``` - -## White Labeling - -A white-label product is a product or service produced by one company (the -producer) that other companies (the marketers) rebrand to make it appear as if -they had made it - -[Wikipedia: White-Label Product](https://en.wikipedia.org/wiki/White-label_product) - -Current white-labeling options are limited. We expose the ability to replace the -"Logo" section of the application with a custom "Logo" component. You can do -this by adding a whiteLabeling key to your configuration file. - -```js -window.config = { - /** .. **/ - whiteLabeling: { - createLogoComponentFn: function(React) { - return React.createElement( - 'a', - { - target: '_blank', - rel: 'noopener noreferrer', - className: 'text-white underline', - href: 'http://radicalimaging.com', - }, - React.createElement('h5', {}, 'RADICAL IMAGING') - ); - }, - }, - /** .. **/ -}; -``` - -> You can simply use the stylings from tailwind CSS in the whiteLabeling - -In addition to text, you can also add your custom logo. You can put them -inside the platform/viewer/public/assets folder and use them in the -whiteLabeling section. - -```js -window.config = { - /** .. **/ - whiteLabeling: { - createLogoComponentFn: function(React) { - return React.createElement( - 'a', - { - target: '_self', - rel: 'noopener noreferrer', - className: 'text-purple-600 line-through', - href: '/', - }, - React.createElement('img', { - src: './assets/customLogo.svg', - // className: 'w-8 h-8', - }) - ); - }, - }, - /** .. **/ -}; -``` - -The output will look like - -![custom-logo](../assets/img/custom-logo.png) - - - - -[wikipedia]: https://en.wikipedia.org/wiki/White-label_product - diff --git a/platform/docs/versioned_docs/version-3.0/release-notes.md b/platform/docs/versioned_docs/version-3.0/release-notes.md deleted file mode 100644 index 242221bd7d9..00000000000 --- a/platform/docs/versioned_docs/version-3.0/release-notes.md +++ /dev/null @@ -1,141 +0,0 @@ ---- -sidebar_position: 2 -sidebar_label: Release Notes ---- - -# Release Notes - -> New `OHIF-v3` architecture has made OHIF a general purpose extensible medical -> imaging **platform**, as opposed to a configurable viewer. - -## What's new in `OHIF-v3` - -`OHIF-v3` is our second try for a React-based viewer, and is the third version -of our medical image web viewers from the start. The summary of changes includes: - -- Addition of workflow modes - - Often, medical imaging use cases involves lots of specific workflows that - re-use functionalities. We have added the capability of workflow modes, that - enable people to customize user interface and configure application for - specific workflow. - - The idea is to re-use the functionalities that extensions provide and create - a workflow. Brain segmentation workflow is different from prostate - segmentation in UI for sure; however, they share the segmentation tools that - can be re-used. - - Our vision is that technical people focus of developing extensions which - provides core functionalities, and experts to build modes by picking the - appropriate functionalities from each extension. - -* UI has been completely redesigned with modularity and workflow modes in mind. -* New UI components have been built with Tailwind CSS -* Redux store has been removed from the viewer in favour of services backed by - React's Context API - -Below, you can find the gap analysis between the `OHIF-v2` and `OHIF-v3`: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
OHIF-v2 functionalitiesOHIF-v3Comment
Rendering of 2D images via Cornerstoneβœ…
Study Listβœ…
Series Browserβœ…
DICOM JSONβœ…
2D Tools via CornerstoneToolsβœ…
OpenID Connect standard authentication flow for connecting to identity providersβœ…
Internationalizationβœ…
Drag/drop DICOM data into the viewer (see https://viewer.ohif.org/local)βœ…
White-labelling: Easily replace the OHIF Logo with your logoβœ…
DICOM Whole-slide imaging viewportπŸ”œIn Progress
IHE Invoke Image Display - Standard-compliant launching of the viewer (e.g. from PACS or RIS)πŸ”œNot Started
DICOM PDF supportπŸ”œNot Started
Displaying non-renderable DICOM as HTMLπŸ”œNot Started
Segmentation supportπŸ”œNot Started
RT STRUCT supportπŸ”œNot Started
DICOM upload to PACSπŸ”œNot Started
Google Cloud adapterπŸ”œNot Started
VTK Extension + MIP / MPR layout❌Other plans that involves amazing news soon!
UMD Build (Embedded Viewer). ❌The problem is that this breaks a bunch of extensions that rely on third party scripts (e.g. VTK) which have their own web worker loaders.
diff --git a/platform/docs/versioned_docs/version-3.0/resources.md b/platform/docs/versioned_docs/version-3.0/resources.md deleted file mode 100644 index be7b10ed756..00000000000 --- a/platform/docs/versioned_docs/version-3.0/resources.md +++ /dev/null @@ -1,101 +0,0 @@ ---- -sidebar_position: 9 -sidebar_label: 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: - -## 2022 - -### [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/678769373/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) diff --git a/platform/docs/versioned_docs/version-3.0/user-guide/_category_.json b/platform/docs/versioned_docs/version-3.0/user-guide/_category_.json deleted file mode 100644 index 68ea78e7844..00000000000 --- a/platform/docs/versioned_docs/version-3.0/user-guide/_category_.json +++ /dev/null @@ -1,4 +0,0 @@ -{ - "label": "User Guide", - "position": 2 -} diff --git a/platform/docs/versioned_docs/version-3.0/user-guide/index.md b/platform/docs/versioned_docs/version-3.0/user-guide/index.md deleted file mode 100644 index 52f44bad8cb..00000000000 --- a/platform/docs/versioned_docs/version-3.0/user-guide/index.md +++ /dev/null @@ -1,83 +0,0 @@ ---- -sidebar_position: 2 -sidebar_label: Study List ---- - -# 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`. - -![user-study-list](../assets/img/user-study-list.png) - -## 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: - -![user-study-filter](../assets/img/user-study-filter.png) - -Below the study list are pagination options for 25, 50, or 100 studies per page. - -![user-study-next](../assets/img/user-study-next.png) - -## Study Summary - -Click on a study to expand the study summary panel. - -![user-study-summary](../assets/img/user-study-summary.png) - -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. - - - -![user-studyist-modespecific](../assets/img/user-studyist-modespecific.png) - -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. - -![user-open-viewer](../assets/img/user-open-viewer.png) diff --git a/platform/docs/versioned_docs/version-3.0/user-guide/viewer/Language.md b/platform/docs/versioned_docs/version-3.0/user-guide/viewer/Language.md deleted file mode 100644 index 9032ecc5f62..00000000000 --- a/platform/docs/versioned_docs/version-3.0/user-guide/viewer/Language.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -sidebar_position: 8 ---- - -# 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 - -
- -
diff --git a/platform/docs/versioned_docs/version-3.0/user-guide/viewer/_category_.json b/platform/docs/versioned_docs/version-3.0/user-guide/viewer/_category_.json deleted file mode 100644 index 417861dba3d..00000000000 --- a/platform/docs/versioned_docs/version-3.0/user-guide/viewer/_category_.json +++ /dev/null @@ -1,4 +0,0 @@ -{ - "label": "Basic Viewer", - "position": 2 -} diff --git a/platform/docs/versioned_docs/version-3.0/user-guide/viewer/hotkeys.md b/platform/docs/versioned_docs/version-3.0/user-guide/viewer/hotkeys.md deleted file mode 100644 index 5d8aac1fb47..00000000000 --- a/platform/docs/versioned_docs/version-3.0/user-guide/viewer/hotkeys.md +++ /dev/null @@ -1,15 +0,0 @@ ---- -sidebar_position: 7 ---- - -# 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: - -![user-hotkeys-default](../../assets/img/user-hotkeys-default.png) - -Hotkeys can be assigned to custom bindings that persist for the duration of the browser session. diff --git a/platform/docs/versioned_docs/version-3.0/user-guide/viewer/index.md b/platform/docs/versioned_docs/version-3.0/user-guide/viewer/index.md deleted file mode 100644 index 6918ce3b1b8..00000000000 --- a/platform/docs/versioned_docs/version-3.0/user-guide/viewer/index.md +++ /dev/null @@ -1,29 +0,0 @@ ---- -sidebar_position: 1 -sidebar_label: Overview ---- - - -# 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): - -![user-viewer](../../assets/img/user-viewer.png) - -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 - -![user-viewer-components](../../assets/img/overview.png) - - - - -Now, we explain each component and its sub-elements in detail. diff --git a/platform/docs/versioned_docs/version-3.0/user-guide/viewer/measurement-panel.md b/platform/docs/versioned_docs/version-3.0/user-guide/viewer/measurement-panel.md deleted file mode 100644 index b760bf37e46..00000000000 --- a/platform/docs/versioned_docs/version-3.0/user-guide/viewer/measurement-panel.md +++ /dev/null @@ -1,74 +0,0 @@ ---- -sidebar_position: 3 ---- - -# 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. - -![user-measurement-panel-modal](../../assets/img/measurement-panel-prompt.png) - - - - - -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. - -![user-measurement-panel-tracked](../../assets/img/measurement-panel-tracked.png) - -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. - -![measurement-temporary](../../assets/img/measurement-temporary.png) - - -## 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. - -![user-measurement-edit](../../assets/img/measurement-panel-1.png) - - - -## 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. - - -![measurements-prevNext](../../assets/img/measurements-prevNext.png) - -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. - - -![user-measurement-export](../../assets/img/user-measurement-export.png) - - -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: - - -
- -
diff --git a/platform/docs/versioned_docs/version-3.0/user-guide/viewer/measurement-tracking.md b/platform/docs/versioned_docs/version-3.0/user-guide/viewer/measurement-tracking.md deleted file mode 100644 index a15f7e5dfb6..00000000000 --- a/platform/docs/versioned_docs/version-3.0/user-guide/viewer/measurement-tracking.md +++ /dev/null @@ -1,124 +0,0 @@ ---- -sidebar_position: 4 ---- - -# 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. - -![user-measurement-panel-modal](../../assets/img/tracking-workflow1.png) - -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`. - -![tracked-not-tracked](../../assets/img/tracked-not-tracked.png) - - - -#### Overview video for starting the tracking for measurements: - - -
- -
- - -

- -#### Overview video for not starting 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. - -![SR-exported](../../assets/img/SR-exported.png) - -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. - -![restore-exported-sr](../../assets/img/restore-exported-sr.png) - -The full workflow for saving measurements to SR and loading SR into the viewer is shown below. - -![user-measurement-panel-modal](../../assets/img/tracking-workflow2.png) -![user-measurement-panel-modal](../../assets/img/tracking-workflow3.png) - - -#### Overview video for loading DICOM SR and making a tracked series: - - -
- -
- -

- -#### Overview video for loading DICOM SR and not 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. - - -![locked-sr](../../assets/img/locked-sr.png) - -

- - -#### Overview video for loading DICOM SR inside an already tracked series: - - - -
- -
diff --git a/platform/docs/versioned_docs/version-3.0/user-guide/viewer/study-panel.md b/platform/docs/versioned_docs/version-3.0/user-guide/viewer/study-panel.md deleted file mode 100644 index 1b5190ffaeb..00000000000 --- a/platform/docs/versioned_docs/version-3.0/user-guide/viewer/study-panel.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -sidebar_position: 2 ---- - -# 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. - - - -![user-study-panel](../../assets/img/user-study-panel.png) - -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. - - - - diff --git a/platform/docs/versioned_docs/version-3.0/user-guide/viewer/toolbar.md b/platform/docs/versioned_docs/version-3.0/user-guide/viewer/toolbar.md deleted file mode 100644 index cb982ce25b8..00000000000 --- a/platform/docs/versioned_docs/version-3.0/user-guide/viewer/toolbar.md +++ /dev/null @@ -1,85 +0,0 @@ ---- -sidebar_position: 6 ---- - - -# 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) - -![user-viewer-toolbar](../../assets/img/user-viewer-toolbar.png) - - -## 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. - - -![user-viewer-toolbar-measurements](../../assets/img/user-viewer-toolbar-measurements.png) - - -## 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. - - -![user-toolbar-preset](../../assets/img/user-toolbar-preset.png) - - -## 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) - -![user-toolbar-download-icon](../../assets/img/user-toolbar-download-icon.png) - -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. - -![user-toolbarDownload](../../assets/img/user-toolbarDownload.png) - - - -## 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: - - -
- -
diff --git a/platform/docs/versioned_docs/version-3.0/user-guide/viewer/viewport.md b/platform/docs/versioned_docs/version-3.0/user-guide/viewer/viewport.md deleted file mode 100644 index 173728ca153..00000000000 --- a/platform/docs/versioned_docs/version-3.0/user-guide/viewer/viewport.md +++ /dev/null @@ -1,39 +0,0 @@ ---- -sidebar_position: 5 ---- - -# Viewport - -Image visualization happens at the viewport which contains canvas or canvases that -renders series. - -![user-viewer-main](../../assets/img/user-viewer-main.png) - - -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. - - -![user-viewer-layout](../../assets/img/user-viewer-layout.png) - - -## Overview Video -An overview of viewport layout change, and manipulation can be seen below: - - -
- -
diff --git a/platform/docs/versioned_sidebars/version-1.0-sidebars.json b/platform/docs/versioned_sidebars/version-1.0-deprecated-sidebars.json similarity index 100% rename from platform/docs/versioned_sidebars/version-1.0-sidebars.json rename to platform/docs/versioned_sidebars/version-1.0-deprecated-sidebars.json diff --git a/platform/docs/versioned_sidebars/version-2.0-sidebars.json b/platform/docs/versioned_sidebars/version-2.0-deprecated-sidebars.json similarity index 100% rename from platform/docs/versioned_sidebars/version-2.0-sidebars.json rename to platform/docs/versioned_sidebars/version-2.0-deprecated-sidebars.json diff --git a/platform/docs/versioned_sidebars/version-3.0-sidebars.json b/platform/docs/versioned_sidebars/version-3.0-sidebars.json deleted file mode 100644 index caea0c03ba6..00000000000 --- a/platform/docs/versioned_sidebars/version-3.0-sidebars.json +++ /dev/null @@ -1,8 +0,0 @@ -{ - "tutorialSidebar": [ - { - "type": "autogenerated", - "dirName": "." - } - ] -} diff --git a/platform/docs/versions.json b/platform/docs/versions.json index 8858c6ab305..fe701e38475 100644 --- a/platform/docs/versions.json +++ b/platform/docs/versions.json @@ -1 +1 @@ -["2.0"] +["2.0-deprecated", "1.0-deprecated"] diff --git a/yarn.lock b/yarn.lock index 09ee9082529..1e36f10b442 100644 --- a/yarn.lock +++ b/yarn.lock @@ -1589,10 +1589,10 @@ resolved "https://registry.yarnpkg.com/@colors/colors/-/colors-1.5.0.tgz#bb504579c1cae923e6576a4f5da43d25f97bdbd9" integrity sha512-ooWCrlZP11i8GImSjTHYHLkvFDP48nS4+204nGb1RiX/WXYHmJA2III9/e2DWVabCESdW7hBAEzHRqUn9OUVvQ== -"@cornerstonejs/adapters@^1.1.8": - version "1.1.8" - resolved "https://registry.yarnpkg.com/@cornerstonejs/adapters/-/adapters-1.1.8.tgz#0d3ffc5befa543fe69beec9f2a66bd75d564a4c9" - integrity sha512-NOq1FTO9IY1XmjY8wE0UpBYMKiX6XFQb4Hyh7M56jRZRh5knpzReI+eIf+N4P1rYMt+I6aUqMJDQhn3QiXTvAQ== +"@cornerstonejs/adapters@^1.2.4": + version "1.2.4" + resolved "https://registry.npmjs.org/@cornerstonejs/adapters/-/adapters-1.2.4.tgz#9920ca4cae2acf064ba3165cde6da67123fbc25e" + integrity sha512-d2wl49d45QdjM9F5ATkO1g8/PoTqTSehk7wYdgEfFXmXbl8FVfaat/PAMDiyRZ65CBctmWcGcgyoFS14U9KvHQ== dependencies: "@babel/runtime-corejs2" "^7.17.8" dcmjs "^0.29.5" @@ -1640,43 +1640,43 @@ resolved "https://registry.yarnpkg.com/@cornerstonejs/codec-openjph/-/codec-openjph-2.4.2.tgz#e96721d56f6ec96f7f95c16321d88cc8467d8d81" integrity sha512-lgdvBvvNezleY+4pIe2ceUsJzlZe/0PipdeubQ3vZZOz3xxtHHMR1XFCl4fgd8gosR8COHuD7h6q+MwgrwBsng== -"@cornerstonejs/core@^1.1.8": - version "1.1.8" - resolved "https://registry.yarnpkg.com/@cornerstonejs/core/-/core-1.1.8.tgz#8040055e45fc74d91b1f6b32b8974947b696e4fc" - integrity sha512-2dcSBYhhKoHaiN7+pQkKNmH5JzymXThx+JzLzG4F5BDGYfHOL2A1bxhVsYGhnbZNIfbxBOPQuIchXJjnfwuFeg== +"@cornerstonejs/core@^1.2.4": + version "1.2.4" + resolved "https://registry.npmjs.org/@cornerstonejs/core/-/core-1.2.4.tgz#98c480f0db3cc98477f1160b47e8c686357e794b" + integrity sha512-CRrpn744m8e6damEdJaE6spF1C7/qS/h2OZiaHQnobDkJHdnSU8JHcPeP4NuMI0eRjk8NL/nGadVF4YXDOSppg== dependencies: "@kitware/vtk.js" "27.3.1" detect-gpu "^5.0.22" gl-matrix "^3.4.3" lodash.clonedeep "4.5.0" -"@cornerstonejs/dicom-image-loader@^1.1.8": - version "1.1.8" - resolved "https://registry.yarnpkg.com/@cornerstonejs/dicom-image-loader/-/dicom-image-loader-1.1.8.tgz#3202f5a1bb3c443620582535ca85fb2c5a50d779" - integrity sha512-Dltl8VSeaODZ8+T1n1vE7j0+wgCD/TJnLN/C6BnnlssH2wD6SrZyq2m3VMR9mLr104rnuegdXr1GeH0BPJ/ojw== +"@cornerstonejs/dicom-image-loader@^1.2.4": + version "1.2.4" + resolved "https://registry.npmjs.org/@cornerstonejs/dicom-image-loader/-/dicom-image-loader-1.2.4.tgz#d917768788d222918c0c5e7e29d7968922fbaf5c" + integrity sha512-b1FHjqc+j4QaWUtEw8JeQGmTsejYfbDwdIBP5GKh7EuHjrURA0N+JThau2fYHL7oNjYmDvNx9OW9A4dYswI0mg== dependencies: "@cornerstonejs/codec-charls" "^1.2.3" "@cornerstonejs/codec-libjpeg-turbo-8bit" "^1.2.2" "@cornerstonejs/codec-openjpeg" "^1.2.2" "@cornerstonejs/codec-openjph" "^2.4.2" - "@cornerstonejs/core" "^1.1.8" + "@cornerstonejs/core" "^1.2.4" dicom-parser "^1.8.9" pako "^2.0.4" uuid "^9.0.0" -"@cornerstonejs/streaming-image-volume-loader@^1.1.8": - version "1.1.8" - resolved "https://registry.yarnpkg.com/@cornerstonejs/streaming-image-volume-loader/-/streaming-image-volume-loader-1.1.8.tgz#1db9b675670d40a58c1d76120e506c4b044d1dd1" - integrity sha512-TkN7gAcGEO3JaDCyJCHcNO5EyLQLA+ndmsRIHkbaePO91Y+wY3vTsir7alBXs6PIxaM4gRNJmAdHNEKXJixMxw== +"@cornerstonejs/streaming-image-volume-loader@^1.2.4": + version "1.2.4" + resolved "https://registry.npmjs.org/@cornerstonejs/streaming-image-volume-loader/-/streaming-image-volume-loader-1.2.4.tgz#cf5c55a44cb736b220b2a7e02a4e3ffc6fc09353" + integrity sha512-MfMz6rvI+Buhd+6OSJRqGHO/8Ol2HSAcSjltXaJ0Sc5YQ6tnzNEYGqnADY/E8mLCFIj/d2l6sT3Uy76USn+ODQ== dependencies: - "@cornerstonejs/core" "^1.1.8" + "@cornerstonejs/core" "^1.2.4" -"@cornerstonejs/tools@^1.1.8": - version "1.1.8" - resolved "https://registry.yarnpkg.com/@cornerstonejs/tools/-/tools-1.1.8.tgz#dc3f73c6e9b1355d592397536a4435a2fb17cce8" - integrity sha512-uc8f2ck0mZZ5TcCw6Erz87sRM9nezpNKGELMRlBO1QR/podEUBjAxhIWnHkJf4nRSB5BGQ9+xaYKC4jZ1q54jg== +"@cornerstonejs/tools@^1.2.4": + version "1.2.4" + resolved "https://registry.npmjs.org/@cornerstonejs/tools/-/tools-1.2.4.tgz#292cc0782158811ab623ee96fb2ba9d7e2fd22e6" + integrity sha512-EM2wf1unzMZ5RPj5hCZP5SDarOO8P1uK9ORZ3aEKL0q+d0xdirKTzazp38cC+Deavda460Q9KmaHCPTtSHfE1g== dependencies: - "@cornerstonejs/core" "^1.1.8" + "@cornerstonejs/core" "^1.2.4" lodash.clonedeep "4.5.0" lodash.get "^4.4.2"