Skip to content
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

Add preview for monitoring slow drift #51

Open
vigji opened this issue Jul 15, 2020 · 6 comments
Open

Add preview for monitoring slow drift #51

vigji opened this issue Jul 15, 2020 · 6 comments
Labels
enhancement New feature or request

Comments

@vigji
Copy link
Member

vigji commented Jul 15, 2020

It would be cool and truly increase throughput to have a separate window where there's a viewer that get one full volume every one or 2 minutes, so that the entire experiment can be monitored online for slow drift and aborted without waiting the end if something is happening.

@vigji vigji added the enhancement New feature or request label Jul 15, 2020
@diegoasua
Copy link
Member

So athing like this will be implemented with the tilt mode of napari once #49 is succesfully merged. Viewer will alternate between single frame and multiplane view. When doing volumetric imaging it makes way more sense to visualise all the planes together than a sequence of frames

@vigji
Copy link
Member Author

vigji commented Jul 15, 2020

What I mostly care about is fast scrolling across the entire experiment one plane or multiplane. What is the deal witht eh napari viewer? It will always update with the available h5 chunks? will it display live? How can it handle both?

@diegoasua
Copy link
Member

Ah Luigi those are all very good questions. Right now it displays the most instant frame according to frame rate imposed. However in the future the viewer will receive volumes, not single frames, from a special process that will become central to the software. You can see already a draft of this in PR #43 although some work is still required to make this a VolumeDispatcher instead. Napari will display the volume with the tilt mode so that one can see all the planes imultaneously. Now, if what you want is to know if there is drift, you can, in parallel to the software, use the Fimpy viewer to see already saved h5 files. The progress bar also includes when a new file has been saved (below the bar) so you can know when it is ready to be opened with Fimpy's viewer. This way you can compare if there is drift among files acquired some minutes ago and current data visualised in the lightsheet software.

The optimal scenario would be something like portugueslab/brunoise#7 in which drift is automatically corrected. That would require slightly correcting piezo/galvos offset or the stage (which can be controlled from the computer, we just need a piezo controller https://www.thorlabs.de/newgrouppage9.cfm?objectgroup_id=1098). That is a further project that I am happy to give to anybody seeking to put an end to the drifting problem.

@vilim
Copy link
Member

vilim commented Jul 15, 2020

There are several solutions to this:

  1. Calculate and plot the displacement of all frames relative to the central frame, in all dimensions, online with pyqtgraph (should be easy to catch drift). The only possible bottleneck here is calculating the center of mass, not sure how long it takes, but it doesn't need to be done for every volume.

  2. the open napari button (proposed in Add quick viewer button for last finished experiment #44) should also work while the experiment is running. This just requires updating the json always when you write a new h5 file (a trivial change, already implemented in the 2p).

  3. once you start an experiment, the first volume is saved as a layer in napari, and there is a button to overlay and compare.

In fact, I think all 3 should be implemented :)

@vigji
Copy link
Member Author

vigji commented Jul 16, 2020

I really like 3!
I am concerned about 2 for the fact that you will be reading lots of data from the disk you are saving onto. That is why I was thinking of just keeping in memory a fraction of the stacks every couple of minutes, to avoid any additional I/o apart from saving. But yes, if you think that is not a problem 2 is definitively a good option

@diegoasua
Copy link
Member

diegoasua commented Jul 16, 2020

Those are really good solution all of them. 1. Is the best and also most computationally expensive and will take some time to implement. 3 is just super simple and I think it is the way to go for now. I can add that functionality already to PR #49 as it is almost a one liner plus a button.

Remember, the simpler the merrier for everybody :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants