Automatische Detektion von Meteor Scatter Spektrogrammen

Guten Morgen Wilhelm,

Sehr gut und vielversprechend ? Die Mask-C-RNNs sind einfach unschlagbar, ich hatte damals übrigens recht unterschiedliche Ergebnisse je nach Bildgröße bekommen und muss bei den Mikroskop Bildern Sliding Windows machen (30000x45000 Pixel). Für neue Implementierungen im Bereich Segmentierung ist das auch mein Weg, zumal die Annotationen auch Leien vornehmen können.

Nutz du immer noch PixelLib zum trainieren? Was ist dein langfristiges Ziel?

Einen schönen Sonntag
Stefanie
 
Hallo Stefanie.
Dankeschön!
Ich bleibe notgedrungen erst mal bei Pixellib, halte aber Ausschau nach alternativen Paketen.
Zu meinen Plänen / Zielen:
Als Nächstes werde ich mal annotieren / labeln. Im Pixellib Tutorial sind es 100 und 200 Bilder für den Test und 2 x 300 fürs Training. Im Moment trainieren ich Meteore (vorwiegend sogenannte Raser) und die Schmetterlinge aus dem Tutorial. Später ersetze ich die Schmetterlinge durch die sogenannten Raucher.
Im Juni möchte ich die Arietiden von unserem Flugplatz aus aufnehmen, um den In Line Peak zu untersuchen. Der Peak lässt sich vermutlich nicht alleine durch die Winkeländerung erklären. Es muss noch einen anderen physikalischen Effekt geben.

Wie würdest du labeln? Eher weit oder eher eng?
Einen schönen Sonntag wünsche ich euch,
viele Grüße
Wilhelm
 

Anhänge

  • labelme.png
    labelme.png
    1,3 MB · Aufrufe: 120
Zuletzt bearbeitet:
Hallo Wilhelm,

Sehr spannendes Projekt, ich freue mich auf die Ergebnisse bzw. Vergleiche!

hier ein paar Tipps:

  • Bildgröße ähnlich, die vom Ursprungsmodell wählen, wenn ich mich recht erinnere, war das 512x512 bei Coco, aber ich bin nicht sicher. Bei unseren Meteor-Bildern sollte das ganz gut passen. Also nicht auf den ROIs (150x300 Pixel) labeln und Modelle bauen, dann funktioniert die Erkennung schlechter.
  • Lieber weniger ROIs labeln, diese dafür aber sehr genau umranden (dein oberes Beispiel). Besser als sehr viele ROIs, sehr ungenau annotiert. Wobei es natürlich auf darauf an kommt was du machen möchtest, Segmentieren (oberes Beispiel) oder nur Klassifizieren (unteres Beispiel).
  • Schau das die Klassen (also auch Hintergrund) die gleiche Anzahl haben, sonst bekommt dein Modell ein Bias oder du musst die Gewichtsparameter ändern (tricky)
  • Augmentieren hat bei mir wenig geholfen, lieber mehr Bilder annotieren. Würde ich nur bei limitierten Datensatz machen (bei uns ja nicht der Fall).
  • Erstell dir zusätzlich zum Test-Set noch ein separates Validierung-Set, an dem du deine Modelle überprüfst. Etwa 200-500 ROIs möglichst zufällig aus den verschiedensten Sessions wählen. Das sollte dir einen guten Eindruck vermitteln, wie genau dein Model ist. Aus Erfahrung reichen die Accuracy und Precision Werte deiner Modelle nicht aus, um einen realistischen Eindruck im Produktionsmodus zu bekommen. Du kannst so auch die Schwächen finden und dort in mehr Trainingsdaten investieren.
  • Für sehr eindeutige ROIs (wie mein Beispiel oben), nutze die OpenCV Konturen, dann brauchst du nicht manuell zu labeln. Den Code kann ich dir zur Verfügung stellen, da ich ihn sowieso für ein Paper brauche.
  • Bei kleinem Datensatz Vorsicht wegen Overfitting, sollte aber der Validierung-Set zeigen. Ich würde mindestens 1000 besser 5000 ROIs pro Klasse annotieren. Wobei ich das systematisch so lange verbessere, bis ich mit der Erkennung des Validierungsset zufrieden bin. Also fang einfach mit 500 ROIs an und guck mal, wo die Probleme sind. Diese dann weiter annotieren und trainieren. Bringt mehr als 5000 zufällige ROIs auf einmal.
Gutes Gelingen!
Grüße
Stefanie
 
BTW, falls du nur eine Bounding Box extrahieren und anschließend Klassifizieren möchtest, dann kannst du das mit dem Thresholding und openCV erledingen und im Windows Explorer in Klassen (Ordner) trennen (Ansicht -> Extra Große Symbole). Das geht deutlich schneller, so habe ich 1 Millionen Bilder annotiert. Kommt halt darauf an, was man machen möchte und wie genau es sein soll.
 
Hallo Stefanie.
Danke für die vielen Tipps. Im ersten Schritt annotiere ich also präzise von Hand. Dein Paper mit der Annotierung via OpenCV würde mich sehr interessieren. Die Augmentierung schalte ich ab. Dadurch werden die Meteore ja nur leicht gedreht (wenn ich das richtig verstehe), was hier nicht nötig ist. Mir war nicht klar, dass die Anzahlen in den Klassen ungefähr gleich sein müssen. Ein Validierung-Set hielt ich für überflüssig, werde es aber auch so machen. Overfitting kannte ich. Für den Leser: Dann fängt die KI an auswendig zu lernen, was sie nicht soll.
Ein Problem ist bei mir immer etwas die Organisation, damit nichts doppelt ist oder Daten sich vermischen.

Hier kommt noch die Sonne raus.
Einen schönen Tag wünsche ich Euch,
viele Grüße
Wilhelm
 
Das Testset könntest du vermeiden, aber den Validierungssplit (random) würde ich definitiv auch empfehlen.
Sieht doch schon mal ganz gut aus.
Ich hatte nun auch mal weiter vorn gelesen, warum die Daten eher ungünstig für ML visualisiert sind. Du hast direkt die Bildschirmausgabe abgegriffen und die Darstellung ist für dich zum Labeln natürlich einfach, aber für die KI wäre natürlich ein einfaches Wasserfall mit einem Graychannel optimaler. Heißt natürlich nicht, dass es nicht so geht...
Du kannst gern mal deine Loss und Accuracy (Train und Validationsets) über die Epochen als Graph einstellen... :y:

Viele Grüße

Sebastian
 
Hallo Wilhelm,

Augmentieren kannst du getrost weglassen, wir haben genug Daten. Dort kann man bei begrenzen Datensatz, zum Beispiel horizontal oder vertikal drehen, Objekte etwas verschieben usw. So kommt man an mehr Daten (siehe Anhang), damit müssen wir uns zum Glück nicht rumschlagen...

Ein ausgeglichenes Training Set ist ich wichtig, im Schlimmsten Fall wird dein Modell versuche die Imbalance mit vorherzusagen, also gibt der einen Klasse deutlich mehr Gewicht.

Datenmanagement ist kritisch, ich habe leider auch noch keinen heiligen Gral gefunden.

Das Paper schreibe ich gerade, es geht darum unsere bereits annotieren Daten (~ 1 Millionen) als Datenbank zur Verfügung zu stellen, sodass es Nutzer zum Beispiel für Transfer Learning verwenden können.

Beste Grüße
 

Anhänge

  • rotation_example.PNG
    rotation_example.PNG
    22,3 KB · Aufrufe: 117
Zuletzt bearbeitet:
Das Testset könntest du vermeiden, aber den Validierungssplit (random) würde ich definitiv auch empfehlen.
Sieht doch schon mal ganz gut aus.
Ich hatte nun auch mal weiter vorn gelesen, warum die Daten eher ungünstig für ML visualisiert sind. Du hast direkt die Bildschirmausgabe abgegriffen und die Darstellung ist für dich zum Labeln natürlich einfach, aber für die KI wäre natürlich ein einfaches Wasserfall mit einem Graychannel optimaler. Heißt natürlich nicht, dass es nicht so geht...
Du kannst gern mal deine Loss und Accuracy (Train und Validationsets) über die Epochen als Graph einstellen... :y:

Viele Grüße

Sebastian
Hallo Sebastian,

das war glaube ich ein Missverständnis. Für das Training wird ja der Datensatz automatisch geteilt, also zum Beispiel 70 % für das Training und 30 % als Testset. So wird das Modell automatisch mittels Backpropagation angepasst. Was ich aus Erfahrung trotzdem wichtig finde ist ein separater Validierungsset, was damit quasi nichts zu tun hat. Die Mühe macht sich aber kaum jemand und im Produkionsmodus kommt dann das böse Erwachen, wenn das Model nicht die 95 % Genauigkeit widerspiegelt, weil die "neuen bzw. echten" Daten ein bissen anders sind, als im Trainingsset.

Grüße
Stefanie
 
Hallo,

ich kenne das von euch eingesetzte Framework leider nicht im Detail. Jedoch scheint unten dem Pixellib pytorch zu liegen, das ist dann die Ebene wo ich mich wohlfühle. Dort gibt es eine Funktion zum splitten und man kann selbst entscheiden wie viele Datensätze man zum Schluss zu wieviel % erhält:
Aber das Prinzip ist ja immer gleich: Train und Evaluation für die Trainingsphase und dann noch ein Testset um es abschließend zu beurteilen, daran werden aber keine Hyperparmeter mehr getuned. Kann es sein, dass wir nur gerade vom Wording her etwas aneinander vorbei reden? Inhaltlich scheinen wir das Selbe zu meinen. Da das Testset auch gern "unbiased evaluation" genannt wird, kommt man hier schnell durcheinander.

Englisch und Deutsch verhauen... Sorry:
Englisch: Train, Evaluation + Test
Deutsch: Train, Test + Validierung

Ist aber auch wirklich verwirrend :ROFLMAO:

Viele Grüße

Sebastian
 
Zuletzt bearbeitet:
Hallo Sebastian,

ja geht mir auch so, zumal man auch im (fast) englischen Programmiert. ich tu mich auch schwer deutsche Vorträge zu dem Thema zu halten, meist benutzt man aus versehen die englischen Fachwörter o_O
 
Gibts denn eigentlich im Bereich der Segmentierung schon einen quasi Standard was das Labeling angeht? Ich hatte mich bei den Boundingboxen damals für COCO entschieden. Da wurde zu jedem gelabelten Bild eine *.json-Datei mit den Koordinaten angelegt.
Damit ich mal zum Thema noch etwas halbwegs interessantes beitragen kann. Ich hänge mal zwei Radarbilder von mir an. Die sind mit einem 120 GHz Radar entstanden, dass natürlich nicht mal den Raum verlässt, geschweige denn Meteore zählen kann. Aber ich finde die Aufgabenstellung immer noch sehr ähnlich. Die X-Achse ist die Zeit und die Y-Achse ist der Abstand ( ca. 8 Meter max).

unnamed.png
radar_person2.png


Wenn man eine stillstehende Person gefunden hat, kann man anfangen die Atembewegung zu extrahieren. Die Schwierigkeit ist, dass wenn man vor einem Schrank steht und atmet (was man meist tut :) ), es natürlich den Hintergrund auch unterschiedlich abdeckt. Das sieht dann visuell ein bisschen so aus, als wenn auch der Schrank atmet. Ohne ML kaum zu lösen.

Ich will das Thema nicht wegziehen... aber das wäre ein Beispiel mit Spektrogramm in Grayscale, mit gleichem Informationsgehalt wie die gekippte Ansicht.

Viele Grüße

Sebastian
 
Standardformat gibt es leider nicht, jeder kocht so sein eigenes Süppchen, mit JSON-Coco ist man schon gut bedient…Gefühlt gehen 80% eh fürs Preprocessing der Daten drauf, bis man endlich mit dem interessanten Teil beginnt…

Das ist ja cool Sebastian, kannst oder darfst du, etwas näher erläutern wie und wozu die Radare aufgenommen werden? Vielleicht können wir ein separates Thema für KI oder Computer Vision aufmachen, es gibt ja immer was neues zu berichten…

Würde mich sehr interessieren!

Grüße
 
Hallo Sebastian,
die gekippte bunte Darstellung liefert gleichmäßige Daten (Flächen) über fast 5 Größenordnungen. Mit KI hoffe ich das noch zu steigern. Es sind alle Informationen drin: die Zeit, die Frequenz (Dopplershift) und die Amplitude. Eine flache Darstellung mit Grau als Z würde meiner Meinung nach nichts bringen und höchstens zu einem Dynamikverlust führen.

Pixellib hat beides, Tensorflow und Pytorch, kann aber im Moment nur mit Tensorflow trainieren. Pytorch mit PointRend liefert etwas schönere Flächen. Die Autorin hatte angekündigt, dass auch das Trainieren mit Pytorch / PointRend möglich werden soll. Allerdings ist die Version noch nicht erschienen. Updates gibt es seit längerem auch nicht. Offensichtlich hat die Autorin nun andere Aufgaben.
Von meinen Nvidia Jetson Projekten weis ich, dass die Instanzen Segmentierung mit Pytorch mit kleinem Datensatz schwierig / instabil ist. Vielleicht ist das auch mit ein Grund.

Einen neuen Thread fände ich auch gut.
Viele Grüße
Wilhelm
 
Hallo Stefanie.
Nochmal vielen Dank für deine Hilfe und Anregungen. Den alten Datensatz habe ich verworfen und baue systematisch einen neuen auf. Technisch läuft der neue Satz schon. Es werden zwar nur ein Meteor (2 Instanzen) und ein Schmetterling erkannt, aber es waren auch nur 4 Epochen, 8 Testbilder und 16 Trainingbilder.
Das rechte Bild vom Schmetterling ist eine UV-Aufnahme. Er sitzt auf Jakobs-Greiskraut.
Hier kommt die Sonne raus.
Einen schönen Tag wünsche ich Euch,
viele Grüße
Wilhelm

Edit: es ist noch einer dazugekommen.
 

Anhänge

  • 1-test.jpg
    1-test.jpg
    551,4 KB · Aufrufe: 114
  • 1-test-filled.jpg
    1-test-filled.jpg
    533,6 KB · Aufrufe: 116
  • 2-test.jpg
    2-test.jpg
    558,6 KB · Aufrufe: 118
Zuletzt bearbeitet:
Hallo Wilhelm,

Das sieht doch schon vielversprechend aus! Ich denke mit 100-200 Bilder sollte es schon einen signifikanten Fortschritt geben.

Ich bin gespannt ?

Beste Grüße
Stefanie
 
Hallo Stefanie,
danke für deinen Zuspruch. Den brauche ich auch: Das Annotieren ist ziemlich anstrengend und zeitraubend.
---------------------------------------------------------------------------------

Du hast direkt die Bildschirmausgabe abgegriffen und die Darstellung ist für dich zum Labeln natürlich einfach, aber für die KI wäre natürlich ein einfaches Wasserfall mit einem Graychannel optimaler. Heißt natürlich nicht, dass es nicht so geht...

Ich will das Thema nicht wegziehen... aber das wäre ein Beispiel mit Spektrogramm in Grayscale, mit gleichem Informationsgehalt wie die gekippte Ansicht.

Eine flache Darstellung mit Grau als Z würde meiner Meinung nach nichts bringen und höchstens zu einem Dynamikverlust führen.

Die Bilder im Anhang verdeutlichen anhand von Starlinks (direkt vergleichbare Meteore gibt es nicht), warum die 3D-Darstellung essenziell ist: Man bekommt im Wasserfall nur einen zarten Strich. Für die Rate ist der Wasserfall ok.

Viele Grüße
Wilhelm
 

Anhänge

  • GRAVES-XYmVV_230307084720.jpg
    GRAVES-XYmVV_230307084720.jpg
    306,6 KB · Aufrufe: 99
  • GRAVES-XYmVV_230307101520.jpg
    GRAVES-XYmVV_230307101520.jpg
    187,8 KB · Aufrufe: 102
  • SW-GRAVES-XYmVV_230307084720.jpg
    SW-GRAVES-XYmVV_230307084720.jpg
    170,4 KB · Aufrufe: 98
Hallo Wilhelm,

das Annotieren nervt, ich weiß :LOL: Sehr gut mit der 3-D Darstellung, wie erwartet liefert eine Axis mehr auch mehr Merkmale. Wobei wahrscheinlich auch die Frequenz und Zeitdauer Informationen aus den Log File Aufschluss geben könnten oder als (zusätzlichen) Merkmal nützlich sein könnten.

Wie schon gesagt zumindest die einfachen Beispiele könntest du aus den OpenCV Konturen umwandeln...

Weiterhin viel gelingen, Musik hilft :y:
Viele Grüße
Stefanie
 
Hallo Stefanie,
ich mache es erst mal von Hand. Gestern habe ich fast 50 Bilder geschafft.

Zwei Fragen habe ich aber noch: Würdest du eher eng oder weit labeln?
In dem engen Fall geht der Label etwas über das Echo.

Ist es von Nachteil, wenn zwei oder mehrere Echos in einem Bild sind?

Viele Grüße
Wilhelm
 

Anhänge

  • eng-auf-dem-Rand.png
    eng-auf-dem-Rand.png
    774,2 KB · Aufrufe: 117
  • weit&zwei.png
    weit&zwei.png
    1,2 MB · Aufrufe: 125
Zuletzt bearbeitet:
Hallo Wilhelm,

Wir Labeln eher grob / weit wie auf dem zweiten Beispiel. Das reicht für ausreichend Kanten Merkmale (daher ist eine Bounding Box ungünstig, du verlierst das Merkmal der Meteor Kanten). Das sollte reichen und geht etwas schneller. Mehrere ROIs im Bild sind eher von Vorteil, so lernt das Modell gleich, dass es zwei Objekte sind und trennt diese bestenfalls auch (wenn sie nicht überlappen).

Grüße
 
Hallo Wilhelm,

ich verstehe! Es lässt sich so wirklich schlecht Labeln für dich! Aber das Spectrogram im Graubild hat kein Informationsverlust.

Viele Grüße
Sebastian
 
Hallo Stefanie,
danke, das beruhigt mich und spart viel Arbeit.

Im Endeffekt sollen Überlappungen aber schon erkannt werden. Bin gespannt…
Viele Grüße
Wilhelm
 

Anhänge

  • Instance-Segmentation.jpg
    Instance-Segmentation.jpg
    549 KB · Aufrufe: 117
Zuletzt bearbeitet:
Doch, Farbe! Wenn auch nur für Wilhelms ColorMap aber dennoch.
Das versteh ich nicht? Beispiel: 0 bis 255 Stufen in Grau oder 0 bis 255 Stufen in einer anderen Colormap der Wahl… Kommt halt sehr drauf an welche Auflösung es aufgenommen wurde und in welcher Farbauflösung es per HDMI übertragen werden kann… Der HDMI Teil ist nen bissel Hacky, da ist die aktuelle Arbeit von Wilhelm schon beachtlich.
Aber ich seh das schon ein, im Graubild kann man das einfach nicht Labeln und unterscheiden.
Am schönsten wäre hier der Rohvektor des Spektrums in Floating Point. Dann kann man sich die Darstellung zum Labeln aussuchen und das CNN bekommt den Vektor direkt als „Graubild“. Wobei das mit dem Grau auch nur eine Colormap ist. Letztendlich ein definierter Wertebereich mit einer möglichst guten Dynamik.
Aber wir sind ja nicht bei Wünsch dir was ?
Was man versuchen könnte. Das Graubild zurück auf einen numpy Array zu lesen und dann zum Labeln wieder eine 3D Ansicht einblenden. Also das Beste aus beiden Welten ?
 
Vielleicht hab ich es auch falsch verstanden meinst du ein RGB Bild mit Grauwerten ColorMap?

Ansonsten RGB bzw HSV= 3 Kanäle
-> 3 mal 0-255 Werte

Graubild = 1 Kanal (1/3 der Information)
-> 1 mal 0-255 Werte
 
In den Bildern lassen sich sowohl die Deskretierungsstufen als auch die Farbübergänger in einem Ereignis noch sehr gut sehen. Ich vermute das hier eine Dynamik von 32 Digits, also 5 Bit im Mittel nötig ist. Mehr ist natürlich immer besser, aber nicht immer nötig. Daher meine Vermutung. Versteh man mich?

14 Bit ist sehr gut und sicher auch ausreichend. Wir haben bei unserem Radar, wo wir auch das Frontend, also die Hardware entwickelt haben den Noise floor bei -60 dB und haben eine Umschaltung zwischen 16 und 12 Bit ADC und sehen hier noch keinen Unterschied. Deine Anzeige steht bei -120 dB, dass wird wahrscheinlich mit verschiedenen Vorverstärkerstufen und Antennengewinnen zusammenhängen. Mit 14 Bit ADC würde man noch keine 0 bis -120 dB Dynamik erreichen.

Der Informationsgehalt in Farbe kann viel großer sein, da stimm ich euch voll zu. Gerade wenn HDMI 8Bit pro Farbe überträgt. Implementierungstechnisch kann es aber sein, dass die Colormaps einfach auf 256 Stufen limitiert sind. Also egal ob man grau oder farbstufen wählt.

Ich freu mich jedenfalls das es schon so gut klappt Wilhelm.??

Viele Grüße

Sebastian
 
Hallo Miteinander,
ich hab mal bisschen in dem Thema quergelesen und mir stellt sich jetzt die Frage ob es einen speziellen Grund dafür gibt das ihr die Meteor Echo Detektion so kompliziert aufzieht nachdem ihr bereist die Phaseninformation weggeschmissen habt, anstatt das ihr gleich vom komplexen Zeitsignal ausgeht, denn dann hättet ihr das Maximum der euch zur verfügung stehenden Information und könntet eventuelle notwendige Transformationen mit in das ML einbauen.
Da ich mich noch nicht so mit ML beschäftigt habe, könnte der Gedanke auch recht naiv von mir sein, also korrigiert mich wenn ich da falsch liege.

mfg
Rainer
 
Hallo Rainer,
danke fürs Lesen.
Ja, der Gedanke ist recht naiv.
Einen schönen Abend noch und viele Grüße
Wilhelm
 
Zuletzt bearbeitet:
Huhu,
ich glaube Phase macht keinen Sinn, da doch alles auf die Erde drauf fällt und die Phasendrehung beim einfachen Doppler Radar zeigt doch nur, ob es sich zum Radar hin bewegt oder davon weg.

Dein Beispielbild leidet leider für mich stark unter JPG-Komprimierungsartefakten und ich habe mal den Schriftzug entfernt:
test.png


Screenshot from 2023-03-08 09-58-19.png


"Jet" als Colormap finde ich sogar noch etwas unübersichtlich.

Source:
Code:
import numpy as np
import matplotlib.pyplot as plt
from skimage import io

img = io.imread('test.png', as_gray=True)
xx, yy = np.mgrid[0:img.shape[0], 0:img.shape[1]]
fig = plt.figure()
ax = fig.gca(projection='3d')
ax.plot_surface(xx, yy, img ,rstride=1, cstride=1, cmap=plt.cm.jet, linewidth=0)
ax.set_box_aspect([2,1.3,1])
ax.view_init(elev=45., azim=45)
plt.show()

Vorteil ist weiterhin, dass deine Aufgabe von einer einfachen Backgroundsubstraction profitieren wird. Hier ein Medianclipping-Beispiel:
Screenshot from 2023-03-08 10-26-21.png


Code:
img = np.clip(img, np.median(img)*2, np.max(img))

Das mit dem JPEG Atefakten ist natürlich nicht so optimal.


Viele Grüße

Sebastian
 
Zurück
Oben