I think the editor is doing the right thing, but there is an issue with the color nodes and/or label map display node. It seem to me that the label scalar range should probably be clamped to be 0 to numcolors-1 for a discrete color table.

I'm not sure if there is any distinction between discrete and continuous color tables. For me, as a user, all colormaps seems to work the same way now.

The problem is that the Editor assumes that the LUT function is identity (f(x)=x), which is not always the case. It's not even the case for many of the built-in colormaps.

The Editor module should do one of the followings:
A. refuse the selection of a colormap with a non-identity LUT (this could be an issue, as the LUT can change, etc.)
B. set LUT to identity in the selected labelmap (can be problematic for built-in colormaps that are read-only)
C. allow selection from the same set of colors as those listed in the color module for the selected colormap => in this case the actual drawing color should be computed using the LUT (you cannot use the color index as drawing color)
D. allow selection of a drawing color from the lookup range and use that value for drawing => in this case you may show the name of the closest color (that you determine by using the LUT)
E. Having "discrete" colormaps with enforced identity LUT. The Editor would only allow selection of discrete colormaps.
...others?

I would probably prefer E. If that's not doable then maybe C.

The Colors module only allows editing for discrete color tables, the number of colors entry box etc are disabled when continous ones are chosen. The colors in the table for continuous nodes are a sampling to try and show a bit of what the color node provides.

I was able to update the color table range when the number of colors is modified in the Colors module, and the steps in the Description above work with that change (not checked in yet).

It's still a problem that if the range on the vtkLookupTable doesn't match the number of colors in the table, the Editor module draws with a different color than comes up in the color chooser. This could be avoided for discrete color nodes by disabling the range slider in the Color module, at least until a more intuitive user experience can be crafted in the Editor module.

From the lettered list: definitely don't do B.
E is probably the safest path for now (and my changes would help enforce it from a copy node perspective), but would require some book keeping if we allow users to change the scalar range on color nodes (we'd have to keep track of when the number of color and/or look up table range are changed).

In the larger picture, the range setting on a look up table is mostly useful for continuous ones (I'm thinking of the heat or PET LUTs), can we come up with a use case where it would make sense on a discrete color table? For me, it's not easily intuitive how the mapping from integer to colour values change as I change the range. If we're going to support it, I'd like to see some changing icon hints like the ones that Julien puts in the drop down menu. Also: verifying that the scalar bar widget properly reflects the range and number of colors.

svn 21993[1] updates the table range and also only updates the number of colors when finished editing on the spin box (press enter or it loses the mouse focus)

[1] http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=21993

I tested the steps to reproduce it, seems like this was fixed as a side effect of my work on the color look up table ranges in bug 3586.

Closing resolved issues that have not been updated in more than 3 months.