dima

Hi. Doing some sort of auto-rejection would be nice; if that's hard simply including some pixel value statistics into the output (noted in the vnlog thread) would be nice too. This is the last part in my workflow that's mostly manual still.

Right. The latest iteration of my script is attached. This uses vnl-paste to combine the two data files; but it still seems like a completely unnecessary extra step. Currently my process is to move an MTF target while taking images and looking at a realtime preview. I freeze for a few frames in locations where I want to measure MTF. I have a wide lens, so I need multiple images to cover the view. Then when I'm done, I process everything with ./evaluate-mtf.sh --linear $(./find-stationary-images.py...

Right. The latest iteration of my script is attached. This uses vnl-paste to combine the two data files; but it still seems like a completely unnecessary extra step. Currently my process is to move an MTF target while taking images and looking at a realtime preview. I freeze for a few frames in locations where I want to measure MTF. I have a wide lens, so I need multiple images to cover the view. Then when I'm done, I process everything with ./evaluate-mtf.sh --linear $(./find-stationary-images.py...

Hello. When gathering images for mtf analysis I generally try to get the exposure at a level where the white areas sit close to 255, but not AT 255, since I'm sure overexposed images will skew the mtf measurements. Are there fields in the "mtf_mapper -q -v 2" output that can be used to identify such edges, and ignore them? I'm seeing some snr and cnr stuff, but that appears to favor the high contrast you get from overexposure. Thanks.

Hi. I'm a lot less excited about relying on serialized_edges.bin. Some of the nice things you get from vnl data is The ability to use the output directly on the commandline, without needing to write any code The format is self-documenting The format is future-proof: you can add or reorder columns, and existing tooling will continue to work You can stream it. You can imagine an "mtfmapper server" where mtfmapper reads images on stdin, and writes its output as a vnl on stdout. This would be easy to...

Cool. I looked at the length to, and the relationship wasn't clear. Looking forward to seeing the simplified logic.

Hi. Those notes are useful. Thanks. I evaluated the response of this camera (with pfstools), and it is indeed linear. So using the tight mtf50 result is justified. Next, I wrapped my commandline logic into the attached evaluate-mtf.sh. You give it your images and maybe --linear, and you get the individual and joint annotated plots and a joint radial plot. This tool makes mtf_mapper conclusively work for my use case. Thank you very much! I tried your suggestion to use oversampling_factor instead of...

Hi. Those notes are useful. Thanks. I evaluated the response of this camera (with pfstools), and it is indeed linear. So using the tight mtf50 result is justified. Next, I wrapped my commandline logic into the attached evaluate-mtf.sh. You give it your images and maybe --linear, and you get the individual and joint annotated plots and a joint radial plot. This tool makes mtf_mapper conclusively work for my use case. Thank you very much! I tried your suggestion to use oversampling_factor instead of...