@floca I tried to build this configuration - but I cant find the executable.

Ok, for the beginning, to have a configuration as fast as possible for the kaapana release, I have kept Qt on board as dependency and not started to mess arround in code.

@schererj Do you mean the XML result export?

@goetzm Thanks for the feedback. I will have a look, if take that road or life with Qt dependency for now. Have to evaluate the impact in practice...

It really depends. I totally agree that it is not necessary for routine jobs, however it comes in really handy for controlling the data on remote locations were executing MITK is not possible/forbidden. That's why it had been build in.

@goetzm Does the GIF mini app realy need the screenshot feature within the app (there is also a CLScreenshot app)?
Reason for the question is, that this feature is the only reason why Qt becomes dragged into the app and it bloats the container/deployment. Just wanted to now if we can the keep the configuration as slim as possible.

Rework of the GIF containes some API breaking changes in the GIF class interface.

Discussion result: For now (MITK 2020) we well deactivate the skipping of empty slices. But such a support would make sense longterm, but it is also a bigger issue. I have opened a dedicated Task T27439: [Segmentation] Support of Mask/Segmentations that are cropped / do not cover the whole image grid for that.

Pushed new branch T22616-Store_version_and_reader_information.

The follwing informations are stored now in properties.

This branch contains a interface breaking commit for all classes
derived from AbstractFileReader. Derived classes have to
implement now "std::vector<BaseData::Pointer> DoRead()".
Normaly the only thing to do, is to rename the Read()
implementation of the derived class to DoRead().

Feature classes where reworked, and cleaned up. Introduce FeatureID allow for more export flexibility but API of feature classes have some breaking changes.

Pushed new branch T27341-New_structured_classifiction_result_format.