ronchi and foucault show too much rough information

[gr5]

Testing with 8.1.0 and I notice for that 100th time. If I only have one igram and try to look at ronchi and foucault I get lots of fringe "print through". I can up the gaussian blur to say 25% and even though the 3d view of the wavefront shows zero print through and looks extremely smooth, the simulated foucault looks awful with fringe print through (red circled area below). Also the outer circumpherence of the foucault is nasty (blue circled area below).

My work around is to always smooth the wavefront (menu tools "smooth current wavefront") and then I also have to disable gaussian smoothing to fix the blue circled issue.

It appears that for the ronchi and foucault, the smoothing is done to the ronchi and foucault images instead of to the wavefront (and then create the ronchi and foucault from the gaussian smoothed wavefront).

I propose to do the gaussian smoothing first, and then create the ronchi/foucault images instead of the other way around.

[githubdoe]

I can't imagine ever smoothing the image instead of the wave front. Can you point to the code that does that?

[gr5]

I didn't look at the code. I'll look at this whole thing some day.

I'll play with this some more some day. But typically 8% blur makes the print through go away in the contour plot. Completely invisible/gone. Yet even with 25% blur I still get print through in the foucault. Still very visible but blurrier.

[githubdoe]

Oh, so it was just a guess. I never say never but- I never would use the Gaussian blur on an image on purpose. In fact I'm not sure it would even work on an image. IIRC There might be left over debugging versions of it but even that is not likely.

[githubdoe]

However you did discover a difference. Foucault and Ronchi images need to use a non nulled wave front. The code creates that but uses a different value for the blur than it should.

It uses mirror diameter to compute the blur radius but it should use the wave front mirror radius in pixels to pass the radius to the blur routine instead of the many times smaller mirror diameter.

Wrong code is inside ::nulledSurface in simulationview.cpp. Correct code can be found in SurfaceManager::generateSurfaceFromWavefront()

After the fix you are going to find that blurring the edge creates a bad artifact around the ronchi image. I think because it turns the edge. I don't think that can be avoided. I usually try to avoid doing any GB when viewing Ronchi and Foucault images. I use the smooth wave front feature instead because it will not turn the edge.

[gr5]

Nice! Thanks for pointing me to the code. Yes it would be nice to always use the smooth wave front before viewing ronchi/foucault. Or maybe no smoothing at all if it's like 100 igrams averaged.

Unfortunately smoothing takes more time. Maybe there should be a popup warning people that they should really smooth the image first. But then DFTF would have to mark which wavefronts have been smoothed.

[gr5]

Okay I see the bug. gaussian blur - you are using opencv funtion cv::GaussianBlur() which is blurring a square matrix. But the image is cicular and so it's averaging stuff beyond the edge of the mirror into the mirror's edge. This is also messing up the edge in the normal results plots (all 3 plots).

I'll write our own gaussian blur that ignores data outside the borders (the outer edge and the inner border as well (if it exists for the current wavefront).

[gr5]

To be clear, there are 2 bugs and I'll fix both:

1. GB for ronchi/foucault simulations is different blurring amount than for results page but they should be the same.
2. current GB takes a square matrix and is averaging in all those pixels beyond the edge of the mirror. I'll fix that also.

[gr5]

Oh. I bet cv::GaussianBlur() is using FFTs to save time. But that won't work with the edges. I want to do a simpler convolution but it will probably by much much slower than the FFT algorithm. Especially as the diameter of the blur function gets bigger. We'll see.

[githubdoe]

I don't think it matters if you blur the whole or the circle. Using a circle boundary still means you have to do something different at the border of the circle. It takes a lot of work to do something that makes sense like reflect. But the reflect is more complicated because now it needs to be on a radius and at an angle. I once tried that but it was not satisfactory. All of that is one reason why I decided to make the zernike based blur. It does not have those issues. It is meant to replace the GB when you need a more accurate noise removal method.

[gr5]

Well when the convolution pattern goes beyond the edge of the mirror you can just skip over those points and add up all the others multiplied by the convolultion. Then instead of dividing by the sum of the pattern (which is usually normalized to 1) you divide by the portion of the pattern that isn't beyond the edge of the mirror.

It should work beautifully. But it may be very slow.

Also typically you save time by doing the gaussian convolution only in one dimension (horizontal pattern) and then repeat vertically. This saves a lot of time multiplications but I don't know if that works with my edge technique.

For a NxN image with a MxM convolution gaussian pattern, to multiply them normally you need N^2M^2 multiplies. With the 1D method twice you get the same result witn N^2m*2 multiplies which is a LOT faster. I think that's how openCV probably does it. That's how the algorithm is described on wikipedia.

Anyway I have to write some code and test it out. See if it's fast (useful) or slower than the zernike smoothing method (then my code would be useless).

[githubdoe]

You are welcome to try any of those methods. Just realize that I tried many of them as well.

[atsju]

@gr5
I had some discussion with chatGPT for fun. Have a look if you want.
https://chatgpt.com/share/690e293e-9df0-800c-b65a-3cb231f50edc

Initially I though it's easy to to gaussian blur without bleeding. And that's true. It's easy to not have artifacts from outside of circle.
But I have run some code (100% vibe coding) and now I get what Dale is explaining. Edges are not blurred like the rest is. You might see some artifacts in some way. And this is even true for the slow convolution method

See ? there is an artifact of the strip while blur is almost perfect in center.

It looks like the reflect method that Dale mentions is not working either but I did not look too much into this one.

Thinking out loud: can we generate a larger picture from zernike polynomials ? Like extrapoling wavefront to a mirror larger than real one by kernel size / 2. Then maybe you can blur without artifacts. I don't know if that makes sense.

[githubdoe]

In my opinion the fix is to use zernike smoothing. Don't bother with the Gaussian Blur. I worked a long time at this. I doubt that anyone will find a better solution. It should be a low priority task.

[gr5]

Julien that blur you did above works extremely well. It ignores the red/yellow areas. Somehow you masked them out. The extra blue at the bottom is as expected. I'd call it a bug if it didn't show the darker blue there.

The gaussianBlur function that Dale uses in opencv doesn't know about the edge of the circle at all. There is no mask or anything sent to that function so it's averaging in crazy values just beyond the edge. I mean some of those values are many waves different particularly if you have many waves of tilt.

I already wrote the new gaussian blur function. I still have to test it.

The function I wrote does know where to mask out. I'm extremely confident it will work better than averaging in the yellow/red area as it completely ignores that. But that doesn't mean it will do something else weird.

My bigger worry is code speed.

[gr5]

the fix is to use zernike smoothing.

Definitely true if it's faster than the gaussian smoothing function I just wrote. We'll see.