Found the reason. The default values from the XML-Configurator-Class and the classes that should be configured differ. This leads to the fact of differently configured readers if you go via "class configuration" (like mitk::ClassicDICOMSeriesReader) or use the xml (classicreader.xml).

To fix it and to brake as less known behavior as possible, we should proceed as follows:

1. change the description of the classicread.xml -> it does not resemble ClassicDICOMSeriesReader
2. Change the default values of classes to the default values the mitk::DICOMReaderConfigurator would use.
3. Change initialisation of ClassicDICOMSeriesReader to have the "old" settings again (so compensate the changes due to #2)
4. Add a xml that is really identical with mitk::ClassicDICOMSeriesReader

Pushed new branch T19437-DICOM_config_file_and_class_inconsistency.

While fixing the task, we decided to let the classes define what is the default and not the configurator (Reason: Now we will get a reader that is equivalent to the class constructor, if we provide an XML with no settings. This seems to be the most natural behavior).

This change leads to potential breakings of old xml configurations, because the following settings have new default values:

• FixTiltByShearing (false -> true);
• StrictSorting (true -> false);
• ExpectDistanceOne (true -> false)

To warn about this fact, all configurations provided by MITK have been raised to version 2. Using old version 1 configurations will create a warning to inform about the potantially changed behavior.