tlambert03 / LLSpy

Lattice light-sheet post-processing utility.
http://llspy.readthedocs.io
Other
25 stars 6 forks source link

Need help understanding LLSPy's OTF generation #25

Closed VolkerH closed 3 months ago

VolkerH commented 4 years ago

Hi Talley,

while I've mainly been using my own lls_dd tool for processing lattice data, we are running an internal workshop next week and I also want to show users how to use LLSpy.

However, I am having some issues with the OTF generation. So I've configured an OTF folder and placed a PSF in there. Using the naming scheme for the psf file according to the documentation the automated matching of the PSF file to the experiment seems to fail for me. I'm trying to track that down but for the time being I can just work with 488.tif as a default file. When I do this and click Preview, a file 488_otf.tif is generated and cudaDeconv runs. The results look rather odd.

The PSF tif files I get from the person running our microscope are galvo-scanned (scanning of the lightsheet, not the sample). I have a feeling that I need sample-scanned PSFs to work with LLSpy as the OTF generation does not look at a Settings.txt file from which it can determine whether the tif file represents sample-scanned or galvo-scanned?

tlambert03 commented 4 years ago

Oh Volker you’re gonna find all the terrible hidden problems, and there are many of them :(. This whole thing was written before I starting writing code as if someone might eventually look at it 😅 The OTF generation is particularly egregious, but it shouldn’t be hard to fix. I made a change in the last version that may require a docs update (but it was broken before that anyway). Can you give me exact names you are using that fail to get found?

Also, there are a few assumptions here that should absolutely be made clearer in the docs, and need to be generally fixed. You do need galvo scanned PSFs, not stage scanned. And importantly, you should use a zstep size of 0.1. (Hard coded 🙄). I don’t think there’s even a workaround there, because the Decon itself assumes the OTF has been generated with dz 0.1 Could that be the reason for your weird results? Feel free to send me some data. There’s no good reason I haven’t added that ability yet, except that everyone using llspy seems to be ok so far with the hard coded 0.1

tlambert03 commented 4 years ago

OK, release 0.4.8 fixes some issues with OTF selection, and makes the assumptions and OTF selection process much clearer in the docs: https://llspy.readthedocs.io/en/latest/main.html#otf-directory

VolkerH commented 4 years ago

Hi Talley,

thanks so much for reply. I got to talk to the person running the microscope today and was told that he also captures all PSFs at dz 0.1, so your hardcoded assumptions appear to be correct. I need to try with some other datasets, maybe I just picked a bad PSF.

With the name matching, I put in some print statements for debugging yesterdayt after I raised the issue and found that this may not actually be related to the part where the OTF filenames are parsed, but due to incorrect extraction of the dates from the actual dataset. In any case, i can work around that by using the default filenames and providing a different PSF input folder for each date.

I've been having a day mostly spent with commuting and meetings today but hope to try out 0.4.8 tomorrow. I can then tell you whether the updated logo is still causing issues when running lls gui via VNC (other issue).