Viewers: Inclusion of VTK extension causes the OHIF study viewer to crash

Created on 12 May 2020  路  13Comments  路  Source: OHIF/Viewers

Thank you for creating an amazing set of components.

I've been trying to embed the OHIF viewer into an existing web application for viewing Dicoms pulled from Orthanc, and I'm running into trouble with with the VTK plugin. Is there an minimal working example that I can inspect to see how to include it?

Right now, I'm using a checkout from the recent master branch with a custom script include build of the extension that I've adapted from the example in your documentation. Here's what the HTML and viewer initialization look like:

<body>
  ...
  <div id="root"></div>

  <!-- OHIF and Plugins -->
  <script type="text/javascript" src="/js/ohif/sonador.app-config.js" crossorigin></script>
  <script src="/js/ohif/index.umd.js" crossorigin></script>
  <script src="/js/ohif/microscopy/index.umd.js" crossorigin></script>
  <script src="/js/ohif/cornerstone/index.umd.js" crossorigin></script>
  <script src="/js/ohif/segmentation/index.umd.js" crossorigin></script>
  <script src="/js/ohif/vtk/index.umd.js" crossorigin></script>
  ...
  <!-- Initialize Viewer -->
  <script>
    // Application configuration
    var containerId = 'root';

    // Read PACS server connection from JSON string
    window.config.servers.dicomWeb = [
      JSON.parse(document.getElementById('pacs-connection').innerHTML)
    ];

    // Logos and branding for viewer
    window.config.whiteLabeling = {
      createLogoComponentFn: function(React) {
        return React.createElement('a', {
          rel: 'noopener noreferrer',
          className: 'header-brand',
        });
      }
    }

    // Extensions
    window.config.extensions = [OHIFExtDicomMicroscopy, OHIFExtCornerstone, OHIFExtDicomSeg, OHIFExtVtk];

    window.OHIFViewer.installViewer(
      // Configuration and container ID
      window.config, containerId,

      // Completion callback
      function() {
        console.log('OHIF Viewer rendered/updated');  
      }
    );
  </script>
...
</body>

The VTK extension loads okay, but when I attempt to load the study viewer, it causes everything to crash with the following error.

image

This is the relevant information from the link included in the output:

Invalid hook call. Hooks can only be called inside of the body of a function component. This could happen for one of the following reasons: 1. You might have mismatching versions of React and the renderer (such as React DOM) 2. You might be breaking the Rules of Hooks 3. You might have more than one copy of React in the same app See https://fb.me/react-invalid-hook-call for tips about how to debug and fix this problem.

Any thoughts on what might be causing this, or how it might be fixed? I'm happy to repair this and submit a merge/pull request, but need some guidance to get started.

Bug Up For Grabs

Most helpful comment

@dannyrb Thanks for responding so quickly with the suggestions. I鈥檒l start by comparing the build manifest for VTK against the other plugins, and try and spot for differences.

The project I鈥檓 working on needs the volume rendering and three dimensional capabilities of VTK, and we鈥檝e decided to build it on OHIF; so this seems like a good time and place to dig into the code.

I鈥檒l see if I can get you a merge request in the next few days. Cheers!

All 13 comments

馃憢 Hello @robertsoakes,
We primarily build and serve the PWA version of the OHIF Viewer, so the UMD packages have not been tested as extensively. I believe the VTK package has thrown this error, or a similar error, for some time.

It may be worth checking how/if it bundles React or expects it as a peerDependency. If there is a version mismatch, or if some other packages similarly conflict between @ohif/viewer and @ohif/extension-vtk.

Some potential solutions:

  1. Build and use the PWA output as a workaround (we know that this works)
  2. Investigate and fix this issue so you and others can benefit 馃帀
  3. Update our CI to build and include the PWA output as a release asset, or published to a versioned branch of this repository

    • Allowing others (and yourself) to leverage the PWA output without having to execute a build

Sorry I'm not much more help. Unfortunately, we have had the bandwidth to dig much more into this one.

@dannyrb Thanks for responding so quickly with the suggestions. I鈥檒l start by comparing the build manifest for VTK against the other plugins, and try and spot for differences.

The project I鈥檓 working on needs the volume rendering and three dimensional capabilities of VTK, and we鈥檝e decided to build it on OHIF; so this seems like a good time and place to dig into the code.

I鈥檒l see if I can get you a merge request in the next few days. Cheers!

@robertsoakes
I pointed this issue some weeks ago : https://github.com/OHIF/Viewers/issues/1003
You might find additional informations in this issue.

Would be very great if you able to fix it,

Best regards,

Salim

@robertsoakes Any good news on this?

I have the same issue with the dicom-rt extension

It's seems the script tag deployment is difficult to maintain,
I now build OHIF from sources, to generate the static build to serve, all extensions are working properly this way

@Dev-Now Unfortunately, no. We spent time trying to track it down, but couldn't find the set of clashes that appeared to be causing the issue. (The build system for OHIF is much more complicated than anything I've ever dealt with. Other members of my team have also been unable to find the source of the problem, though we strongly think it's related to incompatible versions of React or one of its dependencies.) We even had a consultant look at it, and he basically said, "I can probably figure this out, but it's going to take a lot of time to come up to speed."

Because of that, we eventually decided to re-tool. Based @dannyrb recommendation above ("Use the PWA build") we've done two things:

  • Only embed a subset of the viewer functionality (we currently use the core, PDF, HTML, and Microscopy pieces) in our Django application (see https://code.oak-tree.tech/oak-tree/medical-imaging/sonador)
  • Modifying our backend system so that it's compatible with both an embedded script and the PWA build (work on this is ongoing)

@salimkanoun

I now build OHIF from sources to generate the static build to serve, all extensions are working properly this way.

Can you expand on how you are doing this? Are you using the PWA builds or another build mechanism?

@robertsoakes just have a look at this file https://github.com/salimkanoun/Orthanc-Tools-JS/blob/dev/Dockerfile

this section grab OHIF source got from their git, install dependencies and build it to generate the build that is simply copy and pasted in a statically serve folder of my backend (in this case '/viewer' path)

FROM node:12.16.2 as ohif
RUN apt-get update -qy && \
apt-get install -y --no-install-recommends apt-utils\
git
WORKDIR /ohif
RUN git clone -b feat/scroll-sync https://github.com/OHIF/Viewers.git
WORKDIR /ohif/Viewers
RUN yarn install
RUN QUICK_BUILD=true PUBLIC_URL=/viewer/ yarn run build
WORKDIR /ohif/Viewers/platform/viewer/dist

COPY --from=ohif /ohif/Viewers/platform/viewer/dist ./build/viewer

@Dev-Now Unfortunately, no. We spent time trying to track it down, but couldn't find the set of clashes that appeared to be causing the issue. (The build system for OHIF is much more complicated than anything I've ever dealt with. Other members of my team have also been unable to find the source of the problem, though we strongly think it's related to incompatible versions of React or one of its dependencies.) We even had a consultant look at it, and he basically said, "I can probably figure this out, but it's going to take a lot of time to come up to speed."

Because of that, we eventually decided to re-tool. Based @dannyrb recommendation above ("Use the PWA build") we've done two things:

* Only embed a subset of the viewer functionality (we currently use the core, PDF, HTML, and Microscopy pieces) in our Django application (see https://code.oak-tree.tech/oak-tree/medical-imaging/sonador)

* Modifying our backend system so that it's compatible with both an embedded script and the PWA build (work on this is ongoing)

@robertsoakes Thank you for clarifying this. It is indeed complicated, I had about 4 hours of frustration before giving up and deciding to use the PWA build... Seeing your response, I am glad I did not waste more time on this.
It would have been much cleaner for our internal solution to use the UMD extensions as we have customers with different requests... But it is ok for now.

FWIW, using PWA build and code splitting on features specific to clients is a much better experience for end users.

Embedded UMD is _supposed_ to be simpler, and ideal for things like embedding in Google Collab, a Python Notebook, etc.

A few months ago when I started tinkering with the OHIF's embedded build, I ran into this problem too. At the time, it was caused by loading duplicate React at run-time. This was caused by incorrectly specified dependencies vs peer-dependencies as pointed out by @dannyrb and others. Once I move the offending react-related package into peerDependencies, everything worked out.

Although I did not include vtk or dicom-rs extension, it was my own extension.

Looking at vtk/package.json and cornerstone/package.json, I don't see any obvious culprit. The only thing that I see odd is:

extensions-cornerstone

  • peerDependencies: [react-resize-detector ^3.4.0]
  • dependencies: ['react-cornerstone-viewport']

react-cornerstone-viewport

  • dependencies: [react-resize-detector ^4.2.1]

react-resize-detector

  • does NOT specified react in its dependencies nor peer-dependencies

Perhaps the react-resize-detector should be peer-dependencies of react-cornerstone-viewport?
Just sharing my 2cents.

Edit: I've since moved on to PWA build as well, as I need much more customization than the extensions mechanism allows for.

i faced similar issue,, how to fix this? the apps crash when i'm try to build with vtk extension,, any suggestions on how to fix this?

Was this page helpful?
0 / 5 - 0 ratings

Related issues

christianvargasforero picture christianvargasforero  路  4Comments

MuriloSchaefer picture MuriloSchaefer  路  3Comments

trypag picture trypag  路  4Comments

Diegovictorbr picture Diegovictorbr  路  4Comments

ranasrule picture ranasrule  路  4Comments