View in #cornerstone3d on Slack
@Peter_Newhook: Should metadata be fully loaded and cached before an image loader runs? I need to load JPGs for the images because we have an enhancement process that sharpens the image, but I’m writing a custom metadata provider that fetches the original DICOM to get metadata. Do I need to be conscious of the order between image and metadata loader?
@Syed_Pasha: you can ask this question in the office hour that is going on now
https://cornerstonejs.slack.com/archives/C9H262R2N/p1734616801043289
[December 19th, 2024 6:00 AM] ar.sedghi: Just a quick reminder that OHIF office hours will begin in ~60 minutes . If you’ve already asked your questions on the community forum, GitHub, or here on Slack and haven’t received a response yet, this is a fantastic opportunity for you to directly communicate with the maintainers of OHIF and Cornerstone3D. Feel free to join and ask any remaining questions you may have.
This is our last office hours of the year
• add your questions https://docs.google.com/document/d/15VlOD9a7UVjzET-3soT6uSPIqZMv76ev_rVjfWeMxXc/edit?usp=sharing|here
• join via zoom https://us02web.zoom.us/j/87832646908?pwd=SEcrSnlBcGFwOVhQWEJjMnZQb1JBdz09|here
@Peter_Newhook: Thanks, I’ll join in 10 minutes.
Thanks again for your input during office hours @Alireza_Sedghi.
It looks like the dicom-image-loader fetches metadata before it fetches images, would you be able to point out how it ensures the metadata cache is filled before images are loaded?
@Alireza_Sedghi: since we don’t create viewport or anything before that
createImageIdsAndCache is very first
@Peter_Newhook: I meant more in general usage of Cornerstone, not strictly the examples. Looks like OHIF Viewer pulls metadata first. That might be a WADO-RS convenience since it knows where the metadata endpoint is?
I think my confusion comes from the fact the metadata provider is a very simple interface. It handles reading metadata, but since it’s synchronous it’s not obvious to me what the convention is to fetch metadata.
@Alireza_Sedghi: yes in OHIF , data sources run first, hitting the server with metadata
you can look at these files
The first thing in OHIF that mounts after study is opened platform/app/src/routes/Mode/Mode.tsx
and extensions/default/src/DicomWebDataSource/index.ts
for how it handles metadata
and platform/app/src/routes/Mode/defaultRouteInit.ts
which uses
const allRetrieves = studyInstanceUIDs.map(StudyInstanceUID =>
dataSource.retrieve.series.metadata({
StudyInstanceUID,
filters,
returnPromises: true,
sortCriteria:
customizationService.get('sortingCriteria') ||
sortingCriteria.seriesSortCriteria.seriesInfoSortingCriteria,
})
);
@Peter_Newhook: I’ll investigate this. Thanks a lot.
I’m calling cornerstoneDICOMImageLoader.wadouri.loadImage
and able to load an IImage
. However, I was expecting loading an image would store metadata for that image on the wadouri metadataProvider
, but that appears to not be the case. Can you confirm a few things:
Calling cornerstoneDICOMImageLoader.wadouri.loadImage
direct is the correct way to load a DICOM file in scenarios I’m not loading them directly into a viewport?
If a DICOM is loaded with loadImage
is metadata cached somewhere?
If it is not, are the utility functions I should be using to parse and cache the IImage
returned by loadImage
?
Nevermind, the DICOM file wasn’t loading correctly in the first place. After loading the image, I can read the metadata.