Hi everybody,

I'm running a small software project featuring the display of DICOM files. New topic is to read and display eye care Corneal Topography Map images as defined by supplement 168. However, this SOP class gives me some head aches as I do not fully understand how to read these COLOR PALETTE values.
As far as I understand the supplement, corneal topography maps are of circular shapes where the outer areas of the image do not belong to the "payload" and are more like a padding to the rectangular boundary of the image. See the center image of http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.8.30.3.html#figure_C.8.30.3.1-2 as an example.

I wonder how to distinguish these "padding" pixels from those pixels that contain topography map information, especially when it comes to superimposing such maps onto real images and keeping the outer ares transparent. The supplement defines to store such images with photometric interpretation COLOR PALETTE where each pixel value is an index for the palette lookup table. Every pixel value less than the smallest LUT index shall be mapped to the first entry of the LUT, every pixel value greater than the last index shall be mapped to the last entry.

So, how does implementers of this SOP class handle the "non-payload" pixel? Do they define an additional color in the palette (e.g. black)?

Furthermore, until now I did not find any sample images/instances of this SOP class. Is anybody aware of Corneal Topography Map SOP instances, which might work as a reference for me?

Thanks to the group and best regards
Peter

Pixel Padding Value perhaps ?

http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.7.5.html#para_f1ebadfa-530e-434e-944c-bbe9df033ddc

On Friday, September 17, 2021 at 3:16:03 AM UTC-4, captai...@gmx.net wrote:
> Hi everybody,
>
> I'm running a small software project featuring the display of DICOM files.. New topic is to read and display eye care Corneal Topography Map images as defined by supplement 168. However, this SOP class gives me some head aches as I do not fully understand how to read these COLOR PALETTE values.
> As far as I understand the supplement, corneal topography maps are of circular shapes where the outer areas of the image do not belong to the "payload" and are more like a padding to the rectangular boundary of the image. See the center image of http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.8.30.3.html#figure_C.8.30.3.1-2 as an example.
>
> I wonder how to distinguish these "padding" pixels from those pixels that contain topography map information, especially when it comes to superimposing such maps onto real images and keeping the outer ares transparent. The supplement defines to store such images with photometric interpretation COLOR PALETTE where each pixel value is an index for the palette lookup table. Every pixel value less than the smallest LUT index shall be mapped to the first entry of the LUT, every pixel value greater than the last index shall be mapped to the last entry.
>
> So, how does implementers of this SOP class handle the "non-payload" pixel? Do they define an additional color in the palette (e.g. black)?
>
> Furthermore, until now I did not find any sample images/instances of this SOP class. Is anybody aware of Corneal Topography Map SOP instances, which might work as a reference for me?
>
> Thanks to the group and best regards
> Peter

Hi David,

thanks for your response. Pixel Padding Value (0028,0120) looks exactly like what I was searching for. However, after checking the further explanations in chapter "C.7.5.1.1.2 Pixel Padding Value and Pixel Padding Range Limit" this attribute seems to be only applied to grayscale images with photometric interpretation of MONOCHROME1 or MONOCHROME2. Not sure whether this explanation means "Shall not be used for any other photometric interpretation" or "May also be used for e.g. COLOR PALETTE images as well"?

So, how does implementers of COLOR PALETTE images handle this PaddingPixel use case? Is there any sample implementation/images available?

Thanks
Peter

Hi Peter,
Currently there is a CP that is intended to clarify the way to make clear which pixels should be used as color overlay and which as transparent pixels..
Direction is the usage of Real World Value information, where pixels can be marked as having no Real world value.

> Hi David,
>
> thanks for your response. Pixel Padding Value (0028,0120) looks exactly like what I was searching for. However, after checking the further explanations in chapter "C.7.5.1.1.2 Pixel Padding Value and Pixel Padding Range Limit" this attribute seems to be only applied to grayscale images with photometric interpretation of MONOCHROME1 or MONOCHROME2. Not sure whether this explanation means "Shall not be used for any other photometric interpretation" or "May also be used for e.g. COLOR PALETTE images as well"?
>
> So, how does implementers of COLOR PALETTE images handle this PaddingPixel use case? Is there any sample implementation/images available?
>
> Thanks
> Peter

Thanks for the info, Wim.

I would not assume anything about the outcome of discussions about the CP that Wim mentions.

Pixel Padding Value has served us well for 28 years (it was in the 1993 DICOM 3.0 edition), many uses of COLOR PALETTE have no need for and no meaning in terms of Real World Value Maps, and support for Real World Value Maps is limited (much as I like them personally). So extending the definition of Pixel Padding Value to include flagging a particular COLOR PALETTE stored pixel value as "padding" is not beyond the bounds of possibility.

Implied "transparency" for overlays is another question, in that Pixel Padding Value has traditionally been clamped to black or white as appropriate (to suppress windowing of surrounding padding), and the "transparency when overlaid on something else" use case is not specifically mentioned in the standard in the description of padding values (it probably should be).

I would not be surprised if some existing viewers already treated the padding value as special, even for COLOR PALETTE images, if they share the same single channel pipeline as grayscale display, before applying pseudo-coloring, especially if they then allow windowing updates before pseudo-coloring, but have not experimented to find out.

For all interested readers, the CP in discussion is CP-2171 "Define use of Pixel Padding Value for PALETTE COLOR images". Unfortunately, there is no public draft yet.

Regards,
Jörg