Hello, I am trying to extract the Header information of a DICOM file using ITK.js. I am reading through the documentation, and I do not see anything for reading header data for DICOM. Does ITK.js support reading the header data of DICOM files?
Hello Andrew,
We would like to add this capabilitiy to itk.js.
I created the following issues:
1 Like
@aliu4, you might also be interested in looking at dcmjs which provides a javascript native way of accessing DICOM metadata (and also ways to create derived data such as DICOM SEG and SR).
We are developing it in collaboration with the OHIF and it integrates with vtkjs. I don’t think much has been done yet, but it should also be possible to move data back and forth with ITK.js as well.
2 Likes
itk.js and vtk.js already work together quite nicely.
In vtk.js, convertItkToVtkImage converts a native itk.js JavaScript image data structure to a native vtk.js image data structure.
In itk.js, a processing pipeline can directly generate a vtk.js PolyData JavaScript data structure.
2 Likes
Hi @pieper! We have some funding available to work on adding an API in itk.js to extract DICOM metadata and organize patients/studies/series. Could you offer some insight on dcmjs vs daikon? Girder uses daikon and it seemed pretty mature.
Does OHIF already provide an API that could be exported to use in itk.js directly?
We’ll be searching more about those 3 possibilities to figure out which one makes the most sense to embed in itk.js. Thank you!
2 Likes
Hi @agirault! Great to hear you are working on this - looking forward to what you learn and figure out.
I don’t know much about diakon. It looks cool and probably we should collaborate with those folks somehow, at the very least on interoperability.
Regarding dcmjs, probably the distinguishing feature is that it targets both reading and creation of dicom, so we have code for working with segmentations, reports, etc. It would be great if itk.js could use this to create correct dicom instances of analysis results with proper encoding of references to input, etc.
Also we have work in progress on dicomweb client and server code. Neither is feature complete but the server can be used as a back end to OHIF and the client work with the DICOMweb servers we use (dcm4chee, google, orthanc, etc). (As an aside, we’ve talked for a while about adding DICOMweb support to girder, and dcmjs/dicomweb-server could act as a front-end for that since it has pluggable back ends).
Yes, I think there’s a way to use OHIF and ijk.js but we haven’t gotten there yet. OHIF now has a nice extension API (something akin to Slicer) and it would make sense to use itk.js as part of extensions, probably with some further hooks.
Internally OHIF uses cornerstone’s dicomParser for most things, but we are also using dcmjs for things like segmentations. You could also use dicomParser independently as part of itk.js if you wanted to.
1 Like
Very nice, thank you @pieper. Based on this it looks like it might make more sense to use dicomParser within itk.js for reading, since it seems more mature than daikon, or maybe use dcmjs directly if it wraps dicomParser nicely to expose what’s needed… you mentioned it already integrates with vtk.js, do you have a code example of that?
Yes, if your main goal is just to read dicom, then I think dicomParser is a good choice. Also it has emscripten-ized codecs and web workers. Plus a lot of real-world use with various datasets.
dcmjs doesn’t currently wrap dicomParser per se, but long term that may be an option. For now we use them for different purposes - dicomParser for basic download and display, and dcmjs for segmentation and other derived data.
Here’s an example whre the vtk component in OHIF interacts with the dicomParser metadata provider.
On the other hand here’s the dcmjs code for converting dicom dataset into vtkjs actors. Personally I prefer this code (I’m biased) because the full dicom dataset is exposed as a javascript object with member variables named based on the dicom data dictionary. So the documentation for dcmjs datasets is just the dicom standard.
1 Like
It looks like dicomParser allows to expose the metadata from DICOM, but is there any logic elsewhere to organize the DICOM entities (patients, studies, series, such as OHIF, Slicer, etc…) that could be leveraged that you’d be familiar with? The DICOM summary example is nice but it’s really just an hardcoded html to organize the metadata, and only works for one DICOM file, not multiple files.
We’ll probably push for dicomParser given that it seems better maintained and also supported by the OHIF community, but might do some performance comparison with daikon.
Right - dicomParser is more general, since it is generally speaking slice-oriented and allows you to have various image stacks. I’m not sure how daikon handles that. In OHIF the patient/study/series organization comes for free if the data comes via dicomweb.
In dcmjs, I have been using the concept of modality-specific code to normalize acquisitions into image volumes. IMHO this is the right way to organize frames into volumes or sequences for rendering or processing because modality-specific code can be adapted to make better use of the acquisition-specific data. This is something like the dicom plugins we use in Slicer to map various dicom datasets to the corresponding Slicer data nodes.
Very good thanks, I’ll start writing some logic to sort the DICOM entities per patient/study/serie based on dicomParser and/or daikon since it appears it’s not really anywhere generic enough to be leveraged.
I’m not sure yet where those normalizers would fit in the workflow to load data with itk.js, but we can revisit that later on, thanks for the link.
Also just FYI, here is a paper that leveraged daikon to access DICOM objects on the browser: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC5603437/