(0088, 0200) Icon Image Sequence Non conformance with standard.

[opennog]

Hello,

I have set up a PACs which I recently updated from pynetdicom 1.4.1 to >=2.0.0. Before the update all the images were correctly transferred with this PACs, however, since the update the tag '(0088, 0200) Icon Image Sequence' seems to be causing problems to subsequent softwares that are in conformance with the DICOM standard.

In other words, pynetdicom versions >=2.0.0 seem to mangling out that SQ. Could you please provide an explanation of why what used to work with version 1.4.1 is not working anymore?, and could you please fix it in the next release?

Thank you very much.

I originally posted the issue in the dcm2niix tool, please, see whole thread here: https://github.com/rordenlab/dcm2niix/issues/638

[neurolabusc]

@opennog I realize that you have clinical data which you can not share. However, I think a sample dataset that illustrates the issue is required. It is possible that some issues were caused by a previous or subsequent anonymization step. In your case, dcm2niix assumed that the icon must have image data associated with it because the SQ did not end with a delimiter.

The issue you are having is an interaction of three factors:

1. The DICOM file contains an Icon Image Sequence (0088, 0200).
2. This icon has no image data (7fe0,0010) associated with it.
3. The SQ was saved with an explicit length, so it did not have a delimiter.

It makes no sense to describe a thumbnail icon and then not include the thumbnails image data. However, I do not think the images you provided are DICOM violations. Rather, they triggered a series of kludges in dcm2niix that are designed to handle invalid GE GEIIS thumbnails which were often mangled by subsequent PACS or anonymization attempts. I have tried to refine dcm2niix's handling detection of GEIIS icon related corruption to deal with SQs of explicit length.

[scaramallion]

Thanks for the info @neurolabusc