obscure colormapping issue related to quantization

Yes, I'm thinking some sort of functional, rather than table lookup, version would be useful. The table lookup is fast, but has its limitations for this kind of problem. I'll think a bit about it too. This kind of request comes up regularly (in one form or another) that it deserves some sort of solution.



On Aug 2, 2005, at 5:30 PM, Danny Shevitz wrote:

But... your last idea is superb. Why not a different way of doing it? How about instead of a lookup table, I just
write a colormap that has three user defined functions. Then I could do the thresholding exactly. It seems like
it would be pretty easy to do. I had originally thought colormaps were needed because graphics drivers had finite resolutions
so you couldn't put up too many colors. So, if I were to create a "functionColormap" instead of a "linearSegmentedColormap"
with millions of points in the image is there a danger I would run out of colors or is there some internal rounding or truncation
to prevent this? If there is no problem, then a new colormap subclass is definately the way to go. I assume it would be slower, but
I'm not sure it matters.