You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Feature: make exact evaluation of function-defined colormaps accessible #157
Colormap.__call__ always goes through a 256-entry LUT, so a colormap defined by a function (ColorStops(lut_func=...), e.g. prism, flag, gnuplot, cubehelix) cannot be evaluated exactly at an arbitrary position through the public API. The function itself is only reachable as the private ColorStops._lut_func, and color_stops.stops holds a 256-point sampling of it.
import numpy as np
from cmap import Colormap
cm = Colormap("prism")
x = np.array([0.1234])
print(cm(x)[0, :3])
print(cm.color_stops._call_lut_func(x)[0, :3])
[1. 0.9237 0. ]
[1. 0.9744 0. ]
lut(n) already evaluates the function directly at any n but there's no public entry point for arbitrary x. Either a public read-only ColorStops.lut_func property or an N=None option on Colormap.__call__ that evaluates lut_func when it exists would be nice...
I agree, and I'm open to either solution. The public accessor is a little more explicit, but also a bit more "different" for the user wanting a color mapped at an arbitrary location. N=None is nice for the single entry point, but slightly more magic. I'm open to either. You have a preference?
Despite wanting to push the magic solution, I think just making the accessor public is the more responsible option. That wouldn't preclude adding the N=None approach later if there was a compelling reason/demand for it...
100%. Also wondering (a) if you’d had time to look at #155 and (b) where you sit on the idea of having a fourth exceptional value representing masked voxels? Right now napari lumps masks into bad_color along with nan. I peeled that out of this PR based on @jni’s reticence, but I still think it could be supported via the same mechanism without adding much additional complexity.
On Oct 2, 2026, at 8:01 AM, Family Schabel ***@***.***> wrote:
100%. Also wondering (a) if you’d had time to look at #155 and (b) where you sit on the idea of having a fourth exceptional value representing masked voxels? Right now napari lumps masks into bad_color along with nan. I peeled that out of this PR based on @jni’s reticence, but I still think it could be supported via the same mechanism without adding much additional complexity.
> On Oct 2, 2026, at 3:24 AM, Talley Lambert ***@***.***> wrote:
>
>
> tlambert03
> left a comment
> (pyapp-kit/cmap#157)
> <#157 (comment)>
> Sounds good to me, would you be able to make that PR?
>
> —
> Reply to this email directly, view it on GitHub <#157?email_source=notifications&email_token=AAOPZ2YJDV7DQVHISRB2AVT5R5Q3XA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKOJUHAYTEOBXHE2KM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-5948128794>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAOPZ2YWF2B3XURXUNXFLF35R5Q3XAVCNFSNUABFKJSXA33TNF2G64TZHM2TQMZZHE4TAMZTHNEXG43VMU5TKNRVG44TGNRVG44KC5QC>.
> You are receiving this because you authored the thread.
>
Activity
tlambert03 commentedon Oct 1, 2026
I agree, and I'm open to either solution. The public accessor is a little more explicit, but also a bit more "different" for the user wanting a color mapped at an arbitrary location. N=None is nice for the single entry point, but slightly more magic. I'm open to either. You have a preference?
matthiasschabel commentedon Oct 1, 2026
Despite wanting to push the magic solution, I think just making the accessor public is the more responsible option. That wouldn't preclude adding the N=None approach later if there was a compelling reason/demand for it...
tlambert03 commentedon Oct 2, 2026
Sounds good to me, would you be able to make that PR?
matthiasschabel commentedon Oct 2, 2026
matthiasschabel commentedon Oct 2, 2026
tlambert03 commentedon Oct 2, 2026
commented there, i'm ok with it 👍