# napari community meetings (Pacific)

- [Zoom Link](https://numfocus-org.zoom.us/j/89631373371?pwd=iSmpAe0fJzAoaFlcKalarZgPeRCXWw.1)
- [This HackMD](https://hackmd.io/@napari/community-pacific/edit) -- Previous HackMD
- [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!

## 2026-02-05/06

Attendees: Yohsuke, Juan, Carlos, Draga, Tim, Sesan

### Topics

- Carlos: getting back to napari-metadata
- been working on getting napari-metadata on conda-forge
- Jaime reviewed the PR and now it's out
- we'll update packaging requirements so we can get a bundle build out
- napari/packaging#342
- Sesan: back after a while!
- PR is basically ready to go, after many roundabout issues!
- will be merged today or tomorrow
- Yohsuke: selected labels event
- Lorenzo suggested we connect to the psygnal selection event rather than our evented model attribute
- however the callback we want to connect was previously receiving a vispy event, not a psygnal event
- JNI: can we make a new callback that calls the old callback?
- YF: we were using event.source which used to hold the layer that emitted the event. We need to know whether `on_colormap_change` is called by the selected data event
- JNI: I think it's ok to check the event type to see if it's a psygnal or a tuple, and determine off that. Want a more detailed comment
- JNI: new idea. You change colormap shader when selection changes AND show selected is on. Need to connect selection to on colormap change and then decide if you need to change it. Instead, in `on_selected_label_changed`, if `show_selected_label` is on, then call `on_colormap_changed` directly.
- Draga: brief release update, hoping for an alpha tonight
- Carlos:
- working on splines, increasing the number of points in the spline and increasing the area of it
- some issue with the edge connection between the different splines
- would be great to have a bug report, ideally with minimal button interactions

### Action items

- JNI: Add to docs contributor guide: how to use datasets from Zenodo, since we can't use them directly, we need to upload them to our GDrive (and/or Cloudflare)
- the script for pulling down example data is [here](https://github.com/napari/napari/pull/8051/changes#diff-1c984d69c3cb4302a8827caebb517350e2bcb0a200b50b559fb2f45821d4c38aR12)
- note I've linked to a PR, because that's where I add the comments on how to do it

## 2026-01-22/23

Attendees: Draga, Juan, Yohsuke, Carlos

### Topics

- [Yohsuke] PR for selected_labels https://github.com/napari/napari/pull/8405 is (I hope) ready. I was playing with the events but finally decided to merge `events.selected_label` and `events.selected_labels` into `events.selected_labels`. I started to work on the actual dispaly and I would like to discuss shader implementation. (I noticed Aroz was using `image` layer for his purpose, which perfectly makes sense). https://github.com/yfukai/napari/blob/191205293931073441f8893c2efe8ee94a52baca/src/napari/_vispy/layers/labels.py#L45-L62 (current shader impl).
- Goal of the PR is to work towards allowing multiple labels to be selected, rather than single one.
- This PR just updates the `selected_label` property to `selected_labels`, but keeps a private `_selected_label` property
- `selected_label` event needs to be deprecated, using a WarningEmitter
- https://github.com/napari/napari/pull/5701/files#diff-ae7753430cbb6fe9e6dc532f409eed7d2ee7fe362347f8309cbdc4e349bd6063R379
- only updating API, not updating the UI
- UI thoughts - we may want to decouple the "painting" label from selected labels, because once you can select multiple labels you may want to paint with any one of them
- next steps:
- add a modifier to the mouse click when in eye-dropper mode on labels to add labels to the selection
- update the "View selected label" checkbox so it shows all selected
- for displaying the labels, the concern is that using DirectColormap might be slow because we don't want to actually change the color, so we'd have to build a Direct map from the cyclic colormap, and it would also change the colormap mode of the layer
- hard to do this if the user already had a direct colormap, you don't want to override that
- let's try making a private attribute on the Cyclic colormap or on the labels layer that is creating a "Direct" colormap out of the existing selected labels
- YF thinks it might be better in shader
- but not clear how we can update the "$selection"
- [Yohsuke] Issue about border rendering in Labels layer https://github.com/napari/napari/issues/8582
- JNI: yeah this is very old code, so not surprised it's slow
- could potentially be done in a shader?
- or could offload into a separate thread so at least it doesn't block the GUI?
- Yohsuke will play with some ideas and see how it goes
- [Draga] Guillaume's docs PR constraints update
- https://github.com/napari/napari/pull/8581
- ideally would update constraints for only new packages
- the `compile_constraints.sh` script seems to only work for existing packages in constraints, so can't use it for new ones
- would be nice to have an `@napari-bot add new constraints` or some similar command, that adds only the new packages and doesn't transitively update their dependencies
- especially when CI is green with the new dependencies
- Draga will manually update the constraints for the new packages locally by running the script and then remove any unrelated changes
- Discussion on how affine would work in napari-metadata
- Carlos will also check on napari-tiff 62 to see how that meshes with napari-metadata
- https://github.com/napari/napari-tiff/pull/62

### Action Items

- Draga: update constraints manually for 8581
- Draga: make issue for new napari-bot constraints command

## 2026-01-08/09

Attendees: Carlos, Sesan, Tim

Topics:
- (Carlos suggestion) Discussion about metadata-plugin (No progress but getting back to work!) and interpolation in layers (\#1256, \#2345, \#5334, \#7099, \#7582) + path tool not in the howtos.
- Discussed for a long time splice interpolation and potentially how to expose it
- This is when Tim came into the meeting
- We talked about mimicing an implementation like other PolygonBase properties like edge_width, face_color
- Talk about Sesan's PR and what's holding it up
- Carlos will look into adding missing paths documentation to shapes docs
- Tim and Carlos had a long catch up about napari-metadata
- Tim ran a nice demo of it and its working great, including with plugins that read in lots of metadata
- Works with linked layers BEAUTIFULLY!
- We need to make sure we only fix blockers, not quirks for follow-ups
- We need unit tests
- We need to fix the GUI issues, with size policy stuff and having scrolls
- Carlos will make a running issue in napari-metadata with our to-dos so they don't all end up hidden later in the PR
- But this is really close to MVP! our goal is to ship first alpha by end of Jan 16th

### Notes

## 2025-12-11/12

Attendees: Tim, Draga, Yohsuke, Hiroki Kawai, Sesan

### Notes

- Hiroki is an AI researcher working with Ko Sugawara at LPixel
- worked with plugins before but hasn't contributed to main napari
- plugins for dataset annotation, training & inference
- working on 3D datasets so interested in integrating some tools for AI development and making 3D rendering more smooth
- mainly electron microscopy datasets
- wanting to segment mitochondria and other cell structures
- working with anisotropic data so #8043 would be a good starting point for contribution - adding examples
- #8241 could also be a good start - changing the default for attenuated mip
- want to have some discussion about what a good default value would be and then open a PR!
- Tim happy to pair
- [Updating the image plane rendering example would nice](https://napari.org/stable/gallery/3Dimage_plane_rendering.html#sphx-glr-gallery-3dimage-plane-rendering-py) --currently its generated data and actually hard to visualize how the planes are supposed to work
- Yoshuke: #8405 Updating `selected_label` to `selected_labels`
- clarified the function of `colormap.selection`
- otherwise Yohsuke thinks PR is ready for a first pass at review
- will mark as ready for review
- labels contour mode is very slow with large images being loaded async
- contour mode does work, but UI freezes and is not as smooth as just browsing the image
- Yohsuke will open an issue
- Sesan: cell tracking example
- constraints need updating because of the additional gallery dependencies
- Tim updating them live!
- Tracks layer data
- currently the data is an array whose axes are track-id, t, (z), y, x
- a lot of folks are actually starting with a dataframe, and have to do the ordering themselves
- maybe it makes sense to pass a dataframe and an ordered list of columns, and napari creates the array for you
- underlying data structure is still the array
- Sesan will open an issue

### Action Items:

Tim: Make a post in community meeting about testing attenuated MIP default change. Consider next step --> asking for feedback in general? Pair and make PR?
Sesan: open issue about Tracks layer taking a dataframe
Yohsuke: open issue about label contours being slow on

## 2025-11-27/28

Attendees: Tim, Draga, Carlos, Carolyn

### Notes

- Carlos & napari-metadata
- some git fun
- demo of how things are going
- very nice dropdown, WHICH CAN BE BEAUTIFULLY DRAGGED TO THE TOP/HORIZONTAL AND ARRANGES BEAUTIFULLY
- played a bit with scrollable container but needs more attention, was being screwy
- inheriting metadata
- carlos/juan considers that inheritance could be a separate widget
- tim/draga encourage, for now, that the current widget setup be remained
- consider a "tooltip" that says "checked properties are inherited from the inheritance lanyer" <- put this in the "Axes Inheritance" widget (which could be renamed to "Inheritance Widget")
- "Set Current Layer" -> change to dropdown of layers
- "Apply" button -> "Inherit Properties to Selected Layer(s)" button
- inheritance of "batch" style, should it be a separate widget, or should it be the "shared" list aka the layer list. Tim has experience with both styles, and found that users find the experience of using the layer list to be more intuitive compared to
- consensus to rip out reader and writer
- consensus to rip out the sample data
- will need to test on multi-scale data
- napari should push towards scrollable widget container area
- chatting with Carolyn about her work on osteoarthritis
- repository the osteoarthritis initiative with clinical data from a bunch of sources
- mris, cts, xray + clinical data like questionnaires, diagnostic, etc.
- https://nda.nih.gov/oai
### Actions

Carlos: make PR for napari-metadata
Tim: start by ripping out readers and writers

## 2025-11-13/14

Attendees: Juan, Tim, Yohsuke, Sesan

### General
Yohsuke - I've been mainly working on [tracksdata](https://github.com/royerlab/tracksdata) and my track correction software (with some deadlines, almost done.)

Current plan:
- Dec.-Jan.? Labels layer with multiple selection
- Feb.-? Graphs layer revival
- Hiroki Kawai may join from Nov. 28?

### Labels layer with multiple selections
PR merged for psygnal (making Selection reversible).
https://github.com/pyapp-kit/psygnal/pull/395

https://github.com/napari/napari/pull/8405
- Test running
- Do not add `selected_labels` to the vispy event
- We want to make `selected_label` into `active_label` and make a deprecation
- What is the purpose of `self.events.add()`? This is a way for people to know what the event contributions are. But these are VisPy events. This pattern is `layer.events.selected_labels.connect()`
- In Psygnal, the object itself is evented. So you can do `layer.selected_labels.connect()`

https://github.com/yfukai/napari/blob/99bdf474f60196e04426cb91f6237e1e7d6b1e87/src/napari/layers/labels/labels.py#L718-L725

    @property
    def selected_label(self):
        """int: Index of selected label."""
        # TODO update the implementation by next(reversed(self._selected_data))
        # once https://github.com/pyapp-kit/psygnal/pull/395 is accepted
        # There is no length check here because self._selected_labels
        # always contains at least one label.
        return list(self._selected_labels)[-1]

Question about events (expose all objects?)
Not sure how I can touch here
https://github.com/yfukai/napari/blob/99bdf474f60196e04426cb91f6237e1e7d6b1e87/src/napari/layers/labels/labels.py#L375-L391

        self.events.add(
            brush_shape=Event,
            brush_size=Event,
            colormap=Event,
            contiguous=Event,
            contour=Event,
            features=Event,
            iso_gradient_mode=Event,
            labels_update=Event,
            n_edit_dimensions=Event,
            paint=Event,
            preserve_labels=Event,
            properties=Event,
            selected_label=Event,
            selected_labels=Event,
            show_selected_label=Event,
        )

Shall we expose both of selected_label and selected_labels?
Maybe yes, since some operations (e.g., deleting from the selection) will not change the selected_label (last component).

How can I emit a signal for selected_label when selected_labels changes? How can we test this?

Updating the rendering will be done in the next PR?

Possibly changing `selected_label` to `active_label`?

### Graph layer

Trying to understand what to do.
First milestone: A copy of the point layer that takes a NetworkX graph as input?

Lorenzo kindly explained about the difference b/w thick slice and "spilling" in the points layer
[#working-group-graph > Graph layer revival @ 💬](https://napari.zulipchat.com/#narrow/channel/360030-working-group-graph/topic/Graph.20layer.20revival/near/555281984)

> > Caroline Malin-Mayor [said](https://napari.zulipchat.com/#narrow/channel/360030-working-group-graph/topic/Graph.20layer.20revival/near/553972154 "https://napari.zulipchat.com/#narrow/channel/360030-working-group-graph/topic/Graph.20layer.20revival/near/553972154"):
> Yohsuke T. Fukai [said](https://napari.zulipchat.com/#narrow/channel/360030-working-group-graph/topic/Graph.20layer.20revival/near/553281024 "https://napari.zulipchat.com/#narrow/channel/360030-working-group-graph/topic/Graph.20layer.20revival/near/553281024"):
> > > Also, I would appreciate it if anyone could let me know if it's possible to get the distance from the slicing plane for each point in the `Points` layer.
> > There is thick slicing capability built into napari (right click on the slider) so it must be possible to get that information
> These are two separate things in napari. Thick slicing depends on the Dims model which decides how thick the slice is, and then the data is projected based on layer parameters. However, we have the separate concept of "out of slice display", which both points and vectors use, which allows to display data that is not _exactly_ within the slice but just "passes through", with a resizing or fading mechanism to distinguish them from "fully in slice" data. It's a holdover from the past and it might be wise to remove it in favour of the former (by implementing a new points/vector projection mode that account for distance from the `Dims.point` and resizes accordingly). But in the meantime, the code [here](https://github.com/brisvag/napari/blob/9f639d8b46e788af9db8b5a14a267a1c5fad6785/src/napari/layers/points/_slice.py#L120-L139 "https://github.com/brisvag/napari/blob/9f639d8b46e788af9db8b5a14a267a1c5fad6785/src/napari/layers/points/_slice.py#L120-L139") might be useful to look into for how it works.

https://github.com/brisvag/napari/blob/9f639d8b46e788af9db8b5a14a267a1c5fad6785/src/napari/layers/points/_slice.py#L120-L139

- we need to review Sesan's PR https://github.com/napari/napari/pull/8051

## 2025-10-16/17

Attendees: Draga, Sesan, Tim, Juan, Carlos

- Carlos: uses napari regularly, used to work in Fiji, current PI prefers python, so shifting towards napari
- haven't used it for publication yet but writing plugins for their own data
- using npe2
- knows pyqt!
- JNI: one of the things we really want to do is add a histogram, would involve some guts
- Sesan: doing well, working on tracks
- idea is to load ground truth and silver truth, and then compare tracks
- debugging script to load & solve tracks with trackastra
- Sesan will push debugged script to his PR
- We will look to see if we can minimize the downloading/extracting code so it doesn't distract from the tracking aspect

## 2025-10-02/03

Attendees: Draga, Juan, Tim, Sesan, Peter

### Topics

- Version switcher fixing...
- Juan suggests adding pre-commit hook to check valid json
- fixed it for released docs, but the current issue remains i.e. if you deploy malformed version-switcher URL you can't detect it and you merge it which breaks your build which means you can't then build & deploy the fix
- Need Melissa to check our logic, but should have the fix done
- since we're not doing unversioned pages anymore we should just go back to the original conf.py config for sphinx
- separate site for unversioned?
- more of a headache with pulling docs from multiple places
- could do the numpy approach
- needs to be a dedicated project for someone rather than getting it done over time in small PRs
- Draga talks about npe2 / hub badges for plugins. Need to switch things to redirect old urls to the new url
- will pair with Grzegorz at some stage
- `view_*` deprecation https://github.com/napari/napari/issues/7047
- make an issue in general about deprecation
- camera angles https://github.com/napari/napari/pull/8281
- needs to be merged EARLY
- communicate EARLY about the change
- Tim ping Alister
- Tim still confused on pyqt6 status for 0.7
- https://github.com/conda-forge/qt-main-feedstock/issues/349
- We missed `aiohttp` going into packaging (for remote zarr reading)
- we should milestone in `packaging` to help guide release managers
- figure out a way to help point the `pyproject.toml` updates to a certain napari milestone
- Dropping 3.10, adding 3.14?
- Sesan not a lot of time to work on cell tracking challenge example, but getting back to it now

## 2025-09-18/19

Attendees:

### Topics

- Add your topics here :)

## 2025-09-04/05

Attendees: Sesan, Tim, Draga

## Topics

- draga wrapped up Eureka prizes
- we need to make some kind of announcement -- who will do this?
- share the video especially!
- should also video some stuff at the hackathon to share out
- ndev-settings
- Tim originally made napari-ndev https://github.com/ndev-kit/napari-ndev
- plugin to help manage a bunch of different microscopy file types
- now relies on bio-io
- hope was to get batch analysis in napari without using code
- use GUI to make workflow and then run it
- utilities
- opening/saving files, correcting metadata
- converting files to a more usable format
- APOC
- machine learning part
- workflow
- create a workflow and run in batch
- measure
- a thorough regionprops-based measuring tool, allows you to batch measure stuff
- spits out a nice dataframe, which you can edit the format of within the GUI
- eventually want to use nyxus which should be faster and more thorough than skimage regionprops
- settings tab
- allows you to setup reading preferences, scene handling, export settings etc.
- settings tab pulled out into its own plugin: https://github.com/ndev-kit/ndev-settings
- settings file contains information that can be passed to create_widget from magicgui
- widgets get created directly from the yaml within each group
- Draga: thinks there could be a settings contribution, but from the napari-side manifest directly
- We would need to add a settings contribution, that points to a settings file or a schema for a settings file (a validator)
- Draga is thinking about the reader settings - and that reader can offer settings - potentially we can populate the reader settings with that dialog
- This means we can link logic where we know what plugin reads the file, we can ask / expect that writer to be
- This also intersects with the idea of profiles / schemas, etc. Where we customize napari on load for a use case. Like geospatial, or a particular plugin
- We can combine all this into a profile
- Splitting out settings group (like in ndev-settings) makes it really nice to find what each plugin contributes, and split it out
- this is a step towards richer plugin manifest
- cell-tracking example
- Sesan working with pytorch folks to work out the learning step of cellGNN
- goal is to have it working with data of different densities/time resolution etc.
- looked at trackastra and it worked pretty well, but needs fine-tuning
- Draga gives her thesis
- Where do we spend human time?
- On fine-tuning a model?
- Or on iterative method (whether modifying labels or writing scripts, etc)
- We have a choice to make
- Will fine-tuning work?
- How do we know the time spent vs quality?
- Draga focuses on a non-learning method that gives *reasonable* results, then have methods that *help/guide* the users inspect, correct, evaluation workflow that helps the user understand error and estimate time spent.
- The big challenge is estimating accuracy from sparse data
- Sesan: there is no God model. Architecture needs to be understood to really use effectively