that is at least one of the two code locations I assume to make problems. (The other one is when the interpolation results are written back to the segmentation)
For now, I wouldn't try to patch in multi-label support into the interpolation class. Instead I would ensure that only a label image (so an image that just contains the active label) is passed to the interpolation class.
I think that that is the most pragmatic approach to it, procure the current implementation will never work properly when multiple labels are present, due to the assumptions already stated by @kalali.

oops, sorry. than I have mixed something up.

Down prioritized it, because survey indicated currently low relevance.

Down prioritized it, because survey indicated currently low relevance.

Comment: One should seperate the open todos into sub tasks, I think.

@kalali Aren't you already working on that topic? I thought, i just reviewed something in that direction?!?

@kleina Just as a remark. I would postpone this task a bit, as we have enough other things to do and @kislinsk is currently working on interpolation and this might have also impact on this tasks.

I think that are good ideas.

• Does the problem also occure with the current release?
• It is a known problem that Windows (OpenGL problem) does not work (well) remote with MITK. The best way is installing the right drivers (see https://phabricator.mitk.org/T26427#224676)

I cannot answer that question directly. As I do not know the history of this class and documentation does not help. Maybe @nolden does.

Sounds like it goes in the write direction. :) thanks.

This is then based on the QmitkDataStorageTreeInspector? Would make sense, wouldn't it?

It seems to me that most of this points are at least 1-2 work days worth of time. If this right it would make sense to turn them into subtasks. Then we also have a clearer burn up, because one can explicitly marke sub tasks as done...

Just as a side note. As far as I know, the data storage interace gives no guarantees regarding the order (aplied sorting criteria) of returned node sets. So any implementation that relies on such an order is likely to fail.

In T28523#225188, @kleina wrote:

What is the status here? This is on "unbreak now", but no assignee. Is there something to evaluate yet?

Good point. @a178n I put you as asignee for now as you started the survey. How many answers do we have already. If it is a low number, then could you send a reminder. So that we can compile the result for internal read through next Wednesday?

In T28135#225112, @kalali wrote:

@floca Is this something worth looking into before the refactoring is done?

I would say: no.

I understand the reasoning behind that feature request, but I think it should be discussed. At least it contradicts one of the key assumptions of the new selection concept: relevance criteria is defined localy in the view.

In T27665#224913, @kalali wrote:

@floca I can't reproduce this anymore. However, I'm not sure where some changes were done. Do you have an idea?

The QmitkDataSelectionWidget uses the new selection concept widget SingleNodeSelectionWidget. So it is not redundant per se.
But it is right that it makes no sense to dublicate the widget in the plugins. It should be in MitkSegmentationUI and only one time.

Pushed new branch to rMITK MITK: feature/T28525-Design_refactoring_labelset.

Update regarding the problem of @tpenzkofer (Software Rendering with VMWare VMs):
After the update to the newest VMWare version, the software rendering works correctly also with newer MITK versions. It seems like the new VMWare version has its own Mesa driver with OpenGL 3.3 support wich does the trick.

I think Stefan is refering to that https://developer.nvidia.com/designworks, arn't you @kislinsk ?

Does it only crash with erosion or also with other utilities?