There are error messages in the logging view after loading the data:

Info BlueBerry mbilog backend registered BlueBerry
Info Logfile: C:/Users/franza/AppData/Local/DKFZ/MITK Workbench_28743646/data/13/mitk.log
Info Registering PicFileIOFactory
Info BlueBerry Workbench ready BlueBerry
Warning Could not access tag (0028,0030): IDifyTagValue() illegaly called with empty tag value
Warning Could not access tag (0018,0050): IDifyTagValue() illegaly called with empty tag value
Warning Could not access tag (0028,0030): IDifyTagValue() illegaly called with empty tag value
Warning Could not access tag (0018,0050): IDifyTagValue() illegaly called with empty tag value
Warning Could not access tag (0028,0030): IDifyTagValue() illegaly called with empty tag value
Warning Could not access tag (0018,0050): IDifyTagValue() illegaly called with empty tag value
Warning Could not access tag (0028,0030): IDifyTagValue() illegaly called with empty tag value
Warning Could not access tag (0018,0050): IDifyTagValue() illegaly called with empty tag value
Warning Could not access tag (0028,0030): IDifyTagValue() illegaly called with empty tag value
Warning Could not access tag (0018,0050): IDifyTagValue() illegaly called with empty tag value
Warning Could not access tag (0028,0030): IDifyTagValue() illegaly called with empty tag value
Warning Could not access tag (0018,0050): IDifyTagValue() illegaly called with empty tag value
Warning Dicom images are missing attributes for a meaningful sorting.
Warning Sorting error. Leaving series unsorted.
Error Reader implementation made wrong assumption on tag (0020,0032). Found 0 instead of 3 values.
Error Reader implementation made wrong assumption on tag (0020,0032). Found 0 instead of 3 values.
Error Reader implementation made wrong assumption on tag (0020,0032). Found 0 instead of 3 values.
Error Reader implementation made wrong assumption on tag (0020,0032). Found 0 instead of 3 values.
Error Reader implementation made wrong assumption on tag (0020,0032). Found 0 instead of 3 values.
Error Reader implementation made wrong assumption on tag (0020,0032). Found 0 instead of 3 values.
Error Reader implementation made wrong assumption on tag (0020,0032). Found 0 instead of 3 values.
Error Reader implementation made wrong assumption on tag (0020,0032). Found 0 instead of 3 values.
Error Reader implementation made wrong assumption on tag (0020,0032). Found 0 instead of 3 values.
Error Reader implementation made wrong assumption on tag (0020,0032). Found 0 instead of 3 values.
Error Reader implementation made wrong assumption on tag (0020,0032). Found 0 instead of 3 values.
Error Reader implementation made wrong assumption on tag (0020,0032). Found 0 instead of 3 values.
Error Reader implementation made wrong assumption on tag (0020,0032). Found 0 instead of 3 values.
Error Reader implementation made wrong assumption on tag (0020,0032). Found 0 instead of 3 values.
Error Reader implementation made wrong assumption on tag (0020,0032). Found 0 instead of 3 values.
Error Reader implementation made wrong assumption on tag (0020,0032). Found 0 instead of 3 values.
Error Reader implementation made wrong assumption on tag (0020,0032). Found 0 instead of 3 values.
Error Reader implementation made wrong assumption on tag (0020,0032). Found 0 instead of 3 values.
Error Reader implementation made wrong assumption on tag (0020,0032). Found 0 instead of 3 values.
Error Reader implementation made wrong assumption on tag (0020,0032). Found 0 instead of 3 values.
Error Reader implementation made wrong assumption on tag (0020,0032). Found 0 instead of 3 values.
Info Reading series 0: 1.3.12.2.1107.5.4.1.2151361210.20111212.114833.11024.1024.0
Error Skipping series 0 due to exception
Info Reading series 0: 1.3.12.2.1107.5.4.1.2151361210.20111212.114833.11024.1024.1
Error Skipping series 0 due to exception
Info Reading series 0: 1.3.12.2.1107.5.4.1.2151361210.20111212.114833.11024.1024.2
Error Skipping series 0 due to exception
Info Reading series 0: 1.3.12.2.1107.5.4.1.2151361210.20111212.114833.11024.1024.3
Error Skipping series 0 due to exception
Info Reading series 0: 1.3.12.2.1107.5.4.1.2151361210.20111212.114833.11024.1024.4
Error Skipping series 0 due to exception
Info Reading series 0: 1.3.12.2.1107.5.4.1.2151361210.20111212.114833.11024.1024.5
Error Skipping series 0 due to exception

This bug could not be fixed within the 2013-06 release and has medium severity. Setting target milestone to unspecified.

This bug could not be fixed within the release 2013-06. Setting its target milestone to unspecified

MITK still crashes while loading fluoroscopy DICOM images. Added attachment to bug.

Fluoroscopy Arthur's hand (Test Image)

@Arthur: are you actively working on this? Could you please take the bug then?

This bug also occurred when I tried to load fluoroscopy data in MITK a while ago. If you need more test data you can ask me, I still have it here on CD. Unfortunately I can't put it online because it is confidential patient data.

New remote branch pushed: bug-13248-LoadFluoroscopyData

I just took a look at the code of branch bug-13248-LoadFluoroscopyData and I'd like to comment on some things:

• what kind of DICOM class are you working with? This is stored in tag SOPClassUID
• I cannot find any reference to what actually happens. What are the values of the tags PixelSpacing or ImagerPixelSpacing?
• could you please describe what your code actually changes?
  • from a quick guess, I'd say that you made DICOMStringToSpacing accept spacings like "2", although spacing must always be expressed as "y\\x"
  • I don't really understand the intended change in FixSpacingInformation(),

An important part in DicomSeriesReader is that it tries carefully to describe the meaning of its produced spacing values, see type PixelSpacingInterpretation. I don't see how this is regarded. If I correctly understood that you handle partially declared spacings such as "3.1", I would not trust that the spacing of mitk::Image is valid for measurements.

There is also a big refactoring effor going on in T16744. When your changes are finalized, we should take care that they are transferred to this other bug.

Regarding test data, a very useful tool for anonymization can be found here:

http://mircwiki.rsna.org/index.php?title=DicomEditor
http://mirc.rsna.org/download/DicomEditor-installer.jar
Syntax: http://mircwiki.rsna.org/index.php?title=The_MIRC_DICOM_Anonymizer

Just take care to remove not only the patient's name but his address as well as the names and addresses of the institutions and the three physician roles involved.

My code tries to avoid that the DICOMSeriesReader sets the spacing to 0.

"from a quick guess, I'd say that you made DICOMStringToSpacing accept

spacings like "2", although spacing must always be expressed as "y\\x" "

• No I just incorporated an IF-clause to avoid spacing to become 0. The bug I fixed happens in mitkDicomSeriesReader Line 1446 and 1447. For some reason (iterative process) the spacing gets changed for 2D images (but which have three dimensions in DICOM file) to 0 at some point.

I do not change spacings if they are corrected - I just don't them to be zero (assert in mitkSliced3DGeometry.cpp line 552 then fails).

(In reply to Arthur Teimourian from comment #10)

My code tries to avoid that the DICOMSeriesReader sets the spacing to 0.

"from a quick guess, I'd say that you made DICOMStringToSpacing accept

spacings like "2", although spacing must always be expressed as "y\\x" "

• No I just incorporated an IF-clause to avoid spacing to become 0.

I referred to your changes in DicomSeriesReader::DICOMStringToSpacing. With your change, this method does not require two tokens anymore to return true. Sascha pointed out in a mail that error checking (replacing atof) would be good here), which is right. However, I would suggest not to accept anything other than a string of two tokens separated by a backslash as valid spacing. I don't know a place in DICOM that describes pixel spacing with a single value.

The bug
I fixed happens in mitkDicomSeriesReader Line 1446 and 1447. For some reason
(iterative process) the spacing gets changed for 2D images (but which have
three dimensions in DICOM file) to 0 at some point.
I do not change spacings if they are corrected - I just don't them to be
zero (assert in mitkSliced3DGeometry.cpp line 552 then fails).

Ok, some point that would help me to understand you better:

• what pixel spacing tags (and what values) do you find in your dataset?
• what spacing does the mitk::Image that is passed into FixSpacingInformation have (this is part of the geometry's information)?
  • also the original ITK-Image's (ImageSeriesReader's output) spacings would be interesting.
• when you say "spacings get changed", what change do you observe (should be ansered by above questions)?

By now, Arthur has provided me with an example dataset (private mail).

The dataset is SOP class "Secondary Capture Image Storage" for modality "XA".
PixelSpacing is "00.000\00.000". Other tags pose tiny challenges for parsers, e.g. RescaleIntercept is " 0" (spaces), Window Center is "00512\000512", WindowWidth "1024\01024". There are also several older ACR-NEMA tags.

I hope you are aware that any kind of measurements on this image will produce artificial, non-meaningful numbers. Also the sole display may be wrong if pixels are not squared in the original image.

In my opinion, a fix to make this image display at all should look like this:

• spacing should be fixed to 1\1 (consequently this should happen in any case where the parsing does not find two positive numbers)
• spacing interpretation should be fixed to "unknown spacing (pixels)" (this is important to let applications know that the mitk::Image is not to be trusted regarding pixel spacing)
• both current master and the branch of 16744 would need fixing

But to be clear, I would recommend to not implement any complicated solutions for images that are broken like this. Ask the vendor to produce correct information or (more probable) add a patching step to your workflow and fix the PixelSpacing tag.

Arthur, do you still work on this bug? Was there any progress?

If not please reset to "confirmed".

No I am not. I had requested a core changed request a few month ago, which got rejected.