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.

We commented out the entire if-else clause for the RT data and it seems to do what it is supposed to do, even without the special conditions. Need to check that in more detail.

Pushed new branch to rMITK MITK: bugfix/T28455-rt-struct-3d-visibility.

Discussed it in the MITK meeting:

I narrowed it down.

If you load a RTStruct via DICOMBrwoser, the node has a special "visible" property for stdmulti.widget3 (the 3D view). You can enable/disbale it via the Properties plugin. #Workaround :-P

Ok, we tested it on several machines and it is as described above: After loading via DICOM Browser we can confirm the issue.

@s434n and I tried this on Windows and Linux. It looks like, if you load the data via "classical drag'n'drop", it works as expected. If we use the DICOM browser to load the exact same dataset, we can reproduce @nolden's issue.

Sure, here it is:
https://phabricator.mitk.org/rOBSHYPPOPYa340b927d14acdef69cea4e64b92524270066920