We have various points-of-interest in our software and would like to export them into DICOM format files. To my understanding, the correct format for this would be DICOM Structured Reports (SR) and its planar annotations. Is there any handy way to export ITK points into DICOM SR? The export should be in world coordinates i.e. in the same space as the original image. Internally our points are of types itk::Point and itk::Index, the software written in C++ and we are using ITK version 5.0.1.
I believe I could try to build my own exporter by modifying respective DICOM tags ((0040,A040),(0070,0023) etc) by hand via MetaDataDictionary::Set() method, but I wish there was a more automated and validated way.
Of course, I could export the points as an image mask or overlay, but this is not the most elegant way. Any custom text file export is out of the question, because we want the exported data to be readable in all DICOM viewers.
@dzenanz thank you for pinging me, I really appreciate it!
@hapap overall, you would not be modifying any of the DICOM tags in your images being annotated. Instead, you would need to create a new DICOM series of SR modality, which would contain a structured report that follows the standard template TID 1500. Unless you are really curious how the standard works, I would not encourage you to study in detail the link above, but instead use an existing library that abstracts SR complexities and provides API to populate the content.
For that purpose I recommend you take a look at highdicom.
@dzenanz thank you for the shout out for dcmqi, but unfortunately it does not have the relevant functionality. TID 1500 is rather versatile, allowing to capture quantitative and qualitative measurements at the level of individual image/series or study, associated with point/planar or volumetric annotations. dcmqi is built around APIs provided in DCMTK dcmsr library and implements a narrow “branch” of TID 1500 to encode/decode measurements derived from a volumetrically defined image region (measurements derived from DICOM segmentations).
highdicom is built on top of pydicom, and (among many other things) provides a more comprehensive coverage of TID 1500, including planar and point annotations.
However, unlike dcmqi, which provides command line converters that read/write supported types of DICOM containers, parametrized by dcmqi-specific JSON, highdicom is just a library, and task-specific conversion code needs to be written by the user, which (IMHO!) can be rather difficult for those who do not have experience using DICOM for encoding image-derived content.
In a related project, I started working on a script that takes point annotations for one of the publicly available collections and encodes those as DICOM SR. I worked on that more than a year ago, and by now highdicom API may have changed, but in any case it might be helpful to @hapap, so I committed that here: TCIA-IDC-Coordination/issue-27-prostatex/ProstateX_conversion.ipynb at master · ImagingDataCommons/TCIA-IDC-Coordination · GitHub. This post adds motivation for me to get back to that project and complete the task. Harri - take a look and let me know if this helps or if you have any further questions. I will be happy to help as much as I can, and if I am stuck we can ask help from Markus Herrmann and Chris Bridge, who are the developers of highdicom.
Bridge, C. P., Gorman, C., Pieper, S., Doyle, S. W., Lennerz, J. K., Kalpathy-Cramer, J., Clunie, D. A., Fedorov, A. Y. & Herrmann, M. D. Highdicom: a Python Library for Standardized Encoding of Image Annotations and Machine Learning Model Outputs in Pathology and Radiology. J. Digit. Imaging35, 1719–1737 (2022). http://dx.doi.org/10.1007/s10278-022-00683-y
@fedorov Highdicom sounds like exactly something I want - except it seems to be only in Python. I do like doing Python in my AI projects, but unfortunately in this case we are restricted to C++. We are dealing with a regulated medical device and including Python library into the software would cause all kind of validation and verification hassle or something. And the decision to include Python is not in my hands anyway, I’m just a simple coder.
So, there’s no C++ version of highdicom, right? Even a command line tool would suffice for now, but I guess it’s not so straightforward to convert Python codes into something that could be run as a stand-alone executable? At least I didn’t manage to do it in another project couple of years ago.
Thanks for the link to NCI. Some examples of DICOM SR data would surely be helpful at this stage. Previously I have used data form The Cancer Imaging Archive (TCIA) and NCI looks quite similar to that. Maybe their databases are overlapping or even two way to access the same data?
Maybe there’s no sense in trying to write my own DICOM SR exporter. At this stage, all I need to export is a handful of points with coordinates and I could copy all the other tags from the original DICOM image data. I have some experience on getting my hands dirty with reading/modifying/writing DICOM tags even from binary stream, and perhaps I would succeed. But in the future we need to export various segmentations and perhaps brain tractograpy stuff anyway, so maintaining my own exporter would soon become quite a heavy task. With segmentations dcmqi should prove to be handy. Thanks @dzenanz!
It’s a pity indeed I cannot use Python in this project as highdicom would have solved many of my current and upcoming problems.
Harri, thank you for the clarification. It’s an interesting extra motivation for supporting C++ tools…
IDC is a cloud-based (Google Cloud Platform based) repository that contains data from several existing data repositories and data coordinating centers. It includes all of TCIA DICOM public content, but also contains DICOM digital pathology and fluorescence imaging collections that are not in TCIA.
Putting aside differences in the content of the repository, IDC is more than a repository from where you can download the data. You can use IDC to search and subset 45 TB of data based on DICOM metadata defined via SQL queries, visualize both radiology and pathology images and annotations using open-source DICOM-based viewers, develop and share complete analysis workflows using Colab interacting with IDC data. The tutorial I linked before hopefully can demonstrate those capabilities, if you are interested.
highdicom would be the most expedient option, but if you need to do it in C++ it should not be too too bad. You should review the APIs in DCMTK dcmsr module DCMTK: dcmsr: a structured reporting library and utility apps. You can either use a subset of the API to build the initial TID 1500 SR DCMTK: TID1500_MeasurementReport Class Reference, which you could then modify by interacting directly with the SR tree using DCMTK API to add the content items to support your use case, or you could implement API to support the sections of the template needed for your application.
DCMTK developers and community are very supportive, so you could bring this up for discussion in their forum: https://forum.dcmtk.org/. If you wanted to contribute this missing functionality to dcmqi, this would also be a welcomed addition.
In either case, you can use highdicom to experiment with creating valid SRs of the kind you need and to understand the structure of the content tree, before jumping into the implementation (either using DCMTK or your internal code).
It seems dcmsr indeed looks like a good place to start from. I see there’s xml2dsr conventer - would this serve my purposes? A quick and dirty solution at this point could be to create an XML file containing my point coordinates and then convert it with xml2dsr into DICOM SR. If this works, I believe it wouldn’t take much effort to remove the unnecessary file write-read step from this and feed the XML information directly to respective function in xml2dsr.
By the way, are you aware how widely supported these DICOM SRs are? One of our priorities is of course that the exported points would be easily opened in other programs (often by people with minimal technical skills such as medical doctors). I tried to open some DICOM SR files from a TCIA dataset, but was not very successful. I guess 3DSlicer could handle them but MIPAV was behaving quite badly. Some image viewers like ITK-SNAP are not really even designed to show point-like structures.
With quick look dcmsr copyright allows commercial use as long as the copyright text is attached, right? This is not a my head ache anyway, legal people will check the licence if needed.
I’m travelling this week so I may not have time to implement any code yet, but this seems promising now.
Aha! Indeed, I completely forgot about that tool! Yes, this is yet another practical path forward. I personally have never used this approach, but it should be quite feasible, so would be very interested to hear about your experience with it.
Not widely at all, unfortunately.
But I do not think there is a non-standard alternative that is widely supported either. Reality is that standardization of images into DICOM was driven by the radiology clinical needs, and unfortunately interoperability of machine-readable image-derived content - be it segmentations, measurements, annotations, diffusion tracts - has not been a priority in the clinic (with the notable exception of radiotherapy applications, but maybe there are others I can’t think of right away).
Depending on the flavor of TID 1500 SR, OHIF Viewer may be able to meet your needs. We’ve been adding support for some of these features driven by the needs of the IDC project, and we will continue to do so, and there is good momentum centered on DICOM in the OHIF community.