thahnen / aiolos Goto Github PK

In beiden Funktionen (RT + CT) kommen x1-4 und y1-4 jeweils mehrfach vor, daher sind mehrere IF-Abfragen eigentlich überflüssig!

Hinzu kommt, dass bei falschen Werten einfach übersprungen wird, anstatt ggf irgendwie damit umzugehen. Wird aber nicht aus dem Paper ersichtlich!

Ggf. kann man auch noch c_1-4 irgendwie zusammenfassen, dass Berechnungen nicht doppelt und dreifach durchgeführt werden müssen! Zwischenwerte am besten danach verwerfen!

So when iterating through every radius up to the maximum do not use every one but every second or so!

Considering uint8_t or uchar, but prefering first one as it is for numbers and not characters.
Saves space (around 3 Bytes) and does not really cost any speed in computation.

Ist jeweils eine Division aller GLCM-Elemente durch den Normalisierungsfaktor nötig? Ich sehe darin keinen Gewinn und eigentlich nur Rechenverlust da alle Werte erneut ändern O(n^2) Rechenoperationen kosten würde!

Damit sollten in allen GLCM-Elementen eigentlich für beide nur ganzzahlige Werte vorkommen können, was ausserdem eine Möglichkeit zur Beschleunigung ist.

In einem Bild kann es mehr als einen dominanten Winkel geben.
Bisher gibt es nur eine Funktion, die genau den Dominantesten findet.

Weitere Funktionen, mit der man sich die anderen Winkel auch liefern lassen kann, bsp über:

• Bild in kleinere Teile aufteilen und aus diesen die Winkel ableiten
• Median aus allen Verteilungen (0-179°) berechnen => die darunter nehmen (?)
• Mittelwert aus allen Verteilungen (0-179°) berechnen => die darunter nehmen (?)
• irgendeine Form der Abweichung vom dominantesten aufstellen und mögliche Treffer nehmen?

Daraufhin sollten alle Verfahren auf Geschwindigkeit und Speicherverbrauch getestet werden und das mit dem besten Ergebnis genommen werden.

Nicht immer an jede Funktion r und theta mitgeben, aus denen je nur eine Entfernung berechnet wird. Allerdings dort mitgeben, wo weitere Berechnungen anhand r und theta erfolgen => sollte Rechenaufwand weiterhin einsparen können!

Veränderungen könnten durchgeführt werden bei:

• Standard-Schemata -> Q, GLCM, GLCM_
• Schemata 1 und 3 ggf.

Allerdings sollte das erst ausgetestet werden, ob daraus auch wirklich was gewonnen wird!

Bisher liegt eine unterschiedliche Implementierung vor, die jeweils effizienter zur Laufzeit (RunTime) oder zur Kompilierung (CompileTime) ist.
Laut OpenCV Dokumentation (sowie in genereller C++ Praxis) sollten Template-Typen nur genutzt werden, wenn Informationen zur CT vorliegen.

Probleme:

• Wenn Bilder zur RT erst geladen werden, müssen jeweils Fallunterscheidungen auf unterster Ebene (Implementierung GLCM) durchgeführt werden, die Rechenzeit kosten!
• Die Implementierung zur CT in dem Fall zu nutzen würde aber pro unterschiedlichem Matrix-Typ (meines Erachtens nach) vorsichtshalber jeweils eine Implementierung generieren, auch wenn sie nie gebraucht werden würde.

Deshalb muss noch überprüft werden, wie sich die Anwendung der beiden Implementierungen im normalen und "falschen" Fall auswirkt!

Bisher ist die CT Implementierung (deutlich) besser, wenn Bilder zur Kompilierung geladen werden!