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

SNR calculation is very slow, makes continuous mode appear delayed #525

Open
zacsimile opened this issue Jul 17, 2023 · 3 comments
Open
Labels
future Let's not worry about this for now... low priority low priority task refactoring Improving existing code by either reduction, readability, ease of use or some combination

Comments

@zacsimile
Copy link
Collaborator

As the title states, the SNR processing makes the data thread take a much longer time to get through displaying all of the images. This leads to non-real-time feedback.

@AdvancedImagingUTSW
Copy link
Collaborator

Not a whole lot that can be done here since the conversion is so basic.

S = image.astype(float) - offset_map.astype(float)
    S[S < 0] = 0  # clip
    N = np.sqrt(S + variance_map.astype(float) + 1.0) 

Perhaps the offset_map and variance_map should be converted to type float upon initial loading in the update_snr command? This way it is done once, as opposed to every time? Not sure how much that will shave off the calculation time.

@zacsimile
Copy link
Collaborator Author

zacsimile commented Jul 26, 2023

@annie-xd-wang more or less circumvented this problem in #533. Converting everything to float on initial loading may help. The sqrt() is likely slowing us down a lot. It's kind of an expensive calculation. Will have a think.

@AdvancedImagingUTSW
Copy link
Collaborator

Quickly tried some other ways to do the square root operation, but numpy is pretty damn good. 22x faster than the built in python method for a 2.2k x 2.2k 16-bit image.

Python Version - Duration: 0.044397497177124025
Numpy Version - Duration: 0.002041006088256836

@zacsimile zacsimile added refactoring Improving existing code by either reduction, readability, ease of use or some combination future Let's not worry about this for now... low priority low priority task labels Nov 4, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
future Let's not worry about this for now... low priority low priority task refactoring Improving existing code by either reduction, readability, ease of use or some combination
Projects
None yet
Development

No branches or pull requests

2 participants