Workflow for evaluating differences between air and an imperfect window.
Status: Beta
Brought to you by:
fvdbergh
Menu
▾
▴
I would like to evaluate the distortion effects of windows mounted in front of the lens.
Lens imaging through air should generate the baseline.
Camera Basler-ace-aca5472-17um-usb-30-monochrome captures 20-Mpix 12-bit monochrome saved as 16-bit PNG images.
Lens: Century Tele-Athenar 230mm F3.8 C-mount lens (focused on target).
Window: mounted at about 1 m from the camera at different theta and/or phi. Some of the test materials generate noticeable “astigmatism”.
Target: MTF target design lensgrid_A3 printed at 1200 dpi on fine cardstock. Aligned to within 1 degree roll pitch and jaw at about 11m from the camera.
Typical imaging: (Aperture f/5.6, 84048 μs, Gain optimized to fill the histogram at 12-bit) PNG saved as 16-bit.
You see lots of red N/A resulting in missing slanted edge lines.
Is there a limitation with presenting 12-bit images saved as 16-bit?
Is there a recommended preprocessing for 12-bit data stored in 16 bit files?
What would be the best workflow to quantify the optical quality of different windows?
I see:
2023-03-13:” MTF Mapper uses a window of only -28 to +28 pixels”; should I use binning to reduce the pixel count?
I will review images in ImageJ for evenness of the white background.
I think there is only very minimal unevenness from multiple ceiling lights and one large bottom illuminant.
A 16-bit PNG file containing 12-bit values should not be a problem, and should "just work". There is still some room for error, e.g., if Pylon decided to save the data with a different gamma value (i.e., not gamma = 1.0). But that should not affect things too much.
The MTF Mapper -28 to +28 window of pixels is measured in the direction perpendicular to the edge. Unfortunately I cannot tell from your provided PDF file what the actual scale is (how many source image pixels to PDF "pixels"), so I cannot really measure how "wide" (meaning distance from edge along perpendicular line) your edges are. But I can tell from the comparison between the with/without window samples that your images are quite soft through the window.
You did not mention whether MTF Mapper works as expected on the images captured without the window.
Would it be possible to send me the sample cropped images that were included in the PDF file, but as separate PNG files? If you cannot post those here, feel free to send them to my email address (fvdbergh@gmail.com). That will allow me to give you some more useful feedback.
You could also try using the "manual edge selection" path within the MTF Mapper GUI. This allows you to separate the detection step from the MTF measurement step a little; you only have to manually mark 5 or so edges to see if this makes a difference.
Regards,
Frans
Thank you very much for the software and your interest in my project and your kind advise.
I will soon take new images of hopefully better windows and will keep my target clean.
Perhaps there is even a cleaning cycle on the printer that could run before the preparation of new targets.
To minimize the noise, I could take multiple images and then average but any position or angle variance will contribute to apparent line spread.
Please see 3 attached files.
Cropped images have no processing.
Highcontrast image has 2 rounds of "enhance local contrast CLAHE"
Thanks again!
I see what you mean; the CLAHE enhanced image does appear to have some ghosting.
I have attached a comparison of the Edge Spread Function (ESF), comparing the Air image (blue) with the Window image (green and orange). You can see that MTF Mapper is actually truncating the ESF around 28 pixels in the Window image. This will introduce some error at very low frequencies (close to 0 cycles/pixel), but it is probably not as bad as it sounds.
Both the green and orange curves represent the same Window edge, but green was extracted with a normal automatic run, while orange was extracted with manual edge selection. You can see some wavy modulation in the green ESF curve, most likely a sign that the automatic edge orientation estimation was struggling a bit. This looks terrible in the ESF, but only shows up as some noise near 1 cycle/pixel in the SFR, so again, not as bad as it sounds.
So my conclusion is that your Window images are just right at the edge of the scale (width of edges measured in pixels) where MTF Mapper is still able to function. I think that is why some of the edges are randomly tagged with red "N/A" annotations.
But even looking at the Air images your baseline MTF50 is on the lower end. There are many possible reasons for this (e.g., if your sample crop is from close to the edge of the FOV, then lens performance may simply be low because of field curvature). It could also be sub-optimal focus. In general, I think a well-focused edge (in Air) should get MTF50 values of around 0.15 to 0.25, depending on absolute lens performance. To put it differently, if you can improve your Air performance a little bit, your Window performance will be within MTF Mapper's "normal" operating range.
You asked if MTFmapper worked as expected.
I am fully aware that I use your program outside of the original intent. I like that your method is independent of the shift created by the glass thickness.
I had hoped for bigger numbers on the air images to have a baseline that is clearly distinct from the images distorted by the window.
I was very optimistic because I could resolve the concentric dark border in the fiducial mark and that seemed as focused as it could get.
I find annotations of 0.08 to 0.12 for air and 0.03 to 0.05 for the image through a mediocre window but only for those few edges that I had manually selected during import.
In the exported result I see it had found quite a few more. :-)
Observing trends between mediocre and slightly less mediocre windows will need some method improvements.
So far I think of: e.g. better target, better focus, better camera support, better illumination, better windows.
What do you think?
Yes, I think improving your Air performance (mostly optimizing focus) should be your primary objective, since this will bring the Window performance into the usable range.
There is a Python-based docker container (here that is a reasonble start for automating the focus process. The README found there gives you some guidance, but if you can create a small capture tool with Pylon (I seem to recall they had some code samples) that just captures a frame periodically (1 Hz, or maybe 2 Hz), you can connect it to the MTF Mapper Docker container. The Python script will print out the mean MTF50 value by default, but you can easily customize the script to only analyze the center of the frame (for example).
With a little bit of work you can have a low-framerate solution for focusing the lenses interactively to maximise your MTF50 values. In my experience this type of focusing is essential because MTF50 values are incredibly sensitive to even small focus changes.
Regards,
Frans