Closed JamesAPetts closed 11 months ago
FYI @nutzlastfan @Zaid-Safadi
Hello, Using the JSON launch method, compared to version 1 of the viewer, many metadata items have been added as a requirement. Many of them (if not all) like "Columns" and "Rows" for example (as well as most pixel related metadata in the example above), are present in the dicom instance metadata and are available for the viewer once the dicom instance has been retrieved using its url. So why is this required ? Implementing this on a production web app is inefficient because it requires either preparing the metadata in advance for each study - which produces a lot of redundant data (for example, for a 2000 images MRI study, with 10 series, the StudyInstanceUID field repeats 2011 times (1 for the study level, 1 for each series and 1 for each image), or producing the metadata on the fly, which requires unnecessary compute and time (for the same reasons). The previous version of the viewer was able to render images with much less metadata. So, is there a way to get the required metadata from the dicom instances after retrieval?
What is the correct JSON for loading multiframe images ? Should the "instances" key be repeated for each frame ? (I think this is not consistent with the DICOM information model where one instance can have many frames). Or is there a "frames" section in the JSON ? Can someone point to the correct path ?
Hii all, I recently started integrating OHIF viewer for displaying DICOM images with the JSON support. I observed that we need to change ROWS, COLUMNS properties in metadata object to render DICOM images perfectly without dis-alignment.
Is there any support to give ROWS, COLUMNS values like AUTO 🤔 . or How can i get metadata of a DICOM file located in public url 🤔 . So that we can extract that data and form JSON accordingly.
I am able to view dicom images but I am facing issue with SR files to load it using json. How to load SR dicom images using this json file?
Similar to pmd23, I can view standard DICOM images but not DICOM-RT using the JSON method as the following tags are missing:
DicomTag.AcquisitionNumber: False DicomTag.PixelSpacing: False DicomTag.ImageOrientationPatient: False DicomTag.ImagePositionPatient: False DicomTag.FrameOfReferenceUID: False.
Any suggestions? Thanks in advance for your help.
Overview
Hey all,
In 3.7.8 PR #1481 revamped how we deal with metadata in OHIF. The main goal was to address these issues:
imageId
s, and instead associate metadata with theStudyInstanceUID
,SeriesInstanceUID
andSOPInstanceUID
s.imageId
, and then the images are fetched with WADO-URI (WADO-RS retrieve frames isn't supported everywhere), and then the images couldn't access their metadata from their ownimageId
.cornerstoneTools
, which expect the metadata to be provided in a legacy format.The upshot of this is now the following methods of using the application:
are all processed in the same way, and provided the DICOM headers are rich, will all be able to access the same functionality. Which was a major issue issue previously.
MetadataProvider
We now have a re-vamped metadata provider in
@ohif/core
:With which data can be added via the following method
Where the payload is either:
dcmjs
)ArrayBuffer
(a "DICOM file")The data is then indexed based on its Study, Series and SOPInstanceUIDs.
This provider is registered to cornerstone with a high priority, and data can then be retrieved by:
As standard.
The
imageId
is broken down into it's UIDs if it is a WADO-URI or WADO-RSimageId
, and the appropriate resource is fetched.imageId
s for JSON launch are auto registered as a route to the correct resource even if they are in some proprietary format, e.g.https://jamesesnicebackend/someStrangeRoute/dicom_1
.The queries you may give are:
"instance"
- Returns the entire naturalized DICOMJSON instance."imagePlaneModule"
,"voiLutModule"
, etc. Data is aggregated from the underlying DICOMJSON and is returned in the same form as cornerstoneWADOImageLoader and react-cornerstone-viewport define.JSON Launch
JSON launch has had its schema changed, to contain naturalized DICOM JSON headers:
The format is the same as before, but note
seriesList
has been renamedseries
, and under instances there are now only 2 properties:metadata
- DICOM JSON formatted metadata.url
- The url to the Part 10 DICOM.Above shows the minimum data required to use all functionality in OHIF at the time of writing. However in the general sense, if you return a full naturalized DICOM JSON header in the
metadata
property, all future content added to the repo that works with a full DICOMWeb implementation should work.naturalized DICOM JSON as the source of truth
Throughout the app any DICOM keywords have been capitalized as they are in the standard, e.g.:
sopInstanceUid
,sopInstanceUID
, etc have all becomeSOPInstanceUID
. All naturalized DICOM variables should follow this practice across the application.Naturalized DICOM JSON is DICOM JSON where the tag names are replaced with keywords, single values replaced with strings or numbers, multiple values replaced with arrays, and sequences replaced with arrays. I.e. human readable DICOM.
You can naturalize any DICOMJSON (e.g. a WADO-RS header for an instance) with
dcmjs
:Which is probably the best way to look at the format at this time, by example. At this time
dcmjs
documentation could do with some love.I believe that is all for now. Happy DICOM-ing!