Proposal: Review of priorities and development planning of dcmqi

[fedorov]

Project Description

dcmqi (DICOM for Quantitative Imaging) is a free, open source C++ library for conversion between imaging research formats and the standard DICOM representation for image analysis results.

This library has been around for quite some time, and gained some adoption, but has not been actively developed for the past few years. The goal of this project would be to discuss what, if anything, could be done to make it more usable and address any of the needs that users might have. Some of the specific tasks could be:

• discuss with @jcfr any topics related to the possible integration with ITK-Wasm dicom package
• revisit basic python wrapping, similar to pyplastimatch done by @denbonte
• clean up issue tracker
• discuss support of enhanced multiframe as SEG reference images and confirm understanding of the level of support of enhanced multiframe in Slicer/ITK (@michaelonken tried and failed to load any such images in Slicer)
• revisit documentation

[fedorov]

Related project: #870

[pieper]

I think it would also make sense to discuss interoperability testing with highdicom and dcmjs and maybe other tools.

[michaelonken]

discuss support of enhanced multiframe as SEG reference images and confirm understanding of the level of support of enhanced multiframe in Slicer/ITK (@michaelonken tried and failed to load any such images in Slicer)

The enhanced object I tried (Enhanced CT) loaded but reported missing slice geometry; so I am not sure whether derived objects (like segmentations exported using dcmqi) will receive the correct geometry from the underlying images. Actually I had problems with the exported segmentation that's why I want to discuss this with @pieper.

At least the part of the Slicer python code that reports the missing geometry explicity denotes that there is no support for enhanced multi-frames. On the other hand, at least Slicer displays all frames in a meaningful way and I don't know whether this comes from heuristics that kick in or parts of the Slicer code (e.g. the C++ code) that I did not look at yet.

[pieper]

@michaelonken yes, the Slicer python code reports warnings about geometry for multiframes because none of the geometry correction code has been adapted to support multiframes (although it could be added). The reader typically delegates to ITK to read the multiframes so the geometry is usually correct.

[JoostJM]

I'd like to learn a bit more on dcmqi, specifically to use it to store segmentation in DICOM SEG. If possible, I want to add this as an option in SlicerCaseIterator

[rfloca]

Even so I cannot join in person, I would be very interested to participate in that topic. There are some features that would greatly improve the integration and ease of utilization in MITK (potentially also other use cases and pipelines could profit). Would like to discuss that points and see how we could contribute.
One thing follows the discussion of QIICR/dcmqi#390, but I was wondering if it makes sense to even go further and also allow to provide the information extracted from the source DCM image in a more pragmatic form (e.g. also a json). That would allow also to use dcmqi more easily in situations where you have the needed data, but not as files and people would not need to generate DCM files or learn how to populate dcmdatasets.

[fedorov]

@rfloca great to see your interest! It will be good to meet and brainstorm this together with @michaelonken.

I do note that the last comment on the aforementioned issue says that you were going to submit a patch - can you update that issue with your current understanding and current understanding of the desired behavior?

[rfloca]

Yes, such a patch is already a long time on the todo list, but constantly more important things popped up (I guess you also know this problem).

I think the issue and its proposed solution is pretty much still valid. Depending on our upcoming discussion the project week it could become more of an prerequisite task. Because even if you provide a user-friendlier wrapper that e.g. allows the usage of json for communicating values, internally you most likely would still populated and DCMitem instance, I guess.

[fedorov]

Superseded by #942