Analysis of inteferograms could be UI-independent (prospective/discussion)

[Lucassifoni]

Hi,
Do not take this as a real feature request but more as a discussion.

Is your feature request related to a problem? Please describe.
It is not related to a problem, but my goal is to be able to use DFTFringe as a system that analyzes igrams without the user directly its GUI. I know that the code is very deeply linked to the UI and generally very stateful, and that using DFTFringe as a library would be a major refactor, which is too big to be suggested here.

Describe the solution you'd like
Leverage QT's websockets system to expose stateful manipulation of the program through a websocket, single-consumer, the websocket process acting as a mutex.

Describe alternatives you've considered

• Command-line use of DFTFringe without instantiating the GUI (absolutely major changes)
• Major refactor to make the code more stateless and independent of the QT GUI (same)

My idea would be able to remotely control DFTFringe to build a system that automates an XYZ table, photographic shots, and analysis, while being usable from a smartphone to keep the user in the loop.

QT's websockets are the "most straightforward" way to get a POC running since it allows to just deal with the stateful nature of the program, and run it on a full linux distro without a screen, while a coordinating system interacts with it through a socket. But it isn't the best engineering solution, more like the most feasible one in the current state.

Would you be interested in a POC ? Or is this so out of scope that I can just do it on my side without taking your time ?

Honestly this is a bit of an XY problem. The real problem would be to be able to leverage DFTFringe's analysis process without the GUI parts. Note that the batch processing feature is already a step in this direction : the code already orchestrates the successive steps that need to be done for analysis.

In any case, happy new year and thanks for all your maintaining and evolution efforts !

I am happy to work on a POC to feed this discussion in any direction

[Lucassifoni]

Based on code exploration, a bite-sized POC that would fill my needs would be :

• Add a --live-picture-source flag to DFTFringe. It would allow to configure a source to fetch an image from, instead of Dale's hardcoded skysolve camera IP
• Use the existing SingleApplication+MessageReceiver structure to allow a --capture flag that triggers m_mainWindow->load_from_url()

I would not implement an alternative UI but work directly with DFTFringe, except that the program that controls my camera and XYZ table would signal DFTFringe to pull a frame.

I will try a POC in this direction.

[gr5]

Would it help if all the data processing code was separated from the gui?

I would love to add video ability to DFTFringe. I'd love to have live igram->DSP->wavefront&Zenike display. So you could do those once or twice per second similar to the program waveFrontPro. In particular, I find the live DSP helpful for alignment. For example, you can minimize defocus by shrinking the two lobes as small as possible. Even better I think it doesn't find where defocus is zero but where the defocus is ideal to make larger fringes. Useful for large/fast mirrors.

[Lucassifoni]

Hi George,
Yes, I wouldn't dare to ask for that, but of course, if I were to write a wishlist, from best to worst, it would look like :

• some kind of "libdftfringe" that DFTFringe consumes and contains all the processing code, against which we could write other clients
• next best thing would be a CLI usage that allows to process igrams without spawning the UI
• or the ability to script DFTFringe
• or the kind of hacks I am describing

But decoupling processing code from the GUI looks like a lot of work, which I am unable to take, so I cannot ask for that.

What we are looking to build is indeed a (close to) live solution, but where an external program would coordinate shooting pictures / controlling movements / triggering analysis.

I think outlining mirrors from a video feed with varying fringes on a still mirror would maybe be easier as the "energy" of the mirror between frames would be far greater than of the background (energy isn't maybe the right word here).

[gr5]

The more I think about it, the more I think websockets might be a good idea. But did you take into account that you need user input to find the edge of the mirror? Or were you hoping to use the auto outline feature? Similar for the blue filter in the dsp step.

[Lucassifoni]

Well, in my websocket solution, my UI would :

• set the mirror parameters and igram wavelength
• send an igram for analysis (well, trigger the opening of the igram)
• UI would show the user something like your outline detection, and send it
• UI would show the user something like your center filter outlining, then send it
• UI would then display the result

Basically, if we stay at the stateful level of DFTFringe, my app would be a light client that sends igrams and has an UI that contains the bare minimum to send processing instructions until analysis

[Lucassifoni]

The live video feature you describe would make my whole project unneeded (and for good!) 😄 . It would be huge to be able to hook even a simple mjpeg feed to DFTFringe and see fringes, the DSP screen, and wavefronts, even with a pic every two seconds.

[gr5]

You might want to try waveFrontPro. It's $20/month for hobbyists. It can do about 3 frames per second.

When you say your program would "trigger movements". Would a user do this, or would this step be automated?

[Lucassifoni]

The user would do this, or it would be automated, but according to a fixed movement script (i.e. in my app, not DFTFringe), not based on analysis results for the time being. Thank you for pointing to wavefrontPro, I did not know about it.

[githubdoe]

Actually while DFTFringe is mostly GUI code the analysis is uncoupled from the GUI in just a few .cpp files. So it should not be hard to move those files into something to do what you desire. I think.

[githubdoe]

Most all the GUI code is used to make the displays and allow the user to apply different filtering and averaging to remove the noise generated by the Bath interferometer. It might be easier to understand if you look at the original program OpenFringe. It has much less GUI and then you can discover the structure easier.

[githubdoe]

I don't think it would be hard to add some sort of interface to the code that listens for things to do on the web or some other form of pipe. Then it calls the analysis routines as required. I don't know how to do that but I can point to the routines one would call. Much like other programs that can do that like CAD or Video Editor programs.

[Lucassifoni]

Thank you Dale,
It seems that my limited (well, inexistant) knowledge of qt/c++ prevented me to see this decoupling. I will try to get to my needs in my fork and report back when/if I manage it

[githubdoe]

To help here is a clue. You can follow the code of the batch processor to see the steps it does. It is mainwindow.cpp and the routine called void MainWindow::batchProcess(QStringList fileList)

If you don't know C or C++ it might be hard to decipher. Otherwise It is straight forward c++ code.

[githubdoe]

You probably already have the knowledge to think about solutions but here is what AI says are ways that QT programs can present software interfaces.

Inter-Process Communication (IPC):
Qt provides classes for abstracting IPC, such as QLocalSocket and QLocalServer for communication between processes on the same machine, and QTcpSocket and QTcpServer for network communication. Many professional applications implement a server that listens for connections and commands from other authorized software [1].

D-Bus:
On Linux and Unix-based systems, D-Bus is a widely used message bus system that allows applications to communicate with each other. Qt provides the QtDBus module to integrate with this system, allowing applications to expose methods and receive signals [1].

Component Object Model (COM):
On Windows, applications can use COM (or its more modern variant, COM+) for inter-application communication and integration. This allows applications to expose functionality as reusable software components [1].

[Lucassifoni]

Thanks. I can read c/c++ but do not practice them professionally. I will follow through the batch processor, indeed it already orchestrates those steps without user input, so my initial request is very close