Bump to vispy 0.15 and update Colormap model #7846
Conversation
|
@napari-bot update constraints |
|
Updated packages: This workflow cannot automatically update your PR or create PR to your repository. But you could open such PR by clicking the link: brisvag/napari@vispy-0.15...napari-bot:auto-update-dependencies/brisvag/napari/vispy-0.15. You could also get the updated files from the https://github.com/napari-bot/napari/tree/auto-update-dependencies/brisvag/napari/vispy-0.15/resources/constraints. Or ask the maintainers to provide you the contents of the constraints artifact from the run https://github.com/napari/napari/actions/runs/14598410732 |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #7846 +/- ##
==========================================
+ Cove
8000
rage 92.92% 92.94% +0.02%
==========================================
Files 641 641
Lines 60627 60660 +33
==========================================
+ Hits 56335 56381 +46
+ Misses 4292 4279 -13 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
pyqt6 should be downgraded to 6.8.1. I still do not fix the problem with pyqt6==6.9.0 on CI. |
|
Should I manually edit the constraints, or is this pin being added in some other PR? |
|
Manually edit. I may do this for you (just local edit of |
if you can, yes please! |
| # some colormaps use BaseColormap and custom mapping functions instead of | ||
| # standard colors/controls, so they are broken in napari |
There was a problem hiding this comment.
Whoa, like what, and is that something we should support? Could be handy. 😃
There was a problem hiding this comment.
Not really; basically, you can create a BaseColormap and define your own glsl function for it, which might be whatever crazy thing you want. However, it's not really easy to communicate between python and "stringy glsl", so I don't think it's a good idea.
# References and relevant issues - fixes #7855 # Description Some colormap from vispy are broken (see issue for explanation). This PR simply removes them from the available colormaps. Updating them in vispy is another option, but I think it's worse because these colormaps have been in vispy a long time, and people might depend on their quirks. Also, `hot` is provided by matplotlib and `grays` is essentially a duplicate of matplotlib's `gray`, so we really only lose `ice`. Note that #7846 additionally introduces a `HiLo` colormap, which also currently cannot be represented by our `Colormap` model. Support for that will need to be added in that PR.
| 'bad': Colormap( | ||
| name='bad', | ||
| display_name='bad', | ||
| colors=[[0.0, 0.0, 0.0, 1.0], [1.0, 1.0, 1.0, 1.0]], | ||
| bad_color=[1.0, 0.0, 0.0, 1.0], | ||
| ), |
There was a problem hiding this comment.
LOL is this a common name for this colormap? Or do we want to call it nan also?
There was a problem hiding this comment.
lol nope, I just made it up, assuming I would get lots of comments about it :P Yeah, nan is also an option. I can imagine even more verbose, like highlight_nan
There was a problem hiding this comment.
going for simply nan for now.
Co-authored-by: Juan Nunez-Iglesias <jni@fastmail.com>
I put matplotlib as you suggested. Note that vispy's was literally added on this release, so it's hardly a standard :P |
napari/_vispy/layers/image.py
Outdated
| cmap_args = self.layer.colormap.dict() | ||
| cmap_args.pop('name') | ||
| cmap_args['bad_color'] = cmap_args.pop('nan_color') | ||
| self.node.cmap = VispyColormap(**cmap_args) |
There was a problem hiding this comment.
I prefer to add proper method to our Colormap for dict construction rather than doing this in vispy.
There was a problem hiding this comment.
This method already exists (dict()). The problem here is that our Colormap and vispy's are diverging, and I think this is the right place to take care of this difference. Eemember we plan to have different backends, and the _vispy module is exactly where vispy-specific stuff should be.
There was a problem hiding this comment.
Current code makes it harder to test it. We should be able to easy iterate over all napari color maps and check if it properly converts into Vispy one.
Without spawning viewer etc.
There was a problem hiding this comment.
I see what you mean; I unified them into a function that lives in the _vispy module, and is now also used by the surface layer.
In fact, we shuld probably move everything relating to vispy from napari.utils.colormaps to there... except some are technically public api 🤔
|
Looks like the headless failure is real — there's now some qt imports leaking into the non-Qt parts of the codebase. |
|
I think it can be fixed by moving the new function from |
I'm not convinced by this, we shouldn't have vispy code in non-vispy areas. But we can do that another time, I'll move to see if that fixes it. |
|
I agree with @brisvag. We need the same colormap for all backends. |
My point is not opposed to that. Having ie I wouldn't have done: return VispyColormap(**cmap_args)but just return cmap_argsand then in the calling functions change: self.node.cmap = _napari_cmap_to_vispy(self.layer.colormap)to self.node.cmap = VispyColormap(
**_napari_cmap_to_vispy(self.layer.colormap)
)Having said that, everything is green now, so maybe we merge and refactor another time??? 🥳 🚀 The other thing is that there might be a longer-term solution such that we can run vispy tests in the headless code. But currently that doesn't seem to be the case. |
|
(I also note that you didn't need to add an import for VispyColormap, so it was already used in that file?) |
yep, that's why I said
|
|
Adding a gif and image here for release notes: |
Description
Bump vispy to the latest version. This brings in a few bugfixes and performance improvements, as well as some new features that will be usable in napari. Changelog: https://github.com/vispy/vispy/releases/tag/v0.15.0
Notable changes:
bad_color,low_colorandhigh_color. These allow to set respectively the mapping for NaN, values <=0 and values >= 1. This PR updates the napariColormapobjects to match (closes HiLO LUT #6878 by introducing a HiLo colormap, and also adds abadcolormap for NaN highlighting).Gridlineshave settable limits (allows Add grid overlay #7827).