Open KrisThielemans opened 1 month ago
I too have encountered datasets that crashed at that line. They might have been from GE systems, but I can't recall.
What I found is that the DICOM file had a Transfer Syntax UID (meta header attribute) that indicated that it was compressed (see examples syntax values here).
I have a change on a forked version of STIR (that I've been meaning to submit a PR for...) that resolved the issue that I was experiencing. The change was to use GDCM to rewrite the file using an uncompressed transfer syntax, and then re-reading it.
I can't say for certain if its the same issue reported here, but I suspect so. I'll try to submit the PR for my change soon, but in the meantime, my fork is here:
https://github.com/smanwell/STIR/tree/Enhanced_support_multi-head_SPECT_projection_data
Thanks a lot! It was indeed the case that the data used compression. At present, we got around this problem by using
gdcmconv --raw input.dcm output.dcm
and then using SPECT_dicom_to_interfile
on that. Obviously, being able to do that directly would be better.
I had a quick look at your branch. I'm wondering if we could use a higher level GDCM function which does the decompression for us, to avoid creating a temp file. In any case, looking forward to a PR! And thanks for your help.
@varzakis has some files from GE D670 where
SPECT_dicom_to_interfile
fails as it cannot read the raw data, specifically after https://github.com/UCL/STIR/blob/master/src/utilities/SPECT_dicom_to_interfile.cxx#L559-L560bv
is 0. Currently this causes a segfaultReading up a bit, this is likely because the data is "encapsulated" (or stored as "fragments"), see https://dicom.nema.org/medical/dicom/current/output/chtml/part05/sect_A.4.html which is quite horrible to understand.
Possibly code to read this (if uncompressed) from https://sourceforge.net/p/gdcm/mailman/gdcm-developers/thread/VI1PR0301MB2366421A4748670995353892E01C0%40VI1PR0301MB2366.eurprd03.prod.outlook.com/#msg35269196:
@smanwell do you have any experience with this?