Merge pull request #423 from dannyrb/docs/reamining-cleanup
Docs/reamining cleanup
This commit is contained in:
Danny Brown
GitHub
commit
af48839414
@ -1,13 +0,0 @@
|
||||
version: '3.5'
|
||||
|
||||
services:
|
||||
viewer:
|
||||
container_name: ohif-viewer
|
||||
build:
|
||||
context: ../
|
||||
dockerfile: Dockerfile
|
||||
ports:
|
||||
- '80:80'
|
||||
environment:
|
||||
- NODE_ENV=production
|
||||
- REACT_APP_CONFIG=config/public_dicomweb
|
||||
@ -1,31 +0,0 @@
|
||||
# Guide
|
||||
|
||||
Build docker container using:
|
||||
|
||||
- Build: `docker build -t authproxy .`
|
||||
- Tag: `docker tag authproxy:latest authproxy:staging`
|
||||
|
||||
> Start your docker container, and volume mount the directory containing the
|
||||
> `nginx-keycloak.conf` configuration file. We also mount the current directory
|
||||
> under `/usr/share/nginx/html` so any html files in the current directory will
|
||||
> be hosted behind the authenticating proxy. Finally, we mapped port 80 on the
|
||||
> host to port 80 in the container.
|
||||
|
||||
`docker run -d -it -p 80:80 -v $PWD/:/config -v /:/usr/share/nginx/html authproxy -c /config/nginx.conf`
|
||||
docker run -d -it -p 80:80 -v /:/config -v /:/usr/share/nginx/html authproxy -c
|
||||
/config/nginx-keycloak.conf
|
||||
|
||||
## Orthanc
|
||||
|
||||
- Configuration
|
||||
- http://book.orthanc-server.com/users/configuration.html#configuration
|
||||
|
||||
## Keycloak
|
||||
|
||||
### Setup
|
||||
|
||||
Library we use to manage OpenID-Connect `implicit` flow:
|
||||
https://github.com/maxmantz/redux-oidc
|
||||
|
||||
- Set admin user/pass in `docker-compose`
|
||||
- What are realms?
|
||||
@ -2,12 +2,12 @@
|
||||
|
||||
- Essentials
|
||||
- [Getting Started](essentials/getting-started.md)
|
||||
- [Installation](essentials/installation.md)
|
||||
- [Data Source](essentials/data-source.md)
|
||||
- [Configuration](essentials/configuration.md)
|
||||
- [Themeing](essentials/themeing.md)
|
||||
- [Troubleshooting](essentials/troubleshooting.md)
|
||||
- [Architecture](essentials/architecture.md)
|
||||
- [Deployment](essentials/deployment.md)
|
||||
- [Scope of Project](essentials/scope-of-project.md)
|
||||
|
||||
---
|
||||
|
||||
@ -19,10 +19,6 @@
|
||||
- [Extensions](advanced/architecture.md#misc-extensions)
|
||||
- [Diagram](advanced/architecture.md#diagram)
|
||||
- [Common Questions](advanced/architecture.md#common-questions)
|
||||
- [Data](advanced/data.md)
|
||||
- [Hierarchy](advanced/data.md#hierarchy)
|
||||
- [Display Sets](advanced/data.md#display-sets)
|
||||
- [Measurements & Annotations](advanced/data.md#measurements-and-annotations)
|
||||
- [Extensions](advanced/extensions.md)
|
||||
- [Overview](advanced/extensions.md#overview)
|
||||
- [Modules](advanced/extensions.md#modules)
|
||||
@ -35,7 +31,7 @@
|
||||
- [Deployment](deployment/index.md)
|
||||
- [Embedded](deployment/index.md#embedded-viewer)
|
||||
- [Stand-alone](deployment/index.md#stand-alone-viewer)
|
||||
- [Data]()
|
||||
- [Data](deployment/index.md#data)
|
||||
- Recipes
|
||||
- Script Include
|
||||
- [Embedding the Viewer](deployment/recipes/embedded-viewer.md)
|
||||
|
||||
@ -1,17 +1,35 @@
|
||||
# Architecture
|
||||
|
||||
Looking to extend your instance of the OHIF Viewer? Want learn how to reuse _a portion_ of the Viewer in your own application? Or maybe you want to get involved and draft or suggest a new feature? Regardless, you're in the right place!
|
||||
Looking to extend your instance of the OHIF Viewer? Want learn how to reuse _a
|
||||
portion_ of the Viewer in your own application? Or maybe you want to get
|
||||
involved and draft or suggest a new feature? Regardless, you're in the right
|
||||
place!
|
||||
|
||||
The OHIF Viewer aims to be decoupled, configurable, and extensible; while this allows our code to be used in more ways, it also increases complexity. Below, we aim to demistify that complexity by providing insight into how our Viewer is architected, and the role each of it's dependent libraries plays.
|
||||
The OHIF Viewer aims to be decoupled, configurable, and extensible; while this
|
||||
allows our code to be used in more ways, it also increases complexity. Below, we
|
||||
aim to demistify that complexity by providing insight into how our Viewer is
|
||||
architected, and the role each of it's dependent libraries plays.
|
||||
|
||||
## Overview
|
||||
|
||||
The [`OHIF/Viewers`](https://github.com/OHIF/Viewers/tree/react) repository contains the source code for the OHIF Medical Imaging Viewer. It is effectively a React [progressive web app](https://developers.google.com/web/progressive-web-apps/) (PWA) that combines the business logic housed in [`OHIF/ohif-core`](https://github.com/OHIF/ohif-core) and the components in our React Component library [`OHIF/react-viewerbase`](https://github.com/OHIF/react-viewerbase). It provides customization for common use cases through [configuration](../essentials/configuration.md) and for adding functionality via [extensions](./extensions.md).
|
||||
|
||||
The [`OHIF/Viewers`](https://github.com/OHIF/Viewers/tree/react) repository
|
||||
contains the source code for the OHIF Medical Imaging Viewer. It is effectively
|
||||
a React
|
||||
[progressive web app](https://developers.google.com/web/progressive-web-apps/)
|
||||
(PWA) that combines the business logic housed in
|
||||
[`OHIF/ohif-core`](https://github.com/OHIF/ohif-core) and the components in our
|
||||
React Component library
|
||||
[`OHIF/react-viewerbase`](https://github.com/OHIF/react-viewerbase). It provides
|
||||
customization for common use cases through
|
||||
[configuration](../essentials/configuration.md) and for adding functionality via
|
||||
[extensions](./extensions.md).
|
||||
|
||||
### Business Logic
|
||||
|
||||
Our goal is to maintain the majority of our business logic in [`OHIF/ohif-core`](https://github.com/OHIF/ohif-core). `ohif-core` offers pre-packaged solutions for features common to Web-based medical imaging viewers. For example:
|
||||
Our goal is to maintain the majority of our business logic in
|
||||
[`OHIF/ohif-core`](https://github.com/OHIF/ohif-core). `ohif-core` offers
|
||||
pre-packaged solutions for features common to Web-based medical imaging viewers.
|
||||
For example:
|
||||
|
||||
- Hotkeys
|
||||
- DICOM Web
|
||||
@ -22,33 +40,46 @@ Our goal is to maintain the majority of our business logic in [`OHIF/ohif-core`]
|
||||
- [And many others](https://github.com/OHIF/ohif-core/blob/master/src/index.js#L49-L69)
|
||||
|
||||
It does this while remaining decoupled from any particular view library or
|
||||
rendering logic. While we use it to power our React Viewer, it can be used with Vue, React, Vanilla JS, or any number of other frameworks.
|
||||
|
||||
rendering logic. While we use it to power our React Viewer, it can be used with
|
||||
Vue, React, Vanilla JS, or any number of other frameworks.
|
||||
|
||||
### React Component Library
|
||||
|
||||
[`OHIF/react-viewerbase`](https://github.com/OHIF/react-viewerbase) is a React Component library that contains the reusable components that power the OHIF Viewer. It allows us to build, compose, and test components in isolation; easing the development process by reducing the need to stand-up a local PACS with test case data.
|
||||
[`OHIF/react-viewerbase`](https://github.com/OHIF/react-viewerbase) is a React
|
||||
Component library that contains the reusable components that power the OHIF
|
||||
Viewer. It allows us to build, compose, and test components in isolation; easing
|
||||
the development process by reducing the need to stand-up a local PACS with test
|
||||
case data.
|
||||
|
||||
[Check out our component library!](https://react.ohif.org/)
|
||||
|
||||
|
||||
### Misc. Extensions
|
||||
|
||||
Want to add custom logic or UI Components to the OHIF Viewer, but don't want to maintain a fork? We expose common integration points via [extensions](./extensions.md) to make that possible. For a list of extensions maintained by OHIF, [check out this helpful table](./extensions.html#ohif-maintained-extensions).
|
||||
Want to add custom logic or UI Components to the OHIF Viewer, but don't want to
|
||||
maintain a fork? We expose common integration points via
|
||||
[extensions](./extensions.md) to make that possible. For a list of extensions
|
||||
maintained by OHIF,
|
||||
[check out this helpful table](./extensions.html#ohif-maintained-extensions).
|
||||
|
||||
|
||||
If you find yourself thinking "I wish the Viewer could do X", and you can't accomplish it with an extension today, create a GitHub issue! We're actively looking for ways to improve our extensibility ^_^
|
||||
If you find yourself thinking "I wish the Viewer could do X", and you can't
|
||||
accomplish it with an extension today, create a GitHub issue! We're actively
|
||||
looking for ways to improve our extensibility ^\_^
|
||||
|
||||
[Click here to read more about extensions!](./extensions.md)
|
||||
|
||||
### Diagram
|
||||
|
||||
This diagram is a conceptual illustration of how the Viewer is architected.
|
||||
This diagram is a conceptual illustration of how the Viewer is architected.
|
||||
|
||||
0. (optional) `extensions` can be registered with `ohif-core`'s extension manager
|
||||
1. `ohif-core` provides bussiness logic and a way for `viewer` to access registered extensions
|
||||
2. The `viewer` composes and provides data to components from our component library (`react-viewerbase`)
|
||||
3. The `viewer` can be built and served as a stand-alone PWA, or as an embeddable package ([`ohif-viewer`](https://www.npmjs.com/package/ohif-viewer))
|
||||
0. (optional) `extensions` can be registered with `ohif-core`'s extension
|
||||
manager
|
||||
1. `ohif-core` provides bussiness logic and a way for `viewer` to access
|
||||
registered extensions
|
||||
1. The `viewer` composes and provides data to components from our component
|
||||
library (`react-viewerbase`)
|
||||
1. The `viewer` can be built and served as a stand-alone PWA, or as an
|
||||
embeddable package
|
||||
([`ohif-viewer`](https://www.npmjs.com/package/ohif-viewer))
|
||||
|
||||
|
||||
|
||||
@ -56,10 +87,14 @@ This diagram is a conceptual illustration of how the Viewer is architected.
|
||||
|
||||
## Common Questions
|
||||
|
||||
> When should I use the packaged source `ohif-viewer` versus building a PWA from the source?
|
||||
> When should I use the packaged source `ohif-viewer` versus building a PWA from
|
||||
> the source?
|
||||
|
||||
...
|
||||
|
||||
> 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. `react-viewerbase` would then become a guide for the components you would need to recreate.
|
||||
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. `react-viewerbase` would then become a guide for the
|
||||
components you would need to recreate.
|
||||
|
||||
@ -1 +1,8 @@
|
||||
# Tool Management
|
||||
|
||||
This is not yet exposed in an easy/convenient way. Most tools are currently
|
||||
added by creating new Viewport, Toolbar, and SOPInstanceHandler extension
|
||||
modules. You can read more about that approach in [extensions](./extensions.md).
|
||||
|
||||
In the near future, we intend to improve the extensibility of tools for existing
|
||||
Viewports (like our Cornerstone.js and VTK.js viewports).
|
||||
|
||||
@ -1,9 +0,0 @@
|
||||
# Data
|
||||
|
||||
## Hierarchy
|
||||
|
||||
Studies, Series, Instances, Frames
|
||||
|
||||
## Display Sets
|
||||
|
||||
## Measurements and Annotation
|
||||
@ -85,18 +85,6 @@ _Advanced_
|
||||
- [GCP + Cloudflare](/deployment/recipes/static-assets.md#gcp--cloudflare)
|
||||
- [Azure](/deployment/recipes/static-assets.md#azure)
|
||||
|
||||
...
|
||||
|
||||
#### Docker
|
||||
|
||||
- Why Docker?
|
||||
- Ship your environment
|
||||
- "It works on my machine"
|
||||
|
||||
_Ship Archive w/ Client:_ todo
|
||||
|
||||
...
|
||||
|
||||
## Data
|
||||
|
||||
The OHIF Viewer is able to connect to any data source that implements the [DICOM
|
||||
@ -107,27 +95,101 @@ 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](./../essentials/configuration.md).
|
||||
|
||||
### What if I don't have an imaging archive?
|
||||
#### What if I don't have an imaging archive?
|
||||
|
||||
We provide some guidance on configuring a local image archive in our
|
||||
[Data Source Essentials](./../essentials/data-source.md) 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 it's 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](deployment/recipes/nginx--image-archive.md).
|
||||
|
||||
#### What if my archive doesn't support DicomWeb?
|
||||
|
||||
> This is possible to do with the OHIF Viewer, but not as straightforward. Look
|
||||
> out for documentation on this subject in the near future.
|
||||
|
||||
...
|
||||
|
||||
#### Making sure your archive is accessible
|
||||
### Securing Your Data
|
||||
|
||||
- CORS
|
||||
- Proxy (dangers)
|
||||
- Note: PACS not meant to be directly accesible from Web
|
||||
> Feeling lost? Securing your data is important, and it can be hard to tell if
|
||||
> you've gotten it right. Don't hesitate to work with professional auditors, or
|
||||
> [enlist help from experts](./../help.md).
|
||||
|
||||
#### Securing your data
|
||||
The OHIF Viewer can be configured to work with authorization servers that
|
||||
support one or more of the OpenID-Connect authorization flows. The Viewer finds
|
||||
it's OpenID-Connect settings on the `oidc` configuration key. You can set these
|
||||
values following the instructions laid out in the
|
||||
[Configuration Essentials Guide](./../essentials/configuration.md).
|
||||
|
||||
- Reach out to experts
|
||||
- Recipes
|
||||
_Example OpenID-Connect Settings:_
|
||||
|
||||
### What if my archive doesn't support DICOM Web?
|
||||
```js
|
||||
window.config = {
|
||||
...
|
||||
oidc: [
|
||||
{
|
||||
// ~ REQUIRED
|
||||
// Authorization Server URL
|
||||
authority: 'http://127.0.0.1/auth/realms/ohif',
|
||||
client_id: 'ohif-viewer',
|
||||
redirect_uri: 'http://127.0.0.1/callback', // `OHIFStandaloneViewer.js`
|
||||
response_type: 'code', // "Authorization Code Flow"
|
||||
scope: 'openid', // email profile openid
|
||||
// ~ OPTIONAL
|
||||
post_logout_redirect_uri: '/logout-redirect.html',
|
||||
},
|
||||
],
|
||||
}
|
||||
```
|
||||
|
||||
- Mapping layer
|
||||
- GraphQL?
|
||||
You can find an example of this setup in our
|
||||
[User Account Control Deployment Recipe](deployment/recipes/user-account-control.md).
|
||||
|
||||
#### Choosing a Flow for the Viewer
|
||||
|
||||
In general, we recommend using the "Authorization Code Flow" ( [see
|
||||
`response_type=code` here][code-flows]); however, the "Implicit Flow" ( [see
|
||||
`response_type=token` here][code-flows]) can work if additonal precautions are
|
||||
taken. If the flow you've chosen produces a JWT Token, it's validity can be used
|
||||
to secure access to your Image Archive as well.
|
||||
|
||||
### 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.
|
||||
|
||||
- Script Include
|
||||
- [Embedding the Viewer](deployment/recipes/embedded-viewer.md)
|
||||
- Stand-Alone
|
||||
- [Build for Production](deployment/recipes/build-for-production.md)
|
||||
- [Static](deployment/recipes/static-assets.md)
|
||||
- [Nginx + Image Archive](deployment/recipes/nginx--image-archive.md)
|
||||
- [User Account Control](deployment/recipes/user-account-control.md)
|
||||
|
||||
<!--
|
||||
Links
|
||||
@ -142,5 +204,6 @@ support it yet, but it is gaining wider adoption.
|
||||
[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
|
||||
<!-- prettier-ignore-end -->
|
||||
|
||||
@ -65,9 +65,7 @@ how to configure the project for your own imaging archive below.
|
||||
### Configuration
|
||||
|
||||
> This step assumes you have an imaging archive. If you need assistance setting
|
||||
> one up, check out the [`Data` section](./../index.md#data) of our Deployment
|
||||
> Guide, or `Getting Started`'s
|
||||
> ["Set up a local DICOM server"](./../../essentials/getting-started.md#set-up-a-local-dicom-server),
|
||||
> one up, check out the [`Data Source` Guide](./../../essentials/data-source.md)
|
||||
> or a deployment recipe that contains an open source Image Archive
|
||||
|
||||
#### How it Works
|
||||
|
||||
@ -1,26 +0,0 @@
|
||||
# Architecture
|
||||
|
||||
The ohif-viewer package provides two different build processes:
|
||||
|
||||
## create-react-app
|
||||
|
||||
> [create-react-app](https://github.com/facebook/create-react-app) provides
|
||||
> pre-configured build process for developing front-end applications with
|
||||
> [React](https://reactjs.org/).
|
||||
|
||||
The ohif-viewer package can be run as a create-react-app application. This is
|
||||
useful for development, debugging, or evolving ohif-viewer into your own custom
|
||||
imaging application.
|
||||
|
||||
## Rollup
|
||||
|
||||
> [Rollup](https://rollupjs.org/guide/en) is a module bundler for JavaScript. It
|
||||
> uses the new standardized format for code modules included in the ES6 revision
|
||||
> of JavaScript.
|
||||
|
||||
The ohif-viewer package can be built with Rollup to provide a set of React
|
||||
components which can be dropped into a larger application. Specifically, the
|
||||
ohif-viewer package provides a React component named `OHIFViewer` which is the
|
||||
entire viewer, configurable via React `props`. This is useful for including the
|
||||
OHIF Viewer in a larger web application, as the entire application can be
|
||||
provided via a `<script>` tag with no build process required.
|
||||
@ -1 +1,57 @@
|
||||
# Configuration
|
||||
# Configuration
|
||||
|
||||
> This step assumes you have an imaging archive. If you need assistance setting
|
||||
> one up, check out the [`Data Source` Guide](./data-source.md) or a deployment
|
||||
> recipe that contains an open source Image Archive
|
||||
|
||||
## How it Works
|
||||
|
||||
The configuration for our project is in the `/public/config` directory. Our
|
||||
build process knows which configuration file to use based on the
|
||||
`REACT_APP_CONFIG` environment variable. By default, its value is
|
||||
[`default.js`](https://github.com/OHIF/Viewers/blob/react/public/config/default.js).
|
||||
When we build, the `%REACT_APP_CONFIG%` value in
|
||||
our[`/public/index.html`](https://github.com/OHIF/Viewers/blob/react/public/index.html#L12-L15)
|
||||
file is substituted for the correct configuration file's name. This sets the
|
||||
`window.config` equal to our configuration file's value.
|
||||
|
||||
## How do I configure my project?
|
||||
|
||||
The simplest way is to update the existing default config:
|
||||
|
||||
_/public/config/default.js_
|
||||
|
||||
```js
|
||||
window.config = {
|
||||
routerBasename: '/',
|
||||
relativeWebWorkerScriptsPath: '',
|
||||
servers: {
|
||||
dicomWeb: [
|
||||
{
|
||||
name: 'DCM4CHEE',
|
||||
wadoUriRoot: 'https://server.dcmjs.org/dcm4chee-arc/aets/DCM4CHEE/wado',
|
||||
qidoRoot: 'https://server.dcmjs.org/dcm4chee-arc/aets/DCM4CHEE/rs',
|
||||
wadoRoot: 'https://server.dcmjs.org/dcm4chee-arc/aets/DCM4CHEE/rs',
|
||||
qidoSupportsIncludeField: true,
|
||||
imageRendering: 'wadors',
|
||||
thumbnailRendering: 'wadors',
|
||||
requestOptions: {
|
||||
requestFromBrowser: true,
|
||||
},
|
||||
},
|
||||
],
|
||||
},
|
||||
}
|
||||
```
|
||||
|
||||
You can also create a new config file and specify its path relative to the build
|
||||
output's root by setting the `REACT_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)
|
||||
- [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)
|
||||
- Using the `cross-env` package in an npm script:
|
||||
- `"build": "cross-env REACT_APP_CONFIG=config/my-config.js react-scripts build"`
|
||||
|
||||
After updating the configuration, `yarn run build:web` to generate updated build
|
||||
output.
|
||||
|
||||
@ -27,7 +27,12 @@ For our purposes, we will be using `Orthanc`, but you can see a list of
|
||||
|
||||
### 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_
|
||||
|
||||
### Running Orthanc
|
||||
|
||||
@ -87,10 +92,37 @@ cross-env PORT=5000 REACT_APP_CONFIG=config/docker_nginx-orthanc.js react-script
|
||||
|
||||
The `REACT_APP_CONFIG` value tells our app which file to load on to
|
||||
`window.config`. By default, our app uses the file at
|
||||
`<project-root>/public/config/default.js`.
|
||||
`<project-root>/public/config/default.js`. Here is what that configuration looks
|
||||
like:
|
||||
|
||||
```js
|
||||
window.config = {
|
||||
routerBasename: '/',
|
||||
relativeWebWorkerScriptsPath: '',
|
||||
servers: {
|
||||
dicomWeb: [
|
||||
{
|
||||
name: 'Orthanc',
|
||||
wadoUriRoot: 'http://localhost:8899/wado',
|
||||
qidoRoot: 'http://localhost:8899/dicom-web',
|
||||
wadoRoot: 'http://localhost:8899/dicom-web',
|
||||
qidoSupportsIncludeField: false,
|
||||
imageRendering: 'wadors',
|
||||
thumbnailRendering: 'wadors',
|
||||
},
|
||||
],
|
||||
},
|
||||
}
|
||||
```
|
||||
|
||||
To learn more about how you can configure the OHIF Viewer, check out our
|
||||
[Configuration Guide](./configuration.md).
|
||||
|
||||
## Open Source DICOM Image Archives
|
||||
|
||||
Our example uses `Orthanc`, but there are a lot of options available to you.
|
||||
Here are some of the more popular ones:
|
||||
|
||||
| Archive | Installation |
|
||||
| --------------------------------------------- | ---------------------------------- |
|
||||
| [DCM4CHEE Archive 5.x][dcm4chee] | [W/ Docker][dcm4chee-docker] |
|
||||
|
||||
@ -1,41 +0,0 @@
|
||||
# DCM4CHEE with Docker
|
||||
|
||||
1. Install Docker (https://www.docker.com/)
|
||||
2. Follow the DCM4CHEE Guidelines for Running on Docker.
|
||||
|
||||
The easiest path is to use Docker-Compose which will start and stop multiple containers for you. There are excellent instructions provided by the DCM4CHEE team on the 'light archive' repository:
|
||||
|
||||
https://github.com/dcm4che/dcm4chee-arc-light/wiki/Running-on-Docker#use-docker-compose
|
||||
|
||||
* Create docker-compose.yml and docker-compose.env files
|
||||
* Start the containers:
|
||||
|
||||
```` bash
|
||||
docker-compose start
|
||||
````
|
||||
|
||||
**Note:** If you are running this on Mac OSX you will probably need to change the default docker-compose.yml file slightly. Specifically, the paths that refer to /var/local/ will likely need to be changed to /opt/
|
||||
|
||||
3. Run the OHIF Viewer or Lesion Tracker using the dcm4cheeDIMSE.json configuration file
|
||||
|
||||
````bash
|
||||
cd OHIFViewer
|
||||
PACKAGE_DIRS="../Packages" meteor --settings ../config/dcm4cheeDIMSE.json
|
||||
````
|
||||
|
||||
## Web Service URLs from DCM4CHEE:
|
||||
Original source here: https://github.com/dcm4che/dcm4chee-arc-light/wiki/Running-on-Docker#web-service-urls
|
||||
|
||||
> - Archive UI: <http://localhost:8080/dcm4chee-arc/ui> - if secured, login with
|
||||
|
||||
> Username | Password | Role
|
||||
> --- | --- | ---
|
||||
> `user` | `user` | `user`
|
||||
> `admin` | `admin` | `user` + `admin`
|
||||
> - Keycloak Administration Console: <http://localhost:8080/auth>, login with Username: `admin`, Password: `admin`.
|
||||
> - Wildfly Administration Console: <http://localhost:9990>, login with Username: `admin`, Password: `admin`.
|
||||
> - Kibana UI: <http://localhost:5601>
|
||||
> - DICOM QIDO-RS Base URL: <http://localhost:8080/dcm4chee-arc/aets/DCM4CHEE/rs>
|
||||
> - DICOM STOW-RS Base URL: <http://localhost:8080/dcm4chee-arc/aets/DCM4CHEE/rs>
|
||||
> - DICOM WADO-RS Base URL: <http://localhost:8080/dcm4chee-arc/aets/DCM4CHEE/rs>
|
||||
> - DICOM WADO-URI: <http://localhost:8080/dcm4chee-arc/aets/DCM4CHEE/wado>
|
||||
@ -1 +0,0 @@
|
||||
# Deployment
|
||||
42
docs/latest/essentials/installation.md
Normal file
42
docs/latest/essentials/installation.md
Normal file
@ -0,0 +1,42 @@
|
||||
# Installation
|
||||
|
||||
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:web
|
||||
|
||||
# Single `.js` script, for embedding viewer into existing apps
|
||||
yarn run build:package
|
||||
```
|
||||
|
||||
## create-react-app (PWA)
|
||||
|
||||
> [create-react-app](https://github.com/facebook/create-react-app) provides
|
||||
> pre-configured build process for developing front-end applications with
|
||||
> [React](https://reactjs.org/).
|
||||
|
||||
The ohif-viewer package can be run as a create-react-app application. This is
|
||||
useful for development, debugging, or evolving the OHIF Viewer into your own
|
||||
custom imaging application.
|
||||
|
||||
You can read more about this particular strategy in our
|
||||
[Build for Production Deployment Guide](./../deployment/recipes/build-for-production.md)
|
||||
|
||||
## Rollup (Packaged Script)
|
||||
|
||||
> [Rollup](https://rollupjs.org/guide/en) is a module bundler for JavaScript. It
|
||||
> uses the new standardized format for code modules included in the ES6 revision
|
||||
> of JavaScript.
|
||||
|
||||
The [ohif-viewer](https://www.npmjs.com/package/ohif-viewer) package can be
|
||||
built with Rollup to provide a set of React components which can be dropped into
|
||||
a larger application. Specifically, the ohif-viewer package provides a React
|
||||
component named `OHIFViewer` which is the entire viewer, configurable via React
|
||||
`props`. This is useful for including the OHIF Viewer in a larger web
|
||||
application, as the entire application can be provided via a `<script>` tag with
|
||||
no build process required.
|
||||
|
||||
You can read more about this particular strategy in our
|
||||
[Embedded Viewer Deployment Guide](./../deployment/recipes/embedded-viewer.md)
|
||||
1
docs/latest/essentials/scope-of-project.md
Normal file
1
docs/latest/essentials/scope-of-project.md
Normal file
@ -0,0 +1 @@
|
||||
# Scope of Project
|
||||
@ -57,3 +57,41 @@ open to pull requests and discussion issues.
|
||||
--viewport-border-thickness: 1px;
|
||||
}
|
||||
```
|
||||
|
||||
## 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][wikipedia]
|
||||
|
||||
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 `whiteLabelling` key to your
|
||||
[configuration file](./configuration.md).
|
||||
|
||||
```js
|
||||
function RadicalImagingLogo() {
|
||||
return React.createElement(
|
||||
'a',
|
||||
{
|
||||
target: '_blank',
|
||||
rel: 'noopener noreferrer',
|
||||
className: 'header-brand',
|
||||
href: 'http://radicalimaging.com',
|
||||
},
|
||||
React.createElement('h5', {}, 'RADICAL IMAGING')
|
||||
)
|
||||
}
|
||||
|
||||
props.whiteLabelling = {
|
||||
logoComponent: RadicalImagingLogo(),
|
||||
}
|
||||
```
|
||||
|
||||
<!--
|
||||
Links
|
||||
-->
|
||||
|
||||
<!-- prettier-ignore-start -->
|
||||
[wikipedia]: https://en.wikipedia.org/wiki/White-label_product
|
||||
<!-- prettier-ignore-end -->
|
||||
|
||||
@ -1,5 +1,9 @@
|
||||
# Troubleshooting
|
||||
|
||||
Common GitHub issues that are not easily remedied with cleaner code or
|
||||
documentation will be recorded here. Please feel free to make PRs to update this
|
||||
page.
|
||||
|
||||
## Common Problems
|
||||
|
||||
| Problem | Most Common Reasons |
|
||||
|
||||
24
src/index.js
24
src/index.js
@ -130,27 +130,3 @@ Plugins
|
||||
"displaySetCount": 1
|
||||
}
|
||||
*/
|
||||
|
||||
/*
|
||||
|
||||
White labelling example
|
||||
|
||||
// Note that you can't write JSX here, so you can use the online JSX compiler:
|
||||
// https://babeljs.io/repl/#?babili=false&browsers=&build=&builtIns=false&spec=false&loose=false&code_lz=GYVwdgxgLglg9mABACwKYBt1wBQEpEDeAUIogE6pQhlIA8AholPWQOaUC8ARAPoBG6emADWXchm5g4cAA6owqMoikVgiimTERBAZx0A5egFtU3NPQAmigLR8yQi2OSqzUKDIBcAei_2LMCHp0GCN6VhgwVgA6CDgjLgA-ElIU1LS02hDWRB0yCA4AcmQ3Tx8_AKCQsIjo2KMvAHcZa1iwKHkoLxAZLEsdLwAmAAYARgB2LxGRrwgyWTkLFrmZBetwMGNURYGomUiCxC8k9JOU2i96BIBuIgBfIiA&debug=false&forceAllTransforms=false&shippedProposals=false&circleciRepo=&evaluate=false&fileSize=false&timeTravel=false&sourceType=module&lineWrap=true&presets=react&prettier=false&targets=&version=6.26.0&envVersion=
|
||||
*/
|
||||
/*function RadicalImagingLogo() {
|
||||
return React.createElement(
|
||||
'a',
|
||||
{
|
||||
target: '_blank',
|
||||
rel: 'noopener noreferrer',
|
||||
className: 'header-brand',
|
||||
href: 'http://radicalimaging.com'
|
||||
},
|
||||
React.createElement('h5', {}, 'RADICAL IMAGING')
|
||||
);
|
||||
}
|
||||
|
||||
props.whiteLabelling = {
|
||||
logoComponent: RadicalImagingLogo()
|
||||
};*/
|
||||
|
||||
Loading…
Reference in New Issue
Block a user