We did the draft together, but it was not implemented into Hyppopy yet.

https://phabricator.mitk.org/source/kaapana/history/feature%252FT28913-myeloma-kaapana/

@gaoh @floca I subscribed you so that you known where to find it, if the question comes up. At the moment there is no open todo on this front.

I am removing myself as an assignee. I just reported this.

This task is still open and still on the workboard. I am removing myself as an assignee, what I did was basically reporting and a bit of investigation as written above.

@kahl I assigned you. If I understand correctly, this is what you did for the new add tool and the new base class.

@kahl Again, I assigned you, this is in the context of the new add tool.

There is already a pull request for CTK that fixes this issue. I commented on it. Nothing to do from our side I guess.

@kahl I hope it is ok, that I assigned you, since you are working on this anyways.

I guess in GIMP the behavior is somewhat similar to your second suggestion. As you are not able to set additional points, it is a "restricted region". You can still modify existing points. This is what the tool looks like in GIMP if you move one of the existing points.

One comment to this: The tool was inspired by the behavior of a similar tool in GIMP. In GIMP it is not possible to add additional points after finishing the contour. So they don't have that problem.

The users have 2D+t data. The current workaround is to convert the 2D+t data to a 3D volume, where one slice is one timepoint and interpolate like this. This is not a perfect solution, as the 3D interpolation tries to interpolate to something like a "round" or "organ shaped" object, which does not make sense in this case.

True, I tried this. There is even a task for it: T28557

Seems to work. I am now able to connect to XNAT 1.6.4 and XNAT 1.8.2. Idk if there are more versions with different calls, these are the only two that I have available to test.

I looked into this together with @kislinsk. It looks like CTK cannot handle newer versions of XNAT. THey try to retrieve the XNAT version via

QUuid uuid = QUuid uuid = xnat->get("/data/version");  //ctkXnatSession.cpp:192

That is what I assumed... the labels created by multi-label plugin always contain only two values, if I am not mistaken: 0 and x with x e [1,2,3,...]. One could check for the label values and if there is only two different ones, use these two. This does not include the case when a label was created externally,e.g., by U-Net and contains several values in a single image.

Tested it on Windows. I can confirm what @kalali said in 2018.04.0. In 2018.04.2 it seems to work on single segmentations.
For multi-label segmentations it interpolates always for the first label (label value=1). So the bug described can be confirmed.

Ah ok, thx. I will try later.

Ehm... I cannot do Interpolation in MultiLabelSegmentation I think. Shouldn't there be a drop down?

The listed changes have been implemented. I realized that there is an issue with the automatically created "last segment". If I click there to create a new control point and move it, I get the behavior shown in the image (sorry, I tried to explain it in words but failed).

Pushed new branch to rMITK MITK: feature/T28607-live-wire-improvements.

LiveWire tool now always connects the current mouse position with the starting point (here displayed in red for demonstration purposes). The mouse cursor is not visible here due to me taking a screenshot via noMachine. The position is where green and red meet. If double-clicked, the green and red line turn into yellow segments.

Oh, ok. Did not know that. I will postpone it then.

This is related to T28464.

I looked into this (to be honest, I did not read Amirs last comment): I totally agree. I fixed the issue, which was not to complicated, but there is a lot of spaghetti code involved. I agree with Amirs suggestion to not fix it this way.

I tested it again with feedback from @kalali and @s434n. The behavior that the tool has is ok for now. I adapted the checklist accordingly. We found some minor issues, that we propose to fix on the near future:

Additionally, I would not auto-confirm as a default. As a user I would first finish the outline and then correct it if needed. I would be really frustrated, if that is then not possible anymore.

In T28113#216792, @floca wrote:

In T28113#216778, @kalali wrote:

I haven't made up my mind about the best way to go, I'm open for suggestions. I just wanted to state that even the checklists state something different. So to align the tests with what the workbench actually does, we should clarify, how the tools actually behave or should behave.

In T28113#216776, @floca wrote:

• If the tool is deactivated (explicitly, by selecting another tool, by closing the view) all unconfirmed contours will be removed.

And this is not the case right now. Currently, a mask will be generated and drawn into the image.

Oops, you are right. On second thought, I would keep it like this for now and make the checklist accordingly. I think would get more frustrated users if the contour just vanishes if the close the segmentation or tool. If we introduce a option for auto confirm we could think of adapting the behavior.

Pushed new branch to rMITK MITK: bugfix/T27711-rename-image-selection-label.

I tried to add

long long

to the list. That caused my superbuild to crash. Then I added

int64_t

The superbuild worked, but now the workbench crashes during the load attempt with:

There was a discrepancy regarding how the RtStruts are displayed. When loading via DICOMBrowser, they were now visible on stdmulti.widget2 and 3. Is this the desired behavior? On there planes, one can only see "dots". We should discuss this.

Same goes for MultiLabel Segmentation.

While we are doing that: The measurement Plugin does not have a label at all. I would suggest having this consistent.

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

Pushed new branch to rMITK MITK: bugfix/T28544-difference-RT-data-loading.

I could not reproduce this.