# Unexpected behavior of color when using LUT with color count \< 255

**URL:** <https://discourse.slicer.org/t/unexpected-behavior-of-color-when-using-lut-with-color-count-255/18542>\
**Category:** Support\
**Tags:** color, custom-color-table\
**Created:** [July 6, 2021, 7:57pm UTC](https://discourse.slicer.org/t/unexpected-behavior-of-color-when-using-lut-with-color-count-255/18542 "2021-07-06T19:57:39Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![squll1](https://avatars.discourse-cdn.com/v4/letter/s/3ec8ea/32.png) [@squll1](https://discourse.slicer.org/u/squll1)\
**Post date:** [July 6, 2021, 7:57pm UTC](https://discourse.slicer.org/t/unexpected-behavior-of-color-when-using-lut-with-color-count-255/18542/1 "2021-07-06T19:57:39Z")

</div>

Hello:  
The issue is first noted when I tried to reproduce a specific LUT in a commercial workstation by creating a custom LUT with 10 colors, and use it in a subtracted CT volume with standardized window and level ( basically with min 0 HU and max at a certain HU ). Then I noted that the displayed color is not compatible with the window and level settings in Volumes module, most region in the volume shows the color of maximum value. I then toggle color bar in Dataprobe module, and found that while as the data probe in left lower corner shows correct value, the viewport shows the color of 20-25 times of the actual value.  
This also applies to builtin color tables with less then 255 colors (e.g. DarkBrightChartColors / 64Color-Nonsemantic) and I then noted that the it shows the color of with [255 / color count] times the actual value.

CT Volume in “Gery” color table:  
 ![image](https://us1.discourse-cdn.com/flex002/uploads/slicer/original/3X/e/2/e217ee94c8b7908914a0e5b9f4f3cde728a2e1dd.jpeg)  
CT Volume in custom 10-color color table (see below for color txt):  
 ![image](https://us1.discourse-cdn.com/flex002/uploads/slicer/original/3X/9/7/975c6bf58d29673352a38806559340d024f5d3bf.png)  
Expected color is shown when adjust color window/level to roughly 25.5X (255/10)  
 ![image](https://us1.discourse-cdn.com/flex002/uploads/slicer/original/3X/4/a/4ac9b6732c44f2eb7bf9b10e4a87802c2611c487.png)

This issue is also reproducible with sample dataset.  
I’m not sure if I’ve missed something. 🤔

the custom color table:

```auto
# step 10
0 Navy_blue 0 0 128 255
1 Blue 0 0 255 255
2 Green 0 128 0 255
3 Harlequin 0 255 0 255
4 Maroon 128 0 0 255
5 Red 255 0 0 255
6 Raw_Umber 128 96 0 255
7 Amber 255 192 0 255
8 Gray 128 128 128 255
9 White 255 255 255 255
#EOF

```

Platform: Windows 10 20H2, 3D slicer 4.11.20210226, intel i5-9400 + nVidia 1060.

---

<div class="post-metadata">

**Author:** ![lassoan](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/lassoan/32/13_2.png) [@lassoan](https://discourse.slicer.org/u/lassoan)\
**Post date:** [July 9, 2021, 5:29am UTC](https://discourse.slicer.org/t/unexpected-behavior-of-color-when-using-lut-with-color-count-255/18542/2 "2021-07-09T05:29:17Z")

</div>

Thanks for reporting. The current behavior is indeed not intuitive. We already have an issue for improving this, but for now you need to specify 0-255 range in the color table and then map it to the volume by setting the appropriate window/level in the display node. See more information here:

> <https://github.com/Slicer/Slicer/issues/5336>
>
> When choosing a procedural color node as a color node for a scalar volume then t…he values are not mapped correctly.
> 
> \## Steps to reproduce
> 
> \- Load MRHead
> \- Choose RedGreenBlue as color node
> \- Adjust window/level =\> ERROR: no matter what you do, red color will not be used
> \- Create a copy of RedGreenBlue, edit values
> \- Colors corresponding to X values do not match actual values
> 
> It seems that 0-255 range of the color transfer function is mapped to the intensity window specified by volume display node's window width/level.
> 
> \## Expected behavior
> 
> Probably the best behavior would be to use the color transfer function for direct mapping (ignore window/level). This would be expected, especially when the user specifies x-\>RGB mapping using a color transfer function.
> 
> If that would be too much of a trouble for some reason then at least the behavior should be changed so that the entire scalar range of the colormap would be used by default (e.g., red, green, and blue colors for RedGreenBlue color node).
> 
> \## Environment
> \- Slicer version: Slicer-4.11.0-2020-09-30
> \- Operating system: Windows 10

---

<div class="post-metadata">

**Author:** ![squll1](https://avatars.discourse-cdn.com/v4/letter/s/3ec8ea/32.png) [@squll1](https://discourse.slicer.org/u/squll1)\
**Post date:** [July 10, 2021, 6:38am UTC](https://discourse.slicer.org/t/unexpected-behavior-of-color-when-using-lut-with-color-count-255/18542/3 "2021-07-10T06:38:11Z")

</div>

Hello:  
Thanks for the quick and precise reply!  
The workaround you provided works fine.  
(upper panel: original 10 step color LUT, lower panel: 255 step workaround)

 ![image](https://us1.discourse-cdn.com/flex002/uploads/slicer/original/3X/1/9/195d2447111be89e9c51a903925b8103140dbe6c.jpeg)