Contrast > 1 at low spatial frequencies
Status: Beta
Brought to you by:
fvdbergh
Menu
▾
▴
Hi Frans,
I have noticed that the contrast goes above 1 at the lowest sample (1/64 c/p) for a subset of the edges in my image. This is always accompanied by a set of ripples in the MTF curve (see attached screenshots). I was wondering if you could give me some clues about why this might be happening.
My current theory is that it is related to the way mtf_mapper handles the phase of the OTF. My reasons for this are:
* Only off-axis field points are affected (where there is singificant coma)
* Only tangential edges are affected (again related coma?)
* Only the inner tangential edges of squares are affected, not the outer ones. This is visible in the white patches of the attached contour plot (black dots represent edge locations). This might be because the ESF is different for the inner and outer edges owing to the non-zero phase of the OTF.
The image I used is raw 12 bit with no sharpening or image processing. The test-target is back illuminated via an integrating sphere and a white glass diffuser. The problem persists with "--esf-model loess" and "--esf-model kernel". I am using --nosmoothing and I need accurate measurements at low spatial frequencies for my application.
So I guess my main question is: how does mtf_mapper handle asymmetric PSFs such as when there is coma? Could this be causing a bias in the MTF at low frequencies?
Thanks so much for making mtf_mapper available to us - I can't believe something of this quality is available for free.
Harry
Hi Harry,
It seems counter intuitive, but it is actually harder to measure the SFR accurately at low frequencies. One of the challenges is that the line spread function (LSF) can be quite wide under certain circumstances, e.g, a very defocused edge, or perhaps coma as you mentioned. For practical reasons, MTF Mapper uses a window of only -28 to +28 pixels wide as measured normal to the edge, which means that very wide LSFs can be truncated, leading to an increase in the SFR at low frequencies.
To compound this, MTF Mapper will try to estimate the first zero crossing of the LSF, and attempt to truncate the LSF there. This is mostly done to deal with very dense test charts where target squares/trapezoids are so closely spaced that two opposing edges are close enough that their LSF windows overlap, i.e., roughly when two opposing edges are separated by fewer than 28 pixels. This truncation also helps to reduce the impact of noise. When I implemented this feature I often found that treating the left/right (or bright/dark) sides of the LSF separately led to issues (cannot remember the exact details, it was a long time ago), so I ended up using the closest zero (between bright/dark sides of the edge) to determine the truncation distance.
I suspect that with a highly asymmetric LSF this symmetric truncation could lead to excessive truncation of one side of the LSF, causing distortion of the lower frequencies of the SFR. It might be time for me to take another look at my truncation code.
Would it be possible to send me a raw image so I can take a closer look and see if truncation is the main problem here? You can send it to fvdbergh@gmail.com if you'd rather not post it here.
Hi Frans,
Thanks for the detailed response! I have attached the image. It sounds plausible that truncation of the long tail of an asymmetric LSF on one side could be the cause of this effect.
Out of interest, is the Tukey window still applied in the current version of MTF mapper, as described here - http://mtfmapper.blogspot.com/2015/06/improved-apodization-and-bias-correction.html ? Also, I read in the manual that the window is a total of 32 pixels wide, but I guess that may have been an old version - is it now 56 pixels?
Also, how difficult do you think it would it be for me to modify the MTF mapper source code to increase the LSF window size to say 200 pixels to improve the accuracy at low frequency? I have had a quick look at the code, but I thought I should check how feasible this is first.
Thanks,
Harry
PS: I guess this issue is probably of no practical concern to the vast majority of MTF mapper users! It is just I am working on an unusual application which only cares about very low spatial frequencies.
By the way the image is saved as a 16 bit png where only the first 12 bits are used. It does work with MTF mapper though
Hi Harry,
Thanks for the raw image!
A few quick answers:
1. MTF Mapper no longer uses the Tukey window; in fact, MTF Mapper does not use any windowing at all, but it does try to taper off the LSF tails using smoothing. Still not perfect for really wide LSFs, but less biased than Tukey windowing at really low frequencies.
2. I've had a look at the dodgy edges with the contrast > 1 at low frequencies. I don't have a good explanation of why I am seeing this, but it appears that your white background is not as uniform as I would expect it to be. I used ImageJ to just plot a mean intensity profile over a rectangular region, as indicated in yellow. One good example is near the 8th radial ring of trapezoids where the white background grows noticeably brighter just before we reach the black trapezoid (see attached images). I we look at the mean intensity of an entire radial slice, this phenomenon appears to be present at some of the other trapezoids rings too (plus some minor vignetting right at the edge).
Perhaps you can capture an image without the MTF target, and investigate the uniformity of your background separately?
So in practice this means that the opposite of what I speculated above is happening: MTF Mapper is not truncating the LSF close enough to the edge, so the bump in the background intensity is included in the measurement, leading to the low-frequency distortion.
You can "clean up" the results a bit by using both the --nosmoothing and the --monotonic-esf-filter flags, but given what I see even in ImageJ I would try to find and fix the root cause first.
I'd be very curious to hear what you find!
Regards,
Frans
Hi Frans,
Thanks so much for your response! You are right - I increased the contrast of the raw image using ImageJ (see attached). It looks like there are some back reflections going on. The test target is chrome on glass so the backs of the squares are quite reflective.
I'm guessing that the sharp edges are internal reflections due to the thickness of the glass target, and the splodges are reflections from the polished surface of the diffuser. What a nightmare! Looks like I am going to re-think a few things about my experiment.
One final quick question: do you know if there is a setting I can change within MTF mapper to increase the LSF window size, either as a CLI option or within the source code? I think this is probably optimistic but I thought I would check just in case. I've got to try and measure the defocused MTF.
Thanks for all your help with this,
Harry
Hi Harry,
That contrast-enhanced image is pretty scary! It is a bit hard to gauge the target size from the photo of the set-up, but would a collimator help to reduce the impact of the reflections?
Anyhow, I played around with the MTF Mapper source code to see what it would take to support a wider ROI around each edge. I have attached the patch file that you can apply to the source code (or you could just manually edit the source as indicated in the patch file). If you can build from source, which is not too hard under Linux, then you can play around with it. If you are stuck, I can generate a .deb file for a specified version of Ubuntu (e.g., 22.04).
There are some caveats, though:
1. The patch works, and MTF50 values are reported correctly, but the change in the sample spacing in the resulting SFR will be different (1/128th pixel after the patch vs 1/164th pixel before). This difference will not be reflected in the GUI, but if you are manually parsing the edge_sfr_values.txt file then you can correct the frequency scale on your end. The number of samples in the SFR increases accordingly (as one would expect from doubling an FFT window size).
2. You are more likely to see interference from the adjoining perpendicular edge. Just visualize the overlap between the two ROIs that meet at the corner of the target trapezoid to see where I am going with this. There is another parameter in MTF Mapper that will pull the ROIs back further from the corners, so I can point you to that if this is becomes necessary. Similarly you will start to see interference from the edge on the opposite side of the trapezoid if the ROIs overlap in that direction. Both of these effects are comparatively small, but I have seen them crop up in simulated images.
I did a quick comparison between the standard ROI (32 pixels from the edge, well, 28 actually, but let's keep it simple) and the doubled ROI (64 pixels from the edge), and on a simulated f/32 aperture on a 4 micron pitch sensor the SFR error at the lowest non-zero frequency was reduced from about 0.03 to 0.02, just to give you an idea of the improvement. By the way, I did this comparison with the flags
(some undocumented options to improve accuracy on noise-free images)
Anyhow, this was just a quick-and-dirty test. If you think it is really important to support a wider ROI, then I can spend a bit more time to make sure all the other bits still work as expected after applying the patch (e.g., does the LSF-truncation actually give you a real-world improvement on a noisy image).
Regards,
Frans
Hi Harry,
(follow up to my previous post)
I found some older synthetic images that I generated with great care to ensure that wider ROIs would be free from contamination, i.e., these were single-edge images so there could be no opposing or adjacent edges. The attached plot shows the difference between the expected analytical SFR of the synthetic image, and the measurement obtained with MTF Mapper at various ROI widths. I notice that there are some pretty wild errors (0.003!) after 0.5 cycles/pixel that are present in all three ROI widths, not quite sure where they come from.
But you can see that the wider ROI does indeed reduce the error at low frequencies nicely.
Hi Frans,
Yes I was thinking about collimated illumination before. I was worried about accidentally decreasing the effective f-number though, since the lens is f/1.8 and it is macro photography.
Thanks so much for sending that patch through!! I'm glad that it also halves the sample spacing, that is perfect: I was struggling with the samples being too far apart before, and I always ended up studying the lowest sample.
That is a good point about the overlapping ROIs - I will keep a lookout for that. Do you know what the ROI size along the edge is at the moment?
My supervisor is quite experienced at building from source for Linux so I should be able to get help with that.
I would guess that it's probably not important to support wider ROIs for the majority of MTF mapper users. In my case, it is just because we are interested in low spatial frequencies and defocus that it makes a difference. I was doing some tests using mtf_generate_rectangle, and I saw overestimation like in the graph you just attached - I am glad to see that the wider ROI improves the accuracy
Thanks for all your help
Harry
Hi Harry,
To address your question "Do you know what the ROI size along the edge is at the moment?":
Most ESF samplers (including the default --esf-sampler piecewise-quadratic) do not have an explicit ROI limitation as measured along the edge, but --esf-sampler line limited to 400 pixels.
But I assume you are asking about the automatic ROIs that apply to trapezoids. Those are definitely tuned for "typical photographic conditions", so they are likely to be too wide (meaning reach too close to adjoining edges at corners) for studying strongly defocused edges with wide LSFs. The actual heuristic currently implemented in MTF Mapper:
* ROI is guaranteed to end at least 5 pixels away from the corner
* ROI is guaranteed to be no further than 16 pixels away from the corner
* In between those two extremes, the ROI ends 8% of the length of the edge from the corner.
I have attached an example patch to show how you could tweak those limits. Not sure if my example is a good fit for your requirements, but there is clearly a trade-off here between using a long ROI (along the edge) to minimize the impact of noise, vs avoiding contamination.
Hi Frans,
Thanks for the detailed response and the patch file, that is super helpful
Harry