How does normcorre deal with edges

[ehennestad]

For example, I provide a template for the normcorre function, and this template has a different crop than the stack that I want to align. Will this cause a poor alignment or alignment artifacts, or does the method ignore edges like that?

[epnev]

It's hard to tell a-priori. If it helps, we have an option where you can ignore a certain number of pixels from each boundary. If you set options_r = NoRMCorreSetParms('d1',d1-bound,'d2',d2-bound); then the algorithm will ignore the first bound/2 pixels on each direction when aligning. We use this for aligning 1-photon data, see this demo if you're interested. Let me know if it helps.

[ehennestad]

This is a naive question, but is it possible to ignore for example black pixels (pixels of value zero), or perform fft on arrays including nans?

The problem is that my images has a circular crop, and there seems to be large artifact from the correction algorithm along the edges. Any ideas of how to get around this would be highly appreciated.

Best regards, Eivind

2017-09-18 23:32 GMT+02:00 eftychios pnevmatikakis <notifications@github.com

:

Closed #11 https://github.com/simonsfoundation/NoRMCorre/issues/11.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/simonsfoundation/NoRMCorre/issues/11#event-1254329151, or mute the thread https://github.com/notifications/unsubscribe-auth/AQcG12BjTl_zN4i6gEDTx1blagPWcdVMks5sjuFQgaJpZM4Pa0jS .

[dpacheco0921]

I noticed a similar issue, before the code used to output 'nan' at edges that moved but now it seems to circularly move the plane or volume, which is more noticeable when you use the 'phase_flag'. What I do is to pad the image with 0 pixels and then after correction I remove the pads. However I wonder if there is a better way to avoid this artifact.

[epnev]

@dpacheco0921 This is controlled by options.boundary. The default setting would copy the value of the adjacent pixel. Setting to 'zero' or 'NaN' would change that. In any case, neurons that are in the boundary and are occasionally not visible due to motion are probably not reliable enough so in my opinion it doesn't matter a lot.

@ehennestad For the circular crop, what you can do right now with the code is crop it a lot, up to the point where a square/rectangle is fully visible, find the shifts there, then apply it to the whole frame (like I explained above). Of course, this would work better for rigid motion correction, whereas non-rigid would be less accurate in the boundaries since you do not use the info there. One can potentially circumvent FFT completely and compute the cross-correlation "manually" by shifting the window around and ignoring any NaNs or black areas. However it's not in my plans to implement something like that at the moment.