compressed pixels with defined length field

[Shaeto]

Found new (sorry think it is again buggy dicom problem with compressed image.

from dcpixel.cc: line 715
/* determine if the pixel data is captured in native (uncompressed) or encapsulated
* (compressed) format. We only derive this information from the length field
* which is set to undefined length for encapsulated data because even in
* compressed transfer syntaxes the Icon Image Sequence may contain an
* uncompressed image.
*/
if (getLengthField() == DCM_UndefinedLength)



but dicom file has DEFINED length for pixel data and, of course, it failed to decode pixels.

i have sent demo dicom (from real modality) to offis mail, thanks.

[Jörg Riesmeier]

As I already wrote by email: The file is not DICOM compliant. For this kind of transfer syntax (encapsulated with compressed pixel data), the pixel data element has to be encoded as a sequence with value representation OB and undefined length. See part 5 of the DICOM standard for details ...

[Shaeto]

yes i know okay will apply some local workaround

thanks!

[Jörg Riesmeier]

Changing the value representation of the pixel data element to OB and the length to undefined might already work ...

In any case, you should inform the manufacturer about this issue. It is a severe violation of the DICOM standard!

[Shaeto]

agree i will inform,

i didn't find how to change VR and lenght outside of library,

setLenghtField is protected member.... and anyway DcmPixelData is loading (and storing after) it as "wrong" class and messing data...

currently solved problem by changing dcpixel.cc

if (getLengthField() == DCM_UndefinedLength || ixferSyn.isEncapsulated())

i know it is very bad solution but at least for dicoms with one PixelData entry it will work fine.

[Jörg Riesmeier]

Patching the file directly (e.g. using a hex editor) works as described above (change OW to OB and explicit length to undefined length). That means, the internal pixel sequence and item structure is correct. Maybe, the wrong VR and length field has been introduced during the transfer ...

i know it is very bad solution but at least for dicoms with one PixelData entry it will work fine.

I agree that this is a bad idea. You should at least check that the pixel data element is on the main level of the dataset (i.e. not inside an Icon Image Sequence or the like).

[Shaeto]

direct patching is not available, i need to fix them on fly btw source is TOSHIBA ! oO and it sends tons of such files

thanks for idea about level checking.

[Shaeto]

just for info, at the moment i solved this (NOT DCMTK!) problem by this patch:

dcpixel.cc:718
OFBool isEncapsulatedPixels = OFFalse;

if (inStream.avail()>=4 && ixferSyn.isEncapsulated()) {
Uint16 groupTag = 0xffff;
Uint16 elementTag = 0xffff;
const E_ByteOrder byteOrder = ixferSyn.getByteOrder();

if (byteOrder != EBO_unknown) {
inStream.mark();
inStream.read(&groupTag, 2);
inStream.read(&elementTag, 2);
inStream.putback();

swapIfNecessary(gLocalByteOrder, byteOrder, &groupTag, 2, 2);
swapIfNecessary(gLocalByteOrder, byteOrder, &elementTag, 2, 2);
// tag has been read
DcmTag newTag(groupTag, elementTag);

if (newTag.getXTag() == DCM_Item) {
isEncapsulatedPixels = OFTrue;
}
}
}

/* determine if the pixel data is captured in native (uncompressed) or encapsulated
* (compressed) format. We only derive this information from the length field
* which is set to undefined length for encapsulated data because even in
* compressed transfer syntaxes the Icon Image Sequence may contain an
* uncompressed image.
*/
if (getLengthField() == DCM_UndefinedLength || isEncapsulatedPixels)
......