Sat, Jan 25
Jan 16 2020
Dec 20 2019
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?
Dec 19 2019
Dec 6 2019
Nov 27 2019
Oct 29 2019
Oct 25 2019
Oct 23 2019
Oct 11 2019
@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:
Basically, it's the following information:
- Patient data
- Image data (e.g. pixel spacing, referrence to original DICOM)
- optional name of Measurement for referrencing
- 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
Can you give us more information about what's actually contained in the report?
Oct 10 2019
Oct 1 2019
Sep 27 2019
- Currently we can put into the methods subsection
- 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.