Get bidirectional scanning correction working again

[raacampbell]

The first thing to decide is whether we need sub-pixel correction and if so whether this introduces artefacts that are unacceptable.

The next thing to consider is how we do the correction. Likely the best option is one correction for the whole frame. For galvo scanning we might want to take the middle 2/3 of the image only.

[raacampbell]

Currently to test this we do:

>> S=tileLoad([100,1,0,0,2]); 
>> OUT=calcPhaseDelayShifts(S,1);

[raacampbell]

With resonant scanning we see a slow drift in the required correction factor over time. e.g. over the course of 5 hours we can see a drift when imaging at 0.5 microns per pixel. To correct this it seems we need to take the ScanImage pixel data back to samples, perform the correction there, then return to pixels. The pixel data aren't quite isotropic and this messes things up.

[raacampbell]

Although should skip tiles with no signal (see #181) we can for now just take the median shift in each section and work with that.

[raacampbell]

As a stop-gap we can now do stitchSection([100,1],2,'bidishiftpixels',-1,'overwrite',true) (6dbf57f). This is a fixed value for a particular section (or sections) and must be user-provided via trial and error.

[raacampbell]

Problem: whole pixel DFT does not identify -1 as the correct value. Try sub-pixel and see if it's a rounding problem.

That does not help. I think I trust the shift value from calibLinePhase so let's return that and compare to the DFT.

[raacampbell]

The code works about 2x faster on cubie (Intel-Core-i7-8086K) compared to tiler (Intel-Core-i7-6900K). Should try on toaster to see how that goes and consider whether we need a new stitching PC for the facility. Fascinatingly, toaster (i9-10900X CPU @ 3.70GHz) is no faster. So it would seem that cubie being a Mac might be what is influencing things. So I guess I could send to pickaxe and see what happens there.

[raacampbell]

I note that the calibLinePhase algorithm is better at picking up the phase delay mismatch with brighter channels. See FM_mar167 section 51 red (bright) vs green (sparser and perhaps dimmer). It follows, however, what the eye sees. So correcting channel 51 in red is obviously better. In green it's better but you have to look carefully and do not notice it being bad before correction.

However, towards the end of the acquisition it is obvious in the dimmer green channel that the phase is wrong. Nonetheless, calibLinePhase is failing to get the correct shift value in green. It tends to either fail to converge or to produce an incorrect value of 2, where the correct value is 1.

Things to try:

• the DFT algorithm keeps returning zero as the shift amount. This is just weird. Confirm it really is doing the right thing. Feed it test images with known shifts that are high contrast. Feed it real images with the dim portions removed. Try to figure out what is happening. I used this algorithm on the 2p fly data in the past and it worked so why not now?
• Try the other Vidrio algorithm. This is the file postHoc.m
• At least with the dimmer green channel calibLinePhase returns mostly Nans and the rest 2s. So we can exclude it from using these shifts. The only weird thing is that in older runs it returned more 2s than Nans. I am checking what could have happened. It makes no sense that the output has changed.
• stitchit.bidiCorrection.calibLinePhase -- Can we distinguish cases where no shift is necessary from those where it just does not converge?