obscure colormapping issue related to quantization

You are right. The problem is that a lookup table is quantized, and the thresholds/intensities are floats.
In my particular case, what I'm looking at is an image representing arrival times. The problem is that
the rounded down quantization gives me a peek into the future, which I don't want. The way I am suggesting
with the ceiling suffers from exactly the same problem, as you mention. If you were looking at lower thresholds
instead of upper thresholds then the ceiling would fail. That is why I was suggesting a switch for both behaviors.
Since this is so obscure hardly anyone would use it or even need to know about it.

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.

D

Danny

Isn't the essence of the problem the fact that the thresholds are specified as floats and the lookup table is quantized by its nature? (And that the current design allows for arbitrary N.) Whatever value you specify for a threshold (unless it it 0 or 1) won't necessarily correspond to a clean boundary between the quantized values (however you choose to define the boundary: floor, midpoint, or ceiling). Isn't it possible that your ceiling version has the same problem the other way (some values that are actually less now show up above the threshold)?

I'm wondering if some other approach isn't needed. But before going into more thought about that I'd like to clarify your usage.

Perry Greenfield