Electron Desktop Viewer

[jdexyz]

Hi,

(This is a community question) I am currently developing a new version of desktop dental application using Electron. The first version used Weasis (another DICOM viewer that requires Java). The Java requirement and the difficulty of having Electron and certain parts of Weasis communicate reliably is making us migrate towards the OHIF viewer.

Since all my DICOM files will be on a local disk, and not accessed through a server, I only need the viewer interface, and not the study list. Dental Dicoms are typically very large (300MB), and mostly 3D data.

As expected, there is a significant speed difference between loading very large files using a native application like Weasis and via the browser using the OHIF viewer.

Do you have advice on how to improve loading speed using native node modules ? What are the typical bottlenecks ? Compression algorithms ? Is there a method I should use to avoid hard coding my modifications to the viewer/loader codebase (like a low-level plugin system) ?

I would be glad to contribute an Electron version of the viewer for the community (although I guess many people are already working on this).

Best regards,

[pieper]

As expected, there is a significant speed difference between loading very large files using a native application like Weasis and via the browser using the OHIF viewer.

How are you getting the images into OHIF? That is, do you use fs to load directly or do you run a local web server?

[jdexyz]

For now I have only tried using a local web server, that statically serves dcm files as in

imageIds: [
'dicomweb://localhost:3000/DCM/03001000.dcm',
'dicomweb://localhost:3000/DCM/03001001.dcm',
...]

Is there a simple way of loading files into OHIF using fs ?

[pieper]

I haven't tried, but I've seen that fs is available in electron. You would need to dig in a bit to figure out where to hook in the buffer to the dicom parser. I can't promise that it would buy a lot of performance. Then again I can't see why electron/ohif would be slower than weasis. It might be something other than image loading. Perhaps you can find a way to do some profiling.

[jdexyz]

Ok thanks, I will dig around and report my findings. Thank you for this very impressive viewer !

[dannyrb]

This is all a bit off the cuff, so feel free to correct or point out issues. I believe the node process (main) and the renderer process (web) can communicate using an IPC Channel. I can't remember if there are any limitations around serialization or array buffers.

I think the two main performance benefits are:

• You can read from disk, instead of over the network
  • This also enables a really nice "offline" experience
• You "know" every instance will minimally support X version of Chromium

Leveraging the above two advantages would also require a bit of work.

Do you have advice on how to improve loading speed using native node modules?

You could spawn a native process that has access to a native decode? However, this might require you to build a much more intense installer for your Electron app to make sure you have everything required to accomplish this? The easier route might just be leveraging recent node WASM improvements, and refreshing our existing decoders.

What are the typical bottlenecks? Compression algorithms?

1. Network
2. Decode
3. Assembling "volume" from "slices"
4. *Memory Limitations

Is there a method I should use to avoid hard coding my modifications to the viewer/loader codebase (like a low-level plugin system)?

We have "extensions", and soon we'll have "modes". The easiest path might be to add a new image loader in an extension and identify a good path for using it's scheme. If you can wait for "modes", we add a new "data sources" concept that makes it easier to wire up data in different ways.

I would be glad to contribute an Electron version of the viewer for the community (although I guess many people are already working on this).

I'm not aware of any open source Electron variants of OHIF; although, I imagine a proof of concept example would not be too difficult. This is something I would love for us to be able to maintain, but we definitely don't have the funding/backing to do it successfully (at this time).

[jdexyz]

I am sorry, my first message was not really clear : I am very familiar with Electron (this is my 3rd large production app). I agree, a proof of concept is really quick to put together, but since this is going into production, I am really trying to make it easy to maintain (and to keep up to date with OHIF). I am very interested in these new "modes"/"Data sources". Do you think these will be available the coming months ? Thank you for the extensions suggestion, I will build one in the meantime.

Rechecking your list of bottlenecks

1. Network // Should be solved by loading directly from disk, using fs for example
2. Decode // Could use native decode
3. Assembling "volume" from "slices" // Could use native decode
4. *Memory Limitations // Probably harder to circumvent

Native node modules are not that inconvenient in Electron deployments thanks to packages like electron-rebuild which rebuild all your native dependencies for your Electron version automatically and electron-builder which creates installers for all platforms very easily. (I am currently using the native module sharp, which uses libvips, for image processing and it works like a charm.) I would be very interested in any suggestions you have on native decoders that I could leverage and that would be similar to your current decoders.

[swederik]

@jeremypatrickdahan - I've invited you to a repo that you mgiht be interested in. It's super basic right now but leverages dicomweb-server via PouchDB to include a local PACS.

[jdexyz]

@swederik thanks, I will check it out !

[ernestzhang-11]

Hello ! @jeremypatrickdahan I want to run this demo in Electron, but I failed. Could you show me your code ? Thanks !!! This is my code.

This is the result.

[jdexyz]

@zhangluwei1997 My branch is not ready, so please be patient. You are probably not loading the correct page (login) and should be loading the StudyList page. You should experiment locally with a browser before jumping into Electron.

By the way, be careful : you are enabling nodeIntegration and loading javascript from the internet which could be very dangerous. Any script you execute within a window with nodeIntegration can run arbitrary nodejs code !

[ernestzhang-11]

Thanks for your reply !! @jeremypatrickdahan I have tried load this html in Chrome by double-click html, encountered the same error.

I use parcel to run this demo, it was successful. But I load this html in Chrome by double-click html, it failed. I do not know why

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[jdexyz]

Sorry for the delay, I had to work on something else... It seems that the dicom loading and initial parsing is done in the cornerstoneWADOImageLoader package. There are a few conversion functions in the imageLoading/colorSpaceConverters folder that could benefit from being run natively for added performance (still need to check that they are a performance bottleneck before that, though). However, I am wondering how to add the modified version of the cornerstoneWADOImageLoader to the viewer. cornerstoneWADOImageLoader seems to used in platform/viewer/src/lib/localFileLoaders/fileLoaderService.js, and invoked in platform/viewer/src/connectedComponents/ViewerLocalFileData.js via platform/viewer/src/lib/localFileLoaders/fileLoaderService.js. @dannyrb , do you think I can actually use an extension to augment the methods in FileLoaderService ? I would rather not fork the monorepo and just hardcode my edits in platform/viewer/src/lib/localFileLoaders/fileLoaderService.js...

[jdexyz]

Ok my mistake, I now understand I should be adding an image loader, as nicely documented here.

[ada-s4c]

@jeremypatrickdahan - I've invited you to a repo that you mgiht be interested in. It's super basic right now but leverages dicomweb-server via PouchDB to include a local PACS.

Late to the party but was this repo what led to #1781 ? Is there any publicly available commit other than those in the PR?