Pushed new branch T27426-IvimFits.

Uh, I noticed that it is possible to add aliases/workflows to Arcanist, that are sourced from the project repository. Could be a nice way of streamlining some things. I also noticed that there's already an arc feature feature/T12345-bla which boils down to a git checkout develop && git checkout -b feature/T12345-bla.

File is correctly saved in the current master.

In T27181#200032, @gaoh wrote:

then build package target in MITK build.

@kislinsk what do you mean with this? Is it just the "normal" process, aka cmake and make in MITK-build. Or do I have to configure something additionally?
I tried the normal way and got also the "normal structure": with a bin, lib, Modules etc folder. Whereas when I download the release 18.04, the libraries are directly packed into the bin folder?

then build package target in MITK build.

@kislinsk what do you mean with this? Is it just the "normal" process, aka cmake and make in MITK-build. Or do I have to configure something additionally?
I tried the normal way and got also the "normal structure": with a bin, lib, Modules etc folder. Whereas when I download the release 18.04, the libraries are directly packed into the bin folder?

The variable "boot_object" that was introduced to the develop branch by this fix is not available in this report. The short multi-task report is without bootstrapping.

Wouldn't that be covered by the RoiBasedFitGenerator together with the CMRO2 Model?

Something important I think is also, that all plot functions work outside of the report as intended (it is desirable that users can also create their own reports). This includes choosing the correct function and giving an error if a function does not work with single tasks, e.g.

Thanks.
In a single task situation, in practice a task will not have a name, so there should be no title and there should not be the need to set a task name I think....
I'll have a look at it, but please give me some time

Now I know what you were meaning with all your points ;)
I started to work on this during our hacking days on this branch. I managed to transform a single-task data set into multi-task data set including one task. I had to adapt some plot code. And for the reports many duplicate changes would have been necessary. So on the way, I decided to refactor the generation of the reports to lower the future maintenance effort: I extracted the report sections to separate files and include them depending on the variables isMultiTask and bootstrappingEnabled. So each text block and code snippet exists only once. And it's still possible to get four types of reports (single-task data set with and without bootstrapping, multi-task data set with and without bootstrapping). I compared the reports with the reference reports I generated from the master branch. They look the same apart from that the plots for single-task data sets are also labeled with the task name. The next step would be a general clean-up of the functionality that was used for single-task data sets.

I think this should be well thought through before putting into action

Yes, this results in Na, but they shouldn't be treated like before; you're right. @wiesenfa: What do you propose for the plots? Should we just remove the warnings?

it's not because of missing test cases. It is because in certain situation no Kendall can be computed. Don't use treat.na for this.

This is due to the fact that missing values cannot be plotted:

Pushed new branch bugfix/T27418-DashboardScriptDownloadWorkaround.

Pushed new branch T27417-FixReaders.

The reason is still unkown. But if you store the segs without skipping the empty slices, then mitk is able to load also segs with one slice.

Pushed new branch feature/T27415-ChangeArcMergeBase.

Ok, I saw it now what is generated for the data set that comes with the package: