this seems to affect 3D images as well.
i can provide test data.

Just one note to my last comment referring to 3D images:

The DICOM standard defines the following DICOM tags that have effect on the slice thickness / position:

• SliceThickness: is the actual thickness of a slices, like it is taken by the imaging modality
• Spacing Between Slices: is not the same like SliceThickness, but the distance between the centers of neighbouring pixels. Thus it is possible to have gaps or overlap between slices (z.B. Thickness 2mm, Spacing 1mm)

Note that "Spacing Between Slices" is not a mandatory field and thus is can happen that it is not always set.
Note also: It would be wrong to use the "Slice Thickness" as the spacing because this would lead to wrong volume calculations that are done upon the image.
Because of that it is recommended to calculate the z-spacing by using the information from the DICOM tags "Image Position" and "Image Orientation (Patient)",
see also: http://public.kitware.com/pipermail/insight-users/2005-September/014711.html

How does MITK handle this:

• MITK cannot display gaps or overlaps between slices. The spacing in MITK is equal to the Spacing Between Slices from the DICOM Standard
• MITK calculate the spacing using the recommended method (based on ImagePositionPatient and ImageOrientationPatient)

So I assume in case of 2D images, we should consider the slice thickness. In case of 3D images this information should not be taken into account for the calculation of the spacing.

I found a 3D image with this particular problem. gdcmdump tells me
(0018,0050) DS [0.28] # 4,1 Slice Thickness
(0018,0088) DS [-0.28 ] # 6,1 Spacing Between Slices
(0028,0030) DS [0.28\0.28 ] # 10,2 Pixel Spacing

MITK and itk-based tools (tested with itk-snap) load this image with a spacing of [0.28, 0.28, 1.0], which give a really thick image. It seems to to me that this image should have a spacing of [0.28, 0.28, 0.28], but I'm not a dicom wizard, so who knows?

I'm pretty sure that MITK is not to blame here. ITK or gdcm return the wrong spacing and MITK use it. Considering that itk has the same problem, I don't think it should be fixed in MITK.