Thank you for your feedback!

Pushed new branch T27402-qpai_CoxAlgorithmReproduction.

I agree, it would be nice if the actual number of NAs would be reported (together with the na.treat method) and not the number after na.treat which is then obviously 0.

layouting (circle sizes, distances, font sizes, size of plot) needs to be automatically optimized which I failed so far

Did you take care that FUN="mean" and FUN=mean is handled differently (in the former case it is a name, in the latter case it is a function)?

might indeed reduce complexity, however,

• many functions need to be adapted requiring some care
• behavior is sometimes by purpose different, e.g. there are plot titles with the task name in multi-task challenges while there is none in single task challenges
• many visualizations apply only to multi-task challenges and trying to use them in single task challenges throws an error, this would be needed to be handled
• also reports for multi task challenges contain more visualizations which would be uninformative for single task challenges (could however be handled by checking the number of tasks internally)
• a workaround would be necessary adding a task column to single class challenges (with the same label in every row)

I guess we have several of these subtle problems with our installers but to be sure we would need to check by building an installer from the current master and try it again.

I think it is interesting to state the number of NAs in the report but this should be the actual number of NAs (not 0).

If the "base", the image, is in dcm, and not a nrrd file (which is the case in dcipher, when pulling the images from the PAC), the Segmentation can be saved as DICOM. The created file can be saved in a mounted folder and can then be directly imported via airflow into the pacs.
Directly sending data from MITK to the PACs is not recommended, because otherwise the metadata is not extracted and the segemtation cannot be triggered via kibana!

I reproduced it with the "Installer".

[63.469] Writing image: /home/hanno/mitk/seg.dcm
Input image size: [512, 512, 7]
CodeSequence Exception: missing value in code sequence
#63.470# ERROR: An error occurred during writing the DICOM Seg: JSON Exception: file could not be read.

What is the tricky part?

What do the others think? Which number of NAs should be stated in the report?

@wiesenfa: Do you have any preference regarding the naming scheme?

@kalali Is this still relevant? If so, it would be greate if this branch becomes merged into the master or relvant changes will be cherry-picked. If not, we just close the branch. But it makes no sense to have this task/branch dangeling arround for ever.

Reporter hasn't got any crashes any more with the new version. Guess my last assumption was right. So we close the issue for good.

The null pointer is returned because mitk::ArbitraryTimeGeometry::IsValidTimePoint(...) evaluates time point 160 ms to false.

I got some data now which shows a problem with MITK 2018.4 but works with the current master. I don't see though the RWV thing. Can't remember exactly how I investigated this back then. Let's hope the more robust handling of DICOM fixed this as @floca noted , I informed the reporting users that they should comment if this should be investigated again.

The status is set as mentioned above because in QmitkImageNavigatorView::UpdateStatusBar() the call of mitk::FindTopmostVisibleNode(...) for time point 160 ms returns a null pointer.

Another observation in the current version: "No image information at this position!" is shown in the status bar when switching from second to third time step.

I tried to reproduce it. I can verify Step 1 with the MITK Multilabel Image reader but if I use the ITK NrrdImageIO reader there is no option to use autocrop.

Dicusssion result:
We make own installers like MITK Perfusion for it. So no part of the normal Workbench installer.
We change this task to a meta task for everything needed to have such own installers and CI checking...

Could it be that there is something wrong with T26840-MitkHomepageReorganization-TopLevel? I created a branch based on it and a review a while ago and the CI system detected compile errors (can't see the error message). But now @kleina has some errors building the diff-branch because of the Pharmacokinetics-Module and the mitkConcentrationCurveGenerator using Ubuntu (probably gcc, which is why did not experience this error). I think 3d5e49433c92 is missing in the TopLevel-branch which @floca added but it was never included in the mentioned branch.

Discussion result: check for option to select it.

Discussion results: check in our code base of someone uses the method. If not: Just remove it. If Yes: Look how they used/need it.

I just tested it, it works!

I don't know if that's a good thing 😈

In 2016.11.0 it's showing different volumes for all of the three time steps.