Re: PALETTE COLOR Ultrasound Images without palette
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.