Seems like there are slight color differences between the cmap library and matplotlib ones? You can download the screenshot diffs at the bottom: https://github.com/fastplotlib/fastplotlib/actions/runs/7090258613

I don't think it's an issue, but I'm curious why it's different.

thanks for the heads up @kushalkolar. I'll have a look at it and figure out what's going on.

I do actually test for parity with matplotlib here (both naming and the actual effect of applying the cmap to an image), so i suspect that the differences might be in the way that colormaps are actually applied in the functions module. I did notice a very slight difference in the values of get_cmap as well, so I suspect that might be the root of it. I'll do some digging and get back to you :)

btw, I'd like to run these tests locally, but i ran into #388 ... any thoughts there?

Thanks!

Everything in the regenerate screenshots workflow seems fine visually, so you can replace the ground truth of the failing tests with those.

Curious what the difference was previously when the colors weren't matching?

oh good. it's working on CI too!
Yeah, the difference is actually a good one for you to know about:

the cmap.Colormap object behaves very much like a matplotlib.colors.Colormap, with the main API being the __call__ method, which takes an array of scalars and returns an array of colors. And, just like the matplotlib API, if the input array is of dtype float, it expects values from 0-1, and it's of dtype int, it expects 0-255.

There's of course a subtle difference in the input array there, for N evenly spaced numbers:

and

... so, in my original PR, I used a slightly lower level construct to retrieve the N evenly spaced colors. Rather than using Colormap.__call__(some_array), I used Colormap.lut(n_colors) ... which was slightly different than the existing code you had here which used np.take on a linspace array of int:

so I switched it to the __call__ approach and then everything matched the current screenshots. probably visually imperceptible, but might as well keep the same behavior :) Don't hesitate to ask if you have any questions about the cmap object. But in general, the __call__ method was designed (and tested) to behave exactly like matplotlibs.

The colormap text files can now be removed too.

oh wow... to be honest, I somehow missed the distinction there that matplotlib was only being used as a fallback.

So, a question for you: I can definitely understand wanting to keep dependencies to the absolute minimum. So, would you like me to update this PR slightly to keep the current behavior for named colormaps that you already bundle, remove cmap from setup.py and fallback to cmap only in the case that a string name is unrecognized? That would still allow you to support custom colormaps using all the previously discussed syntax, but the user would have to opt-in to that behavior. Thoughts?

There's of course a subtle difference in the input array there, for N evenly spaced numbers:

That is a subtle difference, thanks for tracking it down! I think the reason we used the approach that we did, and use int, is because it makes it easier to work with qualitative colormaps when you give n_colors. (not entirely sure, I wrote that part of the code years ago in a previous library)

So, a question for you: I can definitely understand wanting to keep dependencies to the absolute minimum. So, would you like me to update this PR slightly to keep the current behavior for named colormaps that you already bundle, remove cmap from setup.py and fallback to cmap only in the case that a string name is unrecognized? That would still allow you to support custom colormaps using all the previously discussed syntax, but the user would have to opt-in to that behavior. Thoughts?

Since cmap only depends on numpy I'm fine with keeping it in, if there are issues down the road I would rather vendor it in, but I hope you're able to keep producing all the cool things you've been doing in the imaging ecosystem! :)

I like that this will now enable us to do things like line.cmap = ["blue", "green", "yellow"] to create custom arbitrary colormaps. Speaking of which, would you be interested in implementing that? No worries if you don't have time, I can easily do it in another PR 😄

One more thing, does the cmap lib allow centering diverging colormaps arbitrarily?

For example if the following values exist and you want to center the seismic colormap around 0, instead of the middle value here which would be -2?

I like that this will now enable us to do things like line.cmap = ["blue", "green", "yellow"] to create custom arbitrary colormaps.

I just changed examples/notebooks/lines_cmap.ipynb to the following code:

and it seemed to work just fine:

... was there something else you were expecting would be needed?

Ah that's nice when two libraries work together without extra work, maybe speaks to the design of both 😄 .

Does the list of colors also work with the line collection and image example? If that works I will merge, thanks a lot! :D

I'm curious what your thoughts are on this part of our API, our goal was make it easier than and more intuitive than other libraries

image example:

I wasn't able to find a LineCollection example, which one should I try?

This example: https://github.com/fastplotlib/fastplotlib/blob/main/examples/desktop/line_collection/line_stack.py

If you have pyqt6 installed you can use the %gui qt hook. Otherwise you can force the glfw canvas with plot = fpl.Plot(canvas="glfw")

thanks. Yeah that example works, but it does get more confusing due to the overloading of the argument as a colormap or list of colormaps. So, one has to be rather careful there. If I do this:

then it works and I see this:

... but it's rather easy to get into trouble there

Yes you are right, because then this will raise:

But if a line collection is already created, then this will work:

Question: We could enforce that the cmap kwarg should represent a single cmap. If the user wants to pass a list of cmaps we make a new kwarg called cmaps?

After the line collection has been created, this still works to change cmaps of individual lines:

Question: We could enforce that the cmap kwarg should represent a single cmap. If the user wants to pass a list of cmaps we make a new kwarg called cmaps?

I can see arguments for and against. (notably, it's a breaking change). With the appropriate type checking and exception messages, it should be possible to keep a single cmap argument, but you just need to be careful about the inspection of the object and provide clear help/feedback

Question: We could enforce that the cmap kwarg should represent a single cmap. If the user wants to pass a list of cmaps we make a new kwarg called cmaps?

I can see arguments for and against. (notably, it's a breaking change). With the appropriate type checking and exception messages, it should be possible to keep a single cmap argument, but you just need to be careful about the inspection of the object and provide clear help/feedback

Hi, sorry for the late reply, been slow getting back into this after the winter holidays!

I think we can allow the following types of use for the cmap argument in LineCollection:

1. If it is a str of a valid cmap name, ex. jet, then it is handled how it currently is; first line would be dark blue, last line would be red.
2. If it is a list of str check if it is possible to make a cmap from it using your library (so this should be a list of valid color names). If not go to possiblity (3) below.
3. If it is a list of str with the same length as the number of lines, then check to make sure every str in the list is a valid cmap and each individual line uses this cmap across the length of the line.
4. If it is a list of list, if len(outerlist) == n_lines, check that each sublist can be made into a cmap from your library and use this to color each individual line.

I think this should cover all the cases? 😄