DICOM @ OFFIS

Discussion Forum for OFFIS DICOM Tools - For registration, send email with desired user name to the OFFIS DICOM team
It is currently Mon, 2018-09-24, 12:59

All times are UTC + 1 hour




Post new topic Reply to topic  [ 4 posts ] 
Author Message
PostPosted: Wed, 2015-01-14, 10:01 
Offline

Joined: Thu, 2005-08-18, 13:00
Posts: 8
I got a DICOM file created by GE EchoPac.
The dataset is in JPEGBaseline transfersyntax. It has an private tag with VR OB and this tag has an undefined length. Using dcmdump to print the tags result in:
Code:
I: DcmDataDictionary: Loading file: C:\Program Files (x86)\dcmtk\dcmtk-3.6.0\share\dcmtk\dicom.dic
I: DcmDataDictionary: Loading file: R:\FIT\Software tools\DICOMTools\offis - dicom toolkit\private.dic
W: DcmItem: Non-standard VR ' Ê' (0c\d2) encountered while parsing element (0000,0000), assuming 2 byte length field
W: DcmItem: Non-standard VR '¥w' (be\77) encountered while parsing element (a488,0001), assuming 2 byte length field
W: DcmItem: Non-standard VR '  ' (04\00) encountered while parsing element (0003,1d68), assuming 2 byte length field
W: DcmItem: Element Unknown Tag & Data (0003,1d68) larger (61548) than remaining bytes (178) of surrounding item
E: dcmdump: Length of element larger than explicit length of surrounding item: reading file: 82021897.C8.dcm


Using the +E option gives (only the relevant part and yes I know it is illegal to use 0002,0010 in the dataset and GE admits it is incorrect.... :? ):
Code:
....
           (fffe,e0dd) na (SequenceDelimitationItem for re-encod.) #   0, 0 SequenceDelimitationItem
           (7fe1,1062) SQ (Sequence with explicit length #=1)      # 1050984, 1 Unknown Tag & Data
             (fffe,e000) na (Item with explicit length #=7)          # 1050976, 1 Item
               (0002,0010) UI =JPEG2000                                #  22, 1 TransferSyntaxUID
               (0028,2110) CS [01]                                     #   2, 1 LossyImageCompression
               (0028,2112) DS [5]                                      #   2, 1 LossyImageCompressionRatio
               (7fe1,0010) LO [GEMS_Ultrasound_MovieGroup_001]         #  30, 1 PrivateCreator
               (7fe1,1037) UL 28                                       #   4, 1 Unknown Tag & Data
               (7fe1,1043) OB 00\00\11\88\fd\6e\16\40\00\60\b2\08\79\a9\16\40\00\88\73\41\f6\e3... # 224, 1 Unknown Tag & Data
               (7fe1,1060) OB (Sequence with undefined length #=1)     # u/l, 1 Unknown Tag & Data
                 (fffe,e000) na (Item with explicit length #=2)          # 112, 1 Item
                   (0000,0000) ?? (no value available)                     #   0, 1 CommandGroupLength
                   (255c,0001) ?? 3c\00                                    #   2, 1 Unknown Tag & Data
                 (fffe,e00d) na (ItemDelimitationItem for re-encoding)   #   0, 0 ItemDelimitationItem
.....

Looking with an hexeditor at the data it seems to be encoded as encapsulated pixeldata. Probably it is private encapsulated (JPEG2000) pixeldata. And it also seems to have item delimiters. So far I can't detect a real error in the dataset itself for this tag (it should be parsable as an sequence, I think). And we also have other tools / systems that do parse this dataset (e.g. DVTK).
Is dcmtk parsing this kind of tags correctly or is this a known issue with dcmtk?
If you like I can send you the dataset (need to find a way to anonimise, doesn't work with dcmodify.... :wink:: Probably the good old hex editor)

Thanks,
Luuk


Top
 Profile  
 
PostPosted: Wed, 2015-01-14, 10:42 
Offline
DCMTK Developer

Joined: Fri, 2004-11-05, 13:47
Posts: 1687
Location: Oldenburg, Germany
Hi Luke,

yes, please provide the dataset to dicom at offis de. Anoymisation would be good, though we are not interested into any personal details anyway :)

Best,
Michael


Top
 Profile  
 
PostPosted: Fri, 2015-01-16, 09:35 
Offline
OFFIS DICOM Team
OFFIS DICOM Team

Joined: Tue, 2004-11-02, 17:22
Posts: 1217
Location: Oldenburg, Germany
Interesting case of undefined behaviour with regard to the standard. The problem here is that it is not quite clear from the standard how attributes with OB value representation and undefined length other than (7fe0,0010) should be handled. DCMTK assumes that such elements are in fact sequence (SQ) elements, and not pixel data, and tries to parse them as such. This obviously fails here because the items do not contain DICOM datasets, but compressed pixel data fragments. Whether the encoding used in this image (with a Transfer Syntax UID attribute somewhere within the dataset, and a private pixel data element that uses a different transfer syntax than the main image) is legal, is not really clear to me. There is, however, no simple way to handle such datasets with DCMTK.


Top
 Profile  
 
PostPosted: Fri, 2015-01-16, 12:17 
Offline

Joined: Thu, 2005-08-18, 13:00
Posts: 8
Marco, Michael,

Thanks for your time and replies. Opposite to my statement in the first post this tag in the dataset is indeed not parsable as a sequence (as indicated by Marco). The problem is that the dataset doesn't survive (readable for GE) a roundtrip to our archive. And especially if it is transferd in LEI format the tag will become VR UN and then you only can guess it to be an SQ isn't it? But now we are ending in a discussion more suitable for the google dicom group. I'll post it there and see what the comments are. My guess: it should be readable as a sequence although I can't find a real "must" in the DICOM standard (at least this is what I see more often answered by David Clunie in more or less comparable cases :wink:).


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 4 posts ] 

All times are UTC + 1 hour


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group