fix: drain live preview buffer#160
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #160 +/- ##
==========================================
+ Coverage 81.84% 82.09% +0.25%
==========================================
Files 29 29
Lines 1807 1810 +3
==========================================
+ Hits 1479 1486 +7
+ Misses 328 324 -4 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
gcharvin
changed the title
gcharvin
force-pushed
the
codex/mr-live-preview-buffer
branch
from
c84f6ad to
e42eef7
Compare
|
Hello @gcharvin! It's nice to make your acquaintance, and thanks for all your PRs across these two repos! I'm very happy to see a new eager (and clearly quite capable 😄) contributor, and I hope we can ultimately accommodate all of your needs here. I'll get to all of your PRs over the next couple days (we're away teaching a course at the moment, so might be slightly slow). There will likely be some discussion points, but in general: please do feel free to open PRs for anything that would make your life easier. (and also: know that it's still early days for the GUI, so things will be changing fast: for any software you're using to actually drive scopes in the lab, I encourage you to use lock-files to pin specific versions of pymmcore-gui) This specific PR is fine with me. The live preview functionality is all still work-in-progress and I think there are known issues about the buffering (size of buffer aside). Ultimately, I think this should probably be a user preference, since the previous behavior of having a buffer size > 1 lets the user either do a little live burst, or snap a handful of times, and review the most recently snapped images, which some people like to do. But if/when we add back that recent review functionality, we'll try to do so with user configurability |
|
Thanks Talley, nice to meet you too, and thanks for taking the time to look
at these.
I also wanted to say that I really appreciate the pymmcore initiative. I
have been a Micro-Manager user for many years, and it is very exciting to
see this more Python-native ecosystem developing around it.
That makes sense regarding the live preview buffer. My immediate issue was
stale frames accumulating during continuous live preview on our TiEclipse
setup, so keeping only the latest frame fixes the lag for that workflow. I
agree that restoring/reviewing recent frames would probably be better as an
explicit user preference later rather than implicit buffering.
I also have a number of local modifications and feature ideas that came
from real microscope use in the lab. I’ll keep opening PRs, sometimes as
drafts when the design is less clear, in case any of them are useful to the
project. Of course I’m happy to adjust or split things based on what fits
best with the direction of the repos.
Thanks also for the note about lock-files. That makes sense, since we are
using this to drive lab microscopes; I’ll make sure to pin the versions we
deploy locally.
Thanks again and best,
Gilles
…On Tue, Apr 7, 2026 at 2:53 PM Talley Lambert ***@***.***> wrote:
*tlambert03* left a comment (pymmcore-plus/pymmcore-gui#160)
<#160 (comment)>
Hello @gcharvin <https://github.com/gcharvin>! It's nice to make your
acquaintance, and thanks for all your PRs across these two repos! I'm very
happy to see a new eager (and clearly quite capable 😄) contributor, and I
hope we can ultimately accommodate all of your needs here. I'll get to all
of your PRs over the next couple days (we're away teaching a course at the
moment, so might be slightly slow). There will likely be some discussion
points, but in general: please do feel free to open PRs for anything that
would make your life easier. (and also: know that it's still early days for
the GUI, so things will be changing fast: for any software you're using to
actually drive scopes in the lab, I encourage you to use lock-files to pin
specific versions of pymmcore-gui)
This specific PR is fine with me. The live preview functionality is all
still work-in-progress and I think there are known issues about the
buffering (size of buffer aside). Ultimately, I think this should probably
be a user preference, since the previous behavior of having a buffer size >
1 lets the user either do a little live burst, or snap a handful of times,
and review the most recently snapped images, which some people like to do.
But if/when we add back that recent review functionality, we'll try to do
so with user configurability
—
Reply to this email directly, view it on GitHub
<#160 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABNNA6DIAYAOVI2ZJVDKYXT4UT25PAVCNFSM6AAAAACXPDNZHCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DCOJZGA4DCMZUGI>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
2 participants
Summary
This keeps the live image preview from accumulating stale frames during continuous acquisition:
Background
This came from testing pymmcore-gui on a Nikon TiEclipse setup with a high-resolution camera, where the live preview could lag and the viewer buffer could grow unnecessarily for a workflow that only needs the latest live frame.
Validation