Treshold and density in the edge tool

edge
#1

When using the edge tool to detect all edges (contrast mode), I noticed that the lowering the treshold sometimes has a strange impact on the quality of the found edge(s). With a relatively high treshold for this image (lets say 20 for this discussion) it finds one edge with a quality of 20,9. When I lower the treshold significantly (4 in this example), suddenly the found edge has a quality of 12. The density setting also appears to influence this.

To better understand this, I’d like to know a bit more about how this quality score is determined, and more importantly how and why it changes based on the treshold. For the binary treshold this makes sense, as changing the treshold would actually move the edge. Is this also true for the contrast treshold?

Right now I’m simply trying out some values to get a feel for its response, but I’d like to be able to predict its behavior somewhat better.

#2

When using the :cvb: Edge tool in threshold or contrast mode (functions Findxxx, CFindxxx or CSFindxxx) the tool always makes use of the function ScanPlaneUnary from the CVCImg.dll. The pixel callback for ScanPlaneUnary in this case is set up to calculate the row sums and the end of line callback for ScanPlaneUnary normalizes the sum and evaluates the it. In other words: The edge tool will always calculate an average over the scan lines of the area of interest and then use these calculated averages to determine whether or not a relevant edge has been found (see also the description of Projection in the chapter Theory of Operation of the edge documentation.

This is why the density parameter of the functions will definitely have an an influence: Setting density to anything less than 1000 will cause the ScanPlaneUnary function to sub sample the area of interest - which will definitely have an influence on the scan line sums and thereby also on the results. The density parameter will influence both, the result locations and the result qualities. Quality is directly derived from the scan line sums and as lower density settings will alter the scan line sums. Position depends on where the scan line sums (or, in case of the contrast-based functions, the difference between adjacent scan line sums) exceeds the specified threshold - and if the scan line sum changes this location may shift. Furthermore setting values for density significantly below 1000 will lead to sub sampling that skips entire scan lines… Frankly, I’d advise against setting the density to anything other than 1000 unless you absolutely have to and have exploited every other available option (multi threading, stronger hardware)…

So much for the influence of density.

In contrast mode the edge tool will not compare the absolute values of the scan line sums to the threshold, but the difference between adjacent scan line sums. And this difference is also the quality value that will be reported for a result that exceeds the contrast threshold. If a threshold of 20 yields a result at position (x, y) with a quality of 20.9 then reducing the threshold to e.g. 4 is actually quite likely to give you a different result in terms of position (because the threshold will be exceeded sooner than with the higher value of 20) as well as quality (because the result quality may be as low as the threshold).

Maybe this should be described in more detail in the documentation…

1 Like
#3

@illusive
Ah yes, this is the good stuff. Exactly what I was looking for! Oddly enough the value for density in the edge examples is 500, and the manual suggests not to deviate from the default value;

Defines the density that used to scan the image data. Valid values are in the range from 100 to 1000. Higher value result in higher accuracy while lower values result in higher speed. It is recommended to use the default value.

This caused some confusion for me, as to me it would seem logical to only start skipping lines if there is a good reason to do so. I assumed I had maybe misunderstood the functioning of either the edge algorithm or the role of density. I wasn’t far off it seems.

#4

:roll_eyes:
probably one of those cases where some 20 years ago the machines were not yet fast enough for higher density settings and nobody reviewed that piece of advice since… sorry for that!

#5

Gotta love that legacy stuff. Luckily we have internet forums now :smiley: