chooseRepresentation fails for dicom with private pixel data

All other questions regarding DCMTK

Moderator: Moderator Team

Post Reply
Message
Author
Shaeto
Posts: 147
Joined: Tue, 2009-01-20, 17:50
Location: CA, USA
Contact:

chooseRepresentation fails for dicom with private pixel data

#1 Post by Shaeto »

dear community, i have a question:

i have JPEGExtended:Process2+4 dicom with private sequence, for example:

-----------------
(1135,4302) SQ (Sequence with explicit length #=1) # 12412, 1 Unknown Tag & Data
(fffe,e000) na (Item with explicit length #=11) # 12404, 1 Item
(0028,0002) US 3 # 2, 1 SamplesPerPixel
(0028,0004) CS [RGB] # 4, 1 PhotometricInterpretation
(0028,0006) US 0 # 2, 1 PlanarConfiguration
(0028,0010) US 64 # 2, 1 Rows
(0028,0011) US 64 # 2, 1 Columns
(0028,0034) IS [1\1] # 4, 2 PixelAspectRatio
(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) UN 00\00\00\00\00\00\c0\c0\c0\c0\c0\c0\00\00\00\00\00\00\00\00\00\00... # 12288, 1 PixelData
(fffe,e00d) na (ItemDelimitationItem for re-encoding) # 0, 0 ItemDelimitationItem
(fffe,e0dd) na (SequenceDelimitationItem for re-encod.) # 0, 0 SequenceDelimitationItem
---------------
(7fe0,0010) OB (PixelSequence #=2) # u/l, 1 PixelData
(fffe,e000) pi 00\00\00\00 # 4, 1 Item
(fffe,e000) pi ff\d8\ff\e0\00\10\4a\46\49\46\00\01\01\00\00\01\00\01\00\00\ff\db... # 164100, 1 Item
(fffe,e0dd) na (SequenceDelimitationItem) # 0, 0 SequenceDelimitationItem
---------------
in this case chooseRepresentation calls "search(DCM_PixelData, resultStack, ESM_afterStackTop, OFTrue)" and gets first (7fe0,0010) from SQ (1135,4302)
this tag is not EVR_PixelData and chooseRepresentation returns EC_CannotChangeRepresentation (btw it seems this pixel tag is raw pixel data)

every day i see dicoms like this, and i need a solution:
1. implement own or patch DcmDataset::chooseRepresentation/hasRepresentation and skip private (7fe0,0010) tags ?
2. anything more compatible with standard ?

Thanks!

J. Riesmeier
DCMTK Developer
Posts: 2501
Joined: Tue, 2011-05-03, 14:38
Location: Oldenburg, Germany
Contact:

Re: chooseRepresentation fails for dicom with private pixel

#2 Post by J. Riesmeier »

One reason for this behavior is probably that the VR of the (7fe0,0010) element is "UN" instead of OB or OW.
You could check whether setting the global flag dcmEnableUnknownVRConversion to OFTrue solves this issue:

Code: Select all

/** Global flag to enable/disable the automatic re-conversion of defined
 *  length UN elements read in an explicit VR transfer syntax, if the real
 *  VR is defined in the data dictionary.
 */
extern DCMTK_DCMDATA_EXPORT OFGlobal<OFBool> dcmEnableUnknownVRConversion; /* default OFFalse */
Btw, the DICOM standard states in Part 5 Section 7.8.2:
For a Standard Extended SOP Class the Attributes Pixel Data (07FE,0010), Float Pixel Data (7FE0,0008), Double Float Pixel Data (7FE0,0009), Waveform Data (5400,1010) and Overlay Data (60xx,3000) shall not be included within a Private Sequence Item, nor within a standard Sequence Item nested directly or indirectly within a Private Sequence Item.

Shaeto
Posts: 147
Joined: Tue, 2009-01-20, 17:50
Location: CA, USA
Contact:

Re: chooseRepresentation fails for dicom with private pixel

#3 Post by Shaeto »

thank you will try UN conversation but seems it is better to add some custom code to check that pixel tag/data is valid (contains the same transfer syntax as main dataset), that's life - medical vendors do not read standard :)

Shaeto
Posts: 147
Joined: Tue, 2009-01-20, 17:50
Location: CA, USA
Contact:

Re: chooseRepresentation fails for dicom with private pixel

#4 Post by Shaeto »

update: dcmEnableUnknownVRConversion helped to decompress dicom, thank you!

J. Riesmeier
DCMTK Developer
Posts: 2501
Joined: Tue, 2011-05-03, 14:38
Location: Oldenburg, Germany
Contact:

Re: chooseRepresentation fails for dicom with private pixel

#5 Post by J. Riesmeier »

seems it is better to add some custom code to check that pixel tag/data is valid (contains the same transfer syntax as main dataset), that's life - medical vendors do not read standard :)
They have to read and conform to the standard :!: Otherwise, their product is not DICOM compliant.

Anyway, I know what you mean and that's the reason why we have so many "compatibility switches" and "workarounds" in the DCMTK. By default, the toolkit should be rather strict and report a warning on any detected violation (if not aborting). Maybe, I should add a message to the logger that explains the error code EC_CannotChangeRepresentation.

By the way, the transfer syntax of a Pixel Data element that is nested in a sequence item depends on the Transfer Syntax of the surrounding dataset and of the length value of the Pixel Data element (if explicit/fixed, it is uncompressed pixel data; if undefined, it is compressed in the same manner as the main dataset).

Post Reply

Who is online

Users browsing this forum: Ahrefs [Bot], Bing [Bot], Google [Bot] and 1 guest