# napari community meetings (Atlantic)

- Zoom meeting: https://numfocus-org.zoom.us/j/84048930435?pwd=Li2yjziyrGfNHNC3e04k6Ejzllla57.1
- Link to this HackMD: https://hackmd.io/BXWDZ3i8Q6OAEASrkaSNIQ
- [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).

### What this meeting is for

Community meetings are a resource for the napari community to get help directly from napari core developers in using napari or developing plugins. They are also a way to showcase plugins, cool demos, or new scientific use cases!

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

# Agenda†

## 2025-08-27

Attendees:

### Topics

- Add your topics here :)

## 2025-08-13

Attendees: Daniel, Tim, Carol, Jaime, Grzegorz

### Topics

- `napari-plugin-manager` UX/UI improvements:
- Issue: https://github.com/napari/napari-plugin-manager/issues/156
- WIP PR: https://github.com/napari/napari-plugin-manager/pull/170

- intros
- Jaime: working on all things conda and a couple PEPs for packaging
- https://peps.python.org/pep-0725/
- Daniel: Spyder, Qt
- Tim: stumbled into napari, but also a postdoc
- Carol: from open hardware
- tells the story of meeting Juan at a skimage workshop

- Jaime: rattler work on napari-plugin-manager and /packaging.
- https://github.com/napari/napari-plugin-manager/pull/171: adds py-rattler backend for conda
- https://github.com/napari/napari-plugin-manager/pull/172: adds uv backend for pypi

- plugin manager design
- clear up the interface for when there are no plugins (like from a search or at the beginning)
- Suggest some search queries
- generally against "highlighting" certain plugins, like by most popular or something because it will create a divide in the community tha twe don't want
- link to napari-hub for a search
- use metadata from the napari.yaml to assist with queries (like the thing that is "annotation, segmentation, reader, writer, etc")
- Jaime suggests a plugin that write a plugin
- Talk more about Jaime's backend implementations of pixi and uv
- uv backend implementation is easy
- Tim wants a way to use just pixi, but define where the plugin gets pulled from (conda vs pip)
- pyrattler replaces conda
- how to declare an extra to serve a default "optional dependencies" group in the plugin-manager
- Jaime says one way is to serve a minimal separate package that just depends on the optional
- Jaime does not think the plugin manager is the way for us to install these dependencies because it opens a can of worms (Carol agrees)
- we should document this better for plugin authors

## 2025-07-30

Attendees: Lorenzo, Tim, Grzegorz

### Topics

- Lorenzo suggests a regular coffee time to log in and work together
- General talk about current release state (v0.6.3) to merge the remaining stuff
- Then we focused on debugging some drag'n'drop script related issues

## 2025-07-14

Attendees: Tim, Carol, Ian, Brian, Ashley

### Topics

- Add your topics here :)
- napari team - Welcome contributors and first-time attendees
- Tim - SciPy wrap up
- Ian's experience:
- Tutorial (Tim, Draga, Peter) had a good flow (napari, events, plugin).
- Fernando's workshop on deep learning with Zarr and Dask.
- Pixi development working with napari.
- nvidia presence was helpful
- sprints made a plugin and it's now up on napari hub: napari-event-monitor https://www.napari-hub.org/plugins/napari-event-monitor
- It's really great
- Carol:
- Plenary talk by Draga
- Tim's community and contribution talk went well and is a future Turing Way
- Sprint went well
- Lightning talk on Improv and otters Carol, Tracy and Draga
- new plugins, new contributors, new examples, geospatial and xarray
- Tim:
- Sprint went well
- Weather example
- Coffee cup example (Kanai Potts) affine transformation and magic
- Boids (Davin Potts) and DragonHPC meets napari and multiprocessing
- Tim - napari-xarray
- Meeting
- Blog post coming soon
- napari-xarray repo
- Geospatial data in napari
- Ian - Events Monitor Plugin (Napari Event Monitor on Napari Hub and PyPI)
- Mouse events
- Status bar events
- And more...
- Adds listeners for events
- Next interests: reproducible steps from the UI in order
- Two days of sprinting
- Should we move into built-in plugin or reference in the docs
- Events reference is incomplete (napari viewer and viewer model); events on an object on a layer; vispy; private events don't show up in the event reference
- Carol - User experience for installation
- Try napari: uvx commands added to the README (sprint contribution)
- https://github.com/willingc/pixi-napari Working example of pixi with CPU and GPU workspaces
- Docs about reproducible science and pixi: https://matthewfeickert-talks.github.io/reproducible-ml-for-scientists-with-pixi-scipy-2025/
- All: Good discussion of pixi and uv. Brian has some pixi workflows working.

Action Items:
- Ian shows up at Docs meeting tomorrow :wink:
- Ian posts issue in napari/docs explaining the missing events in the events reference
- Ian posts issue or PR in napari/napari suggesting addition of napari-events-monitor to napari somehow. Tim suggests perhaps as an optional dev dependency

## 2025-07-02

Attendees: Carol, Jacopo, Tim

### Topics

- Carol gives a small update on the hub-lite changes
- typing discussion - Jacopo comes from a C background
- carol brings up ty from astral, here's a little toy https://play.ty.dev/
- We then discussed overlays. Jacopo has a desire to have layer specific overlays, to easily display what layers are on and off at a given time. Tim pointed out the (many) issues/PRs we have on this, and hope that others will ask Jacopo for review or that Jacopo will contribute. :)
- the `.gridded` attribute introduced in https://github.com/napari/napari/pull/7870, to attach overlays to viewboxes based on the layers present
- the future colormap overlay which depends on underlying layers https://github.com/napari/napari/pull/7832
- and as such we are implementing overlay tiling https://github.com/napari/napari/pull/7836
- Jacopo brings up the slice text overlay as pointing towards needs https://github.com/napari/napari/pull/6678
- and we discuss Lukasz Migas legend overlay, potential PR https://napari.zulipchat.com/#narrow/channel/212875-general/topic/Legend.20overlay/with/524951226
- fps https://github.com/napari/napari/issues/836
- general overlay issue https://github.com/napari/napari/issues/5960

## 2025-06-18

Attendees: Carol, Jacopo, Tim, Grzegorz

### Topics

Add YOUR topic here :) We will prioritize community-added topics, then the theme, and then other business.

- Discussion about setting up python packages and such (because Tim asked Carol what she's up to at SciPy).
- Hatchling vs setuptools (and other build systems)
- Materials that Carol recommends:
- https://www.pyopensci.org/python-package-guide/index.html
- https://learn.scientific-python.org/development/
- Carol suggests us keep setuptools, since its simple
- Jacopo recommends hatch as a tool chain option in the copier template
- Grzegorz recommends we switch some subpackages to hatchling, so that core devs get experience
- Action needed: Open an issue to support other build systems (in copier repo, but maybe somewhere else)
- Jacopo gives update on his plugin -- https://napari.zulipchat.com/#narrow/channel/212875-general/topic/Custom.20overlay.20for.20reshaping.20a.20live-changing.20image.20layer/near/524283983
- https://github.com/bluesky/bluesky
- https://github.com/redsun-acquisition
- Includes redsun (the acquisition component) and sunflare (a plugin system)
- Built on top of napari, and a reworked plugin-copier template, so we discussed potentially upstreaming some changes
- Jacopo: How will we serve napari online
- Our Model system should help us be backend agnostic
- One challenge is serving 3D graphics online
- sorry, Tim could have taken better notes here...
- Jacopo: what do you mean by backends?
- Mostly means Qt (our rendering system), but realistically both Qt and VisPy
- Trying to work towards including pygfx for visualization
- multi-backend support https://github.com/pyapp-kit/ndv
- Cleaning resources https://github.com/napari/napari/issues/8023
- If the widget has the function defined (to clean up), we can call the function once it is removed from the viewer
- Tim - why make it opt in? Grzegorz - We cannot just dsetroy the widget on removal, in case there are other references to this. Carol - we need to be careful when destroying it, especially if the system is still doing (i.e. async would be a challenge). python garbage collection is indeterminate when it will happen, but its trying to be improved
- We then spent a long time discussing implementation of #8023, and concluded it would be useful to have both a `clean_resources` (for hide) and `clean_resources_and_widget` (for close) so that there is still the ability to use show after a hide. The benefit of having this be a public function that developers can call/add to their plugin is that it can also be backend agnostic rather than relying on Qt events, as well.
- Tim - trying to debug https://github.com/napari/napari/issues/8034
- Easiest way to check an OS specific thing would be to add the config to initial tests (i.e. Windows)
- To not run the whole test suite, edit tox file to specify directory of tests looking at the tests that you only want to do. Grzegorz cautions, as usual, that Qt is goofy and may pass in certain test runs but fail with whole suit
- Tim actually wants the tests to fail to know why the screenshot tests are skipped on windows, and suspects it may be do to processEvents() speed

## 2025-06-04

Attendees: Jacopo, Tim, Grzegorz, Johannes

### Topics

Add YOUR topic here :)

- Jacopo Abramo: this is my curiosity talking, as I haven't dwelt on the internals yet but I wanted to know if anyone joining the call might have insights/experience; the following are entirely suggestions and can be completely skipped in favor of more pressing topics
- an overview of possible performance improvements for the sake of a minimal (and very brief) introduction to alternatives to the existing model layer, including
- different base classes for evented classes;
- prime candidate is `psygnal`
- separation between plugins and internal, non-shared interfaces (i.e. although used by plugins, layers are still somewhat "internal", although exposed)
- a little bit of discussion of how napari saves its state and what are dask and pandas used for
- reasoning: possible, faster alternatives that - in case all of these are not publicly exposed - would allow the replacement and reduce the number of hard dependencies

### Notes

- Discussing pandas vs other dependencies for dataframes https://github.com/narwhals-dev/narwhals. Pandas is currently only used for layer features, and should be a delayed import.
- The only state that we store is settings (yaml) file. Settings are only stored if they are not the default
- Discussed dask implementation: Dask allows caching of remote data, but at the time of implementaiton it was the only stable lazy library. Dask is slow on the startup, so there is motivation to solve this by setting environmental variables through dask.
- *Jacopo:*
- both dask and pandas could be replaced by narwhals as a top layer for common shared dataframe AND array as well (there's an Array interface referenced in the documentation); as suggested by Grzegorz a core dependency should be provided (polars should take care of both);
- these are all internal dependencies that are both lightweight (allegedly) and provide better performance (allegedly) and should not impact the rest of the application (although this is a very shallow assumption)
- other dataframe libraries could then be handled by separate plugins/core add-ons that would expand the `optional-dependency` section in the `pyproject.toml`
- it goes without saying it is a lot of work and some thought in the design should be provided beforehand
- Johannes at TU Dresden, moving to OME-NGFF team with Josh Moore.
- new release today of napari-clusters-plotter
- Working on a decorator to launch any napari plugin function from the command line
- A quick tip from Tim about grid mode stride, to overlap adjacent layers in grid mode
- Showing off an update to napari-clusters-plotter. Now have multi-layer feature highlighting
- Now can color labels (or rather any layer) by a feature as well (Perhaps tracks are currently broken)
- Now can cluster with multiple layers!
- Discussing a weakness (of napari generally) which is the generation and addition of features, this requires
- Another time that layer groups gets brought up - continued motivation to finish this
- Johannes discusses setting up a new workflow system, a weakness of previous workflows was that it uses napari.types.\*Data which resulted in loss of metadata.
- now developing a napari_cli plugin
- demo of this, where Typer https://github.com/fastapi/typer
- writing a decorator to convert Types unknown to Typer to something like Path, so it's happy
- Jacopo asks if you can register new Types to Typer: https://typer.tiangolo.com/tutorial/parameter-types/custom-types/?h=types
- Grzegorz brings up [#6986](https://github.com/napari/napari/pull/6986), so now 'ImageData' should maintain spatial information to outputs
- Also, we could get eyes and feedback on [#7973](https://github.com/napari/napari/pull/7973)
- And feedback on adding on units to layers [#6736](https://github.com/napari/napari/pull/6736)
- Targetting eventually doing workflows with NextFlow https://github.com/nextflow-io/nextflow
- How to use this to connect plugins
- Bring up and discuss a plugin working group to improve talking between plugins
- [#7965](https://github.com/napari/napari/pull/7965)
- How to talk across the timezones and get sufficient feedback from plugin developers
- We *really* need to focus on getting a good API
- Jacopo gets very excited about https://python-dependency-injector.ets-labs.org/ as alternative to in-n-out https://github.com/pyapp-kit/in-n-out
- *Jacopo:*
- for context: I thought that dependency-injector could be used (or ino for that matter) for sharing callables between plugins to build up a pseudo-workflow definer but I might be wrong about that
- Maybe https://ewoks.esrf.fr/en/latest/ as a backend for batch processing
- Discussing much more about how to approach batch / workflow between napari widgets. How strict should the manifest be? Less strict allows the great customizability, but makes communication between plugins more difficult. Magicgui-compatability is a good starting point.
- Johannes finds the Typing in napari to hit a nice middle ground between too scrict and general. Grzegorz says we should not semantic typing. Jacopo is of different thought, where strong Typing helps know correctness.
- Grzegorz suggests extending napari with a domain-specific napari typing package
- Discuss how to add a return type of Features to plugin outputs
- Johannes discusses how to take his napari-cli idea to connecting napari outputs -- perhaps improving napari outputs would make this easier. Part of motivation of NextFlow

## 2025-05-21

- Attendees: Tim, Wouter-Michiel, Carol, Grzegorz, Brian Northan, Ashley, Jacopo Abramo, Peter,

### TOPICS

- Introductions :)
- To share about our newcomers, Brian is working with many clients to try to process thousands of images, and is more recently becoming more interested in napari to get batch processing. Especially with augmenting and using our annotation features for quicker deep learning
- Jacopo is PhD student in Germany -- working currently on managing bounding box overlays to reshape images
- Brian talks about trying to get multiple different libraries version hooked up to the same code (i.e. to compare Cellpose3 and Cellpose4)
- pixi offers support for multi Environments (such as CUDA and CPU). It may work for Cellpose3/Cellpose4 and Zarr2/3 https://pixi.sh/dev/workspace/multi_environment/
- this wont really work when one plugin requires zarr2 (e.g. for tifffile) and another zarr3 e.g. ome-zarr 0.5 (this is a real situation right now, where all of our JAX data has been converted to ome-zarr 0.5, which requires zarr3, but tifffile doesn't support zarr3 so need zarr2)
- Jacopo discusses [ImSwitch](https://github.com/ImSwitch/ImSwitch) and [Bluesky](https://blueskyproject.io/bluesky/main/index.html) to try to get streaming of data set up
- Fernando Active Learning
- Perhaps for a hackathon -- how to get packaging states to be improved. i.e different versions of same library (zarr2/3, cellpose 3/4) but also improve the all-or-none download of plugins (where you get all, or none, or not the backends of interest)
- https://github.com/wheelnext/wheelnext, https://wheelnext.dev/
- https://github.com/Imaging-Server-Kit
- Some packages are more critical for backwards compatability
- Peter discusses the batch needs -- the intermediate step between using the napari viewer and plugins to set up the analysis, but then NOT going to a python script, to run on a folder of images
- Grzegorz discusses that in order to get batch processing hooked up requires plugins to use functional widgets, rather than their own.
- Grzegorz discusses serialization of versions of plugins and the state of the workflow for reproducibility
- Peter says the versioning is a next-level problem, that goes beyond batch processing
- WM discusses OME-NGFF thinking about serialization
- Peter: using the manifest to declate commands that can be batched seems very resonable. Fits with the menu contribution model too, e.g. Layers menu. Not every plugin makes sense for batching, but for some things it makes sense.
- Carol: Create one-page examples for the community to show how workflows should work
- How to deal with dimension ordering for batch workflow plugins talking with each other?
- Grzegorz suggests that dim order state might be improved in napari to help with this
- Peter: manifest could be updated to allow declaring supported dims for commands -- it's totally fine if a plugin only handles 2D data for example, it just needs to be clear/explicit about this
- If we do this, we need to declare very specific expectations for users that this won't be as agnostic as the general use principle of napari
- Peter: plugins should have a better way to declare what data it accepts (just like we do with app-model), especially in manifests
- WM: LinkML has a state management which helps serializing this, and says it is quite human-readable https://github.com/linkml/linkml-arrays/blob/main/tests/input/temperature_schema.yaml
- Grzegorz: this may be very hard because magicgui looks for typing at runtime (sorry Tim is not quite sure how to take this note) -- especially worried about the widget plugins.
- Brian: Collection of files with different sizes of dimensions, causes conflict when trying to be agnostic between workflows. Push data into a 4D state to better scroll through
- Peter: the *commands* in the plugin could be batchable, even if the whole plugin isn't batchable
- Tim: should we be able to scroll not just through dims, but through layers themselves. One issue is that layer list model is slower than slider, but sliders are not great for big data
- Jacopo asks if napari-lite is still a core goal, which everyone discussed positively and we encouraged contribution or even notice of finding the tangles in our spaghetti to open issues
- Update to multichannel grid mode #7870
- Briefly touched on to encourage people to take a look.
- Briefly mentioned #7952 since its such a big move of files, it may be annoying to keep this PR open for a while. So let's hack at it ASAP.

## 2025-05-06

- Attendees: Wouter-Michiel, Tim, Jacopo, Grzegorz, Lorenzo

### TOPICS

- Introductions :)
- [WM/Lorenzo] Lovely multichannel grid mode [#7870](https://github.com/napari/napari/pull/7870)
- Discussing general purpose and function and various improvements including:
- Mirroring cursor in each viewbox
- How to manage many many layers
- Discuss difference between multi-canvas and grid viewer
- [Grzegorz] - Use units when rendering [#7889](https://github.com/napari/napari/pull/7889)
- Discussed how to handle mismatched units in the viewer
- Discussed how/when units should be inherited
- [Jacopo] - Desire to use napari as a streaming visualizer, for multiple cameras. It will initialize a series of image layers.
- 1) Need to lock layers from deletion [#3466](https://github.com/napari/napari/issues/3466)
- 2) ROI overlay - how to solve this? use vispy overlays? use shapes layers?
- How to modify the qt viewer/ extract the qt viewer widgets
- How to add buttons
- How to modify the layer list / add a custom layer list