owned this note   changed 8 days ago  
Linked with GitHub

napari Eurasia meetings (9am CET)

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.

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! We have meetings centered on the Atlantic, Indian, and Pacific oceans!

Agenda

2025-06-23

Attendees

  • Draga, Juan, Wouter-Michiel, Grzegorz

Topics

  • [Draga] Quick hub-lite updates
    • Switchover will be next week
    • quick review of open issues/current state
    • will update footer to highlight the napari team bit as current footer kinda still highlights CZI
    • Look at scancode for license parsing
  • 7870 multiviewport PR needs review
    • Grzegorz & Juan will try to review
  • bermuda potential fix for issue with duplicated points in 3D:
    • preliminary pr: https://github.com/napari/bermuda/pull/58
    • failure when rectangle is viewed orthogonally with error message about points being colinear
    • error thrown and edge not rendered in 2D
    • fix is to ignore the colinear polygons when finding edges that need to be deduplicated when splitting a polygon, and then add them back in after the splitting, before face triangulation
    • the other bug is that in 3D we weren't deduplicating points at all and the data contained some points in a line. The PR also fixes this
    • Fix seems ok, Grzegorz will update PR with docstrings etc.

2025-06-11

Attendees

  • Wouter-Michiel, Grzegorz, Juan, Draga, Lorenzo

Topics

  • Grid-mode: when annotating a layer in grid mode, annotations can appear on layers your cursor isn't hovering over
    • this could be useful in some cases, but it could also be confusing for users
    • Peter's suggestion was that if the layer is not under the cursor, nothing should happen
    • WM suggests it would be good to add a cursor overlay as well so that you get multiple "copies" of the cursor shown across each layer that is part of the view so that it's obvious when you click what your annotation will be
    • that way even if you were clicking on the annotation layer, you could still see where your cursor is sitting on the actual data
    • such an overlay would be relatively easy to implement with the current state, so we should do that in a separate PR
    • we'll turn off the current behaviour in the PR so it's not confusing for users, and open a new PR adding the cursor overlay
  • Grid-mode: making grid strides for overlap a percentage of the layer extent
    • it's not clear how that would work because it changes as you zoom in and out
    • currently the strides are in canvas pixels
    • maybe the "percentage" being referred to is based on cavas size rather than layer extent?
    • need more clarity about what the user story is and what the desired visualization is so that we can understand how to make that happen
    • Lorenzo will write up another message on the PR to clarify
  • Lorenzo: NAP-9 updates (multicanvas/multiview)
    • still some points of discussion left on the NAP where there is disagreement or we haven't settled yet
    • the NAP has been updated with a few specific points worth bringing up as general points
      • one is the naming conventions: currently using view instead of viewport as it's shorter but equally expressive. The good thing about using view is that it conveys both canvas and camera position
      • one point of contention: use of independent layerlists or not. Lorenzo had pushed for independent lists while Ashley had pushed for a global common list where each view would only have control over visibility of the layers in the current view
        • quite a bit of discussion could happen there. Ultimately not a huge difference in implementation, more of a UX question
        • JNI: we need to pull slicing out of the layer. If we don't do that, then we need separate layerlists to slice
        • LG: in a way yes, but the NAP is framed such that removing slicing from the layers is necessary as one of the early steps. The async slicing does a lot of that work, but still quite a bit remaining because we rely on the layer and we communicate with the layer to get information about slicing state. This will need to be ripped out and put wherever the new slicing state lists. If we do a global layerlist, we can't even begin without removing slicing. If we do it with independent layerlists, we could step our way to it by first disallowing shared layers in multiple views. Ultimately the result will be the same, but with separate layerlists the implementation might be a bit easier.
        • JNI: could also be useful for showing subsequent time points in multiple views.
        • LG: yeah orthoviews would also need separate dims. Should come as a default view alongside other common views
        • GB: removing the slicing state from layers could be considerably more effort than just sitting down and rewriting layers from scratch, because the LayerModels have been around for so long that the decoupling will take a long time and a lot of surgery without guaranteeing a better outcome and more maintainable code at the end
        • data transforms API -> https://github.com/napari/napari/issues/7921
        • LG: the NAP highlights in a table what attributes and methods of layer edit/touch/query slicing information and it's a LOT
        • There's a fair bit of consensus that we would likely be better off rewriting layer models from scratch before looking at multicanvas, so that we are not left in an in-between state with removing slicing from layers
        • still worth having the discussion on multicanvas and moving closer to approving the design plan, even if the "final" implementation doesn't happen before the layer slicing
        • a lot of the multicanvas work can actually be done to the point we have a "switchable" canvas without touching the remaining machinery
        • TLDR: please everyone read the NAP and continue the discussion so we can move closer to accepting
    • GUI still remains to be decided but there was a lot of discussion and design work done by Isabela on this. The NAP also lists a couple of ideas of QT objects that could be used to display the canvases, but with DockWidget we get a lot of stuff for free
      • do we want to take into account future GUI libraries/decoupling from QT as part of this discussion?
      • LG: we should consider it but it's probably not something we need to decide right now. We don't necessarily need to strive to have identical behaviour/look in napari "native" vs. napari web. We should have the displays be as close as possible, but it's not necessarily a problem to have e.g. a grid view in napari native vs. only supporting tabbed views on the web
      • there's probably also a situation where users will want a single dims slider across all canvas, when all the different views have the same dims
  • Grzegorz: Additional actions triggered by plugin readers on data.
    • lots of situations where users are using some tricky code to add a widget to the viewer as they read the layer
    • also lots of readers that cannot make use of spatial information either because it's not there or because it's not coded
    • maybe we should allow to define some actions that should be run after adding a layer to the layerlist - could be defined in the yaml file or the function could return a longer tuple that includes paramterised function calls/tasks
    • some of the really common tasks we could chain ourselves
    • for example we could inject our guessing logic into plugins that return layerdatatuple with no spatial information, but it might be that the plugin was planning to do something else with that layer e.g. connect some callback or open some widget
    • JNI: I like where this is going. Modifying the yaml would probably be a bigger lift maybe?
    • DDP: I don't think modifying the return value of the reader spec is fundamentally a different lift than modifying the yaml. I like the idea of keeping it in the yaml because it's declarative and allows us to forewarn the user about what will happen when they choose a reader
    • Looking at something similar to a "pre-hook" and "post-hook" for readers. A "pre-hook" could be used for getting further information from the user before reading, while a "post-hook" could run after the layers are added e.g. pre-read hook, pre-add hook, post-add hook
      • "napari-get-reader" for example would be the function tasked with determining what information is required from the user, then we could run the "mid-hook" by taking information from "napari-get-reader", then we run the "reading" function, then we run the "post-hook"
        • would also allow us to move reading fully to a separate thread as we can "yield" between the different steps
    • Grzegorz has enough now to look at opening an issue for discussion

Action items

2025-05-28

Attendees

  • Draga, Lorenzo, Grzegorz, Juan

Topics

  • Draga: npe2api name normalization confusion
    • decision was that we always store and key by normalized name, and all files e.g. manifest files are named by the normalized name, and the API is accessed via its normalized name
    • however, in hub-lite, we organize a redirect similar to pypi so that whatever name the user enters in the url, they get served the normalize-named HTML
  • Grzegorz: Units
    • Pasting spatial information: https://github.com/napari/napari/pull/7973
      • if you have mix of dimensionality layers, when we go from higher D to lower D, we cull spatial information
      • but when we go from higher D to lower D, we don't pad with default values and this is inconsistent
      • 7973 implements this. For padding it's pretty simple, but need to double check cutting down the shear transform matrix
    • Use units for rendering https://github.com/napari/napari/pull/7889
      • units and scale work in tandem to decide layer alignment and extent
      • e.g. if one layer uses micrometers with scale and another uses nanometers with scale, the extent is computed in nanometers
      • we use the smallest unit for extent as that allows us to multiple larger units rather than divide, which loses precision
      • some issues currently with e.g. points layer, but will be resolved
      • what happens with readers that don't declare/use units?
        • could add a manifest spec line that a reader/widget does not parse/return spatial information
        • those which declare they don't return spatial information would opt into layer spatial information being inferred/computed by napari
        • will open an issue in napari/napari to discuss what options we have for both defining formats for points/shapes etc. that store spatial information AND for extending manifest spec to allow plugins to be more explicit in their handling of spatial information
    • Allow declare readers to not read units.
  • Grzegorz: get acess to docked widgets: https://github.com/napari/napari/pull/7965
    • we don't want to return a copy because it won't stay up to date
    • we need to return something like a "view" that doesn't allow assignment but still gets updated when the dock widgets change in the viewer
  • Lorenzo: QT thick slicing controls
    • we can make it two sliders, side by side, that pop out from right-click the dims scrubbing toggle. Both sliders extend "away" from the center
    • extents should be bigger than the total frames in the dims so that you can "see everything"
    • we add a checkbox that "locks" the sliders so that dragging either one also drags the other to have easy access to symmetrical thick slices

2025-05-14

Attendees

  • Lorenzo, Grzegorz, Wouter-Michiel, Draga, Juan

Topics

  • Juan: GloBIAS hackathon announcement
    • current deadline is May 15th for registration so folks should register and potentially just cancel later if needed
    • check the box that says you're a hackathon contributor
  • WM: vispy spacing PR
    • what should we do if we have someone using two viewboxes, both with position 0,0 and one with colspan 1 and one with colspan 2
    • you probably want spacing in between the single-span columns, but not at the edges, so that the edges of the at-border single-span viewbox overlap with the edge of the souble-span viewbox
  • LG: other than a couple of tweaks the new overlay grid mode is ready
    • if merged it would replace the current grid mode
    • JNI: should we replace it…
    • LG: yeah, the way it's currently done with translations and stuff is basically a hack. People might be surprised at first, but I think they'll find that this is what they wanted in the first place
    • right now grid mode is essentially an additional translation on each layer's transform that tells it where it needs to sit in the grid (with a bunch of tricks to handle extents, and making things the same size, and spacing etc.)
    • means in the scene the layer is physically moved elsewhere
    • then we have stuff in the layer system that "undoes" this translation to give you correct information when you're hovering
    • now each viewbox is essentially a smaller copy of the canvas where only one of the layers is visible
    • if anyone was actually relying on this janky translation transform, that will break
    • also right now grid mode is broken in 3D, whereas with new mode you can fully operate in 3D and the zoom/hovering etc. is all synced so you if you rotate one layer it rotates the rest in tandem, if you zoom it zooms in on all of them, if you pick, you can pick on any layer etc.
  • Creating email addressed with …@napari.org (in theory)
    • the workflow would be you login to info@napari.org with the 1password details all core devs have access to (yell out if you don't), and then from the org admin panel you create your blah@napari.org
    • ok wait maybe not
  • Making zoom meetings with numfocus account?
    • login to info@napari.org and then go to zoom.us and use "login with google" option
    • whatever API thing needs enabling to allow you to create zoom meetings from other software e.g. calendar is also enabled
  • LG: trio of colormap overlay PRs
    • first one #7835 is moving the overlay machinery from vispy layer to the vispy canvas
      • used in several other PRs including gridlines
      • so needs to be merged first to clean up diffs
    • so vispy canvas is hub for generating visuals and putting them where they need to be
    • still no canvas model yet
    • tiling PR #7836
      • some UI issues that don't have easy solution so need to make some decisions there
      • can make it totally non customizable for now as long as we don't back ourselves into a corner
      • only thing that could be worth customizing is the direction of tiling, because there's no obvious way to do it
    • #7827
      • some discussion still needed
      • viz based on plotly
      • ticks are using spacing based on "nice round number", however the grid lines are not on the tick spots because they are in tens of units of the world space i.e. if we have layer from 0-12, thick lines would be at 10 and small lines at 1, if you zoom in you go to 0.1 etc. In this example if you request 10 tick marks, you'll probably get them at 1s, but if you ask for 4 you'll probably get 3, 6, 9, 12
        • Peter reckons not intuitive
        • done that way because the grid is a vispy "impostor" image that is designed that way on purpose, so if we want to align to the tick marks then the divisions in between are going to be at ~0.25 from each other so LG thinks that would be more confusing than having the tick marks offset
        • JNI wants labels on the lines
        • long term would be good if we can configure this very finely e.g. like in matplotlib
        • would also be cool if more/fewer ticks can appear/disappear as you zoom in/out
  • Grzegorz: Lasso RDP bug is worse than really understood, because it can corrupt data on the layer completely, which could lose hours of work. Better to hide the drawing because at least then user can e.g. switch to polygon, save and reload, whatever. Actually they can update the RDP epsilon setting.
  • Image Not Showing Possible Reasons
    • The image file may be corrupted
    • The server hosting the image is unavailable
    • The image path is incorrect
    • The image format is not supported
    Learn More →
    Add agenda items here!
    Image Not Showing Possible Reasons
    • The image file may be corrupted
    • The server hosting the image is unavailable
    • The image path is incorrect
    • The image format is not supported
    Learn More →

Action items:

  • Juan: figure out how to allow folks to create new @napari.org email addresses
Select a repo