SOLVED finding xrossing points via pixels

[ADMGNS]

hello

i'm trying to find geometric shapes' xrossing points (ie intersection) via pixels on a bitmap.
to be clear, not corners.

pls see attachment.

i need some help for a reliable and easy method.

thanks

[MarkMLl]

Quick and dirty: ensure that contrast is wound up as far as it will go. For each pixel count the number of set neighbour pixels weighted to take into account the line width, local maxima are crossings.

MarkMLl

[circular]

To take into account that lines may have different widths: for each black pixel, go trough the pixels on the border of a square around it, for example a square of side 7, so 3 pixels before and 3 pixels after the center pixel. Count the series of black pixels along the border of the square, this will be the number of lines going from the point. If this number is greater than 2, it is an intersection.

Note: you will detect the same intersection on multiple adjacent pixels. When that's the case, it is only one intersection, its location is the average.

[ADMGNS]

thank you for your both valuable suggestions.. i'll try them as soon as possible.. regs

[MarkMLl]

In practice, our suggestions are closely related: for each point, evaluate some function of the neighbouring points. However, there's several ways of interpreting this including

* Cellular automata (some analogue of Conway's "Life").

* 2D spatial filtering (lots of maths with integrals and sigmas) ** .

* 2D spatial filtering (a heuristic like "draw a square around the current point").

** Frankly, the amount of high-level maths in filter design, even 1D filters such as are heavily used in audio signal processing, is intimidating. I never had a lecturer who was brave enough to say "all it means is that you take /this/ fraction of the current sample, /this/ much of the preceding sample, and so on".

Obligatory XKCD: https://xkcd.com/2614

The good news is that you can skip the maths, and apply exactly the same approach in 2D, i.e. "you take /this/ fraction of the current sample, /this/ much of each of its immediate neighbours, and so on". Although I think it's fair to add that from a programming POV it's easy to say "look at a square around the current point", while a mathematician would far prefer that we looked at a circle.

MarkMLl

[circular]

Indeed, I thought about a circle, but it is far more simpler to do a square