Ich suche zur Erfassung mehrere gleichzeitiger Ereignisse eine Entwicklungsplattform für Bildverarbeitung auf FPGA-Basis. Könnt ihr mir etwas empfehlen? Im Grunde brauche ich zunächst nur bilder in 1280*960 oder ähnlich bei einer Bildrate von 60 pro Sekunde. Wichtig ist Echtzeit um später Ereignisse mit mehreren Kameras aufzunehmen, vielleicht auch bei höherer Bildrate. Habe bereits von Elphel (www.elphel.com) eine interessante Lösung gefunden, gibt es ähnliche Alternativen? Was wäre eine optimale Softwarelösung um mehrere Bildquellen zeitgleich auszuwerten (Matlab? OpenCV?) und als JPEG zu speichern?
Bei 1280x960 kommen viele Plattformen in Frage, ich wuerde etwas mit Xilinx Zynq Ultrascale+ nehmen, damit hat man eine Fuelle an Moeglichkeiten. Was fuer Kameras wilst du denn anschliessen? Was sind deine Schnittstellen? Hier kann man die Auswahl dann wieder etwas eingrenzen.
ich verstehe gerade nicht, wonach du suchst. Du möchtest Kameras "anschließen" und die Bilder zeitstempeln. Ok. Aber dann fragst du nach einer Auswertungsmethodik? Wenn ich mich nicht irre, tun sich sowohl Matlab als auch OpenCV mit FPGAs schwer. Also sollen die FPGAs die Daten nur wegspeichern und die Auswertung geschieht am Rechner? Warum nicht gleich ein Echtzeitbetriebssystem auf den Rechner spielen und alles dort laufen lassen? Oder, falls das unbedingt im FPGA sein muss: was heißt denn "Auswertung"? Wie komplex wird's da? Läuft ein neuronales Netz mit Millionen von Parametern? Oder wird nur die druchschnittliche Helligkeit der Bilder verglichen?
Andreas schrieb: > 1280*960 Das ist Tech von vorgestern. Mein Kunde hat schon vor 4 Jahren komplett auf HDMI2.0 umgestellt und arbeitet jetzt auf 3840x2160. Momentan gibt es preiswerte HDMI-fähige Überwachungskameras von den Chinesen, die direkt über IP senden. Kriegt man über Kabel bis zu 8 Stück dran. Auf Wunsch GigEVision. geht mir frame grabbern direkt in den PC. Manuelle Verarbeitung mit Video-Chips, DSPs inklusive Bildfusion, wenn unbedingt nötig. Brauchen aber nur wenige Kunden. FPGAs braucht man da gar keine mehr für, es sei denn, dort muss eine Sonderverarbeitung rein. Militär z.B.
Danke für Eure Tipps! @Tobias: Das sollten fertige Kameramodule sein, mit paralleller Ausgabe. Ich habe noch von Micron ein Developer Kit. Schnittstellen zum PC sind USB oder Ethernet. Mit günstigen USB kameras habe ich bereits experimentiert, da dauert es aber teils bis zu 100ms bis das Bild eintrifft. Per Ethernet habe ich vermutlich bessere Karten. @rava: Die Auswertung soll selbstverständlich auf dem PC laufen. Entschuldige die unpräzise Angabe. Das FPGA soll zunächst die Daten nur schnell an den PC liefern, am liebsten schon JPEG-komprimiert. Alles andere kommt später. Ich muß nur wissen wann die Bilder gemacht wurden (auf ms genau). Also brauche ich nur den Zeitstempel vom FPGA und irgend eine Möglichkeit in der Software darauf zuzugreifen. Mir ist auch klar, dass es dafür Fertiglösungen von Machine Vision Anbietern gibt, die alleridngs sehr kostspielig werden sobald man sie programmieren will.
@Videomann: Ich brauche nicht mehr als die Auflösung, auch wenn es Schnee von gestern ist. HDMI ist keine Option... Schliesslich soll ein einfacher Algorithmus auf dem FPGA laufen, deshalb ist das zunächst so angedacht.
Die Kameras haben heute selber alle FPGAs drinnen, die so ziemlich alles können, was man da machen kann und muss. Alles fertig parametrierbar. Schau dich mal bei den Industriekameras um. Es gibt allein in DE >10 Hersteller, die sowas haben.
von Lattice gibts eine VIP Demo Board. (Video Interface Platform) Sind auch komplette gleich zwei Sony Sensoren drauf die gleich ein Bild abgeben. Die Deep Learn Bibliotheken dazu heissen Caffe und TensorFlow. Auswertung auf dem PC ist wegen der Leistungsaufnahme, dem schlechten Echtzeitverhalten, der miserablen Zuverlässigkeit, den langen Bootzeiten usw. zumindest beim autonomen Fahren und anderen wichtigen Anwendungen verpönt
Moin, das VIP hätte ich jetzt auch empfohlen, allerdings dann mit dem separaten Zusatzbrett mit GigE und USB3-Option. Da gibts auch fertige Referenzdesigns zum Streaming per YUV-raw oder MJPEG per RTP, guck mal nach RFC2435. Auf PC-seite bist du mit gstreamer sehr flexibel was Verarbeitung/Speicherung angeht. Wieviel Resourcen braucht deine Verarbeitung? Allenfalls wird's irgendwann mit BRAM eng, debayer und jpeg sind kleine Speicherfresser.
Ok, bin jetzt einen Schritt weiter. Das Lattice-Kit paßt wohl ganz gut für einen ersten Ansatz. Habe auch schon einen freien JPEG-Encoder bei opencores.org gefunden. Die Blockartefakte bei hoher Kompressionsrate bereiten allerdings noch etwas Kopfschmerzen. Kennt jemant eine gute Alternative? Gibt es verbesserte Algorithmen oder sollte man besser auf JPEG2000 gehen? Ich brauche keine neuronalen Netze oder solches. Der Algorithmus ist wie gesagt recht einfach und sollte wenig Blockram benötigen.
Nimm sonst h264, JPEG und JPEG2000 sind nicht low latency. Die Bloecke sind bei h264 kleiner und stoeren weniger. Opencores kannst vergessen. Guck mal bei https://github.com/bcattle/hardh264.
Weiss nicht, was jetzt bei euch als "low latency" gelten soll, aber die minimalen 8 Bildzeilen (und ein paar zerquetschte) bei JPEG sind mehr als ausreichend, gemessen daran, dass auch bei einem Rolling-Shutter-Sensor intern schon einiges an Verzögerung anfallen kann. Das ist allerdings bei den meisten Sensoren, die Rohdaten ausgeben, deterministisch (also Zeitpunkt der Aufnahme bestimmbar). Wozu brauchst du dann noch low latency? Bei JPEG2k kriegt man's mit Tiling auch in die Richtung, zumindest wenn man einiges vom Standard abspeckt, hat dann aber auch wieder irgendwann Block-Artefakte. Bei JPEG kann man mit cleverem Residual-Coding die Block-Artefakte wegbekommen. Ist aber nicht mehr Standard und nicht mal eben so implementiert. Bin gespannt, wie sie's beim (zukünftigen) JPEG XS hinkriegen. Bei h264 ist "low latency" recht "bedingt" und der Encoder deutlich komplexer. Viel Spass kannst du bei den opencores-Sachen aber schon mal mit effizientem Streaming haben. Es macht einen grossen Unterschied, ob ein Codec nur ein "Beschleuniger" ist oder richtig synchron arbeitet. Ansonsten gilt, wie fast immer: Zeit ist Geld (wenn nicht Lernprojekt), darum würde ich mich auf den Kernalgo fokussieren und die Kompression wenn nötig ganz am Schluss dazukaufen.
Andreas schrieb: > Per Ethernet habe ich vermutlich bessere Karten. > > @rava: Die Auswertung soll selbstverständlich auf dem PC laufen. Da du das eine erkannt hast und das andere sowieso willst, dann verstehe ich nicht, wozu jetzt noch ein FPGA gut sein soll. Es gibt doch fix und fertige Überwachungskameras, die einen RTSP-Stream liefern. Und selbst in recht hoher Qualität sind die nichtmal mehr allzu teuer (~400€ für full HD). Und sie enthalten bei diesem Preis sogar schon eine fertige Entzerrung für die Optik, Bewegungserkennung und weiteren Schnickschnack, den man benutzen kann, aber nicht benutzen muss...
Andreas schrieb: > @rava: Die Auswertung soll selbstverständlich auf dem PC laufen. > Entschuldige die unpräzise Angabe. Das FPGA soll zunächst die Daten nur > schnell an den PC liefern, am liebsten schon JPEG-komprimiert. Alles > andere kommt später. Ich muß nur wissen wann die Bilder gemacht wurden > (auf ms genau). Also brauche ich nur den Zeitstempel vom FPGA und irgend > eine Möglichkeit in der Software darauf zuzugreifen. Vergiss das FPGA. https://www.ximea.com/en/products/xilab-application-specific-custom-oem/embedded-vision-and-multi-camera-setup-xix/sony-imx174-fast-color-industrial-camera Da bekommst Du per PCIe die rohen Kameradaten direkt mit 10 MBit/s in Deinen Hauptspeicher geschrieben. Ohne weitere Latenzen. Direkter gehts nicht. Triggern kannst Du per Software oder per Hardware (Trigger-Signal-Inputs und Outputs vorhanden). Dann weißt Du wirklich, wann das Bild entstanden ist. Global Shutter ist dann auch nützlich. fchk
c-hater schrieb: > Da du das eine erkannt hast und das andere sowieso willst, dann verstehe > ich nicht, wozu jetzt noch ein FPGA gut sein soll. Es gibt schon eine Reihe von Sachen, die man mit einem Bild on the fly machen kann (und auch muss), bevor es in die Bildauswertung auf einen Rechner geht. Das haben schon einige lernen müssen. Idealerweise packt man die Daten, die der FPGA aus dem Bild ermittelt in den Datenstrom zum PC mit hinein. Wenn allerdings die Karte nur den Videokanal hat, dann wird das wiederum etwas tricky, geht aber.
So - hat etwas gedauert, bin jetzt ein Stück weitergekommen mit dem Kit von Lattice. Der Sensor ist allerdings nicht in unserem Sinn, aber das spielt für den Algorithmus keine Rolle. Sorry daß ich darauf nicht näher eingehen kann. Mir auch klar, daß die guten Tips nicht für lau sind, aber ich wollte trotzdem noch ein Thema anschneiden: Bildkompression. JPEG haben wir evaluiert, Problem ist die Bildqualität, sonst ist die Verzögerung optimal. Welche Verfahren sind sonst noch im FPGA umsetzbar, kann man verlustfreie Verfahren sinnvoll mit niedriger Latenz im Prinzip schaffen, oder sollte man einen fertigen Standardcodec einkaufen? Bisher haben wir Tests mit PNG und WebP gemacht, die ausreichend komprimieren. Kann also in der Richtung sein.
Andreas schrieb: > Problem ist die Bildqualität Klar ist JPEG verlustbehaftet. Aber die Frage ist ja: muss es unbedingt verlustfrei sein? Steckt in jedem Pixel eine Information, die genau so vom Bilsaufnehmer bis zur Anzeige/Verarbeitungssystem übertragen werden muss? Oder reicht es nicht aus, wenn das JPEG Bild "ausreichend gut" ist, weil die Information in der Gesamtheit des Bildes steckt (wie das z.B. bei Fotos oder Filmen so üblich ist)?
Komprimierung und algorithmische Auswertung von Kamerabildern vertragen sich nicht gut. Das gilt umso mehr, je schlechter die Bildqualität wird. Mein Arbytegeber setzt daher PCIe-Kameras ein, die ihre Daten im Rohformat in Echtzeit direkt in den Hauptspeicher des PCs schreiben. PCIe Gen2 mit 2 oder 4 Lanes und 5 Gbit/s pro Lane lassen genug Luft für reichlich Megapixel bei bis zu 200 Frames pro Sekunde. Dieses Vorgehen hat sich hier sehr bewährt. fchk
Lothar M. schrieb: > Andreas schrieb: >> Problem ist die Bildqualität > Klar ist JPEG verlustbehaftet. Aber die Frage ist ja: muss es unbedingt > verlustfrei sein? Steckt in jedem Pixel eine Information, die genau so > vom Bilsaufnehmer bis zur Anzeige/Verarbeitungssystem übertragen werden > muss? Genau, wie Ex-Cheffe (Bildverarbeitungsbude) zu sagen pflegte, JPEG ist verlustfrei, weil es das Rauschen entfernt und mehr als 10bit pro Farbkanal sind unnötig weil der Mensch eh nur ca. 1000 Farbtöne unterscheiden kann und die beiden unteren bits ohnehin im Sensor/ADC-Rauschen untergehen. Cheffe hatte da einen eigenen Komprimieralgo, der ca 1000 Logicelemente benötigte. Ansonsten mal in den Klassiker ISBN: 978-3642130960 schauen, worauf es wirklich ankommt.
Camera posterior bulbi schrieb: > mehr als 10bit pro Farbkanal sind unnötig weil der Mensch eh nur ca. > 1000 Farbtöne unterscheiden kann Mit 10 Bit pro Farbe kann ich aber über 1000³ unterschiedliche Farben darstellen. Da meinte er vermutlich 10 Bit für die gesamte Farbinformation.
Lothar M. schrieb: > Camera posterior bulbi schrieb: >> mehr als 10bit pro Farbkanal sind unnötig weil der Mensch eh nur ca. >> 1000 Farbtöne unterscheiden kann > Mit 10 Bit pro Farbe kann ich aber über 1000³ unterschiedliche Farben > darstellen. Da meinte er vermutlich 10 Bit für die gesamte > Farbinformation. Njein, er bezog sich auf die Grauwert-Digitalisierung eines Sensors mit Bayer-Matrix. Genaugenommen sprach er also nicht von Farbtönen sondern Helligkeitsabstufubgen einbes Graukeils die das Säugetierauge noch auflösen kann. https://www.hardwareluxx.de/images/stories/newsbilder/tfreres/2015/10-bit-ausschnitt-71cbac2d6216df6e.jpg Um die Frage zu beantworten, wieviel Farben tatsächlich nötig sind, müsste man vielleicht zu einem Palettenbasierenden System zugreifen, weil bspw tiefere Grünauflösung wohl wichtiger für die Bild(Helligkeits-) Information ist (deshalb hat eine Bayer-matrix auch doppelt soviel grün-Filter). ein Bild mit einer gut gewählten Palette von 1024 wirkt deutlich natürlicher als eins mit 3:4:3 bit R:G:B https://en.wikipedia.org/wiki/Indexed_color
fchk schrieb: > PCIe Gen2 mit 2 oder 4 Lanes und 5 Gbit/s pro Lane lassen genug Luft für > reichlich Megapixel bei bis zu 200 Frames pro Sekunde. Welche Kameras und wieviele lanes?
Hein schrieb: > fchk schrieb: >> PCIe Gen2 mit 2 oder 4 Lanes und 5 Gbit/s pro Lane lassen genug Luft für >> reichlich Megapixel bei bis zu 200 Frames pro Sekunde. > > Welche Kameras und wieviele lanes? verschiedene mit 2 oder 4 Lanes. z.B.: https://www.ximea.com/en/products/xilab-application-specific-custom-oem/Embedded-vision-cameras-xiX oder https://www.ximea.com/support/wiki/xib/PCI_Express_camera_-_xiB und davon dann bis zu 6 an einem Rechner. Weniger Latenz geht nicht. Und wer zeitstempeln will, will keinen Rolling Shutter, sondern Global Shutter. fchk
:
Bearbeitet durch User
Lothar M. schrieb: > Da meinte er vermutlich 10 Bit für die gesamte > Farbinformation. Die meisten industriellen Kameras haben einen 10Bit Ausgang pro Farbe. Ich hatte auch schon welche mit 12 Bit x 3 und 10 Bit x 4 (RGBX). Sensoren liefern durchaus noch mehr. Luminance mit 16 Bit in variabler lokaler Dynamik. Vor Zeiten war ich mal in Sensorproduktion involviert, welche >120dB absolute Dynamik hatten. Im Consumerbereich wird nur abgeschnitten, entrauscht und reduziert. Je nachdem, was an Beleuchtung da ist. Das liegt am HDMI-Standard der ersten Generation, bei dem man nicht ausreichend Bandbreite hatte. Auch mit HDMI 2.0 gehen 10 Bit nicht in 4:4:4 mit 60Hz. Camera posterior bulbi schrieb: > weil der Mensch eh nur ca. 1000 Farbtöne > unterscheiden kann und die beiden unteren bits ohnehin im > Sensor/ADC-Rauschen untergehen. Für Bildverarbeitung ist es unerheblich, was der Mensch sieht. Man kann auch im Rauschen Information über Bildhinhalte ermitteln und zu Messungen und Berechnungen heranziehen. Geht dann frequenztechnisch von langen Bildfiltern bis hin die Auflösungsgrenze des Optik, wenn nur noch 2 pxl angesteuert werden. Muss nur die richtige Sorte Filter drauf. Das konnte ich unlängst eindrucksvoll darlegen!
Mehr als 8 bit sind momentan nicht das Thema, aber kann noch werden. Der Algorithmus arbeitet nicht auf dem komprimierten Datenstrom, aber fürs speichern der Sequenzen (Archivierung von Ereignissen) wäre Kompression vorgesehen. Es ist schlußendlich kein PC mehr im Spiel, außer für Loggen und nachträgliche Auswertung, der Zeitstempel ist nur noch für Synchronisation. JPEG ist eigentlich ok, aber die Artefakte stören eben. Rolling Shutter ist jetzt auch nicht das große Problem, den Sensor wechseln wir dann einfach aus wenn mehr Qualität gefordert wird. Ich stelle mir da einfach nur eine Realisierung von PNG o.ä. im FPGA vor aber muß auch auf Ressourcen achten
Andreas schrieb: > im FPGA vor > aber muß auch auf Ressourcen achten Die Zynq Ultras haben einen internen MPEG Kopressor in Hardware drin. Muss nur angeschlossen werden.
Hein schrieb: > Die Zynq Ultras haben einen internen MPEG Kopressor in Hardware drin. > Muss nur angeschlossen werden. Sinnfreier Hinweis da: Andreas schrieb: > So - hat etwas gedauert, bin jetzt ein Stück weitergekommen mit dem Kit > von Lattice.
Hein schrieb: > Andreas schrieb: >> im FPGA vor >> aber muß auch auf Ressourcen achten > > Die Zynq Ultras haben einen internen MPEG Kopressor in Hardware drin. > Muss nur angeschlossen werden. Sogar mit H.264 und 265. Man muss nur beachten, dass der einen Grossteil in Logik macht und externen DDR Speicher braucht. Wenn das aber kein Problem darstellt, ist das eine Klasse Sache.
Andreas schrieb: > Welche Verfahren sind sonst noch im FPGA umsetzbar, kann man > verlustfreie Verfahren sinnvoll mit niedriger Latenz im Prinzip > schaffen, oder sollte man einen fertigen Standardcodec einkaufen? > Bisher haben wir Tests mit PNG und WebP gemacht, die ausreichend > komprimieren. Kann also in der Richtung sein. WebP ist m.E zu komplex für's FPGA, aber den PNG-Prädiktor kriegst du gut umgesetzt und kommst mit dem klassischen Bitplane-Coding und nachgeschaltetem Huffman-Coder auf ähnliche Kompressionsraten im verlustfreien Bereich, die Latenz ist da im Bereich von Bildzeilen. Hängt halt immens von der Bildquelle ab, ob monochrom oder Farbe, durch Optik bedingte Korrelationen, Bayer-Pattern usw. Wenn's nahezu verlustfrei (kaum sichtbare Artefakte) sein darf, kriegst du mit blockweiser Wavelet-Dekomposition à la JPEG2k und Quantisierung ganz gute Ergebnisse. Fürs FPGA sind mir allerdings keine OpenSource-Codecs bekannt, und eine Eigenentwicklung ein recht aufwendiges Unterfangen. Bei 'nearly lossless' scheiden sich generell die Geister, da gibt es eine Menge unterschiedlicher Metriken (PSNR, SSIM, ...). Siehe auch encode.ru. Tobias B. schrieb: > Sogar mit H.264 und 265. Man muss nur beachten, dass der einen Grossteil > in Logik macht und externen DDR Speicher braucht. Die Latenz scheint da nur recht hoch zu sein, wie hoch konnte mir der MA auf der Messe allerdings nicht sagen.
Strubi schrieb: > Tobias B. schrieb: >> Sogar mit H.264 und 265. Man muss nur beachten, dass der einen Grossteil >> in Logik macht und externen DDR Speicher braucht. > > Die Latenz scheint da nur recht hoch zu sein, wie hoch konnte mir der MA > auf der Messe allerdings nicht sagen. Jep, das ist aber auch logisch und Codec bedingt, da holt man nicht mehr viel raus. Bei den Kodierungsverfahren gehen die Algorithmen auch zeitlich ueber die Frames. In PG252 sind die verschiedenen Latenzen angegeben und reichen von 1 (beim Encoding) bis 5 (beim Decoding) Frames. Ist halt die Frage ob man wirklich H264 und H265 mit Echtzeit kombinieren muss (Kompressionsverfahren und Echtzeit beissen sich immer gegenseitig). Spontan faellt mir da nicht wirklich was ein, zumindest nicht bei Kamerasystemen in Broadcast, Automotive und Medizin. Beim Abspielen und Aufzeichnen von Content spielt Latenz keine Rolle und selbst wenn, dann sind die ~80 ms auch kein Beinbruch (selbst fuer viele Echtzeitanwendungen ist das noch in Ordnung).
:
Bearbeitet durch User
Tobias B. schrieb: > Beim Abspielen und Aufzeichnen von Content spielt Latenz keine Rolle Jepp, früher(tm) beim DVD-Rippen hat es auch keinen gestört, wenn der Rechner über Nacht durchlief, um das Video auf CD-Größe zu bringen ;-)
Bernd schrieb: > Tobias B. schrieb: >> Beim Abspielen und Aufzeichnen von Content spielt Latenz keine Rolle > Jepp, früher(tm) beim DVD-Rippen hat es auch keinen gestört, wenn der > Rechner über Nacht durchlief, um das Video auf CD-Größe zu bringen ;-) Stimmt, tolles Extrembeispiel! :-D
Tobias B. schrieb: Bernd schrieb: >> Beim Abspielen und Aufzeichnen von Content spielt Latenz keine Rolle > Jepp, früher(tm) beim DVD-Rippen hat es auch keinen gestört, wenn der Hier verwechselt jemand Latzenz mit Bandbreite. Klar ist die Latenz egal, aber die Bilder müssen in Echtzeit verpackt werden können und das erfordert power. Also nix mit "warten über Nacht".
Hotte schrieb: > Tobias B. schrieb: > Bernd schrieb: >>> Beim Abspielen und Aufzeichnen von Content spielt Latenz keine Rolle >> Jepp, früher(tm) beim DVD-Rippen hat es auch keinen gestört, wenn der > > Hier verwechselt jemand Latzenz mit Bandbreite. Klar ist die Latenz > egal, aber die Bilder müssen in Echtzeit verpackt werden können und das > erfordert power. Also nix mit "warten über Nacht". Ne, das passt doch. Der Xilinx Core schafft von der Bandbreite De- und Encoding in 4K@30Hz (oder sogar 60Hz, muesste ich nachschauen), hat halt Algorithmen bedingt ein paar Frames Latenz. Dann wurde diskutiert, dass es praktisch keine Anwendung bei dem diese Latenz eine Rolle spielt. Als Extrembeispiel wurde das DVD Rippen ins Feld gefuehrt. Von daher ist die Argumentationskette in Ordnung, ich denke hier ist jedem der Unterschied zwischen Bandbreite und Latenz bewusst. ;-)
Tobias B. schrieb: > Jep, das ist aber auch logisch und Codec bedingt, da holt man nicht mehr > viel raus. Könnte man aber eigentlich. Mit streifenweiser Codierung schafft man bei h264 auch sub-frame Latenzen, da kann der Monitor bzw. Framebuffer noch eher der Bösewicht sein (Ende zu Ende überprüft mit Lichtblitz und Fototransistor).
Strubi schrieb: > Könnte man aber eigentlich. Mit streifenweiser Codierung schafft man bei > h264 auch sub-frame Latenzen, da kann der Monitor bzw. Framebuffer noch > eher der Bösewicht sein (Ende zu Ende überprüft mit Lichtblitz und > Fototransistor). Kannst ja mal in PG252 reinschauen. Da gibts ein ganzes Kapitel zu dem Thema und evtl. ist diese Option sogar vorhanden?
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.