Date   

Re: testing parabola with center hole

Dale Eason
 

The hole needs to be less than 30% the diameter in order for the Zernike values to be correct.  DFTFringe does not use the annular set of polynomials needed to test rings with large central holes.


Re: testing parabola with center hole

George Roberts (Boston)
 

Oh - maybe you are asking about the reference beam.  The reference beam doesn't have to bounce off the center of the mirror - you can aim it at any part of the mirror.


Re: testing parabola with center hole

George Roberts (Boston)
 

I'm not sure I understand the question.  With a bath, you test parabolic and spherical mirrors the same whether they have a hole (aka perforation) or not.

The DFTFringe lets you setup an ignore region where the hole is.  It's in the same page as when you setup the outline.  In the upper right there are 3 radio buttons where you can setup the "mirror outside" "central hole" and ignore "region"s.  The "central hole" option is just for this purpose you seem to be describing.


testing parabola with center hole

Peter Chen
 

Hi folks. 
Does anyone have any suggestions on how to use a Bath to test a parabola with a center hole?  With a minimum of auxiliary optics.

Thanks,
P.C. Chen


Updated Wiki Page: Numeric NULL #wiki-notice

Interferometry@groups.io Notification <Interferometry@...>
 

The wiki page Numeric NULL has been updated by Bruce Griffiths.

Reason: Updated wiki entry on Numeric null to include numeric nulls for hyperboloids, oblate spheroids, ellipsoids...

Compare Revisions


RR results

vladimir galogaza
 

Dale,

In the latest file with RR results there is a graph of Zernike coefficients for all participants.
Can you please send me the list of those coefficient  numerical values for each
participant, or tell me where they are available.
Thanks in  advance.
Vladimir.

--
Vladimir


Re: Errors in DFT based fringe analysis

Mladen, Florida, USA
 

On Fri, Jul 24, 2020 at 09:56 AM, George Roberts (Boston) wrote:
Hopefully you all understand that in the cases of these simulations, peak to peak error is a bad measure and RMS error is much better. 
For simulated theoretical igram analysis which cannot yield an error-free wavefront because of the way the software operates, the edge should be ignored. In my first 150 mm f/8 example with a total of only 10 fringes/pupil (X tilt = 5), the edge was 0.04 waves rms off. This edge error progressively diminished as the number of fringes increased until the results matched a theoretically perfect mirror (at X= 5, 60 fringes/pupil).

This will probably not be the case with larger and faster mirror simulations, so it's important to keep in mind that these edge errors are simple artifacts ("fudge factors") of software and should be ignored


Re: DFTFringe and .png files

Dale Eason
 

On Fri, Jul 24, 2020 at 10:58 AM, Sorin wrote:
I was able to analyze a single igram of 2000x2000.
Yes you are right.  I was thinking I had tried that size before and could not.  It is slow but it works.


Re: DFTFringe and .png files

Dale Eason
 

On Fri, Jul 24, 2020 at 11:00 AM, Michael Peck wrote:
32 bits would mean it has 3 bytes for RGB and another one for transparency.
In my case just to try and figure it out I used windows explorer to show me the file details.  In that one case it said the .png file bit depth was 32 bits and the .tif I made from it using irfranview had 24 bit depth.  I assumed that meant the value of a pixel could be 32 to bits and 24 bits respectively.  Since the image was grayscale I thought that might be the size of the pixel for one channel.

I could with time dig deeper and display what OpenCV thinks are the parameters for a pixel for that .png.

Dale.


Re: DFTFringe and .png files

Dale Eason
 

On Fri, Jul 24, 2020 at 10:58 AM, Sorin wrote:
It seems that gimp, irfanviewer and also many other online converters are not able to correctly convert that file.
I used irfanview to convert it to .tiff yesterday to get the original .png to work with DFTFringe.

In fact it was an accident that I discovered that the original did not have black center lines.  I was using irfanview to scan through some images in my tmp directory where the .png file was.  I went past the images I intended to view and displayed the .png file.  I was surprised to see it displayed without black center lines.  So then I investigated further resulting in my rework of the analysis and deletion of the old analysis.


Re: DFTFringe and .png files

Michael Peck
 

OK it worked. This is an 8 bit per pixel png file with the same dimensions as before (2000 x 2000). Kind of interesting quantization noise is visible and manifests as fringe print through and some apparent shot noise. It's very low amplitude though:


Re: DFTFringe and .png files

Michael Peck
 

On 7/24/2020 10:30 AM, Dale Eason wrote:
Mike I would like to investigate the .png issue.

I see your image is a 32 bit depth.  It is also 2K x 2K.  DFTFringe runs out of memory processing 2K x 2K.  So it must be reduced in size.  That of course can create artifacts.

I'm guessing the 32 bit depth is the issue for me.  The software I use to read it or convert to floating point is not working as expected.

When I converted it to .tiff the tif it turned it into a 24 bit bit depth and then it worked. 

Can you create one with either a smaller max value or a smaller bit depth.  For me to see how that works?


_._,_._,_

Dale:

32 bits would mean it has 3 bytes for RGB and another one for transparency. I used R's built in graphics functions to create that file. They don't offer much control and sometimes strange things happen when copying from an R graphics device to a file.

I just browsed through the packages installed on my Linux PC and found ones named jpeg, png, and tiff. All 3 have the same author and two functions named readXXX and writeXXX that do the obvious things with more control over what gets written (or read). So, yeah I can create an 8 bit png with a 1-1 mapping of the matrix data if you want.

Mike

-- 
Michael Peck
http://wildlife-pix.com
mlpeck54 -at- earthlink.net


Re: DFTFringe and .png files

Sorin
 

Dale,

It seems that gimp, irfanviewer and also many other online converters are not able to correctly convert that file.
The first time, I used photoshop which produces a good tif for DFTFringe.
Still, this online converter seems to also work well:

I was able to analyze a single igram of 2000x2000.

Sorin



On Friday, July 24, 2020, 6:38:12 PM GMT+3, Dale Eason <doeason@...> wrote:


Sorin,
I see you got DFTFringe to import the .png file without the issue I see.  Is that correct?  You did not change the format of the file?  If so then you computer converts them better than mine.  Hmmm.

Dale


Re: DFTFringe and .png files

Dale Eason
 

Sorin,
I see you got DFTFringe to import the .png file without the issue I see.  Is that correct?  You did not change the format of the file?  If so then you computer converts them better than mine.  Hmmm.

Dale


DFTFringe and .png files

Dale Eason
 

Mike I would like to investigate the .png issue.

I see your image is a 32 bit depth.  It is also 2K x 2K.  DFTFringe runs out of memory processing 2K x 2K.  So it must be reduced in size.  That of course can create artifacts.

I'm guessing the 32 bit depth is the issue for me.  The software I use to read it or convert to floating point is not working as expected.

When I converted it to .tiff the tif it turned it into a 24 bit bit depth and then it worked. 

Can you create one with either a smaller max value or a smaller bit depth.  For me to see how that works?

If 32 bit depth is the issue then I really don't know how to fix it since I rely on libraries (OpenCV) to do the job.  It could be that I'm not using that library  correctly to covert to a floating point value of 0 to 1.  Which DFTFringe uses to process them.  

Fortunately most cameras do not create an image like that.  That is with max pixel value = 32 bit depth.

Dale


Re: Errors in DFT based fringe analysis

George Roberts (Boston)
 

Hopefully you all understand that in the cases of these simulations, peak to peak error is a bad measure and RMS error is much better.  Because 99% of the surface is much flatter than the tiny edge.  So that tiny edge error is almost inconsequential.

When looking through a real mirror if 1% of the surface has 1/2 wave peak to peak error and 99% of the surface has 1/20 peak to peak error I hope we can agree it's effectively a 1/20 peak to peak error mirror (it is not 1/20 p to p, but effectively it is).

This is why RMS error is a better measure in general but especially where most of the mirror has much less error than a small area of the mirror.  More typically the error is spread out in a larger area and peak to peak error works good enough as a measurement.


Re: Errors in DFT based fringe analysis

Michael Peck
 

On 7/24/2020 3:38 AM, Sorin via groups.io wrote:

I attached the analysis outputs from both. Both have rms=0.005 and strehl=0.999. The artefacts in DFTFringe have a peak to valley height of about 0.25 waves, but in my R analysis are larger: 0.7 waves.
Maybe the results depend on the fft filter size, which is difficult to set for this particular interferogram (there are large halo's around the central lobes).

Sorin


_._,_._,_

Sorin:

Dale's second analysis is closer to both yours and mine. There must have been some weird artifact introduced in either writing or reading the png file. It looks like DFTFringe and my version of the vortex transform algorithm produce substantially similar results, which doesn't surprise me since both versions relied heavily on Steve Koehler's understanding of the implementation details.

My software produces a net wavefront with Zernike components removed that are intended to be ignored plus the software null (if any) applied. This is the same thing DFTFringe produces only without any form of low pass filter applied. It also returns a Zernike fit wavefront with user specifiable maximum polynomial order. The Zernike fit is my preferred low pass filter, although in this case it produces some really interesting artifacts. So does a Gaussian blur, but they're much smaller amplitude.

-- 
Michael Peck
http://wildlife-pix.com
mlpeck54 -at- earthlink.net


Re: Errors in DFT based fringe analysis

Sorin
 

Dale,

I think your analysis of Mike synthetic interferogram is not correct. Those too large ripples produce a ten times larger rms value: rms=0.04.
I can't say why it is so different. I did myself the same analysis and the result is pretty close to the Michael software output.

I attached the analysis outputs from both. Both have rms=0.005 and strehl=0.999. The artefacts in DFTFringe have a peak to valley height of about 0.25 waves, but in my R analysis are larger: 0.7 waves.
Maybe the results depend on the fft filter size, which is difficult to set for this particular interferogram (there are large halo's around the central lobes).

Sorin






On Friday, July 24, 2020, 3:52:59 AM GMT+3, Dale Eason <doeason@...> wrote:


Here is DFTFringe analysis from Mike's igram.  


Re: Errors in DFT based fringe analysis

Sorin
 

"I don't remember if Mike's does or not."

Michael algorithms don't create the analysed surface from Zernike polynomials. The raw wavefront is produced after phase unwrapping and the net wavefront is obtained from it, subtracting a Zernike based wavefront as DFTFringe does.
The user has the possibility to select what terms will be subtracted from the raw wavefront, to select the number of Zernike terms used for fitting and many others.

If it is desired, the algorithms will display 3 plots: the net, the smooth and the residuals. All the output data is included in an R list containing (the net wavefront, the smooth one-based on the selected Zernike terms, various Zernike lists, pupil data, phase data etc).




On Friday, July 24, 2020, 7:22:51 AM GMT+3, Dale Eason <doeason@...> wrote:


Here's the new DFTFringe analysis of Mike's synth igram.  I deleted the old one from this thread.  For some reason my version of DFTFringe also created line black lines in the center of the white part of the fringes when read the .png file.  So I converted it to a .tif file to get this analysis.  

I did not use any bluring.  DFTFringe gaussian blur  % is displayed in the profile plot and on the control itself.  Which is also a percentage of radius.

DFTFringe does not create the analyzed surface from Zernike poly's.  I don't remember if Mike's does or not.  It only uses Zernike's to remove the terms the user disable from the unwraped phase.  That then is displayed as the wave front.


Re: Errors in DFT based fringe analysis

Mladen, Florida, USA
 

On Thu, Jul 23, 2020 at 08:36 PM, Dale Eason wrote:
No,the accuracy of the software is not tied to that parameter alone as I have been explaining.
Also too many fringes will cause as much error as too few for DFT analysis. 
Okay, but in the case of my simulated D150/R2400 paraboloid example, the improvement was proportional to the number of fringes progressively in increments of 10 fringes/pupil, from X tilt of 5 (first image) to X tilt of 30 (second image). At X tilt = 5 (10 fringes), the results show clear residuals.Finally, at X tilt = 30 (60 fringes) all residuals are gone and the mirror results show theoretically perfect mirror, as it should be.

I have change only X tilt as a factor and none other, so hat had to be the only factor that produced theoretically predicable results..

2101 - 2120 of 31688