search

alihaydaroglu / suite3d

Fast, accurate, volumetric cell detection. Developed for Light Beads Microscopy, usable for other volumetric 2P. In development
6 stars 0 forks source link

GPU registration seems off #46

Closed oterocoronel closed 1 year ago

oterocoronel commented 1 year ago

I have run the new gpu pipeline but it does not seem to be working well for me. I first realized about this because the correlation maps have extremely low values (most pixels were 0 or 0.01, in all pixels). This was for the Coconut data with the same/similar parameters that you used and got you some decent results. I had similar issues in a different recording with an even better SNR, so I don't think it is that. I had to turn down the thresholding parameter to 0 to barely see anything on the correlation maps, even 0.1 was too much.

I was trying to re-run the non-gpu registration so I could make a direct comparison and see if there are any differences in the output in standard vs gpu registration, but the standard registration crashed with the current version (I opened an issue for that). However, by looking at the reference frames generated during initialization and the final result of the registration, there seems to be something wrong in the gpu-registration. The images in the initialization look much better and have a more reasonable distribution of pixel value distribution than the one after registering the whole volume:

Initialization: image

After GPU-registration (average 1000 frames): image image

In order to get the gpu-registered average frame to display with contrast levels similar to those in the reference images, I need to set the limits of the dynamic range as (1.6, 3): image

This is just a guess, but is the reshaping of the data handled identically as it was done before? I'm thinking that if the registration was working for you and it is failing for me, it might be due to the weird reshaping that is necessary for my files. Maybe my files are being reshaped in an incorrect way that causes all pixels to be shuffled in an incorrect order and that makes the registration fail?

alihaydaroglu commented 1 year ago

This is weird. Can you share an example tiff with me? It worked OK on the coconut tiffs I have

oterocoronel commented 1 year ago

I have the same issue with the Coconut tiffs. Here is an example of the deepest plane after doing motion correction on the first 2 tiffs with the old version (non-gpu). The image below is the average of the first 1000 frames:

image

And here are the average pixel values for each plane: image

Same, but using the new gpu version:

image

And pixel values: image

alihaydaroglu commented 1 year ago

ok, I can replicate the issue, working on it now

alihaydaroglu commented 1 year ago

OK, I figured it out and pushed a fix on the dev branch. It was a tiny one-line bug but it had a pretty big effect of clipping the top values in each frame, please re-run your gpu registration jobs before using the data.

The cause: before estimating the shifts, registration clips the top and bottom percentile of values of a frame, and then it applies the shifts in a non-clipped version of the original frame. This was implemented correctly for rigid registration, but the clipped version of the movie in non-rigid registration ended up being shifted instead of the non-clipped version, so all the outputs had their top percentile of values clipped.

alihaydaroglu commented 1 year ago

I aim to merge the dev branch into main today, I just need to run a few tests

alihaydaroglu commented 1 year ago

merged into main #48