I'm trying to read some CT images from a GE Discovery STE. I managed to read them successfully in Analyze (from the Mayo) and matlab, but dcmdump exists after
DcmSequenceOfItems: Parse error in sequence, found (fffe,e000) instead of a sequence delimiter
from the dictionary
(FFFE,E000) UN Item 1
(FFFE,E00D) UN ItemDelimitationItem 1
(FFFE,E0DD) UN SequenceDelimitationItem 1
It seems that something is wrong with the encoding of sequences in that file. You could try option --ignore-errors (+E) in order to see whether at least parts of the file can be parsed correctly.
In DICOM, Item and Delimiter tags do not have a VR. The DCMTK data dictionary uses an internal pseudo-VR called "na" (for "not applicable") to mark such tags. This is indeed correct. With "UN", you would ask DCMTK to process items and delimiters as normal data attributes, and that is guaranteed not to work.
There are three special SQ related Data Elements that are not ruled by the VR encoding rules conveyed
by the Transfer Syntax. They shall be encoded as Implicit VR. These special Data Elements are Item
(FFFE,E000), Item Delimitation Item (FFFE,E00D), and Sequence Delimitation Item (FFFE,E0DD).
I've also done some googling and found other dictionaries that use na as 'VR' for those 3.
Nevertheless, I find this a bit strange/dangerous. I think it would be good when reading the dictionary to either
- force the VR to 'na', or
- abort with a warning and say this is not what you expect
Anyway, for the moment I'll adjust my dictionary such that DCMTK reads it correctly.
The dangerous part is indeed that DCMTK allows you to define these tags in the dictionary at all (despite the fact that there are hard-coded defaults for them anyway), but then adding additional error checking would slow down each and every application while you seem to be the first person in a long time ever have tried to have fun with this - which you had as it seems
