Page MenuHomePhabricator

US 2D image cannot be read: invalid tilt information
Closed, ResolvedPublic

Description

The Canon images (stills; see sample data in super task T27554) cannot be read. The error message given is.

"Invalid tag values when constructing tilt information from origin1 '', origin2 '', and orientation ''.

Reason for the error in case of the example data:

  • The directory containes 2 files/images.
  • Both files have the same patient ID, study and series instance UID etc., so MITK IO assumes to be part of the same volume
  • As Both images have cover the same space in world geometry, MITK reader that support 3D+t are choosen as they assume that they can read it only one volume (other readers need obviously two volumes).
  • 3D+t reader faile in loading process as no meaning full tilt can be deduced (see error message above).

Remark: It is unclear if the anonymization scheme or the data stored by the vendor itself let to the problem of same UIDs etc. May be the anonymization strategies should be checked as it leaves the data illformed.

Possible mitigation strategies or solutions:

  1. see remark above, should be checked (but not a MITK side solution).
  2. Seperate the image in different directories before loading.
  3. Select as reader "MITK DICOM Reader v2 (manual)" and choose any non 3D+t configuration
  4. Offer a reader that only chooses from 3D configuations automatically
  5. Rework reader infrastructure to also check the tilt validity when searching for optimal solution.
  6. Rework reader infrastructure to make tilt invalidity also to a reason to seperate blocks.

Comments regarding solutions:
2: is already possible.
3: see 2
4: Another reader could swamp the selection even more. Adding it as option (e.g. "only static" to the "MITK DICOM Redar v2 (auto)" would cause the workbench to not automatically execute the reader any more as he has options. On the other hand the workbench does not execute DICOMs automatically anyway because we have already 4 different options available...
5: Problematic as we move even more computational stuff in the pure reader selection, which can slow the loading process down even further. Especially because it curently would be thrown away and done twice; 1st for the selection and then 2nd for the real reading.

Event Timeline

floca moved this task from Backlog to MITK Meeting on the Request for Discussion board.

Should discuss in the MITK meeting about the solutions.

floca triaged this task as Normal priority.Jul 19 2020, 3:09 PM

Thanks for the remarks and solution options.

  1. The data is taken from the device as is, ie without any modifications or anonymization. We can check with the vendor if there can be made adjustments for prospective data. However, currently we are using retrospective data that is provided in the given format. Horos (https://horosproject.org/) processes the data in a desirable way - so I assume it might not be "uncommon" or a falsly confgured US device
  2. Solution 2 is feasable and probably the pragmatic, albeit manual, approach

Just as a remark: I am getting the exact same error, if I want to load a dcm image from a folder that contains more than one image. Those images originate from a cadaver study which means that before acquisiton most of the patient input data is left blank (study,series etc). If I put the files into separate folders, they are loaded correctly.

Discussion result:
For a fast mitigation one should choose option 2 or 3 (see description) or ensure that the dicom tag values stay distinctive (see reason 1).

A fundumental change in the sorting, splitting of volumes and selection of reader, would need a big refactoring of the reader infrastructure to avoid decreasing loading performance!
Basically it would to a next generation of MITK DICOM readers, so it is a bigger thing and should be carefully planed and decided to make the time invest worth it.
REMARK: In this context (refactoring/reimplementation) then also T27432: Error loading DCE-MRI DICOM image could be tackled; but that task does not need such an big intervention, so could also be fixed on its own and is just mentioned to identify synergies.

Remark regarding option 4:

If we use an dedicated DICOM US mime type with high priority for dedicated DICOM US Readers. The would not swamp the reader selection for normal dicom images and would be preselected for US images.

kislinsk added a project: Auto-closed.

Hi there! 🙂

This task was auto-closed according to our Task Lifecycle Management.
Please follow this link for more information and don't forget that you are encouraged to reasonable re-open tasks to revive them. 🚑

Best wishes,
The MITK devs

kislinsk claimed this task.
kislinsk added a project: Moved to git.dkfz.de.

This task was closed here on Phabricator since it was migrated to GitLab. Please continue on GitLab.