cornerstoneWADOImageLoader
cornerstoneWADOImageLoader copied to clipboard
cornerstonejs
Proof of concept decoding HTJ2K with progressive loading and rendering
Deploy Preview for cornerstone-wado-image-loader ready!
| Name | Link |
|---|---|
| Latest commit | ef8786835b33aa9bc2782752ef8825a99bab6319 |
| Latest deploy log | https://app.netlify.com/sites/cornerstone-wado-image-loader/deploys/6377c8f095ab2500090d5e2f |
| Deploy Preview | https://deploy-preview-451--cornerstone-wado-image-loader.netlify.app |
| Preview on mobile | Toggle QR Code...Use your smartphone camera to open QR code link. |
To edit notification comments on pull requests, go to your Netlify site settings.
![netlify[bot] avatar](https://avatars.githubusercontent.com/in/13473?v=4 "Published by a pub.dev verified publisher"){kind=small}
Generally LGTM - if we use a custom TSUID. Hopefully Erik can take a look as I'm not terribly familiar with the details of exactly where the codec is created.
Yeah this is really nice and a simpler PR than I was expecting. I'm personally way more interested in the WADO-RS metadata + pixel data approach though, but this has a lot of the pieces we need to get that done. Maybe we should have a NAMIC Project Week project to discusss this.
The image loader could take options when loading the pixel data like imageId?Range=0-100000 and then the next time it's called with a longer range it concatenates the result. Those changes are more for Cornerstone (3D) core than the image loader though.
I like the idea of using a query string parameter on the imageId to pass the byte range, that feels like the right way to do it since the byte range is part of the HTTP request. For other parameters that might get passed to the decoder like sub-resolution (also that might be dynamically changed after the byte-range request), I would think those should probably be exposed as a function of the image-loader to allow dynamic re-rendering.
Interesting POC!
I agree there is a lot to discuss here about what should be done at the imageLoader and volumeLoader layer as sister libraries to Cornerstone3D Core. A succinct api that overwrites/modifies the cache makes a lot sense, and I like how you have already thought about this with "datasetscachechanged" events, which makes a lot of sense.
query parameters for ranges make a lot of sense, I guess that is also something we'd have to try to get into the DICOMWeb standard.
:tada: This PR is included in version 4.3.0 :tada:
The release is available on:
Your semantic-release bot :package::rocket:
