---
### Author:  [@pieper](https://discourse.itk.org/u/pieper)
#### Post date: [August 23, 2019, 1:43pm UTC](https://discourse.itk.org/t/extracting-header-information-from-dicom-image/2187/3 "2019-08-23T13:43:19Z")
@aliu4, you might also be interested in looking at [dcmjs](https://github.com/dcmjs-org) 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](http://ohif.org/) and it integrates with [vtkjs](https://www.youtube.com/watch?reload=9&v=M4pJR1s60kA). 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.
---
### Author:  [@matt.mccormick](https://discourse.itk.org/u/matt.mccormick)
#### Post date: [August 28, 2019, 8:54pm UTC](https://discourse.itk.org/t/extracting-header-information-from-dicom-image/2187/4 "2019-08-28T20:54:48Z")
> [@pieper](#):
>
> 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.
itk.js and vtk.js already work together quite nicely.
In vtk.js, [`convertItkToVtkImage`](https://kitware.github.io/vtk-js/api/Common_DataModel_ITKHelper.html) 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](https://insightsoftwareconsortium.github.io/itk-js/api/browser_pipelines.html) a vtk.js PolyData JavaScript data structure.
---
### Author:  [@agirault](https://discourse.itk.org/u/agirault)
#### Post date: [September 2, 2019, 2:36pm UTC](https://discourse.itk.org/t/extracting-header-information-from-dicom-image/2187/5 "2019-09-02T14:36:53Z")
> [@pieper](#):
>
> @aliu4, you might also be interested in looking at [dcmjs](https://github.com/dcmjs-org) which provides a javascript native way of accessing DICOM metadata
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`](https://github.com/dcmjs-org) vs [`daikon`](https://github.com/rii-mango/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!
---
### Author:  [@pieper](https://discourse.itk.org/u/pieper)
#### Post date: [September 2, 2019, 5:57pm UTC](https://discourse.itk.org/t/extracting-header-information-from-dicom-image/2187/6 "2019-09-02T17:57:49Z")
> [@agirault](#):
>
> adding an API in itk.js to extract DICOM metadata and organize patients/studies/series
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](https://github.com/dcmjs-org/dicomweb-client) and [server](https://github.com/dcmjs-org/dicomweb-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).
> [@agirault](#):
>
> Does OHIF already provide an API that could be exported to use in itk.js directly?
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](https://github.com/OHIF/Viewers/tree/master/extensions) (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](https://github.com/cornerstonejs/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.
---
### Author:  [@agirault](https://discourse.itk.org/u/agirault)
#### Post date: [September 2, 2019, 6:28pm UTC](https://discourse.itk.org/t/extracting-header-information-from-dicom-image/2187/7 "2019-09-02T18:28:11Z")
> [@pieper](#):
>
> Regarding dcmjs, probably the distinguishing feature is that it targets both reading and creation of dicom […] Internally OHIF uses cornerstone’s dicomParser for most things
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?
---
### Author:  [@pieper](https://discourse.itk.org/u/pieper)
#### Post date: [September 2, 2019, 6:52pm UTC](https://discourse.itk.org/t/extracting-header-information-from-dicom-image/2187/8 "2019-09-02T18:52:48Z")
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.
> [@agirault](#):
>
> you mentioned it already integrates with vtk.js, do you have a code example of that?
Here’s an example whre the [vtk component](https://github.com/OHIF/Viewers/blob/master/extensions/vtk/src/OHIFVTKViewport.js#L60) in OHIF interacts with the dicomParser metadata provider.
On the other hand [here’s the dcmjs code](https://github.com/dcmjs-org/dcmjs/blob/master/examples/vtkDisplay/index.html#L407-L549) 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.
---
### Author:  [@agirault](https://discourse.itk.org/u/agirault)
#### Post date: [September 3, 2019, 6:17pm UTC](https://discourse.itk.org/t/extracting-header-information-from-dicom-image/2187/9 "2019-09-03T18:17:17Z")
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](https://rawgit.com/cornerstonejs/dicomParser/master/examples/dragAndDropParse/index.html) 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.
---
### Author:  [@pieper](https://discourse.itk.org/u/pieper)
#### Post date: [September 3, 2019, 7:17pm UTC](https://discourse.itk.org/t/extracting-header-information-from-dicom-image/2187/10 "2019-09-03T19:17:57Z")
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](https://github.com/dcmjs-org/dcmjs/blob/master/src/normalizers.js) 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.
---
### Author:  [@agirault](https://discourse.itk.org/u/agirault)
#### Post date: [September 4, 2019, 12:01pm UTC](https://discourse.itk.org/t/extracting-header-information-from-dicom-image/2187/11 "2019-09-04T12:01:17Z")
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/](https://www.ncbi.nlm.nih.gov/pmc/articles/PMC5603437/)