I too would really like to use the OHIF segmentation features, especially the new âpaintâ type ROIs in the latest version.
Iâve been digging through the OHIF documentation. As near as I can tell, the segmentation service is one of several services that (maybe?) runs right out of the box when launching OHIF? It is certainly working on their demo site, but it is unclear (from my read of the documentation) whether that is by default or configuration.
If I look in the browser developer console as the Orthanc OHIF plugin launches its viewing window, I see that the Segmentation service is among those being started on the javascript side. The segmentation panel shows up on the right. It just has no interactive elements like OHIFâs demo site.
I find the OHIF documentation both thin and more abstract compared to the Orthanc documentation. It is a lot easier to figure out how to configure the minutiae of Orthanc.
I tried playing around with the standalone OHIF viewer on Docker (ohif/app), but eventually gave up for lack of documentation on how to launch and/or configure it.
I tried poking around the Osimis Orthanc docker image, looking for the OHIF javascript libraries, but I suspect they are bundled by way of compilation into the Orthanc executable or OHIF plugin.
I also looked at the OHIF plugin source page on Mercurial, but I suspect I need to look into how the viewer is folded into the Osimis Orthanc docker image.
I found this information regarding services in OHIF:
That default list is missing the Segmentation Service (segmentationService).
Iâm digging into the Orthanc OHIF plugin now to see if that is something I can pass by way of the OHIF configuration file at the time of Orthanc launch, or whether it is something that needs to be compiled into the plugin.
There is some indication in the OHIF javascript in the CPUModal function that some features (including Segmentation) are dependent on the GPU. If no GPU is detected the viewer switches to CPU mode and may turn off the GPU dependent features.
In my case, I am running my web browser in a remote X-windows desktop that I suspect does not pass through GPU access.
I need to test running and accessing the Orthanc OHIF plugin directly on a machine with GPU support to see if the CPU/GPU issue is behind Segmentation not working for me.
Update: I realized that the Segmentation exam in the online OHIF Viewer demo was working for me even with my remote x-windows desktop. So, for the OHIF Plugin, it doesnât appear to be a CPU vs GPU issue that is affecting Segmentation support.
I had created this Dockerfile setup a long time ago,
I cloned my fork of the OHIF v3.6 repo and the OHIF plugin builder repo from Mercurial, built the plugin on the orthanc-builder-base layer and then copied the plugin to the osimis/orthanc version 23.9.0 layer.
This way I was able to build the plugin with some custom code and my config.js, all in one Dockerfile workflow.
I replicated the same with OHIF v3.7 and got 404 error on the path I shared.
Earlier, I was using the Orthanc builder repo and tried to target the OHIF plugin build only but for some reason, the entire project was getting built.
P.S. Alain, I would happily collaborate on this and make the custom OHIF plugin workflow faster and have an out-of-the-box solution over a hack!
In the latest Osimis docker image for Orthanc, the included OHIF plugin is reporting v3.7 in the About info.
I spent a couple days trying to get my own standalone OHIF viewer working and interacting with my Docker based Orthancs. I managed to get a demo running that referenced OHIFâs own online DICOM samples, but I found it very difficult to get OHIF to connect properly to my Orthancs. I eventually succeeded, but only be relaxing all the security measures I had in place to isolate my Orthancs.
Managing the networking, cross-site scripting issues, and SSL certs between OHIF and Orthanc is a real challenge, especially given the relatively narrow focus of the OHIF documentation.
So I really appreciate how much work the Orthanc team has already put in by bundling it into a plugin that works even if only as a viewer.
I didnât try the volume viewer itself. I am less interested in that feature.
I tried the OHIF volume viewer just now, but it wonât let me drag any volume onto the display area without complaining that it violates the hanging protocol. I donât think this is a CPU vs GPU issue, however.
In my testing of the segmentation feature, I was able to get the segmentation to work with a standalone installation of OHIF - just not in the plugin version. And these were both over the same X-windows remote desktop.
My read of the CPU vs GPU came from some error messages I found in the source code for OHIF that suggested that some features would be turned off in the absence of GPU, including segmentation. I donât recall if the volume viewer was included in that list.
Thanks, I did read through the documentation while attempting to build the standalone OHIF viewer. I did manage to get a very simple case (no SSL, no sub-domain/Proxy, no Orthanc/DicomWeb authentication) running to convince myself that the Segmentation feature did indeed work.
However, as soon as I attempted to turn on any of the other aspects (SSL, sub-domains/Proxy, Orthanc/DicomWeb authentication) I ran into errors (or blank screens) for which I could find no solution.
The only step you mention that I did not try was to build the OHIF Docker image from scratch. I tried working with the ohif/app Docker image on Docker hub and was successful at getting the bare bones demonstration I describe above working.
All of this effort is to try to track down in the configuration where the Orthanc team needs to focus in order to turn ON segmentation within their plugin. There does not appear to be much in the OHIF documentation explaining what features are on by default and what features must be explicitly turned on.
The mystery to me is why the Segmentation feature appears in the user interface as a button within the Orthanc OHIF plugin, but produces no effect when clicked. It almost appears as though a service is missing that would intercept the events, but as near as I can tell, the MeasurementService responsible is listed as running in the browser Dev console as OHIF initializes.
Otherwise, you can join the slack channel and ask questions there too Slack
I absolutely agree that there is room for improvement in certain sections of the OHIF documentation for advanced use cases. It goes without saying that we truly value and appreciate any pull requests from individuals who have taken the time to familiarize themselves with the challenges and potential solutions.
Thanks, @alainmazy, I will give that sample Docker setup a try. If I canât make any headway, Iâll sign up for the online session that @alireza suggested.
I tried your docker setup, @alainmazy, and saw the same results between the OHIF as plugin and OHIF as standalone. Now at OHIF 3.8, neither displays the segmentation capability out of the box.
I looked at the OHIF demo page online and it looks like the segmentation function directs to a different URL: âviewerâ for the viewer and âsegmentationâ for the segmentation.
As near as I can tell from the documentation, segmentation is a mode that may need to be added to the list of modes in the config js file (â@ohif-segmentation-modeâ). I tried that much with the standalone OHIF viewer in your docker setup, but that generated a âmissing moduleâ error on the javascript side in the browser. So I am guessing I am still missing some key step in either the build or configuration.
I will check with the OHIF teamâs slack and/or weekly meeting when I have a chance.
@sonaliayash, with Alainâs sample docker setup, I just left things âas isâ. I believe it uses the dicomweb approach?
For my own tests trying to spin up a standalone OHIF viewer with the OHIF/app docker image, I found the whole dicom-web aspect confusing.
There are examples of OHIF configuration files online with all three qido/wado/dicomweb URLs set to dicomweb and others where a wado URL is used. I found one example OHIF configuration where the description was left as âdcm4cheâ but the URLs were all Orthanc urls.
So, Iâm not clear on what the dicomweb settings should be. I did get a very basic setup working including segmentation as I mentioned above with all the dicomweb URLs ending in âdicom-webâ but this is not consistent with the use of at least one wado url in the OHIF example orthanc configurations.