cortex-lab / Suite2P

Tools for processing 2P recordings
Other
120 stars 65 forks source link

Question on Rigid vs Non-rigid Registration #153

Open danachang opened 5 years ago

danachang commented 5 years ago

Hi, I have two questions on non-rigid registration in Suite2P. Is the non-rigid registration implemented in a same way as described in NoRMCorre, where the only difference is Suite2P uses phase_correlation instead of cross_correlation?

Specifically, I have videos with 512 x 512 pixel sizes. and I tried registration with both rigid method as well as non-rigid with ops.numBlocks = [2, 2], [4 4], or [8 8]. However, I don't understand why non-rigid registration has a much poorer performance in general -- I imagined non-rigid would perform equally or better compared to rigid. Is it because the SNR in our images is too bad, such that having more blocks only make performance poorer?

On the other hand, when I set numBlocks to be [4 4], its performance is actually better compared to [2 2]. Here I attach the average projected images from each method. (top left: rigid, top right: non-rigid with numBlocks = [2 2], bottom left: non-rigid with [4 4], bottom right: non-rigid with [8 8]).

rigid_nonrigid22 nonrigid44_nonrigid88

Another odd phenomenon that -- if I compare the same frame in registered video, the performance rank among these methods also vary from frame to frame.

For example, when I compare frame 543, performance rank: rigid > non-rigid [4 4] > non-rigid [2 2] = non-rigid [8 8], as shown below (left: average projection, right: frame 544; top to down: rigid, non-rigid [2 2], non-rigid [4 4], non-rigid [8 8]).

frame543_rigid frame543_nonrigid22 frame543_nonrigid44 frame543_nonrigid88

However, when I compare frame 544, performance rank: non-rigid [2 2] = rigid > non-rigid [8 8] > non-rigid [4 4], as shown below (left: average projection, right: frame 544; top to down: rigid, non-rigid [2 2], non-rigid [4 4], non-rigid [8 8]).

frame544_rigid frame544_nonrigid22 frame544_nonrigid44 frame544_nonrigid88

Therefore, I am confused on how to explain/interpret this, and thought maybe this is caused by specific implementation of non-rigid registration, or ops settings I used? Thanks!!

marius10p commented 5 years ago

Hi,

I think it's probably the type of data. We are aware of registration issues with 1P miniscope data and are working to fix them, but we haven't really been optimizing Suite2p at all for such data yet. We can let you know here when the optimizations are implemented.

The general idea behind our non-rigid approach is similar to NoRMCorre's, or I should say theirs is similar to ours. The implementations differ, mainly because ours is built on top of suite2p's standard rigid registration which has some specific features.

Best, Marius