feat: cornerstone3D stack and volume viewports (#2787)
* feat: cs3d working stack viewport and tools (#19) * Squashed everything * fix weird react issue * fix eslint / prettier stuff * thumbnails work now with cpu rendering * feat: use new loadImageToCanvas in cs3d * make jump to measurement work * fix active thumbnail * fix measurement delete * fix window level presets * remove segmentation and sync groups for now * fix the dicom pdf and dicom video * fix cornerstone window assignment for cypress * apply review comments Co-authored-by: Erik <erik.sweed@gmail.com> * feat: cs3d tools and toolGroups (#20) * add more tools to work with cs3d mode * fix hotkeys * add stack manager usage for stach viewports * add image scrollbar * wip viewport overlay * fix toAnnotation schema for tools * fix the unnecessary size change that triggered resize * hanging protocol improvement to allow unmatched errors * study description matching for hanging protocol * fix the displaysetOptions to work * fix handle the active tool when a new viewport is added * fix separate toolGroups for mode * apply review comments * apply review comments * yarn lock * feat: overlay component (#21) * fix default displayset options * add viewport overlay * apply review comments * feat: loading and orientation indicators (#22) * add loading indicator * add orientation marker initial work * apply review comments * fix: orientation markers (#23) * finished the orientation markers * fix various broken cypress tests * apply review comments * update yarn lock * feat: re-working measurement tracking mode with cornerstone3d (#2805) * feat: cs3d working stack viewport and tools (#19) * Squashed everything * fix weird react issue * fix eslint / prettier stuff * thumbnails work now with cpu rendering * feat: use new loadImageToCanvas in cs3d * make jump to measurement work * fix active thumbnail * fix measurement delete * fix window level presets * remove segmentation and sync groups for now * fix the dicom pdf and dicom video * fix cornerstone window assignment for cypress * apply review comments Co-authored-by: Erik <erik.sweed@gmail.com> * feat: Add Measurement tracking mode with cs3D (#2789) * feat: first render for cornerstone3d tracked viewport * make tool active work * wip for SR extension * renamed dicom sr to cornerstone dicom sr * remove cornerstone from dicom pdf and video * move dicom sr logic to sr extension * feat: Add hydration for the length tool * fix SR display tool for length using cs3d * fix default config * fix: various bugs with sr viewport and tracking * fix promptying to continue tracking for when SR is created * feat: add keep trackign of unique identifiers * fix hydration for same imageIds * feat: Add SR toolGroup creation on modeEnter * feat: remove the need for separate mapper for SR hydration * add SR display for ellipse * handle hydration of elliptical ROI tool * remove cornerstone extension * add arrow mapping * feat: Add ArrowAnnotate SR display and hydration * apply review comments * apply review comments * move viewport labels to the viewportData * apply review comments * fix: integration cypress tests with cornerstone3D and add CINE tool (#2795) * fix: integration cypress tests with cornerstone3D * revert to addOrUpdate as it makes more sense * fix local drag and drop * fix tests * move dicomLoaderService to cornerstone extension * fix various import bugs * fix bug for local PT series * fix various unit tests * bump cs3d versions * add angle and magnify tool * bump dependencies to avoid broken peerDeps * feat: add initial work for capture using cs3d * feat: show annotations on the image capture * feat: add svg layer export * feat: Add CINE Tool * feat: remove unnecessary viewport rendering for cine state changes Co-authored-by: Erik Ziegler <erik.sweed@gmail.com> * docs: modify and improve documentation (#2800) * cleanup docs versionings * feat: Add all version explanations * version docs for 3.0 * wip for changing docs * wip for updated docs * add utility module documentation * fix demo with nohoisting of history * add slides and video to resources * apply review comments * fix: drag and drop SR into SR viewport (#2803) * update yarn lock Co-authored-by: Erik <erik.sweed@gmail.com> * update pathnames to match v3-stable * update the e2e pathname * fix: various bugs with regard to tracking workflow (#2811) * fix: various issues with measurement panel * fix: update default tool style for annotations * fix: annotatoin label getting removed * feat: Add backward compatibility for SR hydration with legacy cornerstone * fix: cursors and ellipse ROI max style * fix: ArrowAnnotate SRDisplay * apply review comments * bump package versions * fix: bugin rehydration of SR * fix: e2e tests * fix active viewport thickness and arrowTool ui * add readme for measurement tracking * use uploaded image for readme * add back images * try to fix e2e test * fix: window level presets hotkeys * Update README.md * update yarn lock * feat: volume api and TMTV mode (#2817) * feat: volumeAPI and TMTV mode * feat: use cs3d cache service to obtain viewportData * wip for volume api * wip: fusion viewport * feat: add blend mode option * wip for image scrollbar * fix drag and drop thumbnail * wip for image scrollbar for voluems * fix: element mismatch bug for scroll * feat: Add image scrollbar to volumes * feat: add syncGroups to volume api * feat: add tmtv mode initial setup * feat: add initial image options for the stack viewports * feat: Add custom load strategy for volume viewports via HP * apply review comments fix: Jump presets cs3d (#2812) * feat: Add JumpPreset to OHIF for Cornerstone3D * fix: accessing viewport service from servicesManager feat: volume API and TMTV mode (#2814) * fix: do not display overlays on mip viewports * feat: add optional disableCommands for toggle buttons * fix: toggleCrossharis * feat: config the crosshairs * feat: add PetSUV Panel for changing metadata * feat: initial work for the rectangleROIThreshold panel * wip: measurement service * roi threshold working * feat: Add displayText to segmentations * feat: add remove segmentation * feat: add csv export * feat: add RT export for annotations in tmtv mode * fix: fusion to use pt in tmtv mode and measuremet mappings * fix: various bugs * apply review comments * apply review comments * feat: add fusion color maps * add readme to tmtv mode * Update README.md * fix: try to fix build * fix unit tests * Update README.md * feat: add about to the panel * fix: changing strategy in roi panel * apply review comments * update package versions * wip for stackPrefetch * fix: cornerstone3d hydration and renaming (#2818) * update readme * renamed cornerstone extension * wip for renaming cornerstone3D variables * wip for renaming cornerstone3D variables * wip for fixing bugs for SR viewport * fix: jumpToMeasurement and initial label after hydration * fix: fileName capitalization * feat: use the new prefetch stack in the cs3d (#2820) * feat: use the new prefetch stack in the cs3d * use viewport scroll api for stack viewport * fix cine stop when scrollbar changes * feat: use new prefetch events * fix loading state to not show repeatedly * fix: various bugs for tmtv mode thresholding and new icons (#2823) * feat: make tmtv mode available in worklist * feat: add new icons for tmtv mode * feat: add fusion color icon * fix: parallel scale calculation * fix: bump Cornerstone to get large image support working * fix: Fix issues with CPU viewport flipping, including config files * fix: bump cornerstone to fix magnify tool * fix: Bump Cornerstone version to fix resetCamera issue in StackViewport * ci: Add _headers file to enable CORS headers for Netlify Drag/Drop deploys * fix: WADO-URI was not working. PET Metadata was coming from the wrong place. Fixed some minor React errors * feat(OHIF):Allow modes and extensions to be added after commpile time. (#2838) Also works with the compile time add that the existing cli uses, so that both build types work. Eric and I agreed this doesn't change existing functionality, but is almost entirely build issues/fixes. * bump: dependency versions to fix hydration bugs (#2848) * bump: dcmjs version to fix hydration bugs * try to fix tests * bump dependency versions Co-authored-by: Alireza <ar.sedghi@gmail.com> Co-authored-by: Bill Wallace <wayfarer3130@gmail.com>
This commit is contained in:
668 files changed
+41669
-13410
No files matched your search
@@ -0,0 +1,203 @@
|
||||
---
|
||||
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.
|
||||
|
||||
|
||||
|
||||
## 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.
|
||||
|
||||
<!--
|
||||
Links
|
||||
-->
|
||||
|
||||
<!-- prettier-ignore-start -->
|
||||
[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
|
||||
<!-- prettier-ignore-end -->
|
||||
Reference in new issue
Block a user