You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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 afterhttps://github.com/UCL/STIR/blob/master/src/utilities/SPECT_dicom_to_interfile.cxx#L559-L560
bv
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?
The text was updated successfully, but these errors were encountered: