Enable metadata loading from images #3935
Conversation
commit after rebase
…er no compatible data source
✅ Deploy Preview for ohif-platform-docs ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
✅ Deploy Preview for ohif-dev canceled.
|
|
This is a new version of PR #3573. Sorry for the long delay. I tried to take your comments into consideration but not sure if this was exactly what you suggested. |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #3935 +/- ##
=======================================
Coverage 44.44% 44.44%
=======================================
Files 80 80
Lines 1332 1332
Branches 327 327
=======================================
Hits 592 592
Misses 587 587
Partials 153 153 Continue to review full report in Codecov by Sentry.
|
|
Sure. This can be tested using the following JSON datasource : I started from this JSON file : https://ohif-dicom-json-example.s3.amazonaws.com/LIDC-IDRI-0001.json |
There was a problem hiding this comment.
Thanks for the PR again,
I'm trying to understand the problem that this PR is solving. I see that you are still using the DICOM JSON format to provide the Study/Series/SOP UIDs, so essentially you are providing the metadata. I am more interested in providing a manifest, and then the viewer loads the rest.
see this example
https://storage.googleapis.com/idc-volview-pilot/idc-test.json
From this project which is for Volview.
I find that really nice and believe it addresses a significant issue.
Do you think this is something you could work on?
|
In fact, in our project, we are working in an XDS like environment. A central registry gathers pointers (DICOM KOS) to DICOM images which are stored in different PACS. When the user wants to view the images, the first step is to retrieve the DICOM KOS and then to open OHIF. From the DICOM KOS, it's quite easy to generate the OHIF JSON datasource, except for the images metadata (rows, columns,…), which are not usually present in a KOS. This is why we submitted this PR, to be able to open OHIF with a reduced JSON datasource, and without too many changes in OHIF code. Opening OHIF from a manifest containing only paths to DICOM images would require much more changes in OHIF in my opinion and I'm not sure we would have the bandwidth to do so. If you think this is less complex that I think, could you please provide some guidance, and we can try to have a look |
|
Ok good to know, then I'll review this |
|
Any feedbacks/reviews on this PR ? |
|
This was on my radar, i will get to it this week, sorry for the delay |
|
Question about getting the viewer to load purely based on an array of DICOM URLs like @sedghi mentioned https://storage.googleapis.com/idc-volview-pilot/idc-test.json Couldn't it be piped down using a similar code to the local mode (https://viewer.ohif.org/local), but instead of drag and drop, just load the files from a JSON file and pass them to the FileLoaderService? @sedghi, if you provide some guidance, we could definitely attempt a PR that would implement this. |
|
@kayone and @ sebastian Here is what I think is a good way to implement it. I think we cannot and should not support the flat URLs since it will take a lot of time to load the whole thing to extract the metadata. So a middle ground would be like this: {
"studies": [
{
"series": [
// series 1
{
"instances": [
{
"url": "dicomweb:https://ohif-dicom-json-example.s3.amazon/1-001.dcm"
},
{
"url": "dicomweb:https://ohif-dicom-json-example.s3.amazon/1-002.dcm"
},
{
"url": "dicomweb:https://ohif-dicom-json-example.s3.amazon/1-003.dcm"
},
]
},
// series 2
{
"instances": [
{
"url": "dicomweb:https://ohif-dicom-json-example.s3.amazon/1-001.dcm"
},
{
"url": "dicomweb:https://ohif-dicom-json-example.s3.amazon/1-002.dcm"
},
{
"url": "dicomweb:https://ohif-dicom-json-example.s3.amazon/1-003.dcm"
},
]
}
],
}
]
}
The series are already grouped, which makes sense since on servers, the DICOMs for a series are typically stored in a folder. Then there's the issue of sorting. If the instances inside the folder are sorted (by However, if they are not properly sorted, we need to load all instances of a series to render them in order based on I hope this explanation makes sense for you to proceed. Since it's not a priority for us at the moment, let me know if you have any questions, and feel free to message me on Slack so I can assist you with this new feature. |
Context
The goal of this PR is to allow the MetadataProvider to read the metadata of dicom images directly without making an extra WADO-RS Metadata request to the PACS.
Internaly it uses dataSetCacheManager of dicomImageLoader to access the DICOM dataset. Then dcmjs parse the dataset and add the metadata to the MetadataStore.
This PR allow the DicomJSON source to provide only the image UID + instance number without the need of putting all the image metadata into the final .json.
You can enable or disable this behavior with the variable fullmetadataset in the JSON datasource.
Changes & Results
Testing
This can be tested using a regular JSON DataSource where only SeriesInstanceUID, StudyInstanceUID, SOPClassUID and InstanceNumber must be present.
Checklist
PR
semantic-release format and guidelines.
Code
etc.)
Public Documentation Updates
additions or removals.
Tested Environment