Does this happen with reguar DICOM open as well?

yes, but similar:

The typical "Output Window" appears telling me:

sorry, the above comment was mentioned to be in T3447.

Regarding this bug:

T:\3M3 Demodaten\dicom_dir is also NOT loaded successfully with 3m3's file->open dialog.

log tells me the loading of each slice, then nothing else happens

(tried with .EXE installer on w6 64bit)

I think this bug is very similar to T3205. Since MITK relies on ITK (more specifically on gdcm) in order to load DICOM images, there is not much I can do about it.

(In reply to comment #4)

I think this bug is very similar to T3205. Since MITK relies on ITK (more
specifically on gdcm) in order to load DICOM images, there is not much I can do
about it.

If it is a ITK bug, you could maybe have a look at the code whether it is easy to fix. If it is reproducable also with just using two slides and they are properly anonymized you could file a bug in ITK and post the link to the bug at their tracker here. Then it can set to RESOLVED THIRDPARTY ...

I've checked the mitkImageMapper2D.

When loading "normal" images, in the first run of GenerateData, the method ends at line 505. The extents are usually smaller or equal to 2 (I think because the reference geometry is not set yet), and the method exits.

In the case of this particular image, the extents are 2.048 though, and the method does not exit. Since the geometry information does not exist yet, the reslicer returns a 0-dimensional data, and a warning happens, as mentioned by Matthias.

As far as I understand, the extents are given in Pixels, and should be unsigned ints instead of floats. I think that the extent calculation should be rounded at the end. However, I am not sure if it is true. Rounding it would solve the problem.

Does someone have another idea?

(In reply to comment #6)

In the case of this particular image, the extents are 2.048 though, and the
method does not exit. Since the geometry information does not exist yet, the
reslicer returns a 0-dimensional data, and a warning happens, as mentioned by
Matthias.

Could you find out why the extents for the problematic image are set to 2.048? This seems quite strange in itself...

The extents in the first run of GenerateData are computed through the norm of the axis vectors in index coordinate (lines 403-406). There are many operation involved:

• Transformation of the vectors in world coordinates to index coordinates, which involves a few matrix transformations;
• Computation of the norm from the transformed vectors.

As I mentioned before, the other images have values smaller or equal to 2.0 for the extents in the first run, and the method returns without further processing (lines 506-509). I've watched the extents of several images and they ranged between 1.2 and 2.0.

Since these vectors represent the extents in index coordinates, I guess that float numbers are not allowed. These extents are also used to compute the mm per pixel values (lines 415-416), so they are definitely the size in pixels, and I can imagine that having float values for them does not make sense.

(In reply to comment #8)

The extents in the first run of GenerateData are computed through the norm of
the axis vectors in index coordinate (lines 403-406). There are many operation
involved:

• Transformation of the vectors in world coordinates to index coordinates,

which involves a few matrix transformations;

• Computation of the norm from the transformed vectors.

As I mentioned before, the other images have values smaller or equal to 2.0 for
the extents in the first run, and the method returns without further processing
(lines 506-509). I've watched the extents of several images and they ranged
between 1.2 and 2.0.

Since these vectors represent the extents in index coordinates, I guess that
float numbers are not allowed. These extents are also used to compute the mm
per pixel values (lines 415-416), so they are definitely the size in pixels,
and I can imagine that having float values for them does not make sense.

Probably the cleanest solution would be to check in another way if the current (reference?) geometry is not yet set, and therefore the extents cannot be computed properly. The check for an index coordinate extent of <= 2 seems to be a bit arbitrary to me (could it not be that the extent in some rare cases suddenly becomes greate than 3.0, e.g.? At least then rounding would also not work...)

(In reply to comment #9)

Probably the cleanest solution would be to check in another way if the current
(reference?) geometry is not yet set, and therefore the extents cannot be
computed properly. The check for an index coordinate extent of <= 2 seems to be
a bit arbitrary to me (could it not be that the extent in some rare cases
suddenly becomes greate than 3.0, e.g.? At least then rounding would also not
work...)

You are probably right. The geometry in question is the WorldGeometry. I gues it represents the planes, is that correct?
The problem only happens if load this specific image after starting the application (when the planes are not yet there). If another image is loaded before, and the planes are already displayed, the warning does not occur.

Is there a way to check if this geometry is valid or not? I guess that checking if the extents are smaller than 2.0 is a way the author of this class used to check that. It has been proved not to be the best way. Can it be done differently?

In order to solve this warning problem, one can check if the world geometry was already initialized with a reference geometry. If not, it means the the planes are not there yet, and the method should return.

[SVN revision 22210]
FIX (#3250): Checking if the worldGeometry2D was correctly initialized before continuing.