# napari community meetings (Eurasia)

- [Zoom meeting](https://numfocus-org.zoom.us/j/83351642622?pwd=avon14qhl1ZTaxg91KP5z1OUrawi5d.1)
- [Link to this HackMD](https://hackmd.io/@napari/community-eurasia/edit)
- [Agenda :point_down:](#Agenda)

### Code of Conduct

We strive to make the napari community a welcoming place! As such, the napari code of conduct applies to all community events. Please take a moment to review our [our code of conduct and incident reporting process](https://napari.org/stable/community/code_of_conduct.html).

### Who and what this meeting is for

Community meetings are a time for the napari community and core team to discuss napari usage and development. We welcome any level of experience and would love if the community showcased plugins, demos, and scientific use cases!

If this meeting is not at a convenient time for you, check out our [calendar](https://napari.org/stable/community/meeting_schedule.html#meeting-schedule)! We have meeting centered on the Atlantic, Pacific, and Indian Oceans!

# Agenda

## 2026-02-04

Attendees: Wouter-Michiel, Margot, Juan, Draga, Lorenzo, Grzegorz

### Topics

- [Margot] point layer colorbar update
- want to plot a points layer and color it by distance to other points
- paired with WM, and have an MVP that can turn on colorbar for a points layer
- but it doesn't turn off when you turn off the properties, and it's sitting in the top-left corner with a viridis colormap
- overlays code still says visible is False
- also even if you try to toggle them off, they don't disappear
- plan is to put up a draft PR
- also want to get it working for labels
- LG: what's the current idea regarding face vs. border?
- for now just disregarding the border and using face only
- LG: what's missing now is the logic to connect a `ColorManager` to the colorbar, because for images and surfaces it's connected to the `IntensityVisualizationMixin`, while points/shapes etc. use `ColorManager`. Do we want to get rid of border and just use selection?
- WM: have definitely seen people use the border for an additional dimension
- WM: refactoring the mixin?
- LG: I think it's the colorbar that needs to be changed, rather than the mixin
- Margot: only touched the colorbar and the points
- WM: want to make sure the colorbar only shows up when a continuous colormap is used, rather than a categorical one or even no color at all
- maybe give warning to user in those cases and don't open the colorbar at all
- LG: ultimately you should be able to point to a `ColorManager` class, and if the colorbar is pointed to it, then it "just works", and then you only need to hook up the visible/etc. Ideally shouldn't have any custom stuff in the points layer to do this
- JNI: don't want to call it ColorManager, want to go to Altair and look at what they call something that transforms a data space into a color space/size space etc.
- WM: in vega they call it a "scale"
- LG: I like mapper
- JNI: encoder - we have StringEncoder
- JNI: recommend Visualization Analysis & Design: https://www.cs.ubc.ca/~tmm/vadbook/ Ch5 in particular
- ColorBarOverlay docstring is not up to date
- updates are included in the PR
- LG: didn't we have or think of having at some stage a precommit tool to check whether the docstrings match the signature
- GB: don't think it exists, and we didn't write it. last time I checked it didn't exist for numpy-style docstrings
- LG and GB working on the pydantic update
- biggest obstacles are over but there's still a few things to do
- a little lost because the remaining stuff is in the settings
- settings causing tests to fail
- GB: looks like a timing problem to me - some event triggered during the clean-up phase and sometimes it hits before the object is cleaned, which is fine, and sometimes the event is already gone. Will spend time to figure it out. Main problem is they've changed how getting data from environment vars works, and I'll need to write a hack to get it working again
- moved initialization of sub-fields after the main pipeline e.g. we have the async setting. If you use the full path, settings file is overwritten correctly, but if you use alias, it doesn't
- need to also move some attributes from private to public but excluded
- is pydantic last thing we need to bump python?
- maybe? we're not testing it on anything so could be other things
- kinda need pydantic done before we can even test anything
- let's just merge the pin PR and then unpin in the pydantic PR
- EuroScipy proposal ideas
- tutorial will be more or less what we did last year
- talk ideas:
- introduction to napari
- migrating pydantic
- hackathon/building community for maintainers track
- CFP deadline updated to Feb 22nd
- WM updated ome-zarr-py and dask to support sharding via a consistent API
- also enabling zarr-rust
- could be nice to benchmark the overhead of dask scheduler vs. other approaches for task management
- JNI: is this internally or for docs?
- WM: initially for a docs page, to highlight to users when it would be useful
- JNI: a docs page that goes into larger-than-memory arrays and using dask/qt/xarray etc. would be very useful
- flaky tests
- could spend time hardening them or we move some tests we can't fix immediately to separate workflows
- tradeoff because we will have more jobs
- JNI/DDP: think it will be worth it
- [Draga] [#8357](https://github.com/napari/napari/pull/8357): changing the behaviour of the new layer buttons
- JNI: maybe we split up the New Layer options to do "from selection" as separate items?
- LG: maybe a different color for the button if a layer is selected?
- LG: maybe update the layer name if there's multiple layers selected?
- GB: don't have a lot of time to update the visual so maybe we do follow-up PR
- [Draga] Cell tracking example #8051 and docs#927
- GB misread the PR -- approved now and we'll merge and hopefully will fix #8051
- [Grzegorz] - future of bermuda - performance fixes for non Shapes layer https://github.com/napari/napari/issues/8582
- JNI: we don't really need thick contours...
- LG: the contours could just be lines also, right? Rendering them would be faster
- GB: yes, but lines are also not that performant
- GB: what if we need a performance fix that is compiled but not available in a generic library
- DDP/JNI: bermuda is the place for all these things, even if it's not triangulation related
- LG: idea of bermuda was that it was reusable stuff outside of napari so maybe we should keep bermuda as is and make a separate library for napari-specific stuff
-

### Action items

- Margot & Wouter-Michiel: open draft PR for points
- Juan: open issue to follow-up 8357 new layer buttons behaviour
- Juan: post on general re. potential interest for hackathon at EuroSciPy
- Juan: put out feelers for connections for hackathon venues?

## 2026-01-21

Attendees: Guillaume, Wouter-Michiel, Juan, Grzegorz, Draga, Lorenzo, Carlos

### Topics

- [w-m] ome-zarr-py metadata
- what should happen with ome-zarr/ngff-zarr, should ome-zarr-py converge with other packages, what should be in napari-ome-zarr
- viewing metadata in napari, perhaps with a validator?
- napari-metadata is the "built-in" plugin for viewing metadata
- goal is that it be included in the bundle/napari['all']
- WM to review and see what metadata folks think should be included that's not there yet
- will also post on image-sc and in the NGFF image-sc zulip channel
- JNI: which plugin depends on ome-zarr-py?
- should that be rolled into existing implementation
- WM: plugin should connect with validation code, but also a goal is for it to be lightweight
- GB: mostly will be good to start developing validators etc. in plugin, because napari is much slower in development. working in plugin allows for faster releases etc., and if it ends up being small and well-defined, can potentially move into napari
- WM: will start with plugin, or even just importing plugin widget and working with that?
- JNI: I don't think we want to be very selective yet with napari-metadata so it's probably easier to contribute directly to it
- napari-metadata alpha out
- quick demo!
- now with scrolling in both orientations
- inheritance checkboxes will be removed in upcoming PRs if the inheritance section is collapsed
- inheritance also works with linked layers so you don't necessarily need a batch update thing
- GW: does metadata get saved?
- not with the built-in writer, but other writers might
- napari-tiff **should** have some of it
- we do have an open PR to write out to ome-tiff: https://github.com/napari/napari-tiff/pull/62
- definitely need this documented, that it may not be saved
- splines discussion
- you can make poly lines in the shapes layer a spline, but it's not exposed in the GUI
- LG: main reason is we didn't know how to expose it in the GUI. Neds to be clear that it's not modifying the underlying data, but many people actually wanted the data modified, so need decision on whether we want to expose both options, or just rendering, or always force the data to change, etc.
- WM: also we had the discussion about e.g. poly line, whether it should be yet another button in the layer controls, since the behaviour is quite different
- JNI: that was before we had the dropdowns on right-click so maybe now we can just do that
- WM: could be useful to unify the other line-drawing items
- CMR: interested in working on that
- LG: maybe would be great to ask folks who want the feature how they want it to work, and what they would expect to do with the data downstream i.e. do you want segments after rendering, do you want an intermediate representation, do you want the spline object, etc.
- JNI: I think you never want the full rendered values because that's information lost
- LG: in my mind the right way to expose it was the points and the interpolation order and that's enough to give it to scipy or some other interpolation machinery and then you'd still get the same result
- JNI: how do you want it represented on disk and what are the different formats?
- ndimensional vector graphic format...? surely?
- LG: another question: do we want to expose this on a shape-level or on a layer-level, because right now it's on a shape. maybe selected shapes is the machinery for that?
- CMR: could be like points where it's currently selected, plus any new lines you draw
- LG: does it work with polygons right now?
- CMR: yes, but slow in general
- WM: possibly same issue as the lasso tool because it's doing the triangulation every time? Maybe if the face isn't showing, that will improve performance and then you only triangulate after the mouse is released? Triangulate only on outline?
- GB: trick will be that when you edit shape it should be moved into its own visual while you're editing, so then you're only triangulating the existing shape
- LG: but right now there's only one shape?
- GB: yes, but all of the associated code still gets called because there's no special path for editing a single shape
- WM: could ask someone at EMBL who's done a lot of work with Blender/Python/ome, they'd be a good person to ask
- [GW] [#8395](https://github.com/napari/napari/pull/8395) is listed in notes for 0.7 release but doesn't seem to be actually included?
- yep! that's a quirk of the release notes generating script, which pull in all PRs tagged with the milestone
- by the time we get to RC it should either be in, or we bump the milestone, but the goal is still to get it in!
- current issue is with parenting the vispy nodes, bounds are not being propagated up... (note taking failure, Draga was writing action items)
- alternative if Juan can't figure it out is to not parent the nodes at all and just put them in the scenegraph?
- LG: they need to be children of something...
- JNI: can have a bunch of compound visuals that each contain an image?
- LG: ...maybe? Couldn't we have our own version of the compound visual where we just detach the graph/child transform updating machinery? Not sure if we can, because afair this is happening as part of a generic refresh that updates everything, but maybe these can be blacklisted?
- JNI: can you point me to particular bits of vispy/napari glue code where I should look. How do you add an image node to scene graph?
- LG: in napari canvas module, once the vispy image layer object is created, it'll create an image layer node, and the image layer node is being swapped in and out by machinery, and it gets parented to the viewbox in which it's supposed to live. Viewbox will be either viewbox in the grid or the 2d viewbox. Canvas does this, upon being given a node
- JNI: can I give it more than one image node?
- LG: either one node with children or compound visual. For multiple nodes in a single layer, you'd have to modify the canvas. Potentially tricky.
- JNI: also want an informative message when you're out of memory
- JNI: more than 1/2 of main ram in integrated case, or more than vram in dedicated case, should raise
- LG: surely queriable? I think vispy has something you can use to inspect this?
- GW: generally, napari doesn't check for this right? it just crashes on server when it switches to 3D...
- JNI: trickier in a server too because your available RAM is not necessarily available if there's jobs
- GB: maybe ask cluster manager if there are some custom scripts if check for this? should probably be something we can edit in settings. But if we can get info about how cluster management queries this info, maybe it's a startinng point
- [GW] Current consensus on adding dependencies to napari to create docs?
- new dependencies (plugins) for opening images
- Guillaume is happy to update the dependencies on napari side
- we didn't want to make the contributing guide for documentation even more complex by adding that, but more than happy to support with the PR
- GB: maybe would be good to look at making sub-environments with UV to generate gallery examples and other contained docs, and then the main environment for building the docs remains clean
- ndevio and napari-meshio (Genevieve's), and it was recently updated
- napari team would take over napari-meshio if we needed to
- [#8579](https://github.com/napari/napari/pull/8579) - Removing npe1 reading and writing
- please play with it!
- jni: ❤️

### Actions

- [x] WM: ask Blender expert at EMBL to join one of our community meetings and share their expertise
- WM: play with napari-metadata and explore validation
- [x] LG: comment on #8395 with suggested paths forward
- GW: Open PR to add reader plugin dependencies for docs.

## 2026-01-07

Attendees: Grzegorz, Draga

### Topics

- Happy new year!
- Add your topics here :)
- (Draga) 0.7.0 PRs:
- [Moving slicing to class](https://github.com/napari/napari/pull/8254), which [Using units for scale](https://github.com/napari/napari/pull/7889) depends on
- code is ready for review
- everything except shapes is fully migrated, shapes is a dummy class for now because it'll be a much bigger lift
- [Cursor overlay](https://github.com/napari/napari/pull/8017) (and other overlays)
- feedback was good, paused to consider the code structure
- other overlays: grids, welcome widget, text overlay
- [Migrate overlays to psygnal](https://github.com/napari/napari/pull/8492)
- a few folks think it would be good to get this in to test pydantic 2 in a low-risk way
- Grzegorz & Lorenzo are still discussing whether other aspects should be migrated before we proceed
- Do we want it or not?
- GB, TM and LG discussed at community meeting, but it's not so much a technical decision as a policy decision
- Generally it's a deprecation question
- psygnal and our own code are both using events as the attribute for connection, but they provide different objects to the callback
- for overlays, we can probably do it whenever, because it's not that widely used
- for all other code, there's not a good path
- could modify our evented model, and the connector could provide a flag
- should be discussed at core team meeting
- [Clipping planes GUI](https://github.com/napari/napari/pull/7993)
- could probably be pushed across the line in some state
- if we want to collaborate, will definitely take longer
- collaboration with Anniek could be great long-term
- do we know of any applications that currently offer a similar feature so we can get inspiration for the GUI design?
- [codespell PR](https://github.com/napari/napari/pull/7619)
- seems like it would need to be redone from scratch? so maybe it's better to just close the PR (or leave it, but remove the milestone)
- GB: like the idea, and we have a lot of spelling errors, but it takes a long time to run locally (possibly not because of the codebase, but because of the local folder). Mixed feelings, because could be really helpful
- should probably remove it from pre-commit and keep it exclusively as a github action + optional tox command
- Grzegorz will try to configure it in such a way that it's runnable quickly locally
- Even if it's slow initially, after merge it should only be checking the diff, so that should definitely be configured
- Grzegorz not sure if you can even configure it to only run on diffed files
- [Cell tracking example](https://github.com/napari/napari/pull/8051)
- example itself is ready to go
- the UI diagrams are failing repeatedly due to a pydeps recursion limit issue
- Draga looking into it, but any ideas welcome
- Grzegorz reckons it's one of the new dependencies added in the PR - not because we use it for the application_status generation, but because it's present in the environment and complicating the dependency graph
- Grzegorz will take a look
- [Multi-layer features](https://github.com/napari/napari/pull/8189)
- Contributor PR
- would not like to delay it beyond 0.7.0 as the contributor has already been working on it for some time and has shown a lot of commitment
- we also can't go back and say "fix it this week"
- given everything else we still need to do, probably worth delaying 0.7.0 to end of Jan...?
- [Histogram](https://github.com/napari/napari/pull/8391)
- Tim is actively working on it now and receiving feedback
- Ideally we can get it in, would be a great headliner
- [Texture tiling](https://github.com/napari/napari/pull/8395)
- Guillaume's PR! I've pinged Juan about it and he said he'll look at the outstanding issue with parenting vispy nodes
- If we're going to merge this at all, it should definitely be in 0.7.0
- (Draga) New target date for 0.7.0rc0?

### Actions

- [x] Grzegorz: fill out core team meeting crabfit
- [x] Draga: schedule core team meeting
Grzegorz: comment on #8492 with possible deprecation options for event callback arguments
Draga: message Tim to bring up #8492, #7993 at Pacific meeting
Grzegorz: look at #8051 pydeps recursion limit failure

## 2025-12-10

Attendees: Juan, Grzegorz, Draga, Carlos, Lorenzo, Wouter-Michiel

### Topics

- npe1 deprecation
- plugin manager PR merge? :pray:
- https://github.com/napari/napari-plugin-manager/pull/191
- need to open PR to switch MacOS-13 images to the latest one as MacOS-13 deprecated, then merge into 191 then merge 191
- plugin manager release?
- cut RC after 191 merged
- run napari --pre tests to make sure there's no funny business
- release
- tools menu stuff
- may not work even with a startup script because the viewer is already launched at this point?
- should clarify behavior and potentially think of some workarounds
- napari-metadata
- https://github.com/napari/napari-metadata/pull/68
- PR open to remove the old code that's currently unused: mostly code that was creating custom metadata keys in the metadata dict.
- Instead we'll now be using the existing layer attributes for translation, units, etc.
- Functionality demo
- Feedback
- separate widgets rather than dropdowns?
- WM, DDP: nahh this seems nice
- GB: re. inheritance widget what's the benefit aside from the granular aspect?
- faster, granular, batch-ier processing, can just be in both places
- WM: people expect things in the same place especially if they're new to the interface. Agree could be in both places
- LG: main advantage I see is the granular selection, but that could also be a dialog on paste. I think what's throwing me off is the repetition of the "inherit" checkbox. Set current layer is a little strange, maybe let's just do a dropdown of the current layers and then just inherit
- JNI: for most use cases you probably just want to look at it and edit it rather than inherit, so inheritance should be separate
- GB: kind of agree. Should be same widget but we hide the inheritance checkboxes etc. until we open the inheritance tab
- JNI: if you're copying across different dimensional images we'll need a bit more care as to what you can tick or untick for inheritance
- ready for review?
- still a bit of work to do before merge e.g. the sub-widgets are not scrollable because of some QtScrollArea issue. Important for small resolution screens
- also question about pint units and what the correct registry would be to use and how to get it
- function `get_application_registry`, it is a pint function and a global registry
- core team will do a first pass for the code flavour and general comments before spending more time on GUI etc.
- would be great to have an example of how someone might extend the GUI components with a new attribute etc.
- maybe a sketch of how you might add rotation as a demo
- jni: benchmarks
- need to decide on machine
- GB: GPU consideration, we may want to have a set of machines with intel gpu, nvidia gpu and metal gpu
- jni: tiled rendering

### Action items

- Draga: bump macos runners in napari-plugin-manager
- Draga: self-merge PR using npe2 adapter
- Core Team: reviewing napari-metadata PR for general code structure and vibes

## 2025-11-26

Attendees: ???

### Topics

- Overlay initialization ([#8443](https://github.com/napari/napari/pull/8443))
- Texture tiling ([#8395](https://github.com/napari/napari/pull/8395))

### Action items

## 2025-11-12

Attendees: Guillaume, Juan

### Topics

- big 3D multiscale rendering
- auto-tiling

## 2025-10-15

Attendees: Draga, Grzegorz, Jaime, Juan, Lorenzo

### Topics

- CI in plugin manager is complaining
- need it for 0.6.6
- Jaime merged one PR because it worked once, but it's flaky
- seg fault in conda python 3.10 pyside2
- thread is started in constructor of the plugin manager, but it should be started in showEvent conditionally
- thread in question: https://github.com/napari/napari-plugin-manager/blob/e7444e79728f5ccb09fd2aa5cb0747278342ffd3/src/napari_plugin_manager/qt_plugin_dialog.py#L251-L257
- should also just make the release not dependent on tests passing
- separate issue with pyside6 on MAC only
- https://github.com/napari/napari-plugin-manager/actions/runs/18408147397/job/52453002626
- release
- other than plugin manager, we're basically ready to merge everything and release today
- kinda need to release today anyway because of the PR party
- Jaime will look at test flakiness, if we can't figure it out, we'll change the CI reqs. to not require tests to pass before release
- label opacity issue with bundle
- https://github.com/napari/packaging/pull/285#issuecomment-3316847965
- it's a pyside6 issue, but Grzegorz can't reproduce (on Linux)
- Juan checking whether he can reproduce his own error
- he can't...
- seems like bundle is ok with pyside6

- Lorenzo asked Juan to test testgl on his mac. Tests passed: https://gist.github.com/jni/ef6ba097afc8aa325e91431f11e96ee9

### Action items

## 2025-10-01

Attendees: WM, Juan, Grzegorz

### Topics

- [Draga] napari hub badges, npe2api stuff, netlify open source plan
- tested and merged https://github.com/napari/npe2api/pull/64
- updated and merged https://github.com/napari/npe2api/pull/67
- [Grzegorz] Unversioned pages
- [jni] existing discussion at https://github.com/napari/docs/issues/836
- [jni] issue with e.g. numpy.org, matplotlib.org: home page looks very different from rest of website
- [Grzegorz]: we can use two different sites but both with the same theme and navbar, to minimise this issue.
- [Grzegorz]: in favour of enabling discussions on repo, so issues are *only* actionable items.
- [jni]: problem is that the branching discussions are extremely hard to follow. Many people feel this way
- [Grzegorz]: have considered writing an agent + LLM summary of GH notifications because they are so broken
- Refined-github has "expand-all-hidden-comments" feature that is itself hidden: alt-click the "expand hidden items" button to use it!

> expand-all-hidden-comments sourcescreenshot
>
> On long conversations where GitHub hides comments under a "N hidden items. Load more...", alt-clicking it will load up to 200 comments at once instead of 60.

- [wm] ESSB conference
- mugs
- tablecloth
- banner
- ~~pens~~
- [napari beach chair!](https://www.flyeralarm.com/de/c/werbetechnik/sitzelemente-moebel/liegestuehle/)

- [wm] webpage idea (for QR code): everything you need to know about napari in 1 minute
- what is napari
- what is the community and how to take part
- testimonials about napari community
- blog posts by core devs: how they became a napari contributor

- [Grzegorz]: can organise napari hackathon in warsaw university next year adjacent to euroscipy (2.5h train krakow<>warsaw)
- [jni]: we do have some budget for a regional hackathon, so that might indeed be a good option

### Action items

- jni: make repo with graphics resources

## 2025-09-17

Attendees: Lorenzo, Juan, Grzegorz

### Topics

- What do you want to talk about Lorenzo
- Discussion about separating out View from Viewer
- GB: Most users use only one View, so it would be annoying to have to descend the viewer -> view hierarchy to access methods
- Juan/Lorenzo: we can pass through to active view from Viewer for most methods.
- GB: we might wanna discuss the single vs multiple layerlist point with the users at the hackaton to see how they would prefer to interact with it
- bermuda repo access -- was already pre-fixed :joy:
- https://github.com/napari/napari/issues/8271
- https://github.com/napari/napari/pull/8254
- Add your topics here :)

## 2025-08-06/07

### Attendees

- Draga, Carol, Grzegorz

### Topics

- Hub lite previews seem fixed, closed issue
- [Draga] (Assuming Grzegorz is there) Vercel stuff
- only Grzegorz can authorize deployments anymore - it used to be that any team member could
- it's USD20/month for additional seats on vercel
- netlify has pretty chill open source plans which would probably be more than sufficient for us and allow multiple seats
- Draga will look into applying for the netlify open source plan:
- https://www.netlify.com/legal/open-source-policy/
- in the meantime Grzegorz will keep authorizing stuff and we'll ping him for it
- [Draga] labels polygon tool like shapes (cellpose)
- it is on the todo list to implement this, but we want to do this via overlays
- currently all drawing on the shapes is in-place modification of the layer and it leads to a lot of performance problems and also means we can't reuse this across layers
- if we do it via overlays then once drawing is completed, a "post-hook" would determine what layer it's being added to and then if it's shapes, add it to the list, if it's layers make it pixels and then squeeze it into the array
- current state of overlays: don't think there's any blockers but there might be some technical stuff that is a hold-up e.g. refactor that simplifies maintenance etc.
- [Draga] Directory filename patterns for readers
- https://github.com/napari/npe2/issues/155
- directory content patterns rather than directory pattern itself?
- this could solve the napari round trip thing
- and could also solve zarr thing
- proposal: write directory matched groups, each group is a list of globs, all globs of a given group must be matched, directory is only passed if one or more of the groups are matched
- proposal: only filename patterns are checked for files, only directory patterns are checked for directories

Actions

- Draga: look into netlify for npe2api
- Draga: write up proposal for directory patterns in the issue