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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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 images). There is actually an implementation of similar tests in the "manual edge selection" GUI code path (gl_image_panel_edges.cc and a few other places).
But what about 16-bit input files? These are often sourced from raw Bayer images and I have dealt with 10, 11, 12, 14 and 16-bit inputs in the past. Even going through libRaw or dcraw it is hard to tell what the native range is. I have considered guessing the range by looking at the data and using the nearest power-of-two-minus-one as the upper limit, but this fails if images are systematically underexposed. Maybe the only workable solution is to combine this guess with an override option where the user can provide the upper limit, or even better the desired overexposure threshold. Or perhaps to use a guessed upper limit in combination with a histogram mode check?
In practice it is good to say well below the saturation limit. If you actually hit this limit on any meaningful number of pixels included in the ROI used to compute the MTF then you will get a clipped ESF which usually produces unrealistically large MTF values, and usually unrealistically large CNR values too.
I still owe another user a section in the MTF Mapper user manual on overexposure, but it is hard to find the time to write it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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!
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 images). There is actually an implementation of similar tests in the "manual edge selection" GUI code path (
gl_image_panel_edges.ccand a few other places).But what about 16-bit input files? These are often sourced from raw Bayer images and I have dealt with 10, 11, 12, 14 and 16-bit inputs in the past. Even going through libRaw or dcraw it is hard to tell what the native range is. I have considered guessing the range by looking at the data and using the nearest power-of-two-minus-one as the upper limit, but this fails if images are systematically underexposed. Maybe the only workable solution is to combine this guess with an override option where the user can provide the upper limit, or even better the desired overexposure threshold. Or perhaps to use a guessed upper limit in combination with a histogram mode check?
In practice it is good to say well below the saturation limit. If you actually hit this limit on any meaningful number of pixels included in the ROI used to compute the MTF then you will get a clipped ESF which usually produces unrealistically large MTF values, and usually unrealistically large CNR values too.
I still owe another user a section in the MTF Mapper user manual on overexposure, but it is hard to find the time to write it.
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.