DCMCONV-Problem: Corrupted data/Parse error
Moderator: Moderator Team
-
- Posts: 4
- Joined: Mon, 2011-02-28, 10:47
DCMCONV-Problem: Corrupted data/Parse error
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
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
-
- ICSMED DICOM Services
- Posts: 2217
- Joined: Fri, 2004-10-29, 21:38
- Location: Oldenburg, Germany
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 ...
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 ...
-
- ICSMED DICOM Services
- Posts: 2217
- Joined: Fri, 2004-10-29, 21:38
- Location: Oldenburg, Germany
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.
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.
-
- Posts: 4
- Joined: Mon, 2011-02-28, 10:47
-
- ICSMED DICOM Services
- Posts: 2217
- Joined: Fri, 2004-10-29, 21:38
- Location: Oldenburg, Germany
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) ...
We will probably also update the Windows binaries on the DCMTK homepage (as time permits) ...
-
- Posts: 4
- Joined: Mon, 2011-02-28, 10:47
-
- ICSMED DICOM Services
- Posts: 2217
- Joined: Fri, 2004-10-29, 21:38
- Location: Oldenburg, Germany
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
(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
-
- ICSMED DICOM Services
- Posts: 2217
- Joined: Fri, 2004-10-29, 21:38
- Location: Oldenburg, Germany
That's a bad idea as I mentioned in the above posting.i had to modify private.dicCode: Select all
(2005,"Philips MR Imaging DD 001",105f) CS Unknown 1
Yes, but you can also (and probably should) update the private data dictionary according to the above referenced patch.can I just turn off private tags parsing but still have capability to receive and store explicit objects ?
I totally agree.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 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!
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!
Who is online
Users browsing this forum: Semrush [Bot] and 1 guest