8000 Grid mode using vispy ViewBox and linked cameras by brisvag · Pull Request #7870 · napari/napari · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Grid mode using vispy ViewBox and linked cameras #7870

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’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 178 commits into from
Jun 25, 2025

Conversation

brisvag
Copy link
Contributor
@brisvag brisvag commented Apr 29, 2025

References and relevant issues

Description

This PR replaces the current transform-based grid mode with a viewbox-based one using linked cameras.

Drag events will remain relative to the original viewbox, making annotation at the edges a breeze. Interacting with one viewbox, such as during annotation, will update the corresponding active layer, potentially in a different grid view.

Additionally, viewer canvas overlays (such as scale_bar) now have a gridded property which, when set to True, will make it so the overlay appears in every grid box instead that on the general canvas.

Grid mode spacing now works proportionally to the layer extensions (i.e. [0,1), as before this PR) or as a pixel value (1,1500]. If spacing amount exceeds a limit that will result in degenerate viewboxes, the spacing will automatically adjust and present a warning to the user. Stride continues to work as before. For discussion on changing the grid layout see #8044.

import napari
v = napari.Viewer(ndisplay=3)
l0, l1 = v.open_sample('napari', 'cell
8000
s3d')
l1.bounding_box.visible = True

v.axes.visible = True
v.grid.enabled = True

v.scale_bar.visible = True
v.scale_bar.gridded = True

image

@brisvag brisvag requested review from melonora and a team as code owners April 29, 2025 14:35
@github-actions github-actions bot added the tests Something related to our tests label Apr 29, 2025
@brisvag brisvag marked this pull request as draft April 29, 2025 14:35
@github-actions github-actions bot added the qt Relates to qt label May 6, 2025
@brisvag brisvag force-pushed the feature/canvas-model branch from 443e246 to da63dc6 Compare May 6, 2025 12:58
@brisvag brisvag marked this pull request as ready for review May 6, 2025 13:56
@brisvag
Copy link
Contributor Author
brisvag commented May 6, 2025

Todo from pairing with @melonora:

  • fix camera getting stuck (and infinite event loops)
  • fix canvas overlays not being shown

@brisvag
Copy link
Contributor Author
brisvag commented Jun 22, 2025

@TimMonko my last commit should hopefuly fix the remaining test and might also fix #8033!

@psobolewskiPhD
Copy link
Member

@brisvag indeed, you also fixed a severe issue with multiscale layers, which are now properly rendered. 🎉

@TimMonko
Copy link
Contributor
TimMonko commented Jun 23, 2025

@TimMonko my last commit should hopefuly fix the remaining test and might also fix #8033!

Unfortunately does not solve #8033. What test were you trying to solve? I don't see any in the recent commits that are screenshot related, just multiscale. The screenshot test in d41bf35 (#7870) looks fixed in 0590cb6 (#7870)

@TimMonko
Copy link
Contributor

Ok, I've figured out the multiscale test fails. The _data_level is correctly 0 at the zoom which the data gets zoomed to in the viewer for the tests, resulting in the test failing. Therefore, the test previously incorrectly had the wrong data level --and this behavior was likely fixed by this PR. But if I force the data level to 1, then the corner pixels still seem the 0 level. I'll let someone more knowledgeable figure this out.
So, I think the tests need changing, but I'm not sure how to correctly do that because I have little experience with multi scale data. It's definitely related the corner pixel stuff you mentioned earlier.

I'm approving :) I tried really hard to break this, and couldn't.

@brisvag
Copy link
Contributor Author
brisvag commented Jun 23, 2025

The screenshot test in d41bf35 (#7870) looks fixed in 0590cb6 (#7870)

Uhm, I thought I solved it in 1372ed9, which is why I thought it might also solve your problem, by updating the canvas before screenshotting. But I might have misunderstood the test, I thought the divide by zero was failing due to the image being denegerate. Maybe we should revert that commit then?

Yeah those multiscale are the same as mentioned in these comments, I should mark xfail!

EDIT: actually, these might be more fixable than the above. Unfortunately, I'm not gonna be able to come back to this for a couple of days, sorry for the bad timing 😅 I'll let you decide what to do!

@TimMonko
Copy link
Contributor
TimMonko commented Jun 23, 2025

The plot thickens. Apparently the screenshot on_draw is needed for ubuntu 3.10. https://github.com/napari/napari/actions/runs/15829545543/job/44618484006?pr=7870#logs Interestingly, again, this doesn't fix it for Windows. Seems like tracking down the solution for #8033 is going to be a pain.

Edit: and it thickens more. it still fails with 954db3c (#7870) for ...

  1. ubuntu-latest py 3.10 pyside2
  2. windows-latest py 3.11 pyqt5
  3. maco-13 py 3.13 pyqt5
  4. macos-latest py 3.13 pyqt5

Maybe it's flaky? I'll try rerunning. Locally it passes for me.

Edit2: Yes it's flaky, so it's not this PR, per-se. It is in the sense we change the draw mechanism, but not a blocker to the PR. I'll still put in a resolution or x-fail here.

@TimMonko
Copy link
Contributor

Ok, so here's my final decision. This test is actually still an issue on main (localy), and is the same issue as #8033.

Without fully processing (like in the tests), we get just the canvas (hence the divide by zero, because the data doesn't ever show up). Hopefully this just means we are slightly slower in displaying the image, but it must be ever so slight, since this is the only test issue. And I mean the change in event processing must be so slight since itss flaky, so I'm not worried about performance. But I do think trying to fix #8033 is high because now it also probably effects others OSes. For that reason, I'm going to add the processing into this test only. I'm guessing this is probably the root of so much of our screenshot test flakiness....
image

Once the whole loop is processed is loaded, the figures/screenshots look good (as expected)
image

Comment on lines -323 to -324
center = tuple(np.round(np.divide(screenshot.shape[:2], 2)).astype(int))
np.testing.assert_almost_equal(screenshot[center], [0, 255, 255, 255])
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe here and above, comment out the code and add a note, as you did with other tests above, so that we know to revive the test as soon as we can?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will do, good catch! Didn't realize Lorenzo commented these out too ... another lead on how this issue is happening. 😬

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

or, why does it need commented out? the test passes?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok actually I'm just confused on what I'm looking at. Is this the most recent commit? It's not what I see locally and I think it's the most recent commit. But this does look like a diff that has this code removed.

@TimMonko TimMonko added ready to merge Last chance for comments! Will be merged in ~24h feature New feature or request labels Jun 25, 2025
@TimMonko
Copy link
Contributor

I am merging this PR because it has had many eyes from the team:

  1. Lorenzo and Wouter-Michiel worked on this initial implementation, with Lorenzo following up for weeks to address issues.
  2. Peter and I stress tested the PR, found many issues, which Lorenzo and I fixed over a period of days.
  3. Juan has given excitement over these changes

We will open follow-up PRs to address a few things, and others revealed during the pre-release including

  1. Figuring out why screenshot-related tests required some changes, despite non-test behavior seems similar.
  2. Adding highlights to the active layer viewbox
  3. Potentially adding borders to the viewboxes

@TimMonko TimMonko merged commit 123d6b5 into napari:main Jun 25, 2025
45 of 46 checks passed
@github-actions github-actions bot removed the ready to merge Last chance for comments! Will be merged in ~24h label Jun 25, 2025
@imagesc-bot
Copy link

This pull request has been mentioned on Image.sc Forum. There might be relevant details there:

https://forum.image.sc/t/test-out-the-upcoming-napari-0-6-2-release/114029/1

jni pushed a commit that referenced this pull request Jun 27, 2025
# References and and Description

Follow up to #7870. After that PR, on main, stride results in layers
stacking up in the wrong order, where lower indexed layers are on top of
the stack.

See #8053 and #8044 for original discussion

```python
import napari
from skimage import data

viewer, layer = napari.imshow(
        data.lily(),
        name='lily',
        channel_axis=2,
        colormap=['red', 'green', 'blue', 'gray'],
        blending='translucent',
        opacity=1,
        )

viewer.grid.enabled = True
viewer.grid.stride = 2

napari.run()
```

main:


![screenshot_XtB3XXSr@2x](https://github.com/user-attachments/assets/62725a9b-5409-405c-b0e4-b6cea548174e)

this PR:


![screenshot_tsNdp7E1@2x](https://github.com/user-attachments/assets/1671a4a3-9955-4653-af41-74b6c6d2617c)

---------

Co-authored-by: Peter Sobolewski <76622105+psobolewskiPhD@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature New feature or request highlight PR that should be mentioned in next release notes preferences qt Relates to qt tests Something related to our tests UI/UX
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Grid is not correctly calculated when dim order is not default (in 3D only?) multicanvas grid display for layers in Napari
8 participants
0