- User Since
- Aug 1 2016, 12:10 PM (346 w, 3 d)
Dec 20 2021
We did the draft together, but it was not implemented into Hyppopy yet.
Dec 16 2021
@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.
Dec 15 2021
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.
Nov 3 2021
Nov 2 2021
Oct 29 2021
Oct 18 2021
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.
Oct 15 2021
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.
Oct 11 2021
Oct 6 2021
Sep 15 2021
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
Pushed new branch to rMITK MITK: feature/T28607-live-wire-improvements.
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
Pushed new branch to rMITK MITK: bugfix/T27711-rename-image-selection-label.
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?
Pushed new branch to rMITK MITK: bugfix/T28544-difference-RT-data-loading.
Jun 15 2021
I could not reproduce this.