fix: fixing errors in documentation (#2728)
Co-authored-by: Louis-Maxime Crédeville <louis-maxime.credeville@gleamer.ai>
This commit is contained in:
parent
6c9b5ca10c
commit
fe9e7123d7
@ -76,7 +76,7 @@ https://pubmed.ncbi.nlm.nih.gov/29092955/
|
||||
|
||||
|
||||
**Note:** If you use or find this repository helpful, please take the time to
|
||||
star this repository on Github. This is an easy way for us to assess adoption
|
||||
star this repository on Github. This is an easy way for us to assess adoption,
|
||||
and it can help us obtain future funding for the project.
|
||||
|
||||
## License
|
||||
|
||||
@ -129,7 +129,7 @@ downloading the dicom file by opening the url in your browser).
|
||||
|
||||
### Local Demo
|
||||
|
||||
You can run OHIF with a JSON data source againts you local datasets (given that
|
||||
You can run OHIF with a JSON data source against you local datasets (given that
|
||||
their JSON metadata is extracted).
|
||||
|
||||
First you need to put the JSON file and the folder containing the dicom files
|
||||
|
||||
@ -137,7 +137,7 @@ value of this environment variable a few different ways:
|
||||
- ~[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 an npm script:
|
||||
- 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
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
# Theme Configuration
|
||||
When adding new theme extendible configuration items, please document
|
||||
them here. See [Theme Configuration with Config Point](#configPoint) on how to modify certain types of
|
||||
configuration values using the config-point defintions.
|
||||
configuration values using the config-point definitions.
|
||||
|
||||
## Hanging Protocols
|
||||
It is possible to customize the available hanging protocols by defining them
|
||||
@ -258,7 +258,7 @@ list: {
|
||||
}
|
||||
```
|
||||
|
||||
and and example for reference could be:
|
||||
and example for reference could be:
|
||||
```js
|
||||
// Base definition:
|
||||
MGHangingProtocol: // ... full definition of MG HP here
|
||||
@ -283,5 +283,5 @@ StudyInstancesColumn: {
|
||||
```
|
||||
Note how in the last example, the transform itself contains a reference. This
|
||||
is a function that generates a javascript function taking props, where the
|
||||
props are available directly. Thus, this props would need `study` containing
|
||||
props are available directly. Thus, these props would need `study` containing
|
||||
the appropriate child objects.
|
||||
|
||||
@ -69,7 +69,7 @@ directory. Our build process knows which configuration file to use based on the
|
||||
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 cofiguration options, check out our
|
||||
file. For more advanced configuration options, check out our
|
||||
[configuration essentials guide](../configuration/index.md).
|
||||
|
||||
## Next Steps
|
||||
|
||||
@ -112,7 +112,7 @@ 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.
|
||||
way_ to request its data.
|
||||
2. \* Your Image Archive needs to have appropriate CORS (Cross-Origin Resource
|
||||
Sharing) Headers
|
||||
|
||||
@ -224,7 +224,7 @@ More info on this JSON format can be found here
|
||||
|
||||
_CORS Issues (Cross-Origin Resource Sharing)_
|
||||
|
||||
If you host a JSON API or Images on a different domain from the the app itself,
|
||||
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
|
||||
@ -233,7 +233,7 @@ to allow your App server origin.
|
||||
|
||||
For example:
|
||||
|
||||
Lets assume your application is hosted on `https://my-ohif-server.com`.
|
||||
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`
|
||||
|
||||
|
||||
@ -9,7 +9,7 @@ sidebar_position: 4
|
||||
|
||||
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, noticably absent is user account
|
||||
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
|
||||
@ -22,12 +22,12 @@ that builds on the lessons learned here.
|
||||
|
||||
Our two biggest hurdles when hosting our image archive and web client are:
|
||||
|
||||
- Risks related to exposing our PACS to the netowrk
|
||||
- Risks related to exposing our PACS to the network
|
||||
- Cross-Origin Resource Sharing (CORS) requests
|
||||
|
||||
### Handling Web Requests
|
||||
|
||||
We mittigate our first issue by allowing [Nginx][nginx] to handle incoming web
|
||||
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.
|
||||
@ -199,7 +199,7 @@ 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
|
||||
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/)
|
||||
|
||||
@ -16,7 +16,7 @@ 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 accomodate this setup.
|
||||
to accommodate this setup.
|
||||
|
||||
_Drag-n-drop_
|
||||
|
||||
@ -111,7 +111,7 @@ Learn more about [surge.sh on their website](https://surge.sh/)
|
||||
> Websites for you and your projects. Hosted directly from your GitHub
|
||||
> repository. Just edit, push, and your changes are live.
|
||||
|
||||
This deploy strategy makes more sense if you intend to maintain your project in
|
||||
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.
|
||||
@ -140,7 +140,7 @@ 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 a update more frequently. To provide
|
||||
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
|
||||
|
||||
@ -11,7 +11,7 @@ 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 it's dependent libraries
|
||||
`OHIF Platform` is architected, and the role each of its dependent libraries
|
||||
plays.
|
||||
|
||||
## Overview
|
||||
@ -46,7 +46,7 @@ you'll see the following:
|
||||
└── README.md
|
||||
```
|
||||
|
||||
OHIF v3 is comprised of the following components, described in detail in further
|
||||
OHIF v3 is composed of the following components, described in detail in further
|
||||
sections:
|
||||
|
||||
- `@ohif/viewer`: The core framework that controls extension registration, mode
|
||||
@ -62,7 +62,7 @@ sections:
|
||||
|
||||
## Extensions
|
||||
|
||||
The `extensions` directory contains many packages that provides essential
|
||||
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:
|
||||
@ -183,7 +183,7 @@ you would need to recreate.
|
||||
|
||||
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 to consume it. This way, in future, if you needed another mode
|
||||
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.
|
||||
|
||||
|
||||
@ -15,7 +15,7 @@ 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] labled `upstream`
|
||||
- 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`
|
||||
|
||||
|
||||
@ -33,7 +33,7 @@ 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 issues requiring `triage` at least once a week
|
||||
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
|
||||
@ -97,7 +97,7 @@ appropriate:
|
||||
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 changed by a significant margin. For some
|
||||
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.
|
||||
|
||||
|
||||
@ -50,7 +50,7 @@ For running the OHIF e2e test you need to run the following steps:
|
||||
|
||||
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
|
||||
A new window will open, and you will see e2e tests being executed one after
|
||||
each other.
|
||||
|
||||

|
||||
@ -118,7 +118,7 @@ choice for asserting an element's border color.
|
||||
|
||||
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 paramater types.
|
||||
with the expected parameter types.
|
||||
|
||||
Example Tooling:
|
||||
|
||||
|
||||
@ -45,7 +45,7 @@ some community members do offer consulting services. You can search our
|
||||
|
||||
### 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
|
||||
**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
|
||||
@ -57,7 +57,7 @@ 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
|
||||
Compliant. It is the users' responsibility to ensure compliance with applicable
|
||||
rules and regulations.
|
||||
|
||||
<!--
|
||||
|
||||
@ -34,7 +34,7 @@ fixes, and target their minimum JS support whenever possible.
|
||||
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_
|
||||
discrepencies, but unimplemented features require a "temporary" implementation.
|
||||
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
|
||||
|
||||
@ -13,7 +13,7 @@ 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 of the tools from the toolbar of the cornerstone
|
||||
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.
|
||||
|
||||
@ -142,7 +142,7 @@ Extensions are building blocks that need to be registered. There are two
|
||||
different ways to register and configure extensions: At
|
||||
[runtime](#registering-at-runtime) and at
|
||||
[build time](#registering-at-build-time). You can leverage one or both
|
||||
strategies. Which one(s) you choose depend on your application's requirements.
|
||||
strategies. Which one(s) you choose depends on your application's requirements.
|
||||
|
||||
Each [module](#modules) defined by the extension becomes available to the modes
|
||||
via the `ExtensionManager` by requesting it via its id.
|
||||
@ -350,7 +350,7 @@ 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 rotate behavior.
|
||||
are used to determine the appropriate implementation of the rotation behavior.
|
||||
|
||||
<!--
|
||||
LINKS
|
||||
|
||||
@ -65,13 +65,13 @@ Note 2: You don't need to use the `@ohif` scope for your extensions. You can use
|
||||
any scope you want.
|
||||
|
||||
Note 3: Although folders names are not important and the `package.json` file
|
||||
contains the mode name, we recommend to use the same name as the folder name.
|
||||
contains the mode name, we recommend using the same name as the folder name.
|
||||
|
||||

|
||||
|
||||
### 2) Configuring OHIF
|
||||
|
||||
There are couple of places inside OHIF which we need to modify in order to add
|
||||
There are a couple of places inside OHIF which we need to modify in order to add
|
||||
the extension. The following lines of code should be added to the OHIF:
|
||||
|
||||
#### Viewer's package.json
|
||||
|
||||
@ -48,7 +48,7 @@ Each definition returned by the Commands Module is registered to the
|
||||
|
||||
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. T
|
||||
is the "command" that is actioned.
|
||||
|
||||
```js
|
||||
exampleActionDef: {
|
||||
|
||||
@ -91,16 +91,16 @@ You can take a look at `dicomweb` data source implementation to get an idea
|
||||
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 interpretting the query parameters and then
|
||||
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
|
||||
selectiton isn't too expensive.
|
||||
selection isn't too expensive.
|
||||
|
||||
## DicomMetadataStore
|
||||
|
||||
In `OHIF-v3` we have a central location for the metadata of studies and they are
|
||||
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.
|
||||
|
||||
@ -20,7 +20,7 @@ that can be displayed in the consuming application's "Panel" Component.
|
||||
|
||||
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 it's own `context` value.
|
||||
optionally provide its own `context` value.
|
||||
|
||||
The `getPanelModule` receives an object containing the `ExtensionManager`'s
|
||||
associated `ServicesManager` and `CommandsManager`.
|
||||
|
||||
@ -11,7 +11,7 @@ The mode chooses what SOPClassHandlers to use, so you could process a series in
|
||||
|
||||
|
||||
SOPClassHandler is a bit different from the other modules, as it doesn't provide a `1:1`
|
||||
schema for UI or provide it's own components. It instead defines:
|
||||
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.
|
||||
|
||||
@ -222,7 +222,7 @@ extension. To use it, you can just add the following definition to the list of
|
||||
## Custom Button
|
||||
|
||||
You can also create your own extension, and add your new custom tool appearance
|
||||
(e.g., split horizantlly instead of vertically for split tool). Simply add
|
||||
(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
|
||||
|
||||
@ -44,7 +44,7 @@ const getViewportModule = () => {
|
||||
## Example Viewport Component
|
||||
|
||||
A simplified version of the tracked CornerstoneViewport is shown below, which
|
||||
creates a cornerstone viewport and and action bar on top of it.
|
||||
creates a cornerstone viewport and action bar on top of it.
|
||||
|
||||
```jsx
|
||||
function TrackedCornerstoneViewport({
|
||||
|
||||
@ -21,7 +21,7 @@ where is the main instance of i18n containing several languages and tools.
|
||||
## 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:
|
||||
language. In summary, you can change the language:
|
||||
|
||||
- In the preference modals
|
||||
- Using the language query in the URL: `lng=Test-LNG`
|
||||
|
||||
@ -32,7 +32,7 @@ const extensionManager = new ExtensionManager({
|
||||
|
||||
- `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 binded.
|
||||
is called, the provided defaultHotkeys will get bound.
|
||||
- `destroy`: reset the HotkeysManager, and remove the set hotkeys and empty out the `defaultHotkeys`
|
||||
|
||||
|
||||
@ -42,7 +42,7 @@ 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 binded to the command
|
||||
- `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
|
||||
|
||||
|
||||
@ -293,7 +293,7 @@ properties inside the [route documentation](./routes.md)
|
||||
Currently `extensions` property in the mode config is used to add
|
||||
_contextModule_ of the mentioned extensions to the list of contexts and provide
|
||||
them through out the app. Since extensions are registered by the
|
||||
ExtensionManager, modes have access to the them even if they have not been
|
||||
ExtensionManager, modes have access to them even if they have not been
|
||||
referred in the mode config file inside _extensions_ property.
|
||||
[Read more about extension registration](../extensions/index.md#registering-an-extension)
|
||||
|
||||
|
||||
@ -7,7 +7,7 @@ sidebar_label: Lifecycle Hooks
|
||||
|
||||
## Overview
|
||||
|
||||
Currently there are two hooks that are called for modes:
|
||||
Currently, there are two hooks that are called for modes:
|
||||
|
||||
- onModeEnter
|
||||
- onModeExit
|
||||
|
||||
@ -90,7 +90,7 @@ 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
|
||||
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
|
||||
@ -114,7 +114,7 @@ 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.
|
||||
finished retrieving its instances' metadata.
|
||||
- Subscribe to `seriesAdded` event, to run the `HangingProtocolService` on the
|
||||
retrieves series from the study.
|
||||
|
||||
|
||||
@ -4,7 +4,7 @@ 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 reffered to
|
||||
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
|
||||
@ -12,7 +12,7 @@ as a ["Dumb Client"][simplicable]
|
||||
> 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 paramaters. Because of this, the Viewer
|
||||
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.
|
||||
|
||||
@ -21,7 +21,7 @@ data source.
|
||||
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 networok
|
||||
- From the local network
|
||||
- From a remote web server
|
||||
- From a CDN (content delivery network)
|
||||
- From a service-worker's cache
|
||||
@ -38,7 +38,7 @@ 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 aide our users and contributors, we attempt to provide several
|
||||
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
|
||||
@ -55,8 +55,8 @@ 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 an user
|
||||
experience that accomodates a large number of studies, you would likely need to
|
||||
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].
|
||||
|
||||
<!--
|
||||
|
||||
@ -5,7 +5,7 @@ It is a service that allows exposing internal "static" configuration data
|
||||
for modification by sites at load time by defining "theme" files. For
|
||||
information on the configuration side of things, see [theme-configuration](../../configuration/theme-conffiguration.md).
|
||||
|
||||
The service isn't a traditional OHIF service avaialble in the services
|
||||
The service isn't a traditional OHIF service available in the services
|
||||
deployment, but is rather a service which exposes static declarations of
|
||||
data as configurable data. For example, suppose a list of modalities
|
||||
was required for the search constraints. The core code might decide to
|
||||
@ -53,7 +53,7 @@ example, in the above modalities list, the original declaration is:
|
||||
{ value: 'ASMT', label: 'ASMT' },
|
||||
...
|
||||
```
|
||||
so the constant should be extracted to it's own file, but it is a fairly
|
||||
so the constant should be extracted to its own file, but it is a fairly
|
||||
simple list, so extracting it that way is fairly easy. A more complex example
|
||||
might be the columns displayed in the search page. These are directly
|
||||
referenced in the WorkList as bits of code that have both the configuration
|
||||
@ -168,7 +168,7 @@ re-render the display. It works like:
|
||||
ConfigPoint.addLoadListener(ThemeProtocols, this._listenThemeProtocols);
|
||||
```
|
||||
|
||||
This is NOT intended for listening for programatic changes to the configuration,
|
||||
This is NOT intended for listening for programmatic changes to the configuration,
|
||||
but is intended only for load time updates. Again, the idea is that the
|
||||
configuration points are constants loaded from configuration files.
|
||||
|
||||
|
||||
@ -33,7 +33,7 @@ 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
|
||||
- `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
|
||||
|
||||
@ -75,7 +75,7 @@ Let's discuss each property in depth.
|
||||
protocol gets applied to the viewer.
|
||||
- `attriubte`: 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 accept a `validator` which can be
|
||||
- `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:
|
||||
@ -94,7 +94,7 @@ Let's discuss each property in depth.
|
||||
}
|
||||
```
|
||||
|
||||
- `stages`: Each protocol can defined one or more stages. Each stage defines a certain layout and viewport rules.
|
||||
- `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.
|
||||
|
||||
- `viewportStructure`: Defines the layout of the viewer. You can define the number of `rows` and `columns`.
|
||||
@ -205,7 +205,7 @@ 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.
|
||||
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.
|
||||
|
||||
@ -6,9 +6,9 @@ sidebar_label: Overview
|
||||
# Overview
|
||||
|
||||
Data services are the first category of services which deal with handling non-ui
|
||||
related state Each services have their own internal state which they handle.
|
||||
related state Each service have their own internal state which they handle.
|
||||
|
||||
> We have replaced the _redux_ store. Instead we have introduced various
|
||||
> 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.
|
||||
|
||||
|
||||
@ -10,7 +10,7 @@ sidebar_label: Pub Sub
|
||||
Publish–subscribe pattern is a messaging pattern that is one of the fundamentals
|
||||
patterns used in reusable software components.
|
||||
|
||||
In short, services that implements this pattern, can have listeners subscribed
|
||||
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.
|
||||
|
||||
@ -71,7 +71,7 @@ async function defaultRouteInit({
|
||||
## Unsubscription
|
||||
|
||||
You need to be careful if you are adding custom subscriptions to the app. Each
|
||||
subscription will return a unsubscription function that needs to be executed on
|
||||
subscription will return an unsubscription function that needs to be executed on
|
||||
component destruction to avoid adding multiple subscriptions to the same
|
||||
observer.
|
||||
|
||||
|
||||
@ -49,7 +49,7 @@ The `ServicesManager` is:
|
||||
|
||||
- Passed to the `ExtensionManager`
|
||||
- The `ExtensionManager` makes the `ServicesManager` available to:
|
||||
- All of it's lifecycle hooks (`preRegistration`)
|
||||
- All of its lifecycle hooks (`preRegistration`)
|
||||
- Each "getModuleFunction" (`getToolbarModule`, `getPanelModule`, etc.) -->
|
||||
|
||||
## Providers for UI services
|
||||
|
||||
@ -11,7 +11,7 @@ sidebar_label: Release Notes
|
||||
## 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 include:
|
||||
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
|
||||
|
||||
@ -13,7 +13,7 @@ and other resources that we have provided to the community in the past:
|
||||
|
||||
### [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
|
||||
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)
|
||||
@ -23,7 +23,7 @@ Cornerstone in the 36th Project Week:
|
||||
|
||||
### [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
|
||||
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)
|
||||
|
||||
@ -7,7 +7,7 @@ sidebar_position: 3
|
||||
## 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`.
|
||||
<!-- We might want to make an entire section about the tracking workflow including SR hydration because it's pretty complicated. Let's review after the deploy branch is ready. Logic is in OHIF-63 OHIF-339 tickets for reference -->
|
||||
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.
|
||||
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.
|
||||
|
||||

|
||||
|
||||
|
||||
@ -31,7 +31,7 @@ In the following, we will discuss each category.
|
||||

|
||||
|
||||
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 pormpt, 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.
|
||||
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
|
||||
@ -80,7 +80,7 @@ The full workflow for saving measurements to SR and loading SR into the viewer i
|
||||

|
||||
|
||||
|
||||
#### Overview video for loading DICOM SR and making a tracked sereis:
|
||||
#### Overview video for loading DICOM SR and making a tracked series:
|
||||
<!-- SR Restore and Yes -->
|
||||
|
||||
<div style={{padding:"56.25% 0 0 0", position:"relative"}}>
|
||||
@ -115,7 +115,7 @@ you cannot edit the DICOM SR measurement.
|
||||
<br></br>
|
||||
|
||||
|
||||
#### Overview video for loading DICOM SR inside an already tracked sereis:
|
||||
#### Overview video for loading DICOM SR inside an already tracked series:
|
||||
<!-- DICOMSRLockedTracked -->
|
||||
|
||||
|
||||
|
||||
@ -21,9 +21,9 @@ This section displays all the available tools inside the mode.
|
||||
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 longest diameter (LD) and longest perpendicular diameter (LPD) 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 ellipical area in *mm<sup>2</sup>* and Hounsfield Units (HU)
|
||||
- Ellipse: Measures an elliptical area in *mm<sup>2</sup>* and Hounsfield Units (HU)
|
||||
|
||||
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.
|
||||
<!-- We should add a smaller screenshot for each measurement tool. Maybe have a matrix with 4 identical sized screenshots in a box? Also we should make sure the screenshots have more realistic measurements -->
|
||||
|
||||
@ -10,7 +10,7 @@ renders series.
|
||||

|
||||
|
||||
|
||||
By default you can modify:
|
||||
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
|
||||
|
||||
Loading…
Reference in New Issue
Block a user