We had a discussion about refactoring the segmentation tools (similar to {D380}). The idea is to outsource redundant code into base classes (e.g. time-management, slice extraction, input data checks etc.) to have a single point of truth for the starting point of the different segmentation-tool-algorithms. This would make the tools less error prone and can simplify testing (even allow automatic testing for the input management steps) (see T27800#211467).

OpenCV 3.4.11 (https://opencv.org/releases/)

Trivial should be:

Known issue: https://github.com/rstudio/rstudio/issues/4718

Fix! :-)

PS: as an explanation, one theory is that the install-zip-package still references libraries from the build machine which causes the different behaviour

In T27669#211004, @schererj wrote:

@nolden I tried the "make package" and it went through without any issues.
Should I upload the result here? Or is it just about the information that there are no error?
Could you please explain what you mean with "target machine"?

I looked again at the tests we have inside the checklist and I think it is still very long and many steps are redundant - because only the clicked tool-button changes and the underlying segmentation algorithm produces different results.
I think it is clearer and even better for testing a specific tool / algorithm, if we somehow separate the tests for different tools.
Also,

In T27507#211660, @thomass wrote:

If necessary, I might need a helping hand because static/dynamic*single/double*2DTools/3DTools = many test cases

Another solution is to use a numeric input field that does not accept other characters.

Deleted branch bugfix/T25882-RewriteDashboardScript.

Deleted branch feature/T25882-MITKOptions.

Pushed new branch feature/T25882-MITKOptions.

Open problems will be tackled in subtasks of T27807: [MultiLabel Segmentation] Inspection of module and plugin, e.g. T27809 and T27810.

This was a tricky bug, thanks!
alpha is now respected, argument FUN is removed. significance ranking is considered an aggregation step, so testThenRank() is nothing else than aggregateThenRank(FUN="significance").
Note that testThenRank will pass all arguments to decision.challenge(), i.e. it will respect arguments:

@thomass OK. Thats enough info, thanks. No further testing for now. We do it in context of a release branch or/and explizit fixes.

In T27507#211659, @floca wrote:

In T27507#211583, @thomass wrote:

In T27507#211505, @floca wrote:

@thomass Thanks.
Now I might be nasty. Have you also checked everything wenn loading to 4D images with different time geometry? E.G. So that the selected time step in the navigator must not correspond to the same time step of the image you segment on?

With two 4D images 3D+t-Heart and US4Dcyl it crashes indeed when

• using the Add tool on the static 3D+t Heart on timestep 0
• changing the timestep and then use the Add tool again

I couldn't reproduce the crash when combining 4D_TEE_Data_MV and US4Dcyl (yet)

Could you please check (if not done already), if this scenario also crashes if you do it with a static segmentation?
This info is important for the decission, if we have to fix it directly or just partialy deactivate the dynamic option for this cycle. (Curently static segs on 4D images are more relevant then dynamic segs).

In T27507#211583, @thomass wrote:

In T27507#211505, @floca wrote:

@thomass Thanks.
Now I might be nasty. Have you also checked everything wenn loading to 4D images with different time geometry? E.G. So that the selected time step in the navigator must not correspond to the same time step of the image you segment on?

With two 4D images 3D+t-Heart and US4Dcyl it crashes indeed when

• using the Add tool on the static 3D+t Heart on timestep 0
• changing the timestep and then use the Add tool again

I couldn't reproduce the crash when combining 4D_TEE_Data_MV and US4Dcyl (yet)