[Bug] DICOM Microscopy worker is called without the Public URL

[salimkanoun]

Describe the Bug

Thanks to @wayfarer3130 PR #4891 the dicom-microscopy-viewer now can be retrieved if bundled with a public URL with this additional fix : https://github.com/OHIF/Viewers/pull/4902/files

However there is another js assets that is missing the PUBLIC_URL, which is missing PUBLIC_URL : /dicom-microscopy-viewer/index.worker.min.worker.js

It seems to from dicom-microscopy-viewer library itself.

For now the layout of dicom-microscopy-viewer starts but remains empty as the worker cannot be loaded

Steps to Reproduce

1. Use a build with public url
2. Open the microscopy mode
3. images doesn't load

The current behavior

no loading of wsi

The expected behavior

Loading of WSI should work even with public url

OS

Linux

Node version

20

Browser

Chrome

[wayfarer3130]

This is an issue in the dicom-microscopy-viewer library needing to have it's files served as /dicom-microscopy-viewer/ There isn't a good fix for it in OHIF other than mounting the files under the path that is expected. It might be possible to fix the included library as an external fix by changing to a relative dependency, but that might not work effectively either as it requires the including library (OHIF in this case) to use the right include setup path, or ensure that the wasm include paths are setup correctly to be relative to the load path for the dicom-microscopy-viewer.

[wayfarer3130]

@salimkanoun - feel free to create PR for dicom-microscopy-viewer to update the build paths as suggested. That can then be included there and then the version of the microscopy library updated in OHIF

[sedghi]

We can't really blame dicom-microscopy-viewer. If OHIF v3 has worked well with dicom-microscopy on the public URL for the past three years, it should continue to do so. We're not sure how many OHIF users share the same use case as reported in this issue. I tried to fix dicom-microscopy-viewer, but I wasn't successful.

ImagingDataCommons/dicom-microscopy-viewer#177

I believe it probably has something to do with how webpack worker is used in the UMD.