error with private OB tag and undefined length

[Luuk]

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: Select all

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: Select all

....
           (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.... : Probably the good old hex editor)

Thanks,
Luuk

[Michael Onken]

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

[Marco Eichelberg]

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.

[Luuk]

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 ).

[J. Riesmeier]

I've found a solution for parsing the private GE pixel sequence: With commit 041f451 and 2acbe09 the issue should be fixed (requires the private data dictionary to be loaded).