Mathieu,

> but using dcmtk I am getting some errors that I do not understand,
[...]
> and the image looks garbaged:

did you use the latest version of DCMTK (CVS snapshot)? Using the current
version, I could convert the image using dcm2pnm without any warnings and
with the expected result.

Probably the following entry in the CHANGES file is related to this issue:

=== CUT ===

**** Changes from 2007.03.16 (riesmeier)

- Fixed problem with wrong interpretation of the palette descriptor in
certain
cases. Now the BitsPerTableEntry stored in the LUT descriptor is used by
default. The previous behavior can be enabled using the ELM_CheckValue
mode.
Thanks to Ewald de Vries for the report.
Affects: dcmimgle/libsrc/diluptab.cc

=== CUT ===

The wrong interpretation in previous versions was the result of a
workaround
that is necessary for incorrectly encoded LUT descriptors ...

Regards,
Joerg

On Sep 25, 1:34 pm, "Joerg Riesmeier" wrote:
> Mathieu,
>
>
>
> > but using dcmtk I am getting some errors that I do not understand,
> [...]
> > and the image looks garbaged:
>
> did you use the latest version of DCMTK (CVS snapshot)? Using the current
> version, I could convert the image using dcm2pnm without any warnings and
> with the expected result.
>
> Probably the following entry in the CHANGES file is related to this issue:
>
> === CUT ===
>
> **** Changes from 2007.03.16 (riesmeier)
>
> - Fixed problem with wrong interpretation of the palette descriptor in
> certain
> cases. Now the BitsPerTableEntry stored in the LUT descriptor is used by
> default. The previous behavior can be enabled using the ELM_CheckValue
> mode.
> Thanks to Ewald de Vries for the report.
> Affects: dcmimgle/libsrc/diluptab.cc
>
> === CUT ===
>
> The wrong interpretation in previous versions was the result of a
> workaround
> that is necessary for incorrectly encoded LUT descriptors ...

Thank you so much for report, I was getting ready to cut a new
release !

So just FYI TomoVision / PowerDicom / Irfanview and Dicomworks all
fails to
display properly the image. I will add that image to my gdcm DICOM
conformance dataset.

regards
-Mathieu

Joerg-san

Thank you for your infomation.
I have carefully read the infomation and I understand the bug in the
dcmtk 3.5.4.
By the way, there is one point I can't understand, it is the following
context;

> Now the BitsPerTableEntry stored in the LUT descriptor is used by
> default. The previous behavior can be enabled using the ELM_CheckValue
> mode.

Please let me know what BitsPerTableEntry means, and what
ELM_CheckValue mode means.
I would appreciate it if you give me the answers of the above
questions.

Thanks,

Maty

> Please let me know what BitsPerTableEntry means, and what
> ELM_CheckValue mode means.

'BitsPerTableEntry' refers to the third value of the LUT Descriptor
and ELM_CheckValue is explained in the source code documentation:

/** bits per table entry modes.
* Specifies whether the given value in the LUT descriptor is used.
*/
enum EL_BitsPerTableEntry
{
/// use given value
ELM_UseValue,
/// ignore given value, use auto detection
ELM_IgnoreValue,
/// check whether given value is consistent with LUT data
ELM_CheckValue
};

Btw, for further questions regarding DCMTK you should use the public
discussion forum at http://forum.dcmtk.org/ .

Regards,
Joerg Riesmeier