[WIP][FIX] irfft: ramp correction and apodization fix for asymmetric interferograms#641
[WIP][FIX] irfft: ramp correction and apodization fix for asymmetric interferograms#641stuart-cls wants to merge 8 commits intoQuasars:masterfrom
Conversation
|
@stuart-cls I think the "original" (on your figure) asymmetric apodization was meant for SNOM IFGs and the intention was to have that shape, where not only the position of the ZPD is offset but also the apodization. In my understanding the reason for this is that the near field signal is contained only on one side of the ZPD and the other should be down-weighted. There is some literature on this: http://hdl.handle.net/10810/26669 NeaSpec does something very similar, but their calculations are proprietary. However, I think there is some actual scientific discussion missing... @raul-freitas, @levandoskije, what do you think? |
|
@borondics I'm pretty sure this part of the code predates SNOM! That said, I definitely don't want to break anything correct. I will simply note that for asymmetric interferograms in an FT-IR, downweighting the short side via shrinking the apodization window ("old") is not the same as downweighting the short side via the ramp ("new + ramp"), and the latter is the correct way. I'll review the literature you sent, I'm also waiting on other feedback. If you have any before / after data of what Neaspec is doing, please send it along: we can compare the two approaches. This is basically what I did for the Agilent imaging data to check for correctness. |
|
Hello @borondics and @stuart-cls. Maybe we can plan some synchronized activities soon. I have two new folks that will give some support to Orange-Quasar in here. |
|
I was just browsing SciPy for something and realized that many (all?) of the apodization functions are implemented there. Since SciPy is a dependency, should we simply use those functions to decrease the code? |
|
@borondics I'm aware of those functions. Originally I wanted to keep the dependencies of Dependencies aside, I looked at how those windows are implemented this time around and they don't work for either of the types of apodization we would like to do. Which brings me to the summary of the current state of this PR: based on our discussions offline, the thesis above, and feedback from others, I think we will have to distinguish between interferometer types:
where type (1) will use this symmetric + ramp approach and type (2) will use the existing approach of different apodization functions for each wing. |
|
After @stuart-cls mentioned this existing issue in ##809, probably it is time to revisit this. As discussed above this is a very very important. The asymmetry apodization (which is currently in the widget) introduces serious artifacts. However, it is necessary for SNOM interferograms. https://doi.org/10.1364/oe.520793 There should be an option in the apodization section. Either just a checkbox for asymmetric apodization or a radiobutton, or dropdown to choose. |
54a3400 to
1ec0294
Compare
|
@ngergihun Could you take a look? I restored the true asymmetric mode and added the option. Could you test and compare with your other code? Something is still not quite right with the phase correction data I think, still thinking about that. |
|
@stuart-cls , yes they are still giving different results. Hmmmm.... I will try to send something more useful report in a few hours.... |
|
Two outstanding things from @ngergihun observations:
|
Now:
Symmetric (Michelson-type) interferometer
a. Fully symmetric interferogram
b. Truncated symmetric interferogram ("Asymmetric" in some software)
Asymmetric (s-SNOM type) interferometer
a96dd70 to
c598f0e
Compare
Fixes an old error in the apodization function generation for asymmetric interferograms, found while adding a ramp correction to avoid double-counting in the symmetric section. Illustration of the issue:
The above figure illustrates how the original apodization code was handling the taper to zero needed in asymmetric interferograms. While it does bring the amplitude to zero at the edge of the short side, it obviously badly violates the symmetry requirements. This would not have been obvious on the original symmetric test interferograms.