Re: PALETTE COLOR Ultrasound Images without palette



yogi wrote:

This image is taken right off from the modality so cannot really say
what went within that. But I don't think there rule that prohibits JPEG
Compression over PALETTE Color.

There is nothing that would prohibit the use of a compressed transfer syntax with PALETTE COLOR. However, any kind of lossy compression is prohibitive because the loss would apply to index values into the LUT table, not to grayscale or color values, i.e. the result would be garbled.

DCMTK (C++ API for DICOM by OFFIS) converts PALETTE COLOR to RGB on
compressing, irrespective of the compression used. From where the pixel
data is obtained, in this process?

That is not 100% correct. When using RLE or JPEG 2000 lossless compression (the latter with a module that is not part of the free distribution), DCMTK will compress PALETTE COLOR without changing the color model. Also the newly released DCMTK 3.5.4 will by default leave PALETTE COLOR as it is when creating a lossless JPEG compressed representation. However, when compressing in any lossy technique (or when using lossless JPEG with older releases), the palette color LUT would be resolved to an RGB image first and the resulting image would then be compressed.

As far as my understanding goes, the descriptors define the entries,
first index and length of each entry and the LUT has the actual
entries, but in this case both things are missing. Is it a case where
we should use the vendors dicom dictionary?

In this case the image is not displayable anymore unless the viewer knows something that the standard doesn't tell us. In short words: The image is dead, it has passed the spoon and gone to meet its creator :-)

Also, ezDICOM is viewing this image. Sadly its in pascal. I know
nothing of pascal so, can't get anything out of it.

Either ezDICOM has a special workaround for this errorneous image, or the PALETTE COLOR photometric interpretation is not actually true. You would have to examine the compressed JPEG byte stream to see whether it contains one or three samples per pixel. In the latter case, the image might have been converted to RGB prior to compression, but the photometric interpretation tag not updated. In that case, the image could be rectified by changing the photometric interpretation to RGB and samplesPerPixel to 3 before attempting to decompress.

Regards,
Marco Eichelberg
OFFIS

.