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€.
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.
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.
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.
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 ;-)
