reading SPECT DICOM projections when using fragments

[KrisThielemans]

@varzakis has some files from GE D670 where SPECT_dicom_to_interfile fails as it cannot read the raw data, specifically after
https:/UCL/STIR/blob/master/src/utilities/SPECT_dicom_to_interfile.cxx#L559-L560
bv is 0. Currently this causes a segfault

Reading 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:

            const gdcm::DataElement &de_idata = ds.GetDataElement( gdcm::Tag(0x7FE0,0x0010) );
            const gdcm::SequenceOfFragments *frames = de_idata.GetSequenceOfFragments() ;
            unsigned int no_of_frames=0 ;
            const char *bvp ;
            if(frames!=NULL){
                no_of_frames = frames->GetNumberOfFragments()  ;
                const gdcm::Fragment &frag = frames->GetFragment(0) ;
                unsigned int flength = frag.GetLength() ;
                const gdcm::ByteValue *bv = frag.GetByteValue() ;
                bvp = bv->GetPointer() ; // This gives the (potentially compressed) data pointer

@smanwell do you have any experience with this?

[smanwell]

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:/smanwell/STIR/tree/Enhanced_support_multi-head_SPECT_projection_data

[KrisThielemans]

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.