Rechenzeiten für Hough Transformationen

Für einen Jahresbericht des Instituts mit Highlights, die hier so bearbeitet werden, habe ich mal meinen Hough-Transformations-Algorithmus gebenchmarkt. Zusammen mit Conformal Mapping.

Man sieht, dass die Zeit, die mein Programm braucht, ungefähr unabhängig davon ist, wie fein das Auflösungsraster gewählt ist. Die auf der x-Achse aufgetragene Auflösung ist dabei proportional zum Winkel α, der bei r(α) = cos(α)*x+sin(α)*y eingesetzt wird. Genauer: Das Inverse der Schrittweite von α. Um’s klar zu machen: Wieviele Auswertungspunkte gibt es im Bereich [0°, 360°).

Die Skalierung mit den untersuchten Event-Sätzen ist dabei relativ linear. Für meine komplette Berechnungskette komme ich auf ca. <4 ms pro Event, wobei ein Event aus mitunter 15 Hits besteht. Analysiert wurden (x,y)-Werte aus dem PANDA STT mit Isochroneninformationen in double precision.

Weil ich eh schon dabei war, habe ich mir angeschaut, welcher Teil von meiner Berechnungskette die meiste Zeit verbraucht. Wie erwartet ist das die eigentliche Hough Transformation – logisch, weil pro (x,y)-Hit eine Zahl von assoziierten (r,α)-Punkten generiert wird, wobei die Anzahl genau von 30 bis 720 (x-Achse) geht. Aber auch hier sieht man: Die Zeit ändert sich nicht mit der Feinheit des angewendeten Grids.

Die Auswertung wurde mit dem benchHough-Programm gemacht. Eine Einteilung in ein Histogramm zum visuellen auswerten fand noch nicht statt – das ist ja auch nicht Teil der Hough Transformation im Engeren.

Erkennbar ist also, dass die Größe des Grids für mich noch interessant ist und kein limitierender Faktor. Das, was ich mir auch erhofft habe. Mal sehen, ob das eine Adaptive-Hough-Methode nicht sinnlos werden lässt…