Describe Your Question
So I am storing the studies directly to google storage.
Now instead of a DICOMJson , I want to provide just a basic JSON with the urls of the files. Now is it possible for the OHIF to generate the metadata required on it’s own, without me explicitly building the dicomJSON ?
This question was arised when we wanted to migrate from v2 to v3, we hadn’t stored all the metadata → hence making it unsuable with v3 as the a few mandatory metadata was absent.
Now there is a chance that this might happen again with v4-5, when we don’t have the extra metadata that might be required then. So we’d like to move away from this entirely and just provide the basic JSON with a set of files as per the DICOMJSON standard.
Which OHIF version you are using?
v3.8
right now you only option is to extract metadata and use dicomjson, but there is a PR to reduce the amount of metadata that is required
OHIF:master
← gpasquie:feat/meatada-loading
opened 09:22AM - 15 Feb 24 UTC
<!--
⚠️⚠️ Please make sure the checklist section below is complete before submi… tting your PR.
To complete the checklist, add an 'x' to each item: [] -> [x]
(PRs that do not have all the checkboxes marked will not be approved)
-->
### Context
<!--
Provide a clear explanation of the reasoning behind this change, such as:
- A link to the issue being addressed, using the format "Fixes #ISSUE_NUMBER"
- An image showing the issue or problem being addressed (if not already in the issue)
- Error logs or callStacks to help with the understanding of the problem (if not already in the issue)
-->
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
<!--
List all the changes that have been done, such as:
- Add new components
- Remove old components
- Update dependencies
What are the effects of this change?
- Before vs After
- Screenshots / GIFs / Videos
-->
### Testing
<!--
Describe how we can test your changes.
- open a URL
- visit a page
- click on a button
- etc.
-->
This can be tested using a regular JSON DataSource where only SeriesInstanceUID, StudyInstanceUID, SOPClassUID and InstanceNumber must be present.
### Checklist
#### PR
<!--
https://semantic-release.gitbook.io/semantic-release/#how-does-it-work
Examples:
Please note the letter casing in the provided examples (upper or lower).
- feat(MeasurementService): add ...
- fix(Toolbar): fix ...
- docs(Readme): update ...
- style(Whitespace): fix ...
- refactor(ExtensionManager): ...
- test(HangingProtocol): Add test ...
- chore(git): update ...
- perf(VolumeLoader): ...
You don't need to have each commit within the Pull Request follow the rule,
but the PR title must comply with it, as it will be used as the commit message
after the commits are squashed.
-->
- [x] My Pull Request title is descriptive, accurate and follows the
semantic-release format and guidelines.
#### Code
- [x] My code has been well-documented (function documentation, inline comments,
etc.)
#### Public Documentation Updates
- [] The documentation page has been updated as necessary for any public API
additions or removals.
#### Tested Environment
- [x] OS: Windows 10
- [x] Browser: Chrome 121.0.6167.161
[blog]: https://circleci.com/blog/triggering-trusted-ci-jobs-on-untrusted-forks/
[script]: https://github.com/jklukas/git-push-fork-to-upstream-branch
But you can also look at the static dicom web project to create files in the correct structure from a set of static files