Problem with setting voi lut using DCMTK 3.5.4

[spencergunn]

Hi,

I am trying to upgrade software from 3.5.3 to 3.5.4 and have some new behaviour in my code.

If I try to set one of 4 VOI LUTS from my DICOM image I get just black. Setting one of the 4 Windows works as before.

I believe this behaviour can also be noticed when using dcmj2pnm. If I ask for the image information I get back info stating that there are 4 VOI LUTs in the file but if I specify +Wl 2 I get an error saying that the number of luts is wrong defaulting to 1 and I get a black output.
Using -v I get


preparing pixel data
activating VOI LUT 2
WARNING: invalid value for 'NumberOfTableEntries' (2705) ... assuming 1 !
writing frame 1 to odxm.bmp
cleaning up memory

dxm.bmp is entirely black.


Can anyone verify this or does anyone know why this behaviour has changed?

Thanks
Spencer

[Jörg Riesmeier]

Could you please send the file by email to dicom/at/offis/dot/de.

[spencergunn]

File sent to the email address given.

Thanks
Spencer

[Jörg Riesmeier]

I checked the file. dcm2pnm version 3.5.3 fails in the same manner as version 3.5.4. The problem is related to the fact that the DICOM file is stored with implicit VR little endian transfer syntax which is no good idea when using LUT data (because this attribute has multiple VRs). I used dcmconv 3.5.4 with the new option --convert-un (+uc) and created a copy of the DICOM file stored with explicit VR little endian (--write-xfer-little or +te). After this conversion, everthing worked as expected.

Hope this helps ...

[Jörg Riesmeier]

... I think we also need to change something in the dcmimgle/dcmimage module in order to support the "implicit VR" case. We'll let you known as soon as we've found a fix.

[spencergunn]

This behaviour is very different from the previous behaviour which handled these files perfectly.

Using 3.5.3 I can use ->setvoilut and get images back in all four windows and LUTs but not in 3.5.4 . This is not an improvement unfortunately.

I have also been able to use 3.5.3 dcmj2pnm downloaded from Offis to convert in all 4 LUTs to a bmp file form the file I sent.

While you may be right about the impilict VR little endian stuff the library used to work and now it doesn't. I have no control over how GE or Hologic choose to store these images and so need a way to make this work hopefully using your library.

Are you suggesting that I set the transfer syntax myself in the code?

Spencer

[Jörg Riesmeier]

There was indeed a bug introduced with DCMTK 3.5.4. The problem is related to the new pseudo-VR "lt" that has been added to handle the different VRs of the attribute "LUT Data".

The fix that I just committed to our internal CVS repository applies the following changes to the source code file "dcmimgle/libsrc/didocu.cc":

Code: Select all

280c280,281
<         if (elem->getVR() == EVR_OW)
---
>         const DcmEVR vr = elem->getVR();
>         if ((vr == EVR_OW) || (vr == EVR_lt))
336c337,338
<         if (OFconst_cast(DcmElement *, elem)->getVR() == EVR_OW)
---
>         const DcmEVR vr = OFconst_cast(DcmElement *, elem)->getVR();
>         if ((vr == EVR_OW) || (vr == EVR_lt))

[spencergunn]

Thanks Dr Riesmeier you have been very helpful.

Spencer