Current status:
If we have multiple DCM files with same series UID but with no image position or orientation (e.g. multiple screenshots or other 2D images).
The loading process throws an exception, complaining that the tilt information cannot computed.

Reason:

1. mitk::DICOMFileReaderSelector::GetFirstReaderWithMinimumNumberOfOutputImages uses DICOMGDCMTagScanner which produces DICOMGDCMImageFrameInfo instance.
2. mitk::DICOMGDCMImageFrameInfo::GetTagValueAsString always return default values for position and orientation of the tags do not exist in the frame.
3. This leads the multiple images to be put into a 3D+t block.
4. When we then realy do the loading (BaseDICOMReaderService::GetOnlyRegardOwnSeries()), DICOMDCMTKTagScanner is used instead (for supporting nested tag paths) -> produces DICOMGenericImageFrameInfo instances
5. DICOMGenericImageFrameInfo does not return default values.
6. This lead to a faiing tilt computation because the values are not set.

Thoughts:
I think the cleanest way is to not let frame info produce any type of default values. The should just return what is ther . Calling code should then decide what they should do with missing values.
In this very case, I think the images should be splitted right away into different blocks.
If we go that route all usages of GetTagValueAsString should be checked under which assumptions they are called and how the values are used.

Remark:
Also stumpled upon other not so rebust situations e.g. in the DICOMTagSorter:BuildID. Here we shoud ad a delimiter to make the id more uniwue also in case of multiple not existing tag values.