not sure whether this is a good idea. imagine a challenge with 18 algorithms. there will be only a 1 and an 18 and nothing in between, this may make it difficult to read. what do you think?

In T27637#233382, @kalali wrote:

You can see how it feels and looks when the differential for the mentioned task is uploaded. However, I am not sure about point 1B and if we should rather create a first initial label when creating a new segmentation (node).

with this point I am also unsure. From first impulse I guess I would find it annoying, if I always have to explicitly generate the first label. So I would always add at least one new label.

I have tried suggested codes but they did not fix the problem. Besides, there caused additional issues. :)

Could you try to replace "breaks" by "labels" in

I have tested this with the provided data. The scaling of the y-axis seems to be correct now. But only the first rank is labeled on the y-axis. Can the other ranks be labeled as well?

In T28950#233457, @holzwart wrote:

Is it resolved?

Is it resolved?

In T28256#233432, @floca wrote:

In T28256#233428, @kalali wrote:

Has been resolved with D533.

However, there is a slightly different behavior now with the selection widgets:
The user cannot select segmentations of image B if image A is selected in the image selection widget (node predicates only allow child-nodes of the selected image node). That means:

Either I do not understand the change correctly, or I am against it.

I think node hirachy should not be a requirement to be selectable. Only the type of node and fitting geometry should. We e.g. have use cases where image and segmentation are on the same hirachy level. In this case it should still be possible to select both (if all other requirements are meet) and modify the segmentation.

In T28256#233428, @kalali wrote:

Has been resolved with D533.

However, there is a slightly different behavior now with the selection widgets:
The user cannot select segmentations of image B if image A is selected in the image selection widget (node predicates only allow child-nodes of the selected image node). That means:

Either I do not understand the change correctly, or I am against it.

Has been resolved with D533.

I stumbled upon this since I want to automatically assign label colors to new labels. I use the Multilabel lookuptable (see https://phabricator.mitk.org/source/mitk/browse/develop/Modules/Core/src/DataManagement/mitkLookupTable.cpp$527) and the values are not working to distinguish neighboring labels / indices sufficiently.

I worked on this while working on T28142:

The problem is almost fixed by giving na.treat parameter in both as.challenge and ranking methods (except rankThenAggregate). Now we can generate reports for all ranking methods.

scale_y_continuous functions inside ./R/Stability.R file were modified. The problem seems solved. You can test it feature/T28966-YaxisOfBlobPlotsAlwaysScaledTo5 branch via the file at the attachment. (You can run it root folder of the challengeR code)

I guess na.treat it is only needed for the line plot for comparing to other ranking methods?
In this case, a message could be thrown when compiling the report saying something like "line plot comparing ranking methods omitted since na.treat is not specified. Specify na.treat in as.challenge() if inclusion of line plot is desired" and allow compilation of the report (excluding line plot).
(Note that you can define na.treat both in as.challenge() as well as in the ranking functions).

Pushed new branch to rMITK MITK: feature/T28959-livewire-closure-improvements.

Thank you for investigating this! In challengeR it is covered in the way that a message is emitted saying "na.treat obligatory if report is intended to be compiled". In order to solve the mentioned issue 2, a strategy for the preferred way to handle it in VISSART should be defined. Should the user be guided to specify the NaN handling strategy? Should the user be able to generate a report but without the plots that require numeric values?

Current status of the issue:

Since in the input image a required tag is missing, MITK cannot provide a fix, allowing a success in dcmqi