CI

Pushed new branch T26942-ImproveCESTPrivateTagParsing.

Despite all of the obvious flaws of the parsing code around the highlighted line linked above, the particular reason for the crash is a missing check against npos regarding the results of the find() calls. Even without a more comprehensive fix, the hex number string extraction and conversion to ASCII characters should be enhanced by checking against non-ASCII hex values.

@k656s Is the example data available on our network drives?

@hentsch : Du kannst es erstmal direkt in PlanaFigure reinpacken, auch wenn es eine DCMTK dependency bedeutet. Wir schauen es uns erstmal an und wollen bis dahin den Aufwand gering halten.

@kislinsk Sure. I attached a screenshot of a sample DICOM-SR file:

• Patient data
• Image data (e.g. pixel spacing, referrence to original DICOM)
• optional name of Measurement for referrencing
• Measurements
  • Length of line in mm (source: PlanarLine or open PlanarPolygon)
  • Length of Major and Minor axis in mm (source: PlanarEllipse or PlanarCross)
  • Area in mm² (source: closed PlanarPolygon)
• Source of measurements with source points
  • POLYLINE or
  • ELLIPSE

Can you give us more information about what's actually contained in the report?

Discussion result:

1. Currently we can put into the methods subsection
2. Next step would be to retrofit the code to be a usefull service. This we have to discuss further

The export is currently implemented as class creating a DCMTK DSRDocument from PlanarFigures and DICOM information. If it's not too much effort, I'm still flexible about implementing it as MITK writer or other implementation details.