Deleted branch from rMITK MITK: feature/T29244-ReintroduceACVD.

Pushed new branch to rMITK MITK: feature/T29239-nnunet-download-without-resultsfolder.

Pushed new branch to rMITK MITK: feature/T29244-ReintroduceACVD.

ok, but then the GPU problem is also feasible! If it is for a pre-known time-limited usage, like in an interactive session, I don't see a problem assigning a GPU to the container.

In T29243#240152, @gaoh wrote:

What is the advantage of running nnunet in MITK in kaapana, over directly running nnunet in kaapana?

If you have a bunch of data, then the airflow workflow is the way to go.

To point 1, in Kubernetes you can mount any path/volume to the desired mounting point. So I could just mount the directory in the MITK container in e.g. /models

I had a nice talk with @nolden about this topic and we concluded that dpkg is a good solution for checking for certain packages. The more I think about it, though, I think that we should stick at least partially to the file checking approach. The main reason is that we are not restricted to the Ubuntu package names or have to maintain additional alternatives. In particular, think of the OpenGL mess. Quite a few packages provide required header files and libraries, overriding each other. For example think of someone with proprietary nvidia dev packages who very likely does not want to be "forced" or wrongly advised to install overlapping mesa packages or similar.

As a quick fix I added D692, but this just fixes a crash. It is not enough to have multiple time navigation controllers.

Pushed new branch to rMITK MITK: feature/T29238-nnunet-improve-validation.

Some more references to mitkDisplayInteractor have already been removed in T27663 / D689.

The feature/T27923-execute-python-code-in-mitk branch should be outdated as the last commit was in 2020. Everything from this work should be integrated in this commit where I pushed all the work from my bachelor thesis on the python-dev branch and based on this, implemented some more features.
The main problems of getting green builds were on the Ubuntu clients where some errors occurred during the build that we were not able to reproduce locally.

In Ubuntu 20.04+, system Qt can be used instead of the online installer, greatly reducing the hassle of creating a Qt account and so on:

Just found this while working on T29234.
When @s434n and I were working on the interactions https://phabricator.mitk.org/D550?vs=on&id=2579 (and earlier the DisplayInteractor was replaced with DisplayInteractionEventBroadcast here https://phabricator.mitk.org/source/mitk/browse/develop/Modules/QtWidgets/src/QmitkAbstractMultiWidget.cpp$51-52) it seems as if this part of the code was forgotten.
The DisplayInteractor is not used anymore and that's why the retrieved object is a nullptr.

Deleted branch from rMITK MITK: feature/T29187-nnunet-show-download-models.

Deleted branch from rMITK MITK: feature/T29202-nnunet-download-model-doku.

Deleted branch from rMITK MITK: bugfix/T29224-confirmbutton-disable.

I connected this task with D686: Not all discussed points are handled here but I removed the UpdateStatusBar-functions completely and added a simple function to update the status bar info with the mouse pointer / world position and the global time dynamically.
More code changes will be uploaded to provide ideas on how to show image pixel information.

In combination with the child task I added a first part of the tasks in D686.
The UpdateStatusBar-functions (and HandleCrosshairPositionEventDelayed-function) are completely removed and a simple function has been added to dynamically write the pointer position / world position and the global time to the status bar.

In T26496#227708, @kalali wrote:

I edited the task description since most of the issues do not occur anymore, due to the changed introduced by D523.
However, the general problem remains: It is not possible to re-initialize / reset the view and camera of individual render windows which is important for the MxNMultiWidget in order to fully unleash its potential.

In T29193#240042, @kalali wrote:

Do you see some (dis-)advantages in one option or the other?

Per se, no. Was only 2 thoughts:

• I think it depends on the performance of the SLIC filter. If 3D has a good performance for the proposed interaction (see task description) I am fine.
• I was not sure if people will realy use it in 3D, as the would have to constantly scroll through slices to ensure that the 3D superpixels are everywhere correct enough.

One thing to consider might be, is SLIC even useful? If neural networks are going to be taking care of segmentation anyway, what is it's likely sell-by date? This depends on how quickly NN based segmentation algorithms are incorporated into MITK.

In T29193#239964, @floca wrote:

In T29193#239962, @s349i wrote:

So it should work for 2D and 3D.

Thanks for the input! My text was missleading. I meant, if we want only have a tool that works on 2D (e.g. in conjunction with interpolation) or also an tool where you can paint superpixels in 3D.

In T25043#239851, @kalali wrote:

1. Do we agree that there will be no position / pixel value information shown in the status bar?
   1. or are we only talking about the (maybe case-specific) pixel value information; meaning the position / index should still be shown in the status bar?
   2. if everything should be removed from the status bar, we wouldn't put any new functions in the "StatusBar"-class, right?

I would say A. So coordinate information is still visible.

Deleted branch from rMITK MITK: bugfix/T29237-TyposInWrapping.

Pushed new branch to rMITK MITK: bugfix/T29237-TyposInWrapping.

@kahl What is the status here? What is the differences between the two pushed branches? are they redundant or do they cover different aspects. I cannot find a documentation of there purpose.
What where the problems that hindered you to get green builds?

Deleted branch from rMITK MITK: bugfix/T29235-PluginManualsOnTopLevel.

Pushed new branch to rMITK MITK: bugfix/T29235-PluginManualsOnTopLevel.

Ah OK. Thats a decision above my pay grade.

In T29193#239962, @s349i wrote:

So it should work for 2D and 3D.

only 2D are also 3D?

Pushed new branch to rMITK MITK: feature/T29227-modify-modal-label.

Additionally I found out that the order of the pixel-position and the index do not match, see screenshot (taken with MITK 2022.04 Release, using Pic3D and brain):