problem files

Questions regarding DCMCHECK, the OFFIS DICOM IOD validation tool

Moderator: Moderator Team

Post Reply
Message
Author
martel
Posts: 3
Joined: Fri, 2010-08-06, 14:31
Location: Magog
Contact:

problem files

#1 Post by martel » Fri, 2010-08-06, 15:22

I am having problems using your tools with XA images from a GE system.

DCMCHECK only see a bunch of tags (0000,0000) (I am using version 2.0.0)

storscu complain:
ERROR: Unknown Tag & Data(5c00,3200) larger (805318656) that remaining bytes in file
storescu: Bad DICOM file: XA2: Invalid Stream


The image seem O.K. to me... It is a well behaved little endian implicit VR part 10 file.

I can open it with my tools and Philips viewer.

Have you encounter this before? I can provide an anonymized copy of the image...

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, 2010-08-06, 15:55

Yes, it would be helpful if you could send the image (by email) to dicom/at/offis/dot/de. I guess that the encoding of the DICOM file is corrupted ...

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 » Fri, 2010-08-06, 17:05

Thank you for the DICOM file. The file is incorrect in a number of ways, however, the main problem is that there is data after the Pixel Data element which is not correctly encoded as a DICOM data element (e.g. Dateset Trailing Padding).

When using dcmdump from the latest DCMTK snapshot you can avoid the warning messages from the parser with option "--stop-after-elem 7fe0,0010" (i.e. do not try to parse the elements after the Pixel Data element).

martel
Posts: 3
Joined: Fri, 2010-08-06, 14:31
Location: Magog
Contact:

thank you

#4 Post by martel » Fri, 2010-08-06, 18:02

Thank you Jorg,

O.K. I see it.

The files where extracted from a DSS format DLT tape. The stuff at the end of the file is from the tape's format (and since it does contain the actual file size, it's easy to get rid of it). Without this trailing information, my application (using your libraries) work like a charm :)

Yves

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest