gdcmconv cannot handle uncompressed pixel data within Icon Image Sequenece
Cross-platform DICOM implementation
Brought to you by:
malat
Menu
▾
▴
#549 gdcmconv cannot handle uncompressed pixel data within Icon Image Sequenece
Steps to reproduce:
Have a dicom file which has an Icon Image Sequenece and is encoded as JPEG2000
Attempt to convert the file to raw format using gdcmconv --raw in out
Expected results:
It works
What happens instead:
gdcmconv fails stating that it cannot change the transfer syntax. Removing the Icon Image sequence allows it to work just fine.
I've not been able to validate my theory but I believe this is due to the Pixel data in the Icon Image Sequence being native data while the rest of the file is encoded as JPEG2000.
While that does seem to be legal according to the DICOM Standard (https://dicom.nema.org/dicom/2013/output/chtml/part05/sect_A.4.html) certain conditions must be followed. It seems vendors are not following the standard and this is leading to a lot of issues while converting between different types of transfer syntaxes.
Here is the Sequence from the problematic file
(0088,0200) SQ (Sequence with undefined length #=1) # u/l, 1 IconImageSequence
(fffe,e000) na (Item with undefined length #=9) # u/l, 1 Item
(0028,0002) US 1 # 2, 1 SamplesPerPixel
(0028,0004) CS [MONOCHROME2] # 12, 1 PhotometricInterpretation
(0028,0010) US 64 # 2, 1 Rows
(0028,0011) US 53 # 2, 1 Columns
(0028,0100) US 8 # 2, 1 BitsAllocated
(0028,0101) US 8 # 2, 1 BitsStored
(0028,0102) US 7 # 2, 1 HighBit
(0028,0103) US 0 # 2, 1 PixelRepresentation
(7fe0,0010) OB (PixelSequence #=2) # u/l, 1 PixelData
(fffe,e000) pi 00\00\00\00 # 4, 1 Item
(fffe,e000) pi 15\15\16\16\16\17\17\17\17\17\17\17\18\18\18\18\18\18\19\18\18\19... # 3392, 1 Item
(fffe,e0dd) na (SequenceDelimitationItem) # 0, 0 SequenceDelimitationItem
(fffe,e00d) na (ItemDelimitationItem) # 0, 0 ItemDelimitationItem
I'd expect the Value Length to be specifed here rather than represented as u/l, this may be the problem with gdcm identifying it as compressed/encoded and it's subsequent refusal to convert the file.
This is a data problem. The Icon sequence is just brain dead.
Here is a correct mixture of uncompress/compress Pixel Data:
(download gdcmdata)
% gdcmconv --j2k simpleImageWithIcon.dcm proper_icon_j2k.dcm
% gdcmdump proper_icon_j2k.dcm | tail
(0028,0101) US 8 # 2,1 Bits Stored
(0028,0102) US 7 # 2,1 High Bit
(0028,0103) US 0 # 2,1 Pixel Representation
(7fe0,0010) OB (OB or OW => OW) 99\96\98\95\97\92\91\90\92\9b\a1\a9\a6\9b\85\5f\46\48\51\52\55\56\55\56\57\53\5a\60\61\67\6a\6c\6f\6d\75\6e\6c\71\6e\74\6f\72\71\71\73\70\74\71\74\75\74\74\76\71\70\70\72\73\70\6f\73\75\71\70 # 16384,1 Pixel Data
(fffe,e00d)
(fffe,e0dd)
(7fe0,0010) OB # u/l,1 Pixel Data
(fffe,e000) ?? [] # 0,1 Item
(fffe,e000) ?? ff\4f\ff\51\00\29\00\00\00\00\00\80\00\00\00\80\00\00\00\00\00\00\00\00\00\00\00\80\00\00\00\80 # 10936,1 Item
(fffe,e0dd) 0
That's how uncompress pixel data is supposed to be written out. You cannot use encapsulated (encapsulated imply compressed).
The formatting isn't maintained when I pasted it, but in case it wasn't clear there is are two instances of 7fe0,0010.
There is a top level tag, representing the actual image, and is indeed stored in encapsulated format and as VR OB. Note it starts with FF4F for it's binary pixel data denoting it is indeed a JPEG2000 image
Then there is the IconImageSequence:
The standard seems to imply this is valid. The VR type of the Pixel is OB which is covered by this section:
`For the Value Representations OB and OW, the encoding shall meet the following specification depending on the Data Element Tag:
Data Element (7FE0,0010) Pixel Data may be encapsulated or native.
It shall be encapsulated if present in the top-level Data Set (i.e., not nested within a Sequence Data Element).`
Further in it details:
The distinction between fixed value length (native) and undefined value length (encapsulated) is present so that the top level Data Set Pixel Data can be compressed (and hence encapsulated), but the Pixel Data within an Icon Image Sequence may or may not be compressed.Finally it states here if it is <= 8 bits allocated it shall be Native and have OB or OW as the VR type (which it does)
`If native, it shall have a defined Value Length, and be encoded as follows:
where Bits Allocated (0028,0100) has a value greater than 8 shall have Value Representation OW and shall be encoded in Little Endian;
where Bits Allocated (0028,0100) has a value less than or equal to 8 shall have the Value Representation OB or OW and shall be encoded in Little Endian.`
When you say the IconImageSequence is brain dead can you explain how you came to that conclusion given the above?
Last edit: John Tournas 2023-09-12
"u/l" in the gdcmdump output stand for "undefined length". You keep on sending me encapsulated icon pixel data, but claims it is native. As long as your icon is send using encapsulated pixel data, this imply compression. So gdcm rightfully tries to decompress the jpeg 2000 icon pixel data.
Thanks for the clarification, I was also leaning towards the fact that the one rule it breaks from the standard is the fact that the Value length is undefined, it seems to follow all the other items from the standard.
In any event a TON of vendors are not writing out this IconSequence properly and it's leading to a lot of transfer syntax conversion errors. The IconImageSequence is of arguable value. Definitely not a bug but would you consider being more leniant on the ImageIconSequence and skipping over it if it's found to be non JPEG data?