Thanks for reporting. The whole method seems to be dubious. The lines of code you mentioned are plain wrong, the loop should start with k=1 and the data type of numPixelsInDataset should be more appropriate.

OK. But I tend/think more and more that we should strive for a unit test testbed that tests all that on the tool class level (either the respective base classes or the tools itself where it is easily possible (e.g. because the have no interaction (but even thous shouldn't be a show stopper).

The checklist don't say anything about multilabel segmentation. This should be addressed with a special focus on creating and combining multiple labels / layers.
I couldn't find any other checklist with a focus on the multilabel functionality.

I updated the document and added content to explicitly tests

I can verify this behavior. Also, if you close the segmentation view while the position nodes are shown, they stay visible.
If you open the segmentation view again and select the 3-Dimensional interpolation, the position nods are still shown, although the checkbox is not checked.
Checking it and unchecking it will hide the position nodes again.

Alright -> removed the task from release-workboard

In T27706#212501, @schererj wrote:

@floca do you know something about the status of the "new" radiomics container?

No.

@floca do you know something about the status of the "new" radiomics container?
Since we don't have the new container yet, we will keep the old radiomics pipepline for this release if that's ok.

Deleted branch feature/T27879-MITK_BUILD_NAME_SUFFIX.

Pushed new branch feature/T27879-MITK_BUILD_NAME_SUFFIX.

No, not yet. I've sent an email and asked for a more detailed description of the problems and will post it in this task when I hear back from Jerome.

@k656s have you heard from @gaoh about the status of this container?
Is there a new one, which is based on the MITK develop branch?

Similar to T27716: Extend "Checkliste Segmentierung – Manuelle Segmentierung / 2D Segmentierung" I updated the document and added content to explicitly tests different image types / segmentation types.
Additionally I tried to make both checklists more consistent.

In T27507#207494, @kalali wrote:

So Region Growing 3D seems to work and could probably be used for reference for other algorithms.

Any details?

Deleted branch bugfix/T26897-RemoveCustomFindGitModule.

Should be fixed now.

In T26897#212304, @kalali wrote:

I wonder how this is related to our findings from December last year.

Pushed new branch bugfix/T26897-RemoveCustomFindGitModule.

I wonder how this is related to our findings from December last year.

I noticed a few things that may be related or not but we should clean them anyway:

Deleted branch feature/T27852-CDashAddOptionToCleanDirs.

You can add the following options to your configuration script:

Pushed new branch feature/T27852-CDashAddOptionToCleanDirs.

Seems to be resolved by setting

"GIT_EXECUTABLE:FILEPATH=/usr/bin/git"

in MITKDashboardScript.cmake

Jerome Devy reported problems with the installation on 12th October 2020.

yes, openstack

May be completely unrelated but who knows: https://cmake.org/pipermail/cmake-developers/2015-November/027082.html

disadvantage would be dependency on another package facilitating ggplot2 dendrograms

current implementation is fine. However, we said it would be nice if all plots (if directly called by users and not within the report) would have the same syntax and could be layouted with ggplot2 syntax. current implementation is using basic R graphics.

turned off in v1.0, everything else postponed

I also agree!

People that are not from the statistics community might find them easier to read and interpret. I would be in favour of keeping them in the reports. We used the plots in one of our papers.

What is the issue with the current implementation?

This just occurred on my ubuntu dartclients. Any idea how to fix this in MITKDashboardScript.cmake?
https://cdash.mitk.org/index.php?project=MITK-Diffusion

Sounds good to me (the view just came up in T27563, so I thought I should open a task that it doesn't get forgotten about). It has low priority though at the moment and it makes sense to tag it with "next milestone".

Should we put this on "Next Milestone" since the chart example will probably not be included in any installer?

Deleted branch hotfix/T27849-MITKExtensionsInCDashScriptOnUnix.

Pushed new branch hotfix/T27849-MITKExtensionsInCDashScriptOnUnix.

https://github.com/Kitware/CDash/issues/514

Oh, I just noticed an "Add repository" button in CDash. There may be the possibility to actually report revisions of more than one repository. Let me check that... :-)

Done. @floca, if you do not agree, please reopen.

I looked into the CDash script and to basically "swap" the primary repository would induce many many new lines of code. Hence, I vote for "let's always keep MITK as primary repository that reports its revision but change the CDash settings to the MITK repository instead of the MITK extension's repository". Tl;dr: Make the revision links work in the web UI but they will always link to MITK, not an MITK extension.