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)
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)
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)
… 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.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 that3.
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.