-
-
Notifications
You must be signed in to change notification settings - Fork 410
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add a sample_ray method to layers #2653
Comments
@sofroniewn , where is the best place to get caught up on the napari transform system? In particular, I would like to get the transformation between the screen coordinates (i.e., coordinates returned by the event.pos in the mouse event) and the data coordinates. |
This is awesome @kevinyamauchi! We've been trying to move cursor position information off the layer, so I'd prefer if this wasn't directly on the base layer, but instead was something that could be calculated with the layer. One option would be to add Given the ray in world coordinates each layer can map that back to make a ray in data coordinates
The key method to go from canvas coordinates (what you call screen above, but the origin is in the top left of the canvas) to world coordinates uses the function defined here napari/napari/_qt/qt_viewer.py Lines 661 to 684 in 097dca8
and updates the cursor here napari/napari/_qt/qt_viewer.py Lines 720 to 721 in 097dca8
I think you could also use/ adapt that method to make the ray and update That cursor position then gets added to the mouse event napari/napari/_qt/qt_viewer.py Lines 723 to 724 in 097dca8
And then inside each layer mouse function callback there is a line coordinates = layer.world_to_data(event.position) see
and you then have something like data_ray = layer.world_to_data(event.ray) How does this sound? |
Thank you, @sofroniewn ! This is super helpful. I agree that we should try to keep the cursor stuff off of the layers and I think the general approach you outlined looks good. I have a couple of follow up questions:
|
Yes, but "world coordinates" in napari are fully nD, I think we at places might say "worldslice coordinates" to mean the "scene coordinates"
Hmm that could be - i think in 2D some of this stuff might not matter / stuff might be equivalent so we didn't notice, but in 3D the differences might be more significant. My hope though is that we could keep changes localized to the |
馃殌 Feature
In support of 3D picking, I think it would be nice to add a method to the base layer that calculates end points of the ray going through the data volume from a point in the canvas in the direction of the view.
Motivation
This ray (
sample_ray
?) can be used for 3D picking or sampling/exploring data along the ray (e.g., plotting intensity, finding voxels with specific values)Pitch
We add a method to the base layer class that when given a point on the canvas (in canvas coordinates), finds the intersection between the ray cast from that point in the direction of the view with the axis-aligned bounding box of the data. In this context, "axis-aligned" means the bounding box is aligned with the axes of the data. For now, the bounding box is the extents of the data (
layer._extent_data
?).In a next step, we could add some basic 3D picking to the layers using the
sample_ray
method. For labels, it's fairly straight forward. For Points and Shapes, we might need to be a bit more careful about performance (e.g., make axis aligned bounding boxes for each object and then test for intersection using those).I have made a (quick and dirty) prototype implementation of finding the intersections sample ray with the data bounding box (used to perform 3D picking) here (
near_point
andfar_point
are the end points of thesample_ray
in data coordinates).In action:
![3d_picking](https://user-images.githubusercontent.com/1120672/116980580-af54bb80-acc6-11eb-9faf-147644d86c22.gif)
Alternatives
Additional context
The text was updated successfully, but these errors were encountered: