Frans van den Bergh

I may have oversold the oversampling factor. A more balanced take is that the oversampling factor replaces any edge-orientation angle quality assessments. There are other factors that go into the quality rating (edge length, for example) that will remain relevant. Still, it might be a good idea for me to revisit the internal calculation of the quality metric to make it a bit more consistent, and to get rid of the explicit edge-orientation grading. But that sounds like a somewhat larger project to...

I'm fine with adding the command line flag, MTF Mapper already has so many of them :) The combined data you are looking for is already available in the serialized_edges.bin file. This file was originally intended for more efficient passing of data between the MTF Mapper command line tool and the GUI, but I have since found many more uses for it, e.g., this Python/Docker tool. The binary format is many times more efficient than parsing the text files, and provides fields not covered by edge_sfr or...

Ok, I think the changes so the contents of the files are fine, but changing the extension of the output files in a blanket approach will break things for other users (I assume). Can we make this entire patch an optional command-line flag? That will maximise backwards compatibility? I have attached a proposed patch. If this works for you, I can merge it.

The linear-vs-nonlinear intensity scale for images with an unknown provenance is always a pain. There are a few ways to resolve this: Look at the ESF curve. Linear images tend to have a symmetric ESF where the width of the knee and the width of the shoulder tend to be similar. I have attached a sample extracted from your images: blue is linear, green is non-linear. You can see the knee looks a bit too sharp in the non-linear image. Use a known grayscale target. In a pinch you can use something like...

Hi! The magic angle, 26.565051 degrees is just atan(0.5), meaning an edge with a slope of 1/2. If the slanted edge is at exactly this angle you do not get sufficient oversampling for the slanted-edge method to avoid aliasing. In the early days of MTF Mapper development I did not have such a good grasp of this phenomenon, but later I added explicit measurement of the effective oversampling rate, e.g., the Snr.oversampling() method. There are some more rule-of-thumb magic numbers here: strictly speaking...

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...

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,...

Thanks for reporting these issues. I have fixed them in r735. Hopefully. Regards, Frans