# napari community meetings (Atlantic)

- [Zoom meeting](https://numfocus-org.zoom.us/j/84048930435?pwd=Li2yjziyrGfNHNC3e04k6Ejzllla57.1)
- [Link to this HackMD](https://hackmd.io/@napari/community-atlantic/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-01-28
Attendees: Margot Chazotte, Wouter-Michiel, Grzegorz, Carlos, Tim

### Topics
- [Margot]: colorbar for other layers than image layers.
- wants to use colorbars for points layer
- discussion about overlays, the IntensityMixin
- `Save All Layers` isn't quite a great conversion to svg, the symbol of the point isn't saved. Request for
- Discussion of napari-metadata, and, in part, how we are working on units (and the PRs stuck in review)
- units: https://github.com/napari/napari/pull/7889
- adding writing of units to OME TIFF https://github.com/napari/napari-tiff/pull/62
- how do we inherit units across layers and match units
- we can *potentially* get 7889 in for 0.7.0
- Carlos - splines in napari
- discussion between LG and GB and CMRR about where / how to expose the splines
- could be similar to how something like "point size" is exposed. Where either it can be set across the whole layer, or individually per shape
-
- Margot: where are scalebar info in docs
- API is missing, need to explicitly update the sphinx contribution
- There is a very old issue about exposing scale bar WOOPS https://github.com/napari/docs/issues/38
- Can't launch an ipython console in napari if napari is launched from ipython

## 2026-01-14

Attendees: Jacopo, Tim, Lorenzo, Ashley, Grzegorz

### Topics

- Discussion about the camera angle conversions
- It *feels* like a conversion should be possible, but we cant figure it out
- Tim's argument is that Euler angles *cant* replicate a quaternion in all cases (and thus the view direction) because its missing the extra dim
- Seems we've nerd sniped Ashley into trying to take a crack at it
- Discussion on the value of actually having the conversion formula, is in agreement with PR discussion where it seems rather low priority
- Jacopo: Vispy2? Lorenzo is not a part of it, and Ashley suggests that pygfx is effectively vispy2
- Our goal is to split out our backend rendering system, with hope towards movement to pygfx as an real alternative backedn
- Even though its built with wgpu-py, it doesn't really get us closer to web, in that sense
- We need to make sure to handle mouse events
- macOS has deprecated OpenGL for a long time, making it a risk for us to hang onto OpenGL
- Grzegorz suggests to introduce teh backend switch as a dock widget
- Discussion about focusing on stabilizing napari
- Discussion about migration to pydantic v2 (shouldn't be a breaking change) and the related switch to psygnal (needs a transition time)
- Minus indexing? https://github.com/napari/napari/issues/8558
- Jacopo gut reaction is strongly dislikes minus indexing! this was great feedback :rolling_on_the_floor_laughing:
- Grzegorz says minus indexing will help us as we match layer axes in future implementation
- Lorenzo is in favor of minus indexing
- We've circled around to Jacopo approving such a change, but is concerned about teaching
- Ashley supports the negative labels
- Final decision about create empty Points and Shape Layer for selected one: [#8357](https://github.com/napari/napari/pull/8357)
- Do this for shapes and points for now because its easy
- We can implement for labels, but that works well on images
- Lorenzo proposes adding this functionaltiy to the new layer buttons
- Tim describes how he's worked with multiple new users that *expect* the new layer buttons to work this proposed way
- Hover over button should provide a tooltip on the behavior
- We may introduce Right click behavior for the button which would allow inheriting from all layers
- in cases where the selected layer is points or shapes, We will need to gray out the labels layer for now
- One way to think about this that currently the behavior is obscure. At the least, introducing this behavior allows users to understand the source of how new layers are inherited
- Changes to GUI (highlights, button icons) can come in follow up PRs

## 2025-12-17

Attendees: Wouter-Michiel (PhD), Tim, Lorenzo, Grzegorz

### Topics

- discuss WM's graduation :)
- discussing Pydantic v2 / 3.14 apocolypse
- with psygnal just get the value, not knowing where it comes from. Everything doing `event.value` will break
- Lorenzo: worried that many things in the codebase inspect themselves to find the event emitter object
- Lorenzo: there is no benefit to this for 0.7.0 - except what GB and JNI say
- LG, WMV, and TM think we should do 0.7.0
- Then 0.8.0 follows immediately with sole focus for 3.14 + pydantic v2
- Our eventedmodel uses named events, so either we need psygnal events with
- psygnal is faster than our events because its compiled with mypyc
- need to upstream custom events to psygnal
- `viewer.dims.events.connect` <- event emitter gets an object called Event, then in callback do `event.value`
- but in psygnal, you don't return Event
- This needs to be a discussion at the core team meeting
- Option: Migrate to psygnal those which are easy drop-in-replace -> Update our internals to pydantic v2 -> Go closer to psygnal implementation for these tricky internals
- Alternatively, focus more on a clean, hard break from pydantic v1/custom models -> pydantic v2 and psygnal
- How can we get feedback on this as a team -> the PR is useful but maybe we need discussion outside it

- Action point: Grzegorz and Lorenzo will write down their views and it will be discussed during core meeting.

## 2025-12-3

Attendees: Tim, Jacopo, Ashley, Grzegorz

### Topics

- Ashley: different rendering of point size to get around the error on some operating systems https://github.com/vispy/vispy/pull/2701
- there needs to be a small napari follow-up to take advantage of it, but this wil llikely be small
- Jacopo: https://github.com/napari/napari/pull/8418 typing
- if PR is just typing, it will be a quick merge
- then do a different PR with psygnal changes
- How do we want to do typing? Do we need some kind of documentation on our typing strategy
- Jacopo notes that it seems we don't follow strict typing
- Grzegorz - current layers are impossible to type in strit mode
- It's problematic code from the past that isn't type, and it is difficult
- notetaker Tim stepped away for a moment
- But they are talking about some kind of data thing and psygnal migration
- https://github.com/data-apis/array-api
- Grzegorz plans to finish https://github.com/napari/napari/pull/8254 so that Jacopo can update PRs
- Goal is to move evented model to psygnal and pydantic 2 models
- Long discussion about how to make the transition towards psygnal, because this will be a consistent way to handle eventing, and require less getter/setters in the codebase
- How to encourage / guide software architecture
- Stick to one architecture
- but what can we do to encourage at least some positive thoughts without bikeshedding this to hell and back
- keep as much logic out of widgets as possible
- maybe highlights plugins that are well organized
- a link https://github.com/napari/napari/issues/8348
- more tutorials about testing
- if its easy to test, its architecture is better
- if tests are too big
- tox, nox, pixi, uv, hatch discussion about testing on ci
- Grzegorz says local tox is so much faster
- uv and pixi allow cerating isolated environments on the fly
- tox allows pass env, and extras -- this prevents passing other environment variables. The good thing is that this helps locally with not having a bad local environment variable set that breaks tests
- back to plugin sustainability

## 2025-11-19

Attendees: Tim, Guillaume

### Topics

- We had a short chat about pixi/uv and end users. Not really coming to any conclusions just mired in it all
- Tim did a live review of Guillaume's excellent #8395, [starting here](https://github.com/napari/napari/pull/8395#pullrequestreview-3483774805)

## 2025-10-22

Attendees: Tim, Grzegorz, Wouter-Michiel, Brian Northan, Jacopo

### Topics

- Wouter-Michiel submitted his thesis!
- WM presented at a recent conference
- Has a banner?
- Folks still wonder about running napari in HPC / xpra container (@psobolewskiPhD, just pinging you)
- WM trying to pawn off the banner
- Brian gives WM an overview of appose
- makes it possible to call functions in different environments
- https://github.com/apposed/appose
- is it actually zero-copy of the data?
- at least passing the header between environments
- We encourage Brian to set up testing on Github CI
- don't use DL algorithms
- try to set up *extremely* simple unit tests to test things like 1) spawning environments, 2) passing the data, 3) functions in the new environment
- Unit testing and plugins
- plugins get confused with Qt testing. should we be testing Qt though?
- Mac has a different order of spawning events -- and that needs to be accounted for
- test logic in the *Controller* (model) not in the View (i.e. qt/ widget stuff)
- maybe in the plugin template we can have a Model / Widget separation as an example
- Grzegorz says this is the problem with magicgui because it only spawns a widget, whereas magicfactory has more stuff
- Ahh! Exactly what Jacopo proposes -- we need a systematic reviewing process
- JOSS
- plugin sustainability initiative, where we have a test/ review process
- donate plugins to the initiative
- look at these contrib things for inspiration
- xarray-contrib / dashboard https://github.com/xarray-contrib
- sphinx-contrib https://github.com/sphinx-contrib
- Grzegorz: **Maybe think about develop more fixtures (or advertise existing) to simplify test. As many tests do not require whole viewer (make_napari_viewer), but just ViewerModel.**
- Jacopo: btw, for the controller thing: the idea of a "controller" in a napari widget is not really "documented" per se
- Jacopo: there should be more structure around the napari architecture, since its so extensible. This will help sustainability
- need better differentiation between "user" documentation and "power user" documentation
- Jacopo critiques that we could work on internal architecture better than newer features
- Wouter gives an overview of recent work in scverse (spatialdata)
- thinking about the plotting ecosystem, between spatialPlot, napari plugin, and others
- mostly thinking about standardizing things through a Vega configuration
- Jacopo asks if there are any blockers now for https://github.com/napari/napari/pull/8134
- Grzegorz says the blockers are now gone,
- There are many things to work on still for layer groups
- So, Jacopo could move forward with this PR
- Does typing speedup runtime in Python? (it can in other duck typed languages)
- *Maybe* if compile with mypyC , but not always easy to compile
- in the context of napari, it will likely not always work, because the public API should be safe/flexible rather than fast (i.e. tuple, list, string all supported by same object)
- psygnal also struggles with type checker
- Once we are able to fully type public API (i.e. napari models) then we can improve things like the plugin checker to have warnings from things like mypy
- we need to better type the layers, generally
- Our encouragement to Brian (and everyone) is that... you should bother us! It not only saves the plugin author time
- Brian has been playing with the microsam plugin -- a lot of functions accept the `Layer` instead of `LayerData` or some other object, that can then be genericized
- napari can provide documentation to improve how to pass better types into plugins, but also improving this will get better eventing and things like LayerDataTuple would be useful

## 2025-10-08

Attendees: Tim, Grzegorz, Brian, Jacopo

### Topics

- Brian shows off "something silly"
- Has a complex, but involved 2D deep learning annotator and is now working on an nD verison
- https://github.com/True-North-Intelligent-Algorithms/napari-ai-lab
- currently using a widget to load directories, isntead of readers - Tim will ping Brian for feedback on the directories implementation
- Jacopo
- was in Genova for a month, worked on optimization of a software in another lab
- Started writing thesis, with [Redsun](https://redsun-acquisition.github.io/) being the final output
- Trying to reduce startup time for custom built setups
- wants to work with the Bluesky folks
- Would be nice to have napari on the web, or something similar
- Jacopo: ideally would be nice to have NapariModel as a server and web frameworks like FastAPI and/or others to allow custom clients to connect to;
- making a napari plugin, and wants to also do a separation of Model and Viewer, would be useful to have a separation of the Model layer with the View layer
- Where is the rendering done? Grzegorz, its done with Qt using Vispy and OpenGL
- Jacopo would need the Qt to be swappable with some other frontend
- Grzegorz -- this is part of our roadmap to enable web based renderings
- Jacopo treats napari as a plugin in and of itself
- Grezgorz brings up the app-model migration process. Opens doors to remote-control of napari. Because things are defined by actions, then the server can communicate through these actions
- Jacopo discussed make a NapariModel to connect things with RedSun
- Tim apologizes its very hard to take notes here because its very Computer Science and Engineering focused discussion and its hard for me to follow -- lots of discussion about Model-View-Controller, Performers, etc? Maybe Presenters? lol sorry. I think the important part is that its MVP vs MVC
- Grzegorz: `viewer` inherits from `ViewerModel` (could be used with any backend)
- otherwise things live in `window`
- VisPy is specialized for 3D rendering
- for us VisPy is for OpenGL binding (this makes "two parts" of the view)
- ideally the View is just a passive renderer
- Qt is the Controller in our model
- trying to make some kind of bypass (I'm a bit lost again)
- Previously worked in the automotive industry?? Cool. he says this is similar to what he's doing now with microscopes
- Jacopo could help improve napari because he has this experience with an external napari usage
- https://github.com/redsun-acquisition/redsun-mimir <- uses napari externally, not just as a plugin
- imswitch already integrated napari externally already
- https://github.com/ImSwitch/ImSwitch
- Jacopo
- For my project I want to treat napari as a plugin within a larger Qt application that is composed by multiple software components imported as plugins and combined together.
- My project relies on the [Model-View-Presenter (MVP)](https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93presenter) architecture; this has been successfully deployed initially by ImSwitch, and later on also by [navigate](https://github.com/TheDeanLab/navigate), an open-source software for controlling light sheet microscopes
- The core concept is to split the architecture into three layers:
- Model: the device interface layer; components within this layer implement the logic to communicate with devices in the form of "move a motor", "read a detector", etc.
- Presenter: the "application logic" layer; components within this layer can have different functionalities, including (but not limited to): exchange requests from the user interface to tell a device to perform an action; perform data processing on an incoming stream of acquired data points; encapsulate the logic of an experiment as a series of atomic, logical steps to execute; effectively it acts as a "middle man" between the user interface and the model layer, because it's in charge of what's called the "business logic" of the application
- View: the user interface layer; this is a "passive" layer in charge of encapsulating the Qt code (and in my specific case, via some magic, I want to support other kinds of frameworks as well)
- Most of the discussion with Grezgorz was related to where napari should "sit" within these 3 layers; in particular, given the current state of the art, napari could effectively be "split" in two: the model part (ViewerModel) and the viewer part (the whole Qt infrastructure); but normally this isn't done because napari is often used as a whole application rather than a single component.
- Currently, Grezgorz and me are the only one either doing or trying to do this approach (I'm in the latter case), and my curiosity was on where (within the 3 layers described above) the ViewerModel and the related Qt logic of napari should sit
- Even further, I was wondering if it could be possible to split the rendering logic of the model (which is either embedded in NapariModel or in the Qt side) of Vispy/OpenGL, in order to perfectly encapsulate napari into those 3 layers
- Brian shows off plugin
- Doing stacks of images
- for bigger data, we have limitations when stacking all the images together
- We plan to add a metadata viewer, and layer.metadata is a great place to stick all things
- Brian discusses appose-napari tests
- maybe use config files to create environments <- Tim thinks Curtis is already working on this
- https://github.com/conda-incubator/conda-pypi this is in the works from conda to ease integration between conda and pypi packages, which I believe the problem is about (dependencies etc if I recall from the original zulip discussion)
- Jacopo is hesistant to move to pixi because others may not adopt it
- Could benefit from the napari-plugin-manager backend selector
- https://github.com/napari/napari-plugin-manager/pull/171
- https://github.com/napari/napari-plugin-manager/pull/172
- these are being worked on

## 2025-09-24

Attendees: Lorenzo, Grzegorz, Brian, Ashley, Tim

### Topics

- Lorenzo: State of release 0.6.5
- Current tough PRs are the tiling of overlays, and the follow-up of colormaps
- Grzegorz would like to be able to have background box for colormaps and be able to shift the colorbar to the side of the image so it is not overlayed
- Tim will add these to the GUI/overlays tracking issue
- Codespell PR moved to 0.7.0 and try to get in early https://github.com/napari/napari/pull/7619
- napari-bootstrapper -- sparse deep learning training and prediction https://github.com/ucsdmanorlab/napari-bootstrapper
- appose - for talking between different environments
- https://github.com/apposed/appose-python#examples to see the nice and clean UI of how to use the environments!
- Nodar Gogoberienze (gnodar) and Curtis Reuden (ctrueden) were working diligently on this at CZI ITF
- They got napari talking to cellprofiler and visa versa. They also had napari talking to imagej (I think for Ilastik)
- Bilayers (from Cimini lab / Broad)-- define a schema for deep learning models and serve through various kinds of UIs
- currently set up I think is cellprofiler and jupyter notebooks and some online thing called gradio
- they containerize the environments, and then can serve reproducibly (because DL stuff is flaky)
- a richer schema than something like bioimage model zoo
- Grzegorz does have a UI that can be built from bioimage model zoo
- Tim shares about https://github.com/ndev-kit/ndev-settings/ as an example way of providing a schema to build a napari plugin UI, this is sort of an example of how bilayers may work in napari (and Tim has made Beth and Nodar aware)
- Grzegorz brings up that removing a plugin and having a central
- Grzegorz says it should use a single directory instead of a settings file, will be easiest for removal because if the plugin removes / changes schema than
- if upstreamed would want to use evented settings, like from psygnal
- we have some migration schema for napari settings, but Grzegorz
- Grzegorz brings up that py 3.13 might have issues with pydantic v1
- Strange CI occurrences... https://github.com/napari/napari/pull/8306 <- Grzegorz says it is his fault
- Brian asks about batch processing strategies, Tim and Grzegorz share a few principles that have been learned from users
- Checking types of files is valuable but...
- its more important to place outputs in subfolders so that users don't get lost in a giant slew of files
- Tim finds that printing to a small .txt file is very useful for logging the settings of the batch workflow and progress of the processing. In addition, print any errors to this file so that users can just send the log and as developer you get much better insight to support them. Often you can find things like dimension mismatches or kernel crash type info
- Also Tim didn't bring up, but should have, that batch processing is absoutely best with multi-threading

## 2025-09-10

Attendees: Grzegorz, Tim, Sai Manohar Thota

### Topics

- Going over a plane bug with Grzegorz
- Grzegorz goes over linking between Vispy
- Was able to fix by switching between planes, resulting in a resync
- We can't find the bug which triggers it
- Discuss Tim being confused
- Introductions after Sai joined
- Dr. Sai, postdoc at Baylor, metabolomics of Huntingdon's disease, now working on prostrate cancer
- EM for prostate cancer cells, how the number of vesicles change with different conditions (such as gene knockdowns)
- Grzegorz -- on core team for 2 years. working on plugins and such
- Sai's issue - interested in the size of vesicles in cryo-EM images
- Anaconda setup
- started 4 or 5 days back. have bioinformaticion that knows python
- tried to get help by reading on forums for the past few days
- next tried to have ChatGPT help generate code to solve the problem
- By Tim's eye, the code looks to be generated as if the images were fluoresence, which often takes a very different approach
- Tim gave a quick tour of napari-hub and napari plugins (especially to read mrc files)
- recommend deep learning because these are very challenging images due to being EM and identifying objects that are a particular organelle type
- Showed how to manually paint layers with napari
- Grzegorz and Tim highly recommended and walked through making a post on image.sc to get the best feedback, and recommended linking to Zulip
- Tried to give practical expectations on how challenging this project could be

## 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