gaussian blur causes weird pixelated edges in simulated ronchi

[gr5]

Version 7.2.3 but I think it does it in many older versions as I've seen this before

To Reproduce
I processed igrams from a real mirror. I'll include pictures of the issue and a picture of a ronchigram of the real mirror.

I smoothed the wavefront with "tools" "smooth current wavefront" although that's not required to see the problem.

I created a perfect simulated wavefront and the same issue happens: looks bad if gaussian smoothing is on.

GOOD:

BAD:

ACTUAL:

[gr5]

I'm guessing the gaussian blur is widening the image by the number of pixels in the convolution and this isn't getting cropped at the edge of the mirror so somehow the ronchi code is including this extra data in it's calculations.

[gr5]

So I fixed this. Wow it was a lot of debugging. A big chunk of the work was understanding the arbitrary changes in outer and inner outlines. The outer outline I have to reduce by 2 pixels and the inner one I have to grow by 1 pixel. If I am off by even just 5 or so of 600,000 pixels scattered around the outer edge of either outline you see it easily in the foucault and ronchi views. Even just one pixel out of 600,000 missed in the outline is visible in foucault and ronchi as "something weird there". So the outlines have to be perfect for the gaussianBlur to work well.

So basically all I did was improve the gaussian blur. Big time. It understands edges now perfectly. It adds zero turned edge now. Yay!

Dale had gaussian blur functions in 3 locations (result tab blur, elliptical flats blur on results tab, and blur used for foucault and ronchi simulations). All 3 locations were controlled by the checkbox and percent we are familiar with.

Dale had improved only one of those 3 by using a function called expandBorder(). This improved things drastically and was 90% as good as the gaussianBlur I came up with in the end. expandBorder did a kind of mirror of the wavefront outside the outer outline (I think it does the same thing on the inner outline). Then he also checks "reflect border" option in cv::gaussianBlur which enlarges the matrix by a large border, reflects the matrix data beyond those edges as well. This wass important near where the circular border was near the matrix border (top, bottom, left, right).

The biggest problem with all this is that he didn't do the same thing for the ronchi and foucault gaussian blurs. So those were messed up quite a bit.

Anyway I fixed both locations with the new code. It is 2x slower but that's fine as it goes from about 15ms to about 30ms each time you do a blur. there are 2 blurs called (one for foucault and one for gaussian) when you do those simulations so this adds 60ms (for a 600X600 wavefront).

[gr5]

Comparison of wavefront smoothing versus gaussian blur.

First image is 14% gaussian blur which is as close as I could get to what it looks like when you do the wavefront smoothing

Second image (below) is with 196 terms.

The only reason they are different is because the smoothing algorithms smooth different zones. The zernike smoothing one smooths in zones of different shapes. So you can see some zonal rings. That aren't really there. I mean they are sort of there but not truly.

These have the inner outline as well as I had to make sure that worked perfectly as well. If you look at the raw data and the gaussian blurred data... these are as perfect as you can get. In the 3d view and also in the ronchi/foucault views.

I personally think the gaussian blur one is more useful now (imagine that!!). It's now going to be more of a personal preference. Certainly the gaussian one is faster since the zernike smoothing took I think about 2 minutes.

I will create a PR later today. I need to merge in master first. And I want to clean up some comments.

[atsju]

Great work !

I haven't seen the code but now that you know it best: does it make sense to have a GaussianBlur class that would be called from the 3 locations you identified ? (If there are different blur algorithms then a blur class and specific inheriting classes.)

Just thinking maintainability/abstraction and futur fixes/evolutions.

[gr5]

I created a new function called cropGaussianBlur() which takes similar arguments but also the inner and outer outlines. I put it in it's own cpp file with it's own .h file. At one point there were 3 functions - one for debugging - but I deleted the debugging one. And one did the blur with my own painstaking code. But that was slower so that's gone as well.

So now it's all in one function by itself in a .cpp and a one line .h file.

I could move it into utils if you prefer. I don't see how it's a class. It takes generic cv::Mat matrix classes as parameters. Dale creates these matrix's and passes them all around on the fly and manipulates them. Particularly for the ronchi simulation.

Should I move it to utils.cpp?

[gr5]

I moved it to utils.cpp. This way no changes to the .pro files also.

[atsju]

I don't see how it's a class

I'm not OOP expert. Discussion with IA, what I though is named a utility class but it seem best approach is a namespace in our case.

What you described is perfectly fine. I'm fine with utils.h.

I will do the review tomorrow or this weekend

[githubdoe]

I class usually is used for things that have state it wants to save and thus member variables. This is just a function and is fine as is. Some would argue it should have it's own class. I don't care if it is until or it's own.