Deleted branch from rMPT MITK-ProjectTemplate: release/T29138-v2022.10.

Pushed new branch to rMPT MITK-ProjectTemplate: release/T29138-v2022.10.

Deleted branch from rMITK MITK: bugfix/T28274-volumerendering-multiple-timesteps.

Deleted branch from rMPT MITK-ProjectTemplate: release/T29138-v2022.04.

Deleted branch from rMITK MITK: release/T29138-v2022.04.

for now we solved it by adding the support in the mapping helper as outlined above. Some sophisticated like services we did not so far.

Added :)

Thank you for spotting that. It is not expected behavior. But I would keep as is (known issue). 1) I think it is acceptable and 2) to handle this properly and not hacky, would be very intrusive and take 1 day. I would prefer to do it when the AutoTool classes will be merged and refined anyways, then it is an quite easy catch.
@kislinsk What do you think?

I was able to reproduce the problem on the snapshot from two days ago. This new version fixes the problem for me, although the behavior is the same as @kalali described it. The newly created segmentation is a complete copy of the current one (including layers, labels, and masked regions of the labels), except for the changed region that was just segmented. I'm not sure if this is the expected behavior, but if it is everything seems to work fine.

I cannot reproduce the crash with the related branch!

Pushed new branch to rMITK MITK: bugfix/T29143-Crash_when_storing_auto_tool_preview_in_new_seg.

In T29143#236955, @floca wrote:

damn I know the reason. At least I have made a telling exception. 😅

damn I know the reason. At least I have made a telling exception. 😅

I updated the Checklist "Volume Visualization_EN.docx" accordingly.

In T28777#235480, @kislinsk wrote:

Regarding the delayed update of the Image Navigator I decided to leave it as is as it is as minor as it can be but would require major code changes. My first idea was to react on OnPreferencedChanged() in the view but this is only triggered for preferences associated with the view, not the preferences of the standard multi widget.

Pushed new branch to rMPT MITK-ProjectTemplate: release/T29138-v2022.04.

Pushed new branch to rMITK MITK: release/T29138-v2022.04.

@a178n Maybe we need to add the hint that an additional tool icon is available for nnUNet for non-windows user?

We found a solution to make the highlighting consistent with the active label state.

This task is resolved in the current release branch.

I updated the image and removed the numbers (like Stefan proposed in his comment).

We updated the checklists.

I added a fix for this by using the same approach as in the segmentation view.
However, the reason for this class is unclear to me: It is only used for the data manager context menu and allows to quickly create a new, empty segmentation child node. It's basically the same as clicking the button in the segmentation view so for me it doesn't add anything and could be removed.

Deleted branch from rMITK MITK: feature/T29066-after-hackathon-changes.

@kislinsk Do we want to close this task, because of 2ef49f51d547?

Pushed new branch to rMITK MITK: feature/T29066-nnunet-diff-fix.

TODOs:

• Reference all "external" data in README files
• In particular, check DICOM data if we have consent and if it really is anonymous regarding DICOM tags etc.

I added a fix in D625, which uses the discussed approach of printing the active label above the labelsetwidget.
The problem with this approach is the same as the one I already presented:

Pushed new branch to rMITK MITK: feature/T29134-nnUnet-doku-update.

There seems to be a problem with the connected messages. I wanted to exploit the ActiveLabelEvent being sent to change the label for the currently active label (https://phabricator.mitk.org/source/mitk/browse/develop/Plugins/org.mitk.gui.qt.segmentation/src/internal/QmitkSegmentationView.cpp$664). It seems as if this only connects the events of the currently active label set and new label sets (e.g. on a new layer) are not connected. I need to look deeper into this to see if I made an error while removing the redundancy (and moving this event-connection to the classic segmentation view) or if it was erroneous from the beginning.

As far as I see neither the mitkFeedbackContourTool nor the used mitkContourModel are capable of representing a contour with holes (which eventually results in two closed contours). Please prove me wrong but it seems as if MITK is not able at all to store such a torus-shaped contour model. Has this ever been done before somewhere?

Merged into current release branch.

A fix for this is available in this pull request: https://github.com/MITK/MITK/pull/257

In T28256#234493, @kalali wrote:

Question: Is it correct that the user can not use the data manager anymore to select data and solely relies on the two data selection widgets? If so, I would rephrase the checklist accordingly.

Yes this is correct.

There are two contour mappers. An OpenGL version using low-level OpenGL API calls through VTK, messing around with contexts and paint devices, and a pure VTK version using PolyData. The former one is currently in use. I switched to the VTK-version which is preferable in principle and it works except for a few minor things like color.

Oh, in debug mode, I still get an error output at least:

It probably is an issue in the contour mapper or maybe even an internal issue in VTK that is triggered by the contour mapper. I noticed crashes in the Nvidia driver and OpenGL error outputs before I updated my driver that also goes into the same direction, even though the crashes are now gone. I want to check if we introduced this issue with the latest minor VTK upgrade in which case we should downgrade again.

I looked into the mitkSetRegionTool-class and found the following: