We are labeling a large project with multiple labelers but are downloading the images onto Dropbox. Our reviewers then have to open Dropbox to review the images.
Is there a web-based project management platform where completed labeled images can get loaded automatically and reviewers can review and communicate thru the webpage? (like a commercial product like V7)/
There was some progress last week working with Kaapana for this kind of work. I’m not sure it’s ready yet but if you are willing to experiment it could be very useful.
We also saw Nora @ Project Week – a medical imaging platform that was recommended as a tool for image labeling and annotation in the cloud.
It does not look like Nora is open source. Is this correct?
@DeepaKrishnaswamy and I have been working on a Slicer extension (it is not yet in Slicer Extension index, and is not documented -but is in a public repo) that aims to streamline annotation in Slicer. It is not a solution that will look as shiny as commercial solutions, and it is work in progress looking for a “killer app”, but it is free open source and has some nice features already:
- can talk to a local Slicer database or remote DICOM server via DICOMweb
- takes care of data loading and viewer configuration
- can be configured with the pre-defined “picklist” of labels that need to be segmented
- saves segmentation results as DICOM SEG, which provides a standard way of associating annotation results with the readers
We have a “recipe” of deploying Slicer on a cloud VM here https://learn.canceridc.dev/cookbook/virtual-machines/idc-desktop, so you can leverage cloud-based DICOM stores from Google, Slicer application talking to those via authenticated DICOMweb, and access Slicer application via your browser.
If you are looking for a ready-to-go solution, it is not, but if you are looking for something to start with - you may want to consider it. We would be happy to organize a call to demonstrate the existing capabilities if you are interested - just let me know.
MONAILabel can be used for this, too. There was some prototype (MONAILabelReview) that allowed identification of users, user roles, etc. but I’m not sure if all those features have made it into MONAILabel.
Correct, source code of Nora is not publicly available. Nora might have a chance either as a product or as an open-source viewer/segmentation tool, but right now it seems to be just an internal tool that is only used by the developers and some of their collaborators.
This sounds great, it would be nice to learn more about this.
It could use the Kaapana tasklist file format that MITK uses already and I plan to add support for in Slicer.
1 Like
Interesting. I have not heard about this before. We should consider this discussion thread in that context: Storing definitions of data collections as DICOM entities - Developers - Imaging Data Commons.
From my perspective (and I think from Kaapana perspective as well), it will be rather important that the definition of task representation is developed with the understanding of requirements and implications of using DICOM for input and output of the segmentation process.
@nolden @hmeine might be interested to monitor this discussion.
Those interested, please add your voice, and we can organize a demo/discussion. We had such demos earlier for @pieper @rbumm and @lassoan I believe, but we can meet again and revisit where we are, and whether there is motivation and interest to go further.
1 Like
Kaapana takes care of collecting data from and uploading the end result to DICOMweb or other storage. But I agree that it could be useful to allow the client (Slicer, MITK, etc) use a DICOMweb or other storage directly.
It could be just a matter of adding a property that specifies storage type (local file, DICOMweb, DICOM DIMSE networking, S3, etc.) and an object that specifies storage properties (server URL, API key, …).
Of course we are talking about redefining/reimplementing features that have been around in DICOM for decades. It would make sense to look at how DICOM modality worklist/performed procedure step data structures would be suitable for this. I guess it is just too tempting to start from scratch with something really simple.
Hi all! @nolden made me aware of this thread. I’m Stefan, one of the MITK core developers. If you have any questions regarding the MITK Segmentation Task List and its file format, please do not hesitate to ask.
We originally created the file format / feature primarily for another internal project but it already sparked quite some interest in (and is used by) other projects like Kaapana. Hence, we are planning to make the format public with the upcoming MITK v2023.04 release:
- File format specification and feature documentation will be part of MITK’s documentation and help system
- The plugin/GUI on top of the MITK Segmentation Task Lists will be available in our official MITK Workbench application (currently only available in the less known, “build yourself” MITK FlowBench application).
We are happy to get any feedback and ideas for extensions in particular regarding any DICOM topics.
2 Likes
Thanks for the information @kislinsk. Have you considered adding support for alternative storage types, such as DICOMweb?
@fedorov Do you have any specific requirement in mind? Do you think DICOM worklist could/should be used for prescribing and tracking completion of manual segmentation tasks?
1 Like
Andras, I don’t have specific requirements in mind right away. I would need to spend time evaluating the alternatives and functionality available in DICOM, I have never looked into those before.
@kislinsk have you looked into the related capabilities in DICOM, such as DICOM worklist and inventory IOD while developing that format proposal?
@David_Clunie do you have any thoughts on contrasting Kaapana tasklist format and existing DICOM capabilities?
We focused on local file paths so far indeed, driven by our requirements and Kaapana’s way of providing general resource access through local files. URIs are not off the table, though, as long as complexity lies within in the intentional KISS spirit of the file format.
We had a look at these alternatives in the beginning but eventually decided to come up with our own, more simple, tailored approach for what we actually need. One of the main goals was to keep it as simple as possible and therefore easily approachable for people in our research environment compared to having a fully fledged solution for clinical routine.
That said, we see DICOM compatibility more from the perspective of I/O mapping instead of having a fully integrated DICOM workflow. For example, we have (experimental) support of DICOM SEG and try to pipe or derive important/necessary DICOM tags through from corresponding input.