View in #cornerstone3d on Slack
@Julian_Linares: I’ve been having an issue with @Jordan_Kojouharov/dicom-image-loader 2.1.1 not finding an especific URL. Afther a while I’ve noticed it has 0 downloads so I assume something is not working with this version?
@Alireza_Sedghi: it is fairly new
so download is not important
does it work on any version of 2.x?
@Julian_Linares: downgraded to 2.1.0 and still having the same issue below. File is in my node_modules but the browser cant seem to find it, maybe its not cs related
@Alireza_Sedghi: Was it working in 1.x?
@Julian_Linares: Yes, previous cornerstoneDICOMImageLoader configuration and initialization worked perfectly. Followed the migration guide to now only use .init() and ran into it
@Alireza_Sedghi: core, tools and everything else has changed too
so it is all or none migration
@Julian_Linares: I know, migrated everything, /tools and /core worked fine but of course I cant load dicom images without the loader
@Alireza_Sedghi: hmmmm
@Ibrahim_Mohamed: looks like it’s not able to find decodeImageFrameWorker.js
maybe try to see if that file is present in node modules
i’m not sure since I didn’t try this locally
@Alireza_Sedghi: you might need to install comlink
@Julian_Linares: comlink didn’t help and the file is present in node_modules, maybe it’s related to how I’m importing the loader?
import * as cornerstoneDICOMImageLoader from '@cornerstonejs/dicom-image-loader'
...
cornerstoneDICOMImageLoader.init();
@Alireza_Sedghi: should not be
@Ibrahim_Mohamed: do you see anything in your network tab
like a 404?
404 for this decodeImageFrameWorker
refresh the page and see
@Julian_Linares: Not really, everything looks fine, except for the URL error I sent.
@Ibrahim_Mohamed: hmm Im not sure then, I know really older versions of cornerstone the decoders would need to be in the public folder since it can’t determine the path otherwise. but i don’t think this is the problem here
wait for Alireza
@Alireza_Sedghi: Doesn’t need to in 2.0 after we moved to ES modules
so pretty weird
@Julian_Linares: The "Failed to construct ‘URL’ " error persists because import.meta.url returns undefined
@Alireza_Sedghi: hmmm
That means the framework you are using does not play well with ES Modules
i’m really surprised, since all big players already have it working https://www.cornerstonejs.org/docs/getting-started/vue-angular-react-etc
React, Vue, Angular, etc. | Cornerstone.js
Take a look at the bundler in each project and see the custom config
they are using probably esbuild or something behind the scene
I know there are some issues regarding import.meta in some targets
https://github.com/search?q=repo%3Aevanw%2Fesbuild+elixir&type=issues
see this one https://github.com/evanw/esbuild/issues/408
#408 wasm filetype loader
sometimes you need to add a plugin for wasm
Keep us posted please
@Julian_Linares: Okay, I’ll investigate how Phoenix’s ES bundler works and try to find a solution, thank you very much for the help, I’ll make sure yo let you know when I make it work
@Alireza_Sedghi: maybe you need to write a cusotm extension to add to vite or something
@Julian_Linares: Good morning! So turns out in LiveView, assets like app.js are bundled in a different folder, so relative paths can break when loading external scripts like decodeImageFrameWorker.js . The way i ““fixed”” it was adding this script to my packaje.json
{
"scripts": {
"build-worker": "esbuild node_modules/@cornerstonejs/dicom-image-loader/dist/esm/decodeImageFrameWorker.js --bundle --outdir=../priv/static/assets --out-extension:.js=.worker.js --format=esm"
}
}
I run this command before starting my app to bundle the worker and its dependencies directly into the priv/static/assets folder. This way, the worker and all of its imports are packaged in a single file, making it accessible to LiveView without path conflicts.
Unluckily though this means changing how the init.js instances the new Worker
const workerFn = () => {
const workerPath = new URL('/assets/decodeImageFrameWorker.worker.js', window.location.origin);
return new Worker(workerPath, { type: 'module' });
};
After a few additional migration steps, the app now seems to be working perfectly. However, I still haven’t figured out an issue with the loading stages, which are currently managed by the IMAGE_LOADED event. I’m not yet sure if this is related to how I resolved the path issue or if it simply requires me to adapt my code further.
@Alireza_Sedghi: Does it work after this? Great progress though!
@Julian_Linares: Edited the message with more info.
@Alireza_Sedghi: Please consider creating a pr to explain liveview error in this page https://www.cornerstonejs.org/docs/getting-started/vue-angular-react-etc
React, Vue, Angular, etc. | Cornerstone.js