Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to put images into cache that are already loaded #266

Closed
gnoeyp opened this issue Oct 27, 2022 · 3 comments
Closed

How to put images into cache that are already loaded #266

gnoeyp opened this issue Oct 27, 2022 · 3 comments

Comments

@gnoeyp
Copy link
Contributor

gnoeyp commented Oct 27, 2022

I'm trying to load volume using cornerstoneWADOImageLoader.wadouri.loadImage rather than streaming-wadors because wadors protocol is not available in my server environment.

After I loaded images and extracted meta data, I realized that I can't find a function to cache images. So currently my implementation loads images twice (for prefetch and volume generation). I wish there was a function like this: cornerstone.cacheImage(imageId, image)

@sedghi
Copy link
Member

sedghi commented Oct 27, 2022

Hey, the caching is done automatically if you have registered image loaders and using cornerstone to load them. If you can't initiate the load from cornerstone, you can look into the cach.putImageLoadObject

@gnoeyp
Copy link
Contributor Author

gnoeyp commented Oct 28, 2022

If I directly call cornerstone.createAndCacheVolume(volumeId, { imageIds }) before the images are loaded, I got an error that metadata does not exist. I think it's because the volumeLoader executes makeVolumeMetaData before loading prefetchIds. Thus I need to call cornerstone.imageLoader.loadAndCacheImage or cornerstone.imageLoader.loadImage before creating a volume.

I tried both ways, and only cornerstone.imageLoader.loadImage worked well.
What I found is, if cached images exist, cornerstone would rescale the image, which was an unexpected behavior in my app's scenario. It results the viewport looks completely white.

I am not sure the dicom files were loaded twice, because chrome network tab shows only one request per file, even though I used cornerstone.imageLoader.loadImage.

스크린샷 2022-10-28 오후 2 44 51

If the images are cached, no problem. Otherwise, it will be perfect if I can pass an argument needToRescale: boolean to createAndCacheVolume so that unexpected rescaling would not occur.

wayfarer3130 added a commit that referenced this issue Jan 20, 2023
* fix(dcmjs):The area and diameter were undefined.

The area and diameter written to the DICOM SR had
the value "undefined" because neither item was being
computed.  Also, the diameter used the area as the
actual value (which happened to be undefined).  This
change reads the values from the source adapter and
then provides them to the TID.300 adapter in the correct
places.

* Removed an unnecessary console log

* fix(dcmjs):Add a comment about the 0 dummy values
@sgielen
Copy link
Contributor

sgielen commented Oct 22, 2024

I believe this issue can be closed as soon as #1509 is merged.

  • Retrieving and storing the image data is now done manually when the image is displayed using the viewport API.
  • Caching the metadata is performed by the WADO image loader (metadata provider), if this behaviour needs to be changed then feat(image loaders): Allow reusing DICOM image loader code for custom image loaders #1509 can be used to write a custom metadata provider and/or image loader which performs the correct behaviour. Update: This has been merged. This example now shows how to do this yourself.
  • Whether to perform prescaling is now chosen automatically on main.

@sedghi sedghi closed this as completed Oct 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants