Ich plane grade ein Projekt, welches sicher schwierig mit einem AVR wird, aber ich denke es ist machbar: Aufgabe: 1.)Bildaufnahme über Kamera 2.)Speicherung und Kompression auf einem AVR 3.)Senden des Bildes über eine (weite) Funkstrecke 4.)Dekompression in einem AVR 5.)Ausgabe auf TFT Anforderugen: 1.)240x320 Pixel mit 8 bit Farbtiefe macht 75KB 2.) 3.)über 1km sollte es sein, Übertragungsrate >=1Kbit/s Hardware) 1.)OV7670 2.)Atmega 128/2560 mit externem (SPI?)-RAM (für die Rohdaten) 3.)SI4463 Tranceiver Modul mit 20dBm TX und -110dBm RX bei 40kbps (-126dBm bei 500bps) https://www.silabs.com/Support%20Documents/TechnicalDocs/Si4464-63-61-60.pdf 4.)Wie 2. 5.)2.4 Zoll TFT Arduino Modul mit ILI9325 o.ä. Software: Die Kompression soll den internen RAM verwenden, also sich möglichst mit 4kB begnügen. Die Rohdaten sollen Blockweise aus dem externen RAM gelesen und gespeichert werden. Es soll sich am PNG-Format orientieren. Also: 1)Dekorrelation Über Delta-Kodierung differenz zu Nachbrapixeln berechnen, sollte Problemlos sein. 2)Substitutionskompression LZSS sollte auch mit kleinem Wörterbuch laufen. Es gibt auch eine AVR implementierung: http://spin.atomicobject.com/2013/03/14/heatshrink-embedded-data-compression/ 3)Entropiekodierung Also Huffmann Dekompression gibt es ja schon: https://www.das-labor.org/wiki/AVR-Huffman/en Ich schaue grade ob inwiefern Huffman Encoden möglich sein sollte auf einem kleinen AVR Kommentare erwünscht Lars
@ Lars (Gast) >1.)240x320 Pixel mit 8 bit Farbtiefe macht 75KB >2.) >3.)über 1km sollte es sein, Übertragungsrate >=1Kbit/s Klingt eine wenig na SSTV (slow scan TV) >Die Kompression soll den internen RAM verwenden, also sich möglichst mit >4kB begnügen. Geht schon. >Ich schaue grade ob inwiefern Huffman Encoden möglich sein sollte auf >einem kleinen AVR Sowas hab ich vor Ewigkeiten mal auf dem 68HC11 gemacht, in ASM. Das Grundprinzip ist ja einfach.
Entschuldigt ich war ein wenig in Eile grade: Es schreibt sich natürlich Huffman ohne nn Zu den Anforderungen habe ich vergessen: 2.)70% Kompressions wären schön
Es gibt Kameras, die werden über RS232 gesteuert und liefern bereits ein komprimiertes Bild. Da müsste dein MC das nur noch senden und nicht selber dran rummachen ... https://learn.adafruit.com/ttl-serial-camera/overview
- Sportlich... wie viel Frames / Jahr sollen übertragen werden? - Warum nimmst Du nicht gleich einen 16 Bit µC? - Bringt diese Art der Kompression überhaupt nennenswerte Verkleinerung bei Pixeldaten? Würde ich vorher mit gängigen Programmen auf dem PC testen. Wenn die Berechnung der Kompression länger dauert als die Zeiteinsparung auf der Übertragungsstrecke... macht es wenig Sinn. Bei Best Case 40kbps dauert ein Bild raw ca. 16 Sekunden, dafür lohnt sich imho der Kompressionsoverhead nicht. Nur bei schlechter Verbindung. - Amateurfunker machen seit zig Jahren SSTV (Slow Scan TV), das ist etwas ähnliches, allerdings rein analog. Vielleicht kannst Du Dir da ein paar Anregungen holen: https://de.wikipedia.org/wiki/Slow_Scan_Television - Die verlustfreien Kompressionsverfahren werden gerade bei Pixeldaten um Längen geschlagen durch die verlustbehafteten Kompressionsverfahren. JPEG wäre hier besser, wenn Du ein Standbild einer z.B. Überwachungskamera hast wäre MPEG noch besser. Allerdings ist das ein Abwägen verfügbare Prozessorleistung vs. Übertragungsgeschwindigkeit, siehe 2).
Wie wäre es mit einem STM32F4 als Mikrocontroller, die haben bis zu 256 KB internem RAM, da sparst du dir den externen. Außerdem haben die ein Kamera-Interface als Peripherie, eine FPU, DSP-Extensions und jede Menge Rechenleistung. Sollte zur Bildverarbeitung wesentlich besser geeignet sein als ein AVR... Mit dem STM32F407-Discovery-Board kriegst du den bereits einsatzbereit verlötet inkl. Debugger/Programmer für < 20€. Das STM32F429-Discovery-Board hat sogar ein Touch-LCD und 8 MByte SDRAM mit dabei für < 30€.
Mit dem STM32 könnte man vielleicht sogar ein Waveletverfahren einsetzen. Das gibt dann berssere Qualität bei kleineren Bildern. :-)
Tcf K. schrieb: > - Die verlustfreien Kompressionsverfahren werden gerade bei Pixeldaten > um Längen geschlagen durch die verlustbehafteten Kompressionsverfahren. Soweit richtig, allerdings ist JPEG noch deutlich aufwändiger. Tcf K. schrieb: > - Bringt diese Art der Kompression überhaupt nennenswerte Verkleinerung > bei Pixeldaten? Ja, 1:3 bis 1:10 sind realistisch bei PNG, auch die Quellen zu LZSS + Huffman lassen darauf schließen, dass 70% weniger möglich sind. Tcf K. schrieb: > - Warum nimmst Du nicht gleich einen 16 Bit µC? Der Sportlichkeit wegen, aber ich werde mal recherhieren, wo die Hardwaregrenze für JPEG liegt, dann ergibt aufrüsten Sinn. Tcf K. schrieb: > Best Case 40kbps dauert ein Bild raw ca. 16 Sekunden, dafür lohnt sich > imho der Kompressionsoverhead nicht. Nur bei schlechter Verbindung. Ursprünglich hatte ich an AX25 Packet Radio über Funkgerät mit 1200Baud gedacht, da ist jedes % weniger Gold wert. Der Zeitaufwand sollte überschaubar sein, wenn denn erstmal genug RAM zur verfügung steht. Frank E. schrieb: > Es gibt Kameras, die werden über RS232 gesteuert und liefern bereits ein > komprimiertes Bild. Bringt mir nichts, da JPEG ja auch komprimiert werden will Außerdem ist Display (4€)+ Kamera (7€) + Ram (2*1€) + AVR(2*5€)+ Funkmoduk(2*4€) schon sehr sexy (jeweils bei Aliexpress). Aber es stimmt schon für den gleichen Preis der großen 8-Bit Controller bekommt man auch 16-Bit oder gleich einen kleinen ARM.
Lars schrieb: >> Es gibt Kameras, die werden über RS232 gesteuert und liefern bereits ein >> komprimiertes Bild. > Bringt mir nichts, da JPEG ja auch komprimiert werden will Ich meine natürlich dekomprimiert auf Empfängerseite. Und das geht auch nicht im Atmega.
Und zum Anzeigen z.b. das stm32f7 discovery, das hat ein 4.3" display mit kapazitivem touch etc drauf. Es ist sogar ein micro sd slot drauf wo du die bilder abspeichern könntest und kostet auch nicht viel. Mfg
@ Lars (Gast) >> Bringt mir nichts, da JPEG ja auch komprimiert werden will >Ich meine natürlich dekomprimiert auf Empfängerseite. Und das geht auch >nicht im Atmega. Sicher? http://elm-chan.org/fsw/tjpgd/00index.html
Lars schrieb: > Ja, 1:3 bis 1:10 sind realistisch bei PNG Quatsch mit Soße. Das hängt natürlich extrem stark davon ab, was genau zu komprimieren ist. Fotos "natürlicher" Szenarien z.B. kann PNG längst nicht so gut komprimieren wie JPEG es kann. > auch die Quellen zu LZSS + > Huffman lassen darauf schließen, dass 70% weniger möglich sind. Hier gilt ganz genau das gleiche. Es hängt extrem stark vom Inhalt ab, was erreichbar ist. Das ist ganz grundsätzlich so bei verlustfreier Kompression. Die erreichbare Kompressionsrate wird ganz grundsätzlich durch die Entropie des zu komprimierenden Inhaltes selber begrenzt. Die Pack-Algorithmen können sich dann nur mit tendenziell in's Unendliche wachsendem Rechenzeitaufwand diesem Ideal annähern. Bei Sachen wie JPEG (was eben nicht verlustfrei ist), sieht das ganz anders aus. Hier wird von vorherein durch den Algorithmus in Kauf genommen, daß "unwichtige" Informationen dabei den Bach runtergehen. Auch wenn bei solchen Algorithmen dann an irgendeiner Stelle letztlich doch ein Entropieencoder verwendet wird, passiert das für's Kompressionsergebnis Entscheidende immer bereits vorher: Das (unwiederbringliche) Wegwerfen (hoffentlich wirklich unwichtiger) Information. Der entscheidende Trick und das Erfolgsgeheimnis aller verlustbehafteter Kompression ist also die möglichst treffsichere Separation (im Sinne der Anwendung) "wichtiger" und "unwichtiger" Inhalte.
c-hater schrieb: > Das ist ganz grundsätzlich so bei verlustfreier Kompression. Ist bei verlustbehafteter Komprimierung auch nicht anders. Blick aufs Meer ist bei Sturm und Regen deutlich schwergewichtiger als bei blauem Himmel und totaler Flaute. Wenns nicht grauslich aussehen soll.
:
Bearbeitet durch User
A. K. schrieb: > Ist bei verlustbehafteter Komprimierung auch nicht anders. Blick aufs > Meer ist bei stürmischer und regnerischen Nordseeküste auch > schwergewichtiger als bei blauem Himmel und totaler Flaute. Nein. Da besteht ein ganz grundsätzlicher Unterschied. Bei verlustbehafteter Kompression kannst du durchaus vorgeben, das beides gleich "schwergewichtig" sein soll. Natürlich wird bei Herbstbildern dann weniger Information weggeworfen werden müssen als bei sonnenbestrahlter Urlaubspostkartenidylle, das ist klar. Aber du hast die Kontrolle über die letztlich nötige Bitrate für Übertragung bzw. Speicherung. Das nennt sich dann CBR. Oder du kannst zugunsten der Qualität oder als Reaktion auf die aktuelle Kapazität eines Übertragungskanals damit rumspielen. Das ist dann VBR. Der springende Punkt ist: du selber kontrollierst das, nicht allein die Entropie des Inhaltes.
c-hater schrieb: > Lars schrieb: > >> Ja, 1:3 bis 1:10 sind realistisch bei PNG > > Quatsch mit Soße. >> auch die Quellen zu LZSS + >> Huffman lassen darauf schließen, dass 70% weniger möglich sind. > > Hier gilt ganz genau das gleiche. Es hängt extrem stark vom Inhalt ab, > was erreichbar ist. Finde ich auch optimistisch. Verlustlose Kompression (RLL/Diff + Huffman) bei "normalen" Aufnahmen mit einer Rate jenseits 50% bei 4KB RAM finde ich schon sehr sportlich. Die o.g. JPG lib sieht aber interessant aus. 'Interlaced' (also mit geringerer Auflösung oder Color Quantisation und dann aufsteigend) wäre möglicherweise ebenfalls eine Option.
:
Bearbeitet durch User
S. J. schrieb: > Die o.g. JPG lib sieht aber interessant aus. Das ist aber ein reiner Decoder. Zur Beachtung: JPEG Compression ist wesentlich aufwändiger als JPEG Decompression, das ist ja gerade der Clou an dem Verfahren.
Sorry, hatte ich nicht gesehen. Aber noch was: Er macht 8 Bit, also mit CLUT?! Wie gut spricht dann noch das RLL/Diff Preprocessing an?
:
Bearbeitet durch User
S. J. schrieb: > Aber noch was: Er macht 8 Bit, also mit CLUT?! Wie gut spricht dann noch > das RLL/Diff Preprocessing an? Erstmal kein LookUp-table, habe das Datasheet nicht richtig gelesen, es werden zwar 8-Bit Blöcke ausgegeben, jedoch entsprechen diese nicht einem Pixel. Trotzdem eine gute Frage, sollte bei größeren Flächen aber schon was bringen. Tcf K. schrieb: > S. J. schrieb: >> Die o.g. JPG lib sieht aber interessant aus. > > Das ist aber ein reiner Decoder. Zur Beachtung: JPEG Compression ist > wesentlich aufwändiger als JPEG Decompression, das ist ja gerade der > Clou an dem Verfahren. Ich kann auch noch diesen Decoder beisteuern: https://code.google.com/p/picojpeg/ Ich habe bis jetzt noch kein Paper o.ä. gefunden, welches darlegt wo bei JPEG eigentlich die (Zeit/Speicher)-Komplexität begraben liegt. Ich rate einfach mal, dass es von folgenen Schritten die DCT ist??? 1)Farbraumumrechnung vom (meist) RGB-Farbraum ins YCbCr-Farbmodell 2)Tiefpassfilterung und Unterabtastung der Farbabweichungssignale 3a)Einteilung in 8×8-Blöcke !3b)diskrete Kosinustransformation 4)Quantisierung 5)Umsortierung. 6)Entropiekodierung. c-hater schrieb: > Hier gilt ganz genau das gleiche. Es hängt extrem stark vom Inhalt ab, > was erreichbar ist. > > Das ist ganz grundsätzlich so bei verlustfreier Kompression. Die > erreichbare Kompressionsrate wird ganz grundsätzlich durch die Entropie > des zu komprimierenden Inhaltes selber begrenzt. Das ist mir schon klar, die 70% habe ich als Durchschnittswert betrachtet. Frank E. schrieb: > Es gibt Kameras, die werden über RS232 gesteuert und liefern bereits ein > komprimiertes Bild. Da müsste dein MC das nur noch senden und nicht > selber dran rummachen ... Hier wird die Reise wohl nun doch hingehen, OV2640 gibt es für weniger als einen 10er, da kann dann ein STM32F4 mit DSP bleiben gelassen werden. Also Hardware: 1)Kamera: mit JPEG Ausgang 2)Sendeseite: sehr kleiner AVR (328 oder so) der die Daten durchschleift (falls niedrige Ausleserate der Kamera möglich, sonst mit RAM) 3)Funkstrecke: SI4463 , für den Anfang mal den alten SI4432 4)Empfängerseite AVR mit >=4KB Ram, externer RAM nur falls Daten nicht direkt ans Display können 5)5.)2.4 Zoll TFT Arduino Modul mit ILI9325 o.ä.
Moin, wenn's nicht wahnsinns schnell sein muss: Es gibt ev. bei manchen chinesischen Anbietern noch ILI9325 oder ähnliche "Digital Picture Frames", die mit einem 8051-Klon ausgestattet sind (ax206). Die Dinger wurden vor einigen Jahren mal gehackt, unter "dpf-ax" gibt's einigen Source. Der Chip hat sogar HW-Multiplier, und wer im ROM rumgräbt, findet auch die etwas abgespeckten JPEG routinen dafür. Der Datenstrom muss nur über USB rein. Betr. JPEG: Speicher ist grade mal für eine MCU-Zeile (8 * X) nötig, und die grösste Rechenarbeit ist in der Tat die DCT. Fürs Encoding kann aber ein etwas aufgemöbelter 8-Bitter schon reichen, nur müsste das Bild zwischengepuffert werden, die Bandbreite reicht vermutlich nicht aus. Gruss, - Strubi
Strubi schrieb: > ... die Bandbreite reicht vermutlich nicht aus.
1 | Datenmenge = Datenrate * Übertragungszeit |
Wenn die Datenrate an die Bandbreite angepaßt ist - wo ist das Problem? Zur Zeit läuft u.a. eine Weltraummission, bei der hochaufgelöste Bilder mit 700Bit/s übertragen werden ;-)
Thread beobachten
Seitenaufteilung abschaltenBitte 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.