@floca @nolden At this point I would say the task is still a blocker from a clinical point of view. The tool is somewhat usable, but still not always working as expected thus making it inconvenient and non-intuitive. Sometimes for example, the region growing cannot be further expanded in contrast to the similarity of nearby image intensities, sometimes it takes several trials at different seed points. Altogether, this makes the tool work differently than one would expect. Also sometimes, the tool displays some kind of 'lag' when waiting for region updates (i.e. mouse position updates that had just worked suddenly have no more effect).

Seems to be fixed already in the current develop branch

Covered by T27492 by accident ;)

Pushed new branch T27512-FixRenamingIssue.

In T27389#204198, @Oshio wrote:

@kalali Your solution solved the problem. I'd like to point out that SetWidgetPlanesVisibility(true) is already called somewhere inside InitializeMultiWidget(), so just AddPlanesToDataStorage()is enough for rendering the planes.

MITK is a great image processing tool that is very popular in our research group. Thank you guys for making/maintaining such an amazing open source project!
Any time schedule to upgrade ITK and VTK to latest version (ITK5.1 & VTK9)?

New Image Statistics (preview)

The image statistics (modules ImageStatistics and ImageStatisticsUI as well as the QmitkImageStatisticsView provided by the plugin org.mitk.gui.qt.measurementtoolbox) have been heavily refactored on the backend and the frontend side. The rework is not yet finished as the current state just ensures that we have no regression but does only to a little extend tap into the potential of the new infrastructure.
The following paragraphs briefly summarize what’s new.

Pushed new branch feature/T27500-use-PythonCApi-in-python-service.

Just add it here.

I would propose the following policy:

1. All tools per default work only on the respective time step of the reference data and the segmentation, that are indicated by the currently selected time point (SliceNavigator). So this is general and independent from the fact if it is a 3D or a 4D segmentation. This is the same behavior like the interactive tools and does not break user expectations.
2. It is up to the specific tool (must be discussed there) if for 4D reference images others then the current time step of the reference data step should be used. Per se, I would say no.
3. It is up to the specific (3D) tool to allow the altering of more then the current segmentation time step (if the segmentation is 4D). If one wants such a feature I would add e.g. a check box to the tool like "confirm for all time steps".

In T27486#204956, @kislinsk wrote:

I think I moved and aligned everything into a draft of the official changelog (click on View Draft Version): 2020 Week 25 (Late June).

@floca The only thing missing is statistics as it seems that the text above is not yet complete.

Image statistics are now correctly cached to prevent recalculation for the same image (-mask pair).
The UI of the histogram has been improved and is now theme-aware.

I think I moved and aligned everything into a draft of the official changelog (click on View Draft Version): 2020 Week 25 (Late June).

Histogram has a simelar problem, but to fix that the Histogramwidget also needs a rework). Such a rework should be done in conjunction with the rework of T27284

This is due to the Autorepeat feature of the SpinBox up and down buttons (which allow to just keep the btn widget press and produce several clicks).
This feature can lead to problems, if you make to time consuming computations in your slot function, that is triggered by the value change, and therefor the button release event comes to late, the auto repeat kicks in.
So debug mode and especially break points often produce false positives. They should be ignored. It is only important if you can observe/reproduce this problem in release mode. I was not able to do so with ~10 dynamic images in one session at once.

@norajitr How pressing is this task with the work arround given by @nolden ?

In the description it says:

MITK User Manual --> MITK Plugin Manuals --> Statistics Plugin

Will be continued in T27097: [MITKDoc] Revise Statistics Plugin Documentation.

Seems to be resolved because D329 changed

// In case the time is not valid use 0 to access the time geometry of the working node
unsigned int time_position = 0;
if (m_LastSNC->GetTime() != nullptr)
  time_position = m_LastSNC->GetTime()->GetPos();

In T25825#204469, @thomass wrote:

But the 3d segmentation has only 1 timestep with duration = sum of durations of all 4D image timesteps, right?

Yes. I think this is more related to your other discussion in T26974: "What to do with a 3D segmentation of a 4D image."

Looked into the topics. Following comments:

But the 3d segmentation has only 1 timestep with duration = sum of durations of all 4D image timesteps, right?

In T25825#203881, @thomass wrote:

• Works for dynamic (4D) segmentations but creates the same segmentation for all timesteps
• Could not be reproduced for static segmentations since the workbench crashes during the creation of a static segmentation (related to T27476)

Deleted branch bugfix/T27503-GCC-9.3-Ubuntu-20.04.

Pushed new branch bugfix/T27503-GCC-9.3-Ubuntu-20.04.