napari: Inconsistent default size of points when creating a points layer using PointsData

🐛 Bug

The default size of points, when creating a layer using PointsData might be computed from the current size of the field of view (= image size * voxel size)

To Reproduce

import napari
import numpy as np

Assuming the field of view is big, points are hardly visible:

viewer = napari.Viewer()

viewer.add_image(np.zeros((1000,1000)))
viewer.add_points([(20, 20)])

napari.utils.nbscreenshot(viewer)

image

In case the field-of-view is smaller, points are super big:

viewer = napari.Viewer()

viewer.add_image(np.zeros((10,10)))
viewer.add_points([(5, 5)])

napari.utils.nbscreenshot(viewer)

image

Expected behavior

I’m not sure where internally those layers are built, but one could build in this line to make the points have a size of 1% of the field-of-view.

points_layer.size = np.asarray(viewer.dims.range).max() * 0.01

This sould make points have the same size in both cases demonstrated above. … as discussed here.

If you like the solution and can point me to the code where this might make sense in napari-core, I’m happy to send a PR.

Environment

  • Please copy and paste the information at napari info option in help menubar here:
napari: 0.4.15
Platform: Windows-10-10.0.19044-SP0
Python: 3.9.13 | packaged by conda-forge | (main, May 27 2022, 16:50:36) [MSC v.1929 64 bit (AMD64)]
Qt: 5.15.3
PyQt5: 5.15.4
NumPy: 1.22.4
SciPy: 1.8.1
Dask: 2022.6.0
VisPy: 0.9.6

OpenGL:
- GL version: 4.6.0 - Build 30.0.101.1029
- MAX_TEXTURE_SIZE: 16384

Screens:
- screen 1: resolution 1920x1200, scale 1.0

Plugins:
- PlatyMatch: 0.0.3
- RedLionfish: 0.5
- animation: 0.0.2
- clEsperanto: 0.18.0
- console: 0.0.4
- devbio_napari: 0.5.6
- napari-3d-ortho-viewer: 0.0.1
- napari-accelerated-pixel-and-object-classification: 0.8.1
- napari-assistant: 0.3.8
- napari-brightness-contrast: 0.1.7
- napari-clusters-plotter: 0.5.1
- napari-crop: 0.1.5
- napari-curtain: 0.1.1
- napari-folder-browser: 0.1.3
- napari-layer-details-display: 0.1.3
- napari-mouse-controls: 0.1.3
- napari-plot-profile: 0.2.1
- napari-plugin-search: 0.1.3
- napari-process-points-and-surfaces: 0.3.1
- napari-segment-blobs-and-things-with-membranes: 0.2.22
- napari-simpleitk-image-processing: 0.3.1
- napari-stress2: 0.0.15
- napari-tabu: 0.1.5
- napari-time-slicer: 0.4.6
- napari-tools-menu: 0.1.15
- napari-workflow-inspector: 0.2.2
- napari-workflow-optimizer: 0.1.4
- napari_skimage_regionprops1: 0.5.2
- napari_skimage_regionprops2: 0.5.2
- ome-types: 0.3.0
- scikit-image: 0.4.15
- svg: 0.1.6
- the-segmentation-game: 0.1.0
  • Any other relevant information:

Additional context

About this issue

  • Original URL
  • State: open
  • Created 2 years ago
  • Comments: 27 (20 by maintainers)

Most upvoted comments

… and it would be cool if napari-core would make sure that results of functions returning PointsData are visible to the user; ideally in a pleasing size neither half a pixel, nor half the screen.

I disagree, because of the points I made above about reproducibility and magic. I’d also like hear what @jni has to say, since he was interested in the experimental_canvas_size_limits discussion.

Because it was added as an experimental feature, and setting it to 0 would change nothing about the behaviour at the time. I’m open to changing the default, though I think in that case we should un-experimentalize it and document it, in case someone prefers their points to have a real absolute size.

The actual problem is that the points are too small in case of large images and too big in case of small images shown in the viewer.

Then this sounds like it’s exactly the use case for which experimental_canvas_size_limits was created 😃 Is there a reason why you don’t think this is the right approach for you in this case? As far as I can tell, absolute point sizes have no meaning in your use case, so this shouldn’t be an issue. My impression is that 3. is just too finnicky 😛

Will close for now, but anyone feel free to reopen if you think there is a way to do this better.