Interferogram from fringe-pattern - FFT(Takeda) and Phase Shifting

[JakobSilbermann]

i would like to implement the FFT(Takeda) algorithm (https://www.osapublishing.org/josa/abstract.cfm?uri=josa-72-1-156) and PSI into prysm to generate Interferogram objects directly from fringe patterns optained by a camera or via a video. For the FFT i already have some code but speed of the fft is an issue there for bigger fringe pattern. I already had a look into propagation.py for this. Also unwrapping is an issue but i saw that prysm uses skimage/restoration here. Before i start to implement it in my fork i wanted to ask if this would be a useful tool for prysm and in wich class it should be best implemented. I thought interferometry would be good but maybe i do not see the whole picture. Jakob

[brandondube]

This one is a bit of a pickle. I have long wondered what the natural "bounds" for prysm are.

Physical optics? The methods are very similar, but then the interferometry module would have to be precluded, so not a good fit.

Numerical optics? Well, then FDTD & EM methods would be fair game, and I don't think they fit well with prysm (~= 0% overlap).

Design and metrology? Maybe.

Lately I sort of think that "forward models" with some vague association to physical optics is a good bound. This would mean that, for example, a code which produces PSF grids for a shack hartmann wavefront sensor would be in scope, but reconstruction (modal or zonal) would not. Similarly, all the machinery to do phase retrieval would be in scope, but phase retrieval algorithms themselves out of scope. The same for PSI, unwrapping, and so on.

The deconvolution method will be removed in v020. Actually, almost all the classes are going to be gone in v020, too. skimage's deconvolution methods work pretty badly, in my opinion. You can do a forward model and provide precisely the PSF used for the forawrd model, and it struggles to restore the true object. That is not a general property of deconvolution algorithms.

In short, I think there should be something like a prysm-ext library, or something with a name like the reverse of a prism, that is the foil to prysm but for reverse-mode problems (phase reconstruction, image restoration, phase retrieval, and so on). But prysm will get too big if all the reverse mode algorithms are put in here. And I think, in general, reverse mode problems are a bit fussier than forward mode problems and the codes are often quite taylored to a specific class of imagery or what-have-you, and are not really sufficiently general for a library like prysm. It is very hard to write adequately general ("broken input proof") reverse mode algorithms.

[JakobSilbermann]

Yes i think i understand what you mean. My thoughts were fixed to the idea to use of prysm with interferometry post processing and my main thought was: why should i use some proprietary interferometer or software package export a file and import it to prysm to work on the data of my interferometer - while i could also take an image of the fringe pattern in my interferometer and extract the phase via the algorithms i mentioned earlier and postprocess it directly in prysm.

This also shows that when it comes to Zernike fitting, representation and so on prysm is way cooler and intuitive than the interferometry package we have in our company :)

Your answer put me into the right perspective. I think i will work on this idea in my own fork and when i have substantial code i will come back to discuss this and the idea of a prysm-ext library for this specific problem and more reverse mode problems. Until then i will close it.

Thanks for your answer and this great piece of software!

[brandondube]

Hi Jakob,

Thanks for the kind words. prysm is the result of many years of effort, both in the capability side of things (at this stage, there is no other open source optics package that covers the same scope) as well as speed and design. Design is subjective, but my goal has always been to make something that is easy for anyone to use, and easy to learn ("it does what you expect").

The next major version (v0.20) is cataclysmic in terms of compatibility. I would appreciate if you could give any feedback RE: especially painful compatibility breaks for your workflow(s), especially if you mostly use the interferogram module (which has a 'decent" forward compat story for v020).

In terms of naming, I think prysm-ext is kind of boring, and would prefer something "flashier" - but if it isn't my code I can hardly dictate =)

For a motivating example, iris is a defunct module of mine for phase retrieval and weighs in at +8000/-5000 lines. It is a maturation of an algorithm originally developed to focus the EECams on perserverence. Iris was made to do my thesis and is pretty derelict now, since I am not actively working in that space and have not put in the time to keep it current to prysm. I would redo the entire design of iris before updating it from prysm v0.12 anyway. The reason I bring this up is that this can often be the fate of reverse-mode code:

• write lots of it
• eventually stop working on it (moved on to a different kind of problem)

--

You should be able to relatively trivially implement the reverse-mode code you write with prysm, just making an interferogram instead of loading one from a dat file. If you have any particular issues, I could help with them.

Cheers, -Brandon