Frans van den Bergh

Hi! Yes, overexposure handling is indeed something that is missing from MTF Mapper. When I do closer integration of MTF Mapper with other workflows I usually add that as an external step, because the specifics of what counts as overexposure depends so much on the image source. For example, it is simple enough to use the >= 254 rule on 8-bit inputs, but you would ideally only apply this test on pixels included in MTF calculations (or background clutter or specular reflections will reject many real-world...

Ok, no problem. I just committed my vnlog patch (after changing the option name to "--vnlog") as r736. With regards to the multiple files, the non-comment lines in edge_mtf and edge_sfr files are supposed to be synchronised by line number, but using the "-v 2" or "--vnlog" output modes you can also join the two files by using the edge centroid fields. With regards to near real-time library versions of MTF Mapper, that is the only way I have been able to generate any income from this project, by doing...

Added vnlog output support

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