DcmSequenceOfItems: Parse error in sequence on GE CT files

All other questions regarding DCMTK

Moderator: Moderator Team

Post Reply
Message
Author
krthie
Posts: 14
Joined: Thu, 2006-03-09, 16:30
Location: Hammersmith Imanet

DcmSequenceOfItems: Parse error in sequence on GE CT files

#1 Post by krthie » Fri, 2006-03-10, 01:52

Hi

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
Can anyone help?

Many thanks

Kris Thielemans
Hammersmith Imanet
London, UK

Jörg Riesmeier
ICSMED DICOM Services
ICSMED DICOM Services
Posts: 2217
Joined: Fri, 2004-10-29, 21:38
Location: Oldenburg, Germany

#2 Post by Jörg Riesmeier » Fri, 2006-03-10, 09:46

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.

krthie
Posts: 14
Joined: Thu, 2006-03-09, 16:30
Location: Hammersmith Imanet

#3 Post by krthie » Fri, 2006-03-10, 15:45

thanks for the suggestion. That gives me
....
(0008,1090) LO [Discovery STE] # 14, 1 ManufacturersModelName
(0008,1110) SQ (Sequence with undefined length #=0) # u/l, 1 ReferencedStudySequence
(fffe,e0dd) UN (SequenceDelimitationItem) # 0, 0 SequenceDelimitationItem
and dcmdump then exits (there's still plenty after that).

I'm sorry, but I still don't know what to do...

Kris Thielemans
Hammersmith Imanet
London, UK

krthie
Posts: 14
Joined: Thu, 2006-03-09, 16:30
Location: Hammersmith Imanet

#4 Post by krthie » Fri, 2006-03-10, 17:48

I found out that my problem is related to the DICOM dictionary that I'm using. If I use dcmtk's dicom.dic everything is fine.

The relevant difference between the 2 dictionaries is

OFFIS dictionary
(FFFE,E000) na Item 1
(FFFE,E00D) na ItemDelimitationItem 1
(FFFE,E0DD) na SequenceDelimitationItem 1
my dictionary
(FFFE,E000) UN Item 1
(FFFE,E00D) UN ItemDelimitationItem 1
(FFFE,E0DD) UN SequenceDelimitationItem 1
with the last settings, dcmdump fails.

I'd appreciate it enormously if somebody could confirm that the 'na' VR is the appropriate one.

Many thanks!

Kris

Marco Eichelberg
OFFIS DICOM Team
OFFIS DICOM Team
Posts: 1237
Joined: Tue, 2004-11-02, 17:22
Location: Oldenburg, Germany
Contact:

#5 Post by Marco Eichelberg » Tue, 2006-03-14, 17:32

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. :wink:

krthie
Posts: 14
Joined: Thu, 2006-03-09, 16:30
Location: Hammersmith Imanet

#6 Post by krthie » Thu, 2006-03-16, 12:05

ok.

I see that now (p.40 of http://medical.nema.org/dicom/2004/04_05PU.PDF):
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.

Many thanks for your help

Kris

Marco Eichelberg
OFFIS DICOM Team
OFFIS DICOM Team
Posts: 1237
Joined: Tue, 2004-11-02, 17:22
Location: Oldenburg, Germany
Contact:

#7 Post by Marco Eichelberg » Mon, 2006-03-20, 12:59

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

Post Reply

Who is online

Users browsing this forum: Bing [Bot] and 1 guest