This has also been adressed in D568 since the problem turned up there in the CI builds. Should we still solve it in D582 separately or just wait until D568 can be landed?

I think related to this task: it seems there is some more inconsistency depending on the shown region. When two images with different geometries are loaded and shown simultaneously after a global reset, planarfigures created on one of the images can extend into the whole shown region, outside the boundaries of the selected reference image (even after a reset on that specific image).
It seems in this case the boundaries for the planarfigure are set incorrectly on creation.

I can't reproduce the problem mentioned for the mapper plugin on v2021.10 . The moving / target information appears in the properties, just as in a registration created via the Algorithm Control plugin.
Can somebody reproduce this (or a related) problem? Otherwise I guess the task was already solved somewhere else and can be closed

It seems to me like this was done in this commit. Can the task be closed?

Status-wise nothing has really changed since we sent out the messages a while back.
Regarding the last release-cycle: my impression was that it would help to direct testers more to suitable test data. People who have suitable data themselves can still use that, but those who don't are blocked from testing if not provided with data. As I see it, we could either achieve this by either

• naming suitable provided test data explicitly in the checklists
• creating a reference document that lists data types and respective test data
• restructuring / renaming files in MITK-data to make it more clear of what type they are

I think option 2 would be pretty simple to implement and might not reduce the likelihood of people using their own data when possible, as option 1 might do when directly recommending certain test data, but would add another layer of complexity / another file to keep track of (for us, as well as the testers).

I think the problem lies in this difference between the MultiLabel Segmentation Utilities and Segmentation Utilities. For the latter, the "Structuring Element" section looks like this:

With both subtasks done, we have successfully implemented the main goal of this task. The remaining bug that deactivating a segmentation tool resets the interaction to an earlier state (the one at which the tool was activated) has been split off into T28630 because it is not critical and can be easily handled with the new feature of deactivating PACS tools.

The proposed change goes kind of in the opposite direction of recent changes that were made, specifically in D531 and part of D532. If the approach of D535 is to be continued, it would need to take into account D532, in which an additional PACS scheme was introduced that leaves the left mouse button unused.
I would personally prefer the direction we have been taking now, splitting up the config files into smaller chunks. This reduces code redundancy, instead of having almost identical config files many times.
Also, in my opinion the approach of D531 makes a lot of sense for overlapping interactions. It allows to change only the aspects of interaction that are necessary while staying oblivious to the current interaction (MITK default, with swivel, PACS, ...). If we want to use full configs, one would need any variation of each scheme for each situation where alterations may be necessary. For example 2D segmentation tools require the left mouse button, so any possible interaction scheme needs to have a corresponding version where the left mouse button is unused. If a tool requires something new, like the right mouse button, new config files have to be implemented for every existing interaction scheme instead of just one file that will be appended.

Possible duplicate of T28278? That task's description is not very clear about the problem, but could be referencing the same thing

As of now, we will remain with Qt 5.12 for a while, since it is a well maintained long-term version

The cause for this problem lies in missing state-transitions of the interaction state-machine. DisplayConfigPACS.xml defines the events based on which the state-machine in DisplayInteraction.xml acts. For modifier-based interactions, a MousePressEvent / MouseReleaseEvent in combination with a modifier-key are responsible to transition into / out of the corresponding state ("move", "zoom", ...). When the modifier-key is released BEFORE releasing the mouse button, the second event is never triggered, causing the state machine to get stuck in that specific state, which blocks most other interactions.

It seems this idea is currently not directly implementable, in the way of clicking a button again to deactivate it. In the constructor of QmitkInteractionSchemeToolBar.cpp the line m_ActionGroup->setExclusive(true); guarantees that exactly one option is selected at any time. Since Qt 5.14 there is the option to set an ExclusionPolicy of ExclusionOptional, which accomplishes exactly what was thought of in this task. As this is not available yet, one would either need to manually implement the desired behavior of activating/deactivating actions, or wait until perhaps a newer version of Qt is used.

So far, I have not heard from anybody about the message I sent around. I wanted to send another reminder of it soon, in case some people just forgot

André, Amir and I discussed the problem a bit and found multiple problems and ideas. The general question is: what is the intended behavior? Some options are:

1. only one interaction can be active at any time. This would mean activating a segmentation tool would deactivate any PACS functionality and vice versa. Not really what we want, since it prohibits using regular MITK interaction behavior (e.g. zooming with the right mouse button) while segmenting
2. only one left-mouse-button interaction is active at any time. Activating a segmentation tool would automatically disable left-mouse-button usage for display purposes
3. multiple interactors can operate on the same events, i.e. PACS + segmentation at the same time is intended behavior, if the user wishes to do so. To make this useful, it should be possible to deactivate PACS interaction, either by allowing to click a button again to deselect it or by providing an additional button that does nothing on left clicks.

The problem really seems to be the disabling / resetting of interactors that was mentioned in an earlier comment, even with the fix that corrects the resetting when the tool is deactivated again. Correct usage would be:

1. moving around the gui, using PACS
2. selecting a segmentation tool (which deactivates other interactors)
3. only using the segmentation tool, without changing the view
4. deactivating the segmentation tool (and thus reenabling previous interactors)
5. -> everything works as intended

When a PACS tool is selected after step 2, this messes up the active interaction and after the segmentation tool is deactivated it resets to what was previously selected, before the tool was activated.

Some additional observations:

• The behavior works as expected when selecting the segmentation tool AFTER changing the PACS action. Only when selecting a new PACS action while the segmentation tool is still active, they both act simultaneously
• When some PACS action (action 1) is selected, then a segmentation tool is selected, the PACS action is changed (to action 2), and the segmentation tool is deselected again, PACS action 1 will be active but action 2 is marked in the sidebar as selected

I was not able to reproduce this bug on Windows with the v2021.02 release as well as the current develop branch

I was able to reproduce the bug for all morphological operations (Dilation, Erosion, ...) and also in all orientations (axial, coronal, sagittal). Other segmentation utilities all work without problem.

It seems to be the same bug, I just failed to find the existing task. Since I found it in the last Release version, the bugfix was just not included yet, but the problem is still solved. I guess this task can be closed then

I've started a draft for a message to send around, found here if you want to have a look or add something: https://hub.dkfz.de/s/HzpkipeWRkq3K8K