Dear DICOM experts,

I am trying to figure out the correct interpretation of stored pixel values when a supplemental color palette is present. The context is that MR images shall be used for processing (segmentation) rather than dislay. In this, color values are not very useful.

PS 3.3, C.7.6.3.1.5 says:
[...]
In the case of the Supplemental Palette Color LUT, the stored pixel values less than the second descriptor value are grayscale values.
[...]
(it does not say however that the stored values above the first mapped value are not)

PS 3.3, C.8.16.2.1.1.1 says:
[...]
If Pixel Presentation (0008,9205) equals COLOR, the stored values are split into two ranges.
[...]
Which Figure C.8-20 illustrates nicely.
This makes me tend to think that the values of the mapped range are indices into a LUT and not suitable for being interpreted as a continuation of the grayscale range.
With that apporach it is possible to provide a color mapping for any pixel in the image regardless of its gray value.

As I see it, this would make it impossible to calculate a gray value for a mapped pixel.

However...
PS 3.3, C.8.16.2.1.1.1 says:
The complete range of stored pixel values can also be displayed via the grayscale visualization pipeline only, but the information content may be less useful because the color information is not available.
(It does not say that this would yield a completely useless image)

This suggests that the pixel data is encoded in a continuous grayscale range of which all gray values above LUT descriptor value 2 _can_ be mapped using the Supplemental Color LUT. Without this mapping applied, the user would see an "ordinary grayscale image".
The possiblity to assign color to a pixel would then be limited to grayscales above (LUT descriptor value 2 - 1). So only pixels with an intensity above X can be mapped to color.

I slightly tend to the "continuous grayscale" interpretation, especially because this possiblity is explicitly mentioned. But I would appreciate a second or third opinion very much, beacuse I am not really sure.

Exclude them from processing.

The Supplemental Palette Color LUT mechanism was added as a very crude way of replacing actual stored pixel values with color LUT index values, so that that those pseudo-colored pixels could be viewed and the rest of the grayscale image windowed without messing with these color values; the index values make no sense in and of themselves, they are just above a certain threshold. They would not normally be included in the range of input values to a Real-World Value Map either (if present). The mechanism was intended as a crude pixel-substitution-based alternative to superimposing one (pseudo-colored) image on top of another with control of opacity values, and was probably a bad idea.

Even though the index values have no meaning if not pseudo-colored, since they are at the top end of the range of stored pixel values, the expectation is that a rendering pipeline (e.g., "dumb viewer") that is unaware of or ignores the Supplemental Palette Color attributes, will render them as the maximum values (i.e., beyond the top end of the range of valid values). They are otherwise meaningless (or if they have a creator-specific meaning, there is no standard way to convey it).

BTW. If a Real-World Value Map is present, that is a guide as to which pixel values are meaningful in the sense of having a mapping to a physical or abstract property.

Thank you very much for your swift response David. That makes it much clearer, but I am not quite there. Sorry if my questions sound stupid - I am looking at the matter from a very technical perspective not knowing much about all fields of application of color LUTs in CT/MR (I have fMRI on my mind). So a few counter-questions below.

dcl...@dclunie.com schrieb am Mittwoch, 29. September 2021 um 14:12:12 UTC+2:
> Exclude them from processing.

...which means that for the mapped pixels we do not have _any_ grayscale information for these pixels at all? In terms of segmentation this would render the whole image unusable for the algorithm. Do you agree with this conclusion?

> They would not normally be included in the range of input values to a Real-World Value Map either (if present).

....which means that for these pixels, nothing but a color can be given at all, and the real world map would have "holes" where special areas were "highlighted (=colored)"?

>
> [...] since they are at the top end of the range of stored pixel values, the expectation is that a rendering pipeline (e.g., "dumb viewer") that is unaware of or ignores the Supplemental Palette Color attributes, will render them as the maximum values (i.e., beyond the top end of the range of valid values).

How can a "dumb viewer" know that they are "beyond the top end of the range of valid values" unless it looks into the Supplemental Color LUT descriptors? I would certainly expect the full pixel value range (including the index values) to make up the attribute value of Bits Stored (0028,0101). And if "mapping them to white" is an appropriate way of handling them, this would mean for the encoder to better not assign colors to darker areas of the grayscale image.
To me this leads to the conclusion that there is no reasonable way of ignoring the Supplemental Color LUT. Or am I mssing something?

> BTW. If a Real-World Value Map is present, that is a guide as to which pixel values are meaningful in the sense of having a mapping to a physical or abstract property.

But since a Real-World Value Map maps grayscales, not pixel rows/colums, this would mean that for "index grayscales":
- either the real-world value cannot be given (as you had stated above)
- or the "index grayscales" are a continuation of the "ordinary grayscales" and "just more nicely displayed in color"
That would depend on the creator of the image. The second option is what the passage "The complete range of stored pixel values can also be displayed via the grayscale visualization pipeline only, but the information content may be less useful because the color information is not available." (PS 3.3, C.8.16.2.1.1.1) was suggesting to me. To me this reads like "They are ordinary grayscales but better displayed in color", but they are not. "may be less useful" is a very weak term for the implications of ignoring the color palette if I got you correctly.

Should I submit a CP?

On Wednesday, September 29, 2021 at 9:45:58 AM UTC-4, marku...@gmail.com wrote:
> ..which means that for the mapped pixels we do not have _any_ grayscale information for these pixels at all? In terms of segmentation this would render the whole image unusable for the algorithm. Do you agree with this conclusion?

If you don't have a way of "ignoring" the replaced pixels, then yes.

As a practical matter, do you actually have any images of this type. or is this just a theoretical discussion. I ask because I haven't seen much, if any, implementation of the Supplemental Palette Color LUT in real devices.

> How can a "dumb viewer" know that they are "beyond the top end of the range of valid values" ...

It doesn't know anything, that's the point, they are high values, so rendered as more white, no more, no less, even if this is meaningless.

> To me this leads to the conclusion that there is no reasonable way of ignoring the Supplemental Color LUT

You can ignore it by not using pixels above the specified range, if you recognize the relevant attributes, and if you don't need all the pixels in the raster for your use case, just as you might/should ignore Pixel Padding Value pixels.

> > BTW. If a Real-World Value Map is present, that is a guide as to which pixel values are meaningful in the sense of having a mapping to a physical or abstract property.
> But since a Real-World Value Map maps grayscales, not pixel rows/colums, this would mean that for "index grayscales": ...

A real-world value map (of which there may be more than one) describes the meaning of stored (pixel) values in the range between first and last value mapped (inclusive) that are a single channel - the creator of the object can map whatever range they want to if they have a meaning for it, regardless of the presence/absence/applicability of rendering information (like the Supplemental Palette Color LUT). E.g., the color indices could have some range that can be mapped to real values (e.g., velocity, probability), linearly or with a LUT.

> Should I submit a CP?

If you like - "meaningless" might be a better term than "less useful" :)

And adding a note about the consequences for image processing (and the analogy to the effect of Pixel Padding Value) might be useful.

David

Thank you very much again, David! It is now perfectly clear to me - so just answering your questions

dcl...@dclunie.com schrieb am Donnerstag, 30. September 2021 um 15:34:26 UTC+2:
>
> As a practical matter, do you actually have any images of this type. or is this just a theoretical discussion. I ask because I haven't seen much, if any, implementation of the Supplemental Palette Color LUT in real devices.

I don't have such images. This is a bit of a dilemma that you probably know very well. The system is supposed to handle Enhanced MR Images, and it is used in the context of an intervention. So risk management is key here. We need define the rules for deciding whether or not a particular image qualifies for the application in that context. And in this we need to consider everything that can possibly happen (another example is identifying stacks that form a volume which we are sure to understand entirely correct). With the Supplemental Color Palette, we have to be prepared to encounter such an image, and we need to handle it in "some way". Even if there is no system in the field supporting that now, it may occur in future without us noticing that. Which way this could possibly be was the subject of my question.
It would be so great if there was kind of a central repository of all DICOM Conformance Statements where the information "does anyone do this or that" can be safely obtained, but I know that this is a stupid and unfulfillable wish.

> > Should I submit a CP?
> If you like - "meaningless" might be a better term than "less useful" :)

With my improved understanding of the matter, I could not agree more. :)

>
> And adding a note about the consequences for image processing (and the analogy to the effect of Pixel Padding Value) might be useful.

Good point. I need to understand the analogy first though :D. I'll consider submitting a CP.

Thanks again

Markus