DCMCONV-Problem: Corrupted data/Parse error

All other questions regarding DCMTK

Moderator: Moderator Team

Post Reply
Message
Author
johnfreak21
Posts: 4
Joined: Mon, 2011-02-28, 10:47

DCMCONV-Problem: Corrupted data/Parse error

#1 Post by johnfreak21 » Mon, 2011-02-28, 11:34

Hello,
I like to convert older dcm-files to dcm-files with DICOM 3 standard.
I´m using dcmconv.exe -v -d +ti (write with implicit VR little endian TS) and it´s working just fine for CTs, but not for the MRs.
The Message I get is:
D: $dcmtk: dcmconv v3.6.8 2011-01-06 $
D:
I: open input file C:\... \1.dcm
D: DcmItem::checkTransferSyntag() TransferSyntax="Little Endian Implicit"
D: DcmItem::checkTransferSyntag() TransferSyntax="Little Endian Implicit"
E: DcmSequenceOfItems: Parse error in sequence, found <4f4c,4143> instead of a sequence delimiter
D: DcmSequenceOfItems::readSubItem():cannot creat Sub Item <4f4c,4143>
F: Corrupted data: reading file: C\... \1.dcm

This is just an example, every file has another sequence, which causes the parse error. The sequence is everytime in the private part.

The MR-device is from Philips and I checked for odd length in some of the files without success. I also tried some additional options like +ao or +Ep, but the result is allways the same.

Thanks for your help

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 » Mon, 2011-02-28, 11:39

Could you please send a sample file that demonstrates this behavior by email to dicom/at/offis/dot/de (without any patient-related date, of course).

Btw, I guess that the version of "dcmconv" is 3.6.0 and not 3.6.8. Also the other logger output suggests that you did not simply copy the output of this tool to your forum posting ...

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

#3 Post by Jörg Riesmeier » Mon, 2011-02-28, 12:53

Thank you for the file. The reason for your problems seem to be that the private tag (2005,105f), which is reserved by the private creator "PHILIPS MR IMAGING DD 001", is not a sequence element (StackSequence) as defined in DCMTK's private dictionary.

So, one solution would be to recompile the "dcmconv" tool without private dictionary support enabled (see corresponding CMake flag). Another solution would be to redefine the entry (tag and private creator) in a separate dictionary file and set the DCMDICTPATH environment variable accordingly. See documentation for details.

johnfreak21
Posts: 4
Joined: Mon, 2011-02-28, 10:47

#4 Post by johnfreak21 » Mon, 2011-02-28, 18:22

Everything works now properly.
Thanks for your help.

st80rules
Posts: 183
Joined: Tue, 2007-05-08, 17:45

#5 Post by st80rules » Mon, 2011-02-28, 19:05

which solution did you choose?

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

#6 Post by Jörg Riesmeier » Tue, 2011-03-01, 11:10

Btw, there was a wrong entry in the private tags dictionary that caused this parse problem. This entry (and some others) has been fixed now.

We will probably also update the Windows binaries on the DCMTK homepage (as time permits) ...

johnfreak21
Posts: 4
Joined: Mon, 2011-02-28, 10:47

#7 Post by johnfreak21 » Wed, 2011-03-02, 20:43

I changed all "StackSequence"-entries from SQ to CS in the private dictionary.

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

#8 Post by Jörg Riesmeier » Wed, 2011-03-02, 22:15

This is not a good idea, because in group 0x2001 the attribute definition is correct (see above referenced commit). Btw, we've replaced the Windows binaries on the DCMTK server.

Shaeto
Posts: 127
Joined: Tue, 2009-01-20, 17:50
Location: CA, USA
Contact:

#9 Post by Shaeto » Fri, 2011-04-22, 07:32

have same problem but in our own application. i had to modify private.dic

(2005,"Philips MR Imaging DD 001",105f) CS Unknown 1

can I just turn off private tags parsing but still have capability to receive and store explicit objects ?

p.s. checked latest Philips conformances, there is nothing about 2005,105f. but per docs 2001,105f is SQ, so, think it is bad idea for us to tag 2005,105f as CS they can change it any time :(

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

#10 Post by Jörg Riesmeier » Fri, 2011-04-22, 13:14

i had to modify private.dic

Code: Select all

(2005,"Philips MR Imaging DD 001",105f) CS Unknown 1
That's a bad idea as I mentioned in the above posting.
can I just turn off private tags parsing but still have capability to receive and store explicit objects ?
Yes, but you can also (and probably should) update the private data dictionary according to the above referenced patch.
checked latest Philips conformances, there is nothing about 2005,105f. but per docs 2001,105f is SQ, so, think it is bad idea for us to tag 2005,105f as CS they can change it any time
I totally agree.

Shaeto
Posts: 127
Joined: Tue, 2009-01-20, 17:50
Location: CA, USA
Contact:

#11 Post by Shaeto » Thu, 2011-04-28, 19:33

i think it will be very interesting to have new parameter for loadBuiltinDictionary() function and member field for DcmDataDictionary class to load/skip private groups even if dcmtk compiled with WITH_PRIVATE_TAGS defined.

it is especially interesting for daemon applications. for example if user requested call lock, reload and unlock dictionary to include or skip private tags.

anyway for now it is easy to implement on our side :)

thanks!

Post Reply

Who is online

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