napari: a multi-dimensional image viewer for Python
Bibliographic record
Abstract
napari 0.6.0 Wed, Apr 30, 2025 🚧 These notes are under construction while in pre-release 🚧 We're happy to announce the release of napari 0.6.0! The right-handed release! This release features major changes so read on to see how they might affect you! napari is a fast, interactive, multi-dimensional image viewer for Python. It's designed for exploring, annotating, and analyzing multi-dimensional images. It's built on Qt (for the GUI), VisPy (for performant GPU-based rendering), and the scientific Python stack (NumPy, SciPy, and friends). For more information, examples, and documentation, please visit our website: https://napari.org/ Highlights Summary Updated viewer handedness ✋ Command palette 🎨 Display polygons with holes ⛳️ Transition to npe2 plugin engine by default 🔌 Many other GUI improvements 🖥️ Updated viewer handedness ✋ So. Funny story. 😅 For (checks notes) 5 years or so, napari has had a 3D view, and for those 5 years, for almost all datasets, that view has been a mirror image of the 3D object they were trying to represent. Any biologists among you might have noticed that loading 3D molecular coordinates of DNA would result in a left-handed helix, while anatomists among you might have been surprised by how many of your samples suffered from situs inversus totalis! By and large, many things that people care about work exactly the same in the mirror world — volume measurements, forces, tracking, speed, ... — so this bug has gone mostly unnoticed, or noticed and shrugged off and unfixed for all this time. But it's important for some things! Your heart is on the left side of your body, but the right side of your mirror image's. This can be critical, for example, when using software to plan surgery! Thankfully, we are not aware of any cases of napari being used in this way. 😅 napari uses zyx coordinates instead of xyz because it is the most natural way to work with NumPy arrays and the rest of the scientific Python imaging ecosystem. Flipping the axes in this way also changes the handedness of the space, unless you also flip the direction of one of the dimensions. The simplest way to illustrate this is this 3D model of a right shoe, which looks like this in previous versions of napari: and in 0.6.0, thanks to #7554: Most users won't notice. But if you were among the users that noticed and you implemented workarounds in your code (such as setting the z-scale to a negative number), now is a good time to undo the workarounds for newer versions of napari! If you run into any issues please get in touch on GitHub issues or on our Zulip chat room! On the user space, we now offer several options to orient the axes any way you like: Through the camera API: the Viewer.camera instance gains two new attributes: orientation, and orientation2d, which is just the last two dimensions of orientation. You can set the direction that the depth, vertical, and horizontal axes point to, respectively in that order, as follows (#7663): # 2D viewer.camera.orientation2d = ('up', 'right') # 3D viewer.camera.orientation = ('away', 'up', 'right') See an example of this in action in {ref}sphx_glr_gallery_xarray-latlon-timeseries.py. Through the UI: By right clicking on the dimension toggle in the viewer, and setting the axis orientations using the drop-down menus (#7686), which in 3D will further indicate whether the resulting coordinate frame is right-handed or left-handed (#7770): Through the startup settings: If you want to use a specific axis orientation consistently, you can set the default orientation on startup by changing the relevant settings (#7787: To restore the orientation from napari 0.5.6 and earlier, change the Depth axis setting to "away" (i.e. depth axis points away from you). Command palette 🎨 Tired of mousing around? Thanks to #5483, napari gains a command palette! Press {kbd}Ctrl/Command+Shift+P and start typing the name of the action you want to use, and press {kbd}Enter when you've highlighted it. It even works with plugins! This is the culmination of many months of work porting napari's actions to Talley Lambert's app-model. 🥳 There's still lots of work to be done here, but in the meantime, give it a try! We on the team have found it very hard to go back to using napari without the palette! Feature improvements to Shapes layers ⛳️ ⚠️ When using numba for triangulation, some shapes will still not be drawn correctly, due to a bug in VisPy. We recommend installing bermuda, our new fast triangulation package, for the best performance. ⚠️ Finally, napari Shapes layers can now display polygons with holes in them, which starts to open it up for use with mapping data, among other things! (#7566, #6654]) Implementing this feature also eliminated a lot of bugs in our polygon drawing code, which could cause crashes. If you've had issues with Shapes layers before, now might be a good time to give them another try! As part of this work, napari gained the ability to select between different backends for triangulation, which means breaking up polygons into collections of triangles, which is what GPUs are good at drawing. (#7747) To use the new backends, install the relevant package (for example, bermuda, partsegcore-compiled-backend, or numba), then go to Settings > Experimental > triangulation backend. (If you use napari[all], you will have bermuda installed and it will be used automatically, as the default option is "fastest available".) Transition to npe2 plugin engine 🔌 npe2 was introduced over four years ago, with napari 0.4.12. npe2 has paved the way for new plugin functionality, such as adding menu items and the command palette. We are now beginning the process of deprecating npe1 (napari-plugin-engine) plugins, which we need to do to continue to improve npe2 functionality, for example in file readers, which is currently very entangled with npe1 code. To aid this migration, npe1 plugins will now be automatically converted to npe2 by default. This may break some features if the plugins relied on import-time behavior. (#7627) During the 0.6.x series, if some plugin functionality is broken by the automatic conversion, you can turn off this conversion in the plugin preferences. However, the option to not convert npe1 plugins will be removed in 0.7.0, and npe1 plugins will only work through automatic conversion. We anticipate 0.7.0 will be released in the second half of 2025. If you encounter conversion issues in a plugin you rely on, please contact the plugin authors to encourage them to migrate their plugin to the npe2 system. For more details on this change and how it affects plugins, see the detailed guide. If you are a plugin author and your plugin is not yet npe2-compatible, please see our npe2 migration guide, and, if you encounter any issues, get in touch in our Plugins Zulip chat channel or by coming to one of our community meetings. GUI improvements 🖥️ You'll notice the main napari GUI is subtly (or not so subtly) different in 0.6.0. Here are some of the improvements: Buttons now have an indicator to show whether they contain an extra menu when right-clicking. (#7556) The button to change between 2D and 3D views much more clearly shows what it does. (#7608) … And it has an extra menu with lots of options to control the camera! (#7626) You can now add a bit of spacing between layers in grid mode (and control it in the grid mode right-click menu!) (#7597) The colormap indicator in image layers is now a button, allowing you to create a linear colormap with any color! (#7600) If you select multiple layers in the layer list, you can now see the status display of all the selected layers in the status bar (#7673) If you switch from 2D to 3D view and back again, your 3D viewing angle will be preserved (#7765) Notice some weird behavior? Our new log handler and viewer might help! Access it with Help > Show logs. (#6900) Other stuff For developers: napari now depends on Python 3.10+ (#7603 and Pydantic v2.2 (#7589). We've supported both pydantic 1 and 2 since 0.4.19, but we're now ready to take advantage of performance and API improvements in Pydantic 2. If your library depends on Pydantic 1.x, now would be a good time to upgrade, or it will not be compatible with napari going forward. If you were dreading 0.6.0 because you were relying on _qt_viewer features, worry not: we have again postponed that deprecation while we add the required APIs. 😅 (#7730) Also, if you've been wanting to contribute that doc fix but found the process daunting, it's now easier than ever, because our default documentation preview build is now much faster! You can propose changes from the GitHub UI and see the rendered results in only two minutes! (napari/docs#669) New Features Implement command palette widget (#5483) Add a custom log handler and GUI viewer with filters (#6900) Add Grid Mode Spacing to change distance between layers (#7597) Enable creation of custom linear colormaps in layer controls (#7600) Add API to Camera model to flip axes (#7663) Show layer status for all visible layers (#7673) Expose new camera orientation API in GUI in ndisplay popup widget (#7686) Improvements Fix issues displaying polygons with holes in Shapes (#6654) Add numba warmup step when creating empty Shapes Layer (#7541) Add Image Border / Bounding Box Gallery Examples for both 2D and 3D (#7546) Add right-click indicator to 3D, Roll, Grid, and Square push buttons (#7556) Change naming of 'pan/zoom' mode to 'Move camera' to clarify functionality differences in 2D and 3D (#7569) ENH: adjust layer coordinates in status by _translate_grid (#7584) Add right click indicator to playback icons (#7590) Change ndisplay button to toggle-like to increase discoverability (#7608) [UI] Add Command Palette to the welcome screen (#7613) Fix layout issue in image/surface controls (#7618) Expose additional Camera parameters in GUI with 3D popup widget (#7626) Add 'Extend wit
Fetched live from OpenAlex and de-inverted. Abstracts are not stored in this database: the inverted indexes are 8.6 GB of the frame’s 9.3 GB of text, and the host has 13 GB free.
How this classification was reachedexpand
Full frame machine prediction
Teacher imitationNot calibrated prevalence, not ground truth. Human validation pending. The Gemma side is a direct model label for every work in the frame, read from the title-only record. The Codex side is a classifier learned from the 10,348 direct Codex labels and calibrated to design-weighted sample rates; fields without enough sample support carry no Codex call. Candidate is the union of the two sides; consensus is their intersection. These outputs are machine_predicted_unvalidated and are not human labels.
Distilled classifier scores by category (both heads)
| Category | Codex | Gemma |
|---|---|---|
| Metaresearch | 0.001 | 0.004 |
| Meta-epidemiology (narrow) | 0.002 | 0.002 |
| Meta-epidemiology (broad) | 0.001 | 0.002 |
| Bibliometrics | 0.002 | 0.001 |
| Science and technology studies | 0.001 | 0.001 |
| Scholarly communication | 0.004 | 0.005 |
| Open science | 0.005 | 0.004 |
| Research integrity | 0.001 | 0.004 |
| Insufficient payload (model declined to judge) | 0.322 | 0.268 |
Machine scores (provisional)
The two teacher heads of the student model, read on this work. A score orders the frame for review; it never asserts a category, and the validation status ships verbatim with every row.
Baseline scores from an immature model (maturity gate not passed, 7 training rounds). Scores rank; they never assert a category.
score_only:v0-immature-baseline · verbatim from the scoring run: score_only means the number may rank works, and no category label ships from itClassification
machine, unvalidatedMachine predicted; a candidate call from one source (direct Gemma or distilled Codex), not a consensus.
How this classification was reached, model by model and score by score, is at the end of the page under "How this classification was reached".