Page MenuHomePhabricator

A segmentation should generate all DICOM relevant IDs as soon as it can be referenced.
Closed, WontfixPublic


Currently, to my knowledge, semgentions written to DICOM generate there relevant DICOM IDs not before they are stored.

I think this is to late and I would open a discussion about it to clarify how we handle it in the future. Especialle with the advent of the new segmentation design and the introduced PropertyRelations this is an important thing to do as early as possible.

Reason: If we generate the DICOM UID on saving, we cannot establish PropertyRelationRules that are based on ths information. Example: Generation of perfusion maps by using a ROI (that is defined by a segmentation). The cleanist way would be by using a relation rule that establishes the relation on the data layer by setting the DICOM source information in the paramter image by using the DICOM UID information of the segmentation.
This is only possible whe nthe UID of the segmentation is already there. You could think of lazy mechanisms that establish a connection and propagetes the UID as soon as it exists and also requests the UID when it is needed ther first time. But I think this is not a good road to go and leads to code that is ugly to maintaine and understand without solving the underlying problem.

Motivation for the UID-generation-on-writing was the fact, that segmentations could be altered while MITK is running and thus the UID has to be another. (Comment but this strategy will only work if you always generat a new UID when writing the segmentation, even when the content has not changed and it is the same IOD; otherwise you cannot cope with a DICOM-seg-loaded-altered-stored scenario)

I think the best and cleanest solution would be to generate the UIDs as soon as a segmentation is "accepted" (meaning that it is "publicly" in the data storage and can be seen and referenced by other (plugins/data). If a segmentation is altered again it must be cloned. And you alter the clone.
How to deal with the original is a usability thing e.g.

  1. just keep it, but clone has its "position" now. So it looks like the orginal has been added.
  2. just keep it, but orginal keeps its "position". So it looks like the clone has been added.
  3. clone replaces the original

We surely have to look carefully on the usability/workflows to make them slike and not cumbersome due to the cloning, but I think that is doable and would end in a much cleaner solution.

What do you think?

Related Objects


Event Timeline

kislinsk triaged this task as Wishlist priority.Oct 5 2018, 9:14 AM
floca added a parent task: Restricted Maniphest Task.Oct 29 2018, 12:43 PM
floca removed floca as the assignee of this task.Mar 22 2019, 2:15 PM

We all agree on the proposed solutions. We want to collect all segmentation related tasks in a a Segmentation project/tag.

kislinsk added a project: Auto-closed.

Hi there! 🙂

This task was auto-closed according to our Task Lifecycle Management.
Please follow this link for more information and don't forget that you are encouraged to reasonable re-open tasks to revive them. 🚑

Best wishes,
The MITK devs