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
Currently, we don't have enough tests including the norm=Normalize(...) argument. It should work for matplotlib and also datshader (after #309), but I think we need some more tests and maybe also a bit more documentation.
Also, I noted that both seem to give the same result, not sure if that's a bug
Thanks for reporting. The instance_id column has values in [0, 1, ..., 9]. With clip=True one would expect the values [0, 1, 2, 3, 4] to have the same color, and the values [7, 8, 9] to have the same color. So it seems like that there is a bug.
Did you notice this only for matplotlib or also for datashader?
After looking into this a bit more, I would say the behavior is not a bug: according to the matplotlib documentation (https://matplotlib.org/stable/api/_as_gen/matplotlib.colors.Normalize.html), with clip=False, values outside of [vmin, vmax] are mapped to values outside [0, 1] (and not exactly to 0 or 1 as would happen with clip=True). Then, the respective colormap can "can mark these under and over values with specific colors".
In the examples above, we use the default colormap viridis, which uses its minimal value for under values and its maximal value for over values (see below).
So, if you would set over and under differently, the result looks like this for clip=False (the clip=True plot looks like above)
Notes on the datashader behavior here: ds.tf.shade() has an argument span that we can use for passing [norm.vmin, norm.vmax]. Unfortunately, there is no way to pass the norm.clip value and datashader always behaves like clip=True (described here: https://datashader.org/getting_started/Pipeline.html#controlling-ranges-for-colormapping). This also means that doing a manual normalization before calling shade() won't lead to the correct result, since these values would be clipped to [0, 1] automatically.
Activity
LucaMarconato commentedon Jan 5, 2025
Thanks for reporting. The
instance_idcolumn has values in[0, 1, ..., 9]. Withclip=Trueone would expect the values[0, 1, 2, 3, 4]to have the same color, and the values[7, 8, 9]to have the same color. So it seems like that there is a bug.Did you notice this only for
matplotlibor also fordatashader?Sonja-Stockhaus commentedon Jan 6, 2025
When using
datashader, both plots look identical as well.Sonja-Stockhaus commentedon Jan 14, 2025
After looking into this a bit more, I would say the behavior is not a bug: according to the
matplotlibdocumentation (https://matplotlib.org/stable/api/_as_gen/matplotlib.colors.Normalize.html), withclip=False, values outside of[vmin, vmax]are mapped to values outside[0, 1](and not exactly to 0 or 1 as would happen withclip=True). Then, the respective colormap can "can mark these under and over values with specific colors".In the examples above, we use the default colormap
viridis, which uses its minimal value for under values and its maximal value for over values (see below).So, if you would set over and under differently, the result looks like this for
clip=False(theclip=Trueplot looks like above)LucaMarconato commentedon Jan 15, 2025
You are right! Thanks for checking this 😊
Sonja-Stockhaus commentedon Feb 4, 2025
Notes on the datashader behavior here:
ds.tf.shade()has an argumentspanthat we can use for passing[norm.vmin, norm.vmax]. Unfortunately, there is no way to pass thenorm.clipvalue and datashader always behaves likeclip=True(described here: https://datashader.org/getting_started/Pipeline.html#controlling-ranges-for-colormapping). This also means that doing a manual normalization before callingshade()won't lead to the correct result, since these values would be clipped to[0, 1]automatically.Sonja-Stockhaus commentedon Feb 10, 2025
Looks like this could be a workaround: https://discourse.holoviz.org/t/specify-datashader-colors-outside-of-color-limits/8561/4