@eisenman I don't get this warning. Could you give more details/ an example? or is this already solved/not relevant anymore?

yes this has historical reasons (largeBetter had been "inverseOrder" in the beginning which was horrible;-))
smallBetter would have the advantage that the user interface would not change, modifying as.challenge with largeBetter would mean that existing scripts lead to wrong results which is problematic.
could someone of you please take care of this one?

see comment in T27241

@aguilera
regarding issue 1: Rmd should be changed if we want to keep that the current package version at the beginning is automatically inserted. otherwise we could only work with the md file and drop the Rmd file. the readme.md file has to stay in the root directory such that GitHub finds it. If .Rmd file is also in root the easiest thing is to compile it such that it will be in the same directory. I don't remember, why do we need to change this?

Is this the correct module? https://docs.mitk.org/2018.04/org_mitk_views_cmdlinemodules.html ? Or is there another command line tool?

1. To my knowledge it should generate a mask out of a Surface and in MITKData there should be some...I will have a look
2. That is rather a bug, because in Phenotyping there is a reference that shouldn't be there, maybe we can remove that.

@eisenman Yes, I have a dataset with ~200 Algorithms, will send it to you!

@reinkea Do you have a dataset containing more algorithms?

@eisenman can larger number of algorithms be checked? what's your opinion? please close otherwise.

solved (at least for 19 tasks) in merge for T27474

items 3 and 4 solved (see separate tasks).
solved at least for 19 algorithms.

solved at least for 19 algorithms (MSD data).

maybe introduce some utility function that takes care of it

I started with the modifications but I have two questions (@thomass):

Discussion result:
For a fast mitigation one should choose option 2 or 3 (see description) or ensure that the dicom tag values stay distinctive (see reason 1).

Discussion result: We close this task. All known issues still open are covered by T27568: US 2D image cannot be read: invalid tilt information. If needed we can open the task again.

Region growing task can be found here T27684

In T27507#208073, @thomass wrote:

2D Segmentation tools:

• Add
• Substract
• Correction
• Paint
• Wipe
• Region Growing
• Fill
• Erase
• Live Wire
• 2D Fast Marching

--> First test Looks suprisingly good, even 2D Fast Marching tool works as expected on US4DCyl.nrrd for dynamic and static Segmentation
--> Region Growing works correctly in terms of timesteps but shows odd behavior (the mouse cursor is released but still more foreground pixels are added --> this often causes an oversegmentation on US4DCyl @kislinsk is this something potentially caused by your recent change?

wip

With D380 2 breaking changes where introduced. See commit messages.

By D380

Is this still a topic?

Checked on windows (develop branch 10.8.; binaries and build tree): DICOM Reader v2 (auto select) works correctly. Have to look into it on Ubuntu.

Crash fixed by D380 :)

Pushed new branch T27676-CmdOnly.

In T27524#208371, @kislinsk wrote:

I cannot see any declaration of GetRenderingManager() in BaseRenderer

You're right, I was mistakenly reading the dialog that shows up when you create a new layer for a layer name dialog.

Layers don't have names. The plugin is only asking for label names which are important of course. For a new segmentation there are two dialogs: for the segmentation name, and for the fist label name + color. I think it evolved from the UI pattern of the old segmentation plugin and I agree that the label dialog should be omitted. A "New label <i>" could be added to the label widget instead and we should probably improve this widget so a double click on the name opens an in-place editor for the name string instead of requiring the user to right click -> Rename... -> Dialog. Color editor already works this way.

I cannot see any declaration of GetRenderingManager() in BaseRenderer (even before rMITK5e0e87c3)? In the second example I even cannot see anything related to RenderingManager? :-)

+1 and I'm also not sure why a Layer needs to have a name. I can't see it anywhere and if the name is used somewhere, the same discussion as for the labels might be needed for layers.

In T27672#208336, @thomass wrote:

Proposed a fix in D388, maybe there is a more elegant way but it works now

Proposed a fix in D388, maybe there is a more elegant way but it works now