githubdoe / dftfringe Goto Github PK
View Code? Open in Web Editor NEWDFTFringe Telescope Mirror interferometry analysis Program.
License: GNU General Public License v3.0
DFTFringe Telescope Mirror interferometry analysis Program.
License: GNU General Public License v3.0
Hi,
Thank you for providing more open source optics software. I would like to make a make a few suggestions. For beginner user it would be useful to provide sample files to experiment with your program. Also, a short tutorial may be worth considering.
Sorry would like to close/delete this one as I created a more detailed version in the next issue before I learned how to edit this. Will try to figure out how to delete this one.
After reading zernike values from a .zrn file the create wave front creates one with all zero zernike values instead of the ones just read.
This is a placeholder to discuss any changes needed to get DFTFringe to compile on a mac.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
both panes should load the new colormap
Desktop (please complete the following information):
Describe the bug
The angle of the profile diameter doesn't quite match the dashed line. It's off by maybe 5 degrees.
The red circled areas in the screenshot below refer to the same spot but the dashed line (blue circle) is off by a bit.
To Reproduce
Find an obvious high or slow spot and rotate the angle until you see the object in the lower profile plot. Note that the diameter misses the object in the upper plot. Or vice versa.
I've been noticing this bug for a long time but thought I'd create an issue.
Desktop (please complete the following information):
This is build candidate for 7.0.0 so the bug should be in 7.0.0 but technically the build is from master version on 8/23/23
In windows.
I put this here only for developpers tracking purpose.
According to this thread, zernike code needs to be updated to 2022 version
https://groups.io/g/Interferometry/topic/103666155
Feel free to add context and information
I'm leaning to calling it Version 7.0 Because from a users perspective it now supports Mac and Linux users.
That way we can refer them to Version 7 when they what to know which version now gives them support to start with.
Hey thats a fedback th the new V3.2B.
I hope this is the right place for feedback.
I tried to analyse an Igram in Autokollimation. Works well but when i tryed to edit the colors, the contour tab is greyed out. No changes can be made.
Second: In V3.2 When i try to change the max/min scale to min=0 and max= 0,5 waves the 2D plot works well but the 3D plot became black in some low parts of the Plot.
thanks cs
Describe the bug
tools -> DebugStuff opens no window and does nothing apparently.
Please confirm
Desktop (please complete the following information):
** Note **
help -> version history is also affected but this is just RevisionHistory.html file missing in installer. I will provide a fix.
I actually already wrote the code and am creating a request to match with the pull request.
There were several options (linear, nearest neighbor, cubic, etc) that were ignored by the rotation code so I wanted to just get rid of this bit of GUI. No need to waste people's time trying to choose which interpolation method when it is then ignored (Dale does bilinear interpolation with some custom features related to when a source pixel is masked).
Worked on a project that had regions.
Switched to a different project and started to outline igram. Regions from other project were there. So I deleted them. Then I auto traced the outline. Regions came back.
So two issues.
Need some way to decide when to drop the saved regions that are saved in the QSettings. Lets say on loading a different config or a different base path for igrams.
Figure out how deleted regions don't stay deleted.
Describe the bug
log shows
[2023-11-05 18:09:15.466] [warning] QT message handler: QBasicTimer::start: QBasicTimer can only be used with threads started with QThread
[2023-11-05 18:09:15.470] [warning] QT message handler: QBasicTimer::start: QBasicTimer can only be used with threads started with QThread
To Reproduce
Run and close the application.
Might need to load and analyse igrams
Desktop (please complete the following information):
Additional context
Seems to happen at deletion. Might come from order of object deletion because of limited parent/child relation or might be an other issue. Additional investigation is needed. Low priority as it doesn't affect users.
To Reproduce
For the following, first process an igram to get a wavefront. Then:
needs igram loaded but not a wavefront
1.tools outline helper
others - just launch dialog and close window:
tools tilt versus astig analysis - first you need to create a zernike csv file. With one or more wavefronts loaded do "file" "save zernike values in csv". Then run the astig analysis off the csv file.
Expected behavior
all dialogs should close when closing DFTF main window.
Desktop (please complete the following information):
win11, master branch as of 8/23/23 - probably will become v7.0.0
Playing around I discovered that if an igram does not have an outline and earlier I gave an outline also an ignore region so that it became the default outline (save in the registry). Then that region will appear. Then if I delete that region and process the igram the next igram without a region gets that deleted region. I once found that I was not updating the region in the registry when I deleted the outline. Is that still the case?
George. Check it out please.
Issue 2.
Astig stats display. When display only averages is check just the average of each of the rotations should be shown. I know longer remember exactly how I figured out what wavef ront were in what rotation. Probably used the directory structure. Or maybe just looked for the some text like avg in the wave front name. Anyway all wave fronts were plotted instead when I expected only the average to be plotted.
I load igram DSC_1452. There should already be an ignore region around the bad spot from oln file. click done. Click computer surface. All works well every time.
Now change a zernike checkbox and click "recompute". It seemingly reanalyzes the ignore region and fills it in with crazy values - many waves up/down from normal.
Describe the bug
Menu item "tools" "smooth current wave front" - if you increase size of zernike terms or just click "create wave front" button, it crashes
correction! It only crashes if you have an inner outline:
After creating outer outline, but before processing the igram, select the "central hole" radio button near the top, then use the mouse to draw a circle inside your igram. I did about 10% of the total diameter. I've tried many different sized inner diameters including some only a few pixels across.
version
tag 7.1.0 (not released) - the version built by github.
7.0.0 also crashes
When I build it myself in QT in debug or release mode it does not crash. I have a different version of the armadillo .h files.
stacktrace
[2023-11-07 10:58:34.004] [critical] Unexpected issue. Stacktrace:
2# 0x000000006FC56FA8 in C:\Users\gr770\DFTF710RC\libstdc++-6.dll
3# 0x000000006FCFD093 in C:\Users\gr770\DFTF710RC\libstdc++-6.dll
4# 0x000000006FD05E12 in C:\Users\gr770\DFTF710RC\libstdc++-6.dll
5# 0x00000000005B9835 in C:\Users\gr770\DFTF710RC\DFTFringe.exe ...ingw32/8.1.0/include/c++/bits/basic_string.h:211
6# 0x0000000000504FF4 in C:\Users\gr770\DFTF710RC\DFTFringe.exe include/armadillo_bits/Mat_meat.hpp:424
7# 0x0000000000507AAE in C:\Users\gr770\DFTF710RC\DFTFringe.exe zernikeprocess.cpp:1422
8# 0x00000000005085A0 in C:\Users\gr770\DFTF710RC\DFTFringe.exe
9# 0x000000000050C4C2 in C:\Users\gr770\DFTF710RC\DFTFringe.exe
Describe the bug
Double click on a wavefront does no permit to rename it.
Once you renamed one wvft with right click they become editable/renamable with double click.
Improvement
I would like to be able to rename using F2 which is standard renaming shortcut on windows
Up/down + enter should select/display the wavefront. Today a click is mandatory and this bothers me as a user.
I'm already working on the code so this issue is more about getting a feedback while working on it.
My basic proposal (this is all nativelly supported by QListWidget)
Potentially controversial proposal
Both the double click and right click are a bit of masked features that a user will not naturally find if he doesn't know about it.
This issue is to track me research.
maybe we can remove it if unused
As stated in #61 (see further discussion in PR itself) :
QString name;
QVector<std::vector<cv::Point> > regions;
bool regions_have_been_expanded;
Also the copy constructor does a deep copy of cv::Mat while the copy operator does not. I'm not sure this is OK or not. I suppose Dale took care of using new
operator where he needed deep copy but I'm not sure this is correct approach.
Note that for the destructor, I think a default one would work fine. clear
is supposed to be called automatically in cv::mat destructor.
Version 6.2
From my understanding, today the .oln file contains the outline, regions and the DFT limit. This lets user reload same picture and modify slightly outline. When loading igram, the outline is loaded automagically.
Problem: on my computer, when loading an igram, the corresponding outline and DFT are loaded, but regions are not.
When I reload the outline file manually, everything is updated correctly
When opening an igram among the list of extensions (.jpg) should also be included ".JPG" (and *.JPEG, *.jpeg, and perhaps png and perhaps more).
In linux file names are case sensitive. You can have a.jpg and a.JPG and they are two separate files potentially in the same folder. You can't do that in windows. Adding "JPG" will make the program easier to use (you don't have to choose "all file types" and you don't have to avoid all the other non-image files).
Describe the bug
regions grow on every recalculation. This is bad. Someone might want to change the zernike checkboxes (e.g. remove astig) then you have to hit recalculate and now the regions grow again.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
Regions shouldn't keep growing.
Fix
Well I'm not sure we should be growing them in the first place but one could add a flag to the region to keep track of whether it has been grown or not and never run the expansion code the second time.
This may be a duplicate. I just tried to start a report but hit return earlier and that then may have created a blank bug report. Could not figure out how to remove it or change it. If in fact it was recorded.
In the mirror config set a non-zero obstruction.
It should show up in all of the displays. It only shows up on the profile plot. But should show up on the 3d, Contour, Star test, PSF, and MTF. I don't remember if it should also on the ronchi foucault.
It does work on version 6.4.
Did figure out how to edit. Yes it should show up on Ronchi and Foucault as well.
Version 6.2
When loading a batch of igram, I then reduce the window "batch process igrams" (closing aborts the process).
But until I'm finished with batch processing, the mouse is not an arrow anymore but has the circular shape for "loading". It's quite disturbing as the computer is waiting for my input and not for an internal action to finish. When i see the "loading" icon, I generally wait for it to return to normal before doing anything else
Describe the bug
"show only average" does still show all points.
probably introduced by my change in #75 :(
Desktop (please complete the following information):
I don't know if this makes sense but as we already change outline file to v7 it's the right moment to do it (if it makes sense).
When loading Igrams in auto mode everything works fine but if one of the wavefront seems inverted then there is a popup to ask about inversion. Does it makes sense to store the info in oln ?
After cleaning over 600 warnings, I finally found 2 wich could have an effect.
Line 1566 in 9320be9
Same for
Line 673 in 9320be9
@gr5 @githubdoe I let you fix them as I still do not have the level to dig into it and you will best know the effect of this potential problem.
One the Foucault Ronchi tab
Set start offset to -.1 set end offset to .1 set step size to .01
Set the ROC multiplier to 10
press scan it should change the roc offset from -.1 to .1 in steps of .01 displaying those images one at a time and then stop.
Instead it display only the very first offset image and thinks it done.
Then start and end computations use the wrong value. I bet it mistakenly uses the ronchi roc offset. Which was added more recently and modified by the ROC multiplier to get it to display better since ronchi needs larger offsets to display meaningful results.
If I set the Ronchi ROC multiplier to 1 it works as expected. I think it would work if it watched the Foucault offset instead of the ROC offset. As I said there use to be only one offset until I added the ronchi ROC multiplier.
Sorry guys. Can one of your look at that?
I realize there are several dozen files missing in this repository. I'll add them. None are crucial. Some are jpg files needed for the help documentation (html files) and some are color maps. Nothing critical. I'll take care of this. This issue is to remind me to rectify this.
There has been lots of great work on CI side recently. Now that we have available builds for three platforms, it might be good to include some basic 'linting' on commit.
I know that when I cloned the repo and saved a file (with no edits), git would show changes due to the Mac vs Windows line endings, for example.
This could initially be used to solve problems with:
I'm thinking really basic to begin with. Line endings, duplicate includes, etc...
We can gradually introduce other rules over time, including being able to enforce coding style.
Er...
Don't do anything?
Or maybe there is some repo or editor setting that could achieve this?
I've have no idea how to do this, but I know it can be done in a fairly off-the-shelf manner from other projects I've been on. @atsju is this something you have experience of?
example data and result:
https://groups.io/g/Interferometry/topic/97668823#33021
I'd like to work on this issue. It probably won't be for a few weeks but I'd like to look at the code for this and see if I can come up with a solution.
Perhaps not a bug but a consequence of how outlines are now saved and it can not be helped.
I tried to use version 6 of DFT on the igrams I processed with Version 7 to do some comparisons.
I was trying to use the Batch feature in Auto mode where it would use the existing outline and process all the igrams without intervention.
It claimed there were no outlines for those igrams. I suppose it is because they are now in the new format and can not be read by the old versions. If so that is unfortunate but I suppose can not be helped. It will hit those people like Ric who quickly revert to an old version after thinking 7 or later has bugs. But I don't know any way to avoid it.
I was trying to see if the Batch feature was the cause of the slow computing of the DFT in Version 7. I have found that version 7 intermittently has slow computes when I use it's Batch mode. It may also have them in single mode. However when I try it in single mode an igam that was slow in batch works fast. Then when I go back into batch mode a different igram will become slow. So confusing to figure out what is going on. I was hoping to see if it happened in version 6. But I will have to create outlines compatible with it first. I don't know why Batch mode would be any different than single mode but the issue happened first last night when I was Batch process a set of igrams for Pierre Lemay. (a new Bath and DFTFringe user.)
This is what astigstatsdlg should look like after QTcreator
This is what it actually looks like (before you ask, picture is from 6.2, so before I "messed" with ui files)
This is why I did not see the missing i
effect in #71 during my tests. I couldn't use/test the affected code.
I also found out a different place in original code where i
was not incremented and should be. I will try to fix all this...
I had 5 crashes while using official version 6.2
I have been unable to reproduce the crashes reliably so I can't even tell you what to fix. I think DFTF should catch all exceptions and either write into a log file or show a crash window for people to copy paste the call stack into an issue. It should not close/crash silently. This is standard practice to help developpers fix issues happening on "customer" side.
here are information from windows event report. Not very usefull.
Nom de l’application défaillante DFTFringe.exe, version : 0.0.0.0, horodatage : 0x63db083b
Nom du module défaillant : libgcc_s_seh-1.dll, version : 0.0.0.0, horodatage : 0x00000000
Code d’exception : 0x40000015
Décalage d’erreur : 0x000000000000d6a5
ID du processus défaillant : 0x3b8c
Heure de début de l’application défaillante : 0x01d95ff7eda6c2ff
Chemin d’accès de l’application défaillante : C:\DFTFringe64\DFTFringe.exe
Chemin d’accès du module défaillant: C:\DFTFringe64\libgcc_s_seh-1.dll
ID de rapport : 18c77f35-82bc-4ac2-8d20-1c7e59baf140
Nom complet du package défaillant :
ID de l’application relative au package défaillant :
Nom de l’application défaillante DFTFringe.exe, version : 0.0.0.0, horodatage : 0x63db083b
Nom du module défaillant : libopencv_core3412.dll, version : 0.0.0.0, horodatage : 0x5fddbfdb
Code d’exception : 0x40000015
Décalage d’erreur : 0x000000000023e078
ID du processus défaillant : 0x39d8
Heure de début de l’application défaillante : 0x01d95ff0660379b8
Chemin d’accès de l’application défaillante : C:\DFTFringe64\DFTFringe.exe
Chemin d’accès du module défaillant: C:\DFTFringe64\libopencv_core3412.dll
ID de rapport : a8ff05b6-894e-4a0f-b156-5b5ec77b43d4
Nom complet du package défaillant :
ID de l’application relative au package défaillant :
I just managed to run clazy with exclusion pattern to get only warnings from DFTF code.
Total 8697 warnings
But 8512 of them are connect-by-name and I suppose we must ignore them because nobody plans on updating this
This means we have 185 more meaningfull warns. Not too bad.
clang also generated some [-Woverloaded-virtual]
and [-Wabsolute-value]
. I will probably fix the [-Wabsolute-value]
during #34 I noticed changing the colormap was not natural for me. This means UI is not optimal and could be improved.
Buttons are not logical :
Close should be cancel
Apply should be on the right
Something natural would be :
or
Of course details need to be discussed as none of these proposals are 100% right but cancel and restoreDefault sounds more logical
Also this window should be under "settings" instead "tools" IMHO
Describe the bug
zoom level gets stuck in right wavefront window
To Reproduce
Load an igram, process it click in drag in right window to zoom in somewhat
Without right clicking, go back to igram tab and process again (click "done" then "process igram". now this second wavefront is still zoomed in but it is stuck zoomed in. Right clicking doesn't zoom out.
Expected behavior
Right clicking should zoom back out. Probably should not start zoomed in. Maybe.
"Regions" are free form or line.
A circle shape would be appreciated as it requires only 2 positions to exclude the main laser dot (my laser is especially bad and doesn't give a real "dot", it shows several diffraction circles).
Also regions can only be deleted with button. "dell" key could be a shortcut for any delete action.
And I noticed the zooming into picture of when in region mode, will only work if edge zoom is deactivated.
Describe the bug
null value sometimes ignores edge mask
I personally verified this bug found by Walt
To Reproduce
Screenshots
Can be found in this discussion
https://groups.io/g/Interferometry/message/33334
Mike Peck posted his latest algorithms several months back. The annular algorithms need to be updated into DFTFringe. You may need to get that code from his R repos. They are in C or C++. There is a place in DFTFringe that uses them if the central obstruction exceed a percentage of mirror radius and annular uses is enable from the preferences.
The center between Ronchi and Foucault images should be a number scale. It worked back in version 4.0 but maybe not in version 6 and later. However this display shows version 7.0. I had though it was my usual problem trying to use my 4K laptop screen but this image is from setting my screen down to 1920 x 1080. Probably related to pixels per inch and windows and qt problems I have never understood.
That is text becomes too tiny when I use my 4K display in 4K. So some places I changed the forms to force it bigger but not everywhere. I gave up and hopped most users would use the smaller screen resolution. But that also creates issues. Oh, well. Hope someone can figure out something.
Describe the bug
This line of code in zernikeprocess.cpp is probably wrong:
if (mask.at<bool>(x,y))
All the other times the at() function is used it's y,x. not x,y. This probably only affects regions as outlines are symmetrical across the y=x symmetrical axis. Regions are not. So no one would notice the bug unless they use regions feature.
I'm not certain but I think this code is used in the zernike smoothing feature which is relatively new and probably not used by very many people.
I load wat.jpg, autotrace outline, done, then "show resized image" crashed the application
version 6.0 on win10
Is your feature request related to a problem? Please describe.
When edge mask is non-zero and also unchecked, sometimes it seems to act as though it is checked. The checkbox and value are found in "configuration" "mirror"
Describe the solution you'd like
Just set the value to zero when unchecked.
Describe alternatives you've considered
Instead, all code that uses edge mask could only use the value if checkbox is checked.
Additional context
https://groups.io/g/Interferometry/topic/102697035
Describe the bug
The code that expands the region size by "10%" can expand it beyond the matrix and cause a crash or sometimes create an empty wavefront. Different behaviors depending on unknown factors.
To Reproduce
Create a region well above and left of the mirror before hitting the crop button. After cropping the region is in the negative x and y space.
Process the igram normallly and program crashes.
I already have a fix. Will create pull request asap. The problem is that I keep the region points within the matrix but I need to repeat that code after the "10% expansion" occurs. Very simple fix. If all the points for example are above and left they all end up at 0,0 and the expansion is infinite.
Even if all the points are within the igram, after cropping, if the region is big enough and near (or a little beyond) the edge of the igram, 10% could possibly push the region just outside the matrix.
Version 7 takes up to 7 seconds to compute the DFT of some of the igrams I have tested compared to fractions of a second for my older version.
The igrams I have just tested are only 640 x 640 big with the mirror diameter being only 160 x 160 pixels. So that makes the DFT very small and should not take any time to compute.
I also see a pause after compute surface is pressed that can take several seconds on version 7 and not on the earlier versions.
This is an issue to track macOS build issues.
The version of the QT framework we use in DFTFringe cannot be built with the latest release of macOS (Sonoma, version 14). I have to use this macOS version so haven't been able to build DFTFringe for a couple of months now.
The good news is that the problem has been fixed in the commercial version of QT. The bad news is that it doesn't look like it will get released into the open source repository anytime soon.
However, the relevant issue(s) in their bug tracker do contain all the patch info required (I think!). Yes, its a bit messy, but I dont think there is a great solution right now.
So, I'll attempt to build a new version in the not too distant future!
Dan
To Reproduce
Create a region somewhere in the igram. Process normally. Repeat hundreds of times restarting DFTF each time until you get a massive multi-wavelength spike in the region. The whole region.
Expected behavior
A smooth area where the region outline was.
Screenshot of the issue
Notice how my region (squarish spot) is many (48.1357 to be exact when looking at debug output) waves too high in this example. Strange that term 48 was a value close to 48 but another time it was 111.943 so just a coincidence I guess.
So I figured out the issue. The fillVoid() is using 49 zernike terms but the last one is sometimes a crazy value. The fix will be to limit to Z_TERMS zernike values when filling in the voids. I don't know why the last one is a crazy value but I'm just going to limit smoothing to Z_TERMS.
I call it "smoothing" because it's almost the same code as the zernike smoothing code except it only uses the existing, available zernike values.
This took many hundreds of tries before I was lucky enough to get the bug to happen (was testing something unrelated) and also we had logging running. I wouldn't have found this without Julien's new logging feature.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.