s-SNOM FFT Processing

[stuart-cls]

Continued from #415 @levandoskije @raul-freitas @ok-nc @borondics

[stuart-cls]

@levandoskije Is there some code I can look at for your processing? I'm trying to re-organize the FFT code to make it more maintainable and usable in scripts so now would be a great time to co-ordinate! I'm not that attached to what is there so if we can make something that is easy to read and correct I think it would be best to have a single widget for FFT.

[levandoskije]

@stuart-cls Yes there is! If you can follow the link . It will be great to be able to do coordinated work with you. Just a few small details:

• I'm not working on a new widget, I just added one more class to irfft.py;
• And I'm using data.attributes to automate FFT, but that has made my class very specific.

[stuart-cls]

@levandoskije Thanks! I will take a look at this and get back to you. New class is great, and I like the attributes idea, we had talked about doing that as well (#272) and I think more automation where appropriate is helpful.

[levandoskije]

@stuart-cls, I write here to bring the information together and keep everyone informed. I will divide the work #423 into two parts, as you suggested, the next Pull Request it will include:

• Some tests
• Check_metadata()
• FFT as an inherited class

[ok-nc]

Hey guys, great work so far!

@stuart-cls, one quick note about peak search: there's only a couple commercial s-SNOM instruments, but none do any zpd bookkeeping (at least to my knowledge), nor do most home-built setups, as the user usually has full/arbitrary control of the reference arm scan range. So a peak search for the intfgm max is always necessary, though not ideal for large batch processing. Search off by default when zpd present in metadata is a good strategy.

[stuart-cls]

@levandoskije Fantastic, thanks!

@ok-nc That's good to know. I thought I had read somewhere about determining the zpd with a fixed mirror but that might have been a one-off home-built thing. For the batch processing, the current code only lets you peak search if you do it row-by-row. However, for datasets with weak signals but common zpd, it's better to determine it once for the group and then set it manually to avoid zpd "noise".

[raul-freitas]

@ok-nc and @stuart-cls , these are good points. For any sSNOM instrument, spectroscopy with broadband sources requires several interferograms (averaging or integration) to acquire a reasonable SNR spectrum. Therefore, we usually take 10-20 interferograms with integration time of ~1 min per interferogram. Considering that these are usually delicate instruments that are based on an AFM nano-antenna, mechanical drifts are quite common and the ZPD follow those drifts, then introducing a broadband phase in the spectrum. I understand that this could be a setback for the computing side but for the experiment it seems to be an important approach measuring the ZPD for each (or each N) interferograms.

[ok-nc]

@raul-freitas Great point, I was just about to mention/ask about this! There will always probably be some amount of drift (usually mirror) over many hours for a typical line/area scan. How is your experience with the Neaspec, as far as consistency?

One could in principle push the burden of a slightly shifting ZPD over to the phase correction post-processing side, where you would have to subtract either a straight line from individual spectra. or a plane correction for a 2D image in the case of an area scan. The latter can certainly be made to be more computationally efficient, but honestly I don't think the s-SNOM datasets are large enough to where it makes a huge difference if you find the ZPD for every spectrum, at least in my experience.

[raul-freitas]

@ok-nc : the Neaspec instrument is very stable and the drifts come more from the environment, such as temperature and humidity control. In fact, it is an usual effect for scanning probe microscopes. For synchrotrons there is an extra challenge: the source can drift over time in case of decay mode machines and that can cause a ZPD drift as well. We experienced this in our old machine. In conclusion, there is a convolution of drifts from instrument and source that can produce non trivial phase drifts.

That is why I like the idea of finding the ZPD for every spectrum. How about we add an output (in the FFT widget) with the post-processed interferograms prior to the FFT? This could offer the user an overview of the stack of interferograms. I can suggest @levandoskije to work on this in the future.

Thks for the discussion!!

[levandoskije]

Hi, @stuart-cls, is possible to run test just one test? Something like:

python setup.py test -m test_owfft.py

Because running them all takes a long time on my poor computer

[stuart-cls]

@levandoskije yes, call it like this:

python -m unittest orangecontrib.spectroscopy.tests.test_irfft