- User Since
- Aug 1 2016, 12:10 PM (269 w, 15 h)
Wed, Sep 15
True, I tried this. There is even a task for it: T28557
Aug 16 2021
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
Aug 2 2021
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.
Jul 30 2021
Ehm... I cannot do Interpolation in MultiLabelSegmentation I think. Shouldn't there be a drop down?
Jul 29 2021
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).
Jul 28 2021
Jul 9 2021
Jul 7 2021
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.
Jul 6 2021
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:
Jun 28 2021
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.
Jun 22 2021
Jun 21 2021
Jun 17 2021
I tried to add
to the list. That caused my superbuild to crash. Then I added
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?
Jun 15 2021
I could not reproduce this.
Jun 14 2021
Jun 10 2021
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.
Jun 8 2021
Jun 7 2021
Jun 4 2021
Jun 2 2021
Discussed it in the MITK meeting:
May 10 2021
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.