Ich arbeite über Glasfaser (proprietäres Proto) und habe leichte Bandbreitenprobleme, weil die Koppler nicht mehr können. Ich müsste nun entweder eine zweite Leitung benutzen (sehr teuer) oder eine Datenkompression einschalten. Ich sende unkomprimierte scans von Temperaturprofilen einer Wärmekontrastfolie. Eine verlustbehaftete Kompression wie mpg, was sich anbieten würde, scheidet aber aus, weil die Daten weiterverabeitet und ausgewertet werden müssen. Es geht dabei um minimale Änderungen von einem zum nächsten scan. Momentan schiebe ich 16 Kanäle mit je 50 scans pro Sekunde über eine 10MHz-Leitung (SPI). Ich würde gerne 24 Kanäle schaffen, brauche also 50%. Möglich sein, müsste es, denn wenn man die Bilder oben empfangen hat, und im PC mit ZIP komprimiert, dann schrumpfen die auf etwa 1/4 zusammen. So etwas wie ZIP wäre optimal, gfs auf einer geringen Kompressionsstufe, damit es weniger auffällig ist.
H.M. schrieb: > weniger auffällig ist weniger auf*wändig* ist, wollte ich schreiben. Eingefallen ist mir noch, dass ISDN z.B. auch angeblich Datenkompression macht. Kennt sich hier jemand mit soetwas aus, oder hat einen guten Vorschlag ?
du kannst dir mal png ansehen, das dürfte die Einzelbilder ganz gut zusammenbekommen. Da du hier im FPGA-Forum bist und ein eigenes Protokoll verwendest, kannst du auch überlegen, ob du mit einfachsten Mitteln deine gewünschte Kompressionsrate erreichen kannst. Ich weiß jetzt nicht, wie deine Bilder aussehen - aber vielleicht könnte man nur Änderungen relativ zum Vorgängerpixel übertragen (wird in manchen Modi von png) so gemacht. Dann kannst du dir noch überlegen, ob "Vorgängerpixel" zeitlich oder räumlich zu verstehen ist ;-)
Wenn du viele regelmäßige Farbverläufe hast, dann könntest du ja mal das Delta zwischen 2 aufeinander folgenden Pixeln bestimmen und die Unterschiede durch einen RLE-Encoder jagen. Alternativ könntest du dich an einem der vielen Kompressionsverfahren versuchen. Z.B. LZ77 oder LZW. Ist nur die Frage wie man das effizient in einem FPGA hinbekommt. Dummerweise hast du hier aber keine garantierte Kompressionsrate. D.h. die Bilder könnten unter Umständen auch größer werden.
> Es geht dabei > um minimale Änderungen von einem zum nächsten scan. Dann übertrage nur die Änderung. Die ist doch nur minimal. Setzt voraus, du hast genug Platz um die Daten zu halten. Ich habe mich mit Dekompression schon im FPGA und damit indirekt auch mit Kompression auf dem FPGA beschäftigt. Die Datenrate kann mit einer Kompression nicht gantiert werden. Da du aber über die Datenänderung viel weißt, kannst du in die Kompression viel Vorwissen hienstecken. Das ist effektiver als jeder doofer Algorithmus. JPEG hat in der Kompression drei Stufen: -Cosinustransformation -Quantisierung -Huffman Der Datenverlust entsteht in der Quantisierung. Die Cosinustransformation selbst ist verlustfrei. Jepg spart die Information an scharfen Kanten. Bei einem Wärmebild sollte es keine scharfen Kanten geben. Warum nimmst du nicht Ethernet? Das gibt es auch in Glasfasertechnik und deine Datenraten sind bei 1Gbit. R. Doss
Ja, Ethernet wäre fein, aber ich kann an der Hardware nichts ändern, weil auch alte Systeme gerüstet werden sollen und die will man verständlicherweise nicht umbauen. In einem Wärmebild gibt es es zunächst keine scharfen Kanten, aber die Auflösung der Sensoren ist so, dass die Steilheit dennoch 15% pro Pixel sein kein, d.h. schon über 5-8 Pixel wird von 10% auf 90% gestuert. Nein, es gibt praktisch keine reproduzierbaren Farbverläufe. Jedes Bild ist individuell, zumindest muss eine minimale Abweichung vollständig transportiert werden, da Differenzbilder erzeugt werden müssen. Ich kann also nicht etwas etwas ähnliches zusammenfassen. Ich bräuchte so etwas wie RAR in VHDL.
Wieso schließt du dann die Vorschläge alle aus? Es hört sich eher immer mehr so an als würde z.b. differenz zum Bild vorher oder zu Nachbarpixeln Sinn machen...
Das mit den Differenzen habe ich schon getestet, es ergeben sich andere Zahlen, aber es gibt kaum Repetition und die Änderungen sind in derselben Grössenordnung. Es ist halt auch viel Rauschen und niederfrequente Überlagerung drin, dass erst in nachfolgenden System weggerechnet werden kann und soll. Lattice User schrieb: > Nach nur 2 minuten mit Google: > http://opencores.org/project,deflatecore Development status: Alpha :-(
Hallo H.M. was mir an der ganzen Diskussion um geeignete oder einfache Kompressionen fehlt ist die Information was dir an FPGA zur Verfuegung steht ( Platz, Preis, elektrische Leistung). Bei 10MBaud? koennte man z.B. sogar an eine Implementation in Software nachdenken, (CPU im FPGA). Du schreibst, dass Du Versuche in RAR (einem Losless Kompressor) gemacht hast, deren Ergebnisse 1/4 der Ausgangsgroesse waren. Die Frage die sich nun aber stellt: Sind deine Versuche representativ oder kann der Fall auftreten, dass die Kompression mit den in RAR enthaltenen Algorithmen eine Endgroesse > Eingangsgroesse erzeugt... Wenn NEIN, kannst Du dies beweisen? Falls nicht (nur die Wahrscheinlichkeit gegen unendlich geht, oder jedenfalls sehr hoch ist), wie gehst Du (darfst) mit dem Fall um? Falls Du die Fragen fuer dich zufriedenstellend beantworten kannst, kannst Du auf die Suche gehen, einen (oder mehrere Lossless) Algorithmen herauszusuchen und zu implementieren... Auf der anderen Seite sprichst Du davon dass dein Sensorsignal verauscht ist etc. Waere es dann nicht sinnvoller deine Sensordaten gleich einmal geeignet zu filtern und sich dann nochmal vor die Frage zu stellen, wie die zu uebertragenenden Daten zu dezimieren sind? Gruss Vanilla
Lossless: http://www.analog.com/en/audiovideo-products/video-compression/adv601lc/products/product.html Ist aber eigentlich für CCIR 601; ob das für deine Anwendung geht, lässt sich aus der Ferne schlecht sagen. > Ich arbeite über Glasfaser (proprietäres Proto) und habe leichte > Bandbreitenprobleme, weil die Koppler nicht mehr können. Was benutzt du denn da? Vllt hätte ich da eine Idee.
H.M. schrieb: > Lattice User schrieb: >> Nach nur 2 minuten mit Google: >> http://opencores.org/project,deflatecore > Development status: Alpha :-( Wenn dich Alpha abschreckt und du nicht selbst einen LZ core schreiben willst/kannst, bleibt dir nichts anderes den Geldbeutel zu zücken. Z.B: dafür: http://www.heliontech.com/comp_lzrw.htm
H.M. schrieb: > Das mit den Differenzen habe ich schon getestet, es ergeben sich andere > Zahlen, aber es gibt kaum Repetition und die Änderungen sind in Das ist der Punkt, den hast du noch nicht verstanden: Die Zahlen sind jetzt anders verteilt. Es gibt viel mehr Zahlen mit einem kleinen Wert und wenige Zahlen mit einem großen Wert. Es gibt viel mehr Nullen in den höherwertigen Bits!!!!!! Der Informationsgehalt ist anders. Jetzt gibt es Algorithmen wie z.B. Huffman die Lauflängen codiert sind. Da wird die Bitbreite für die Zahl reduziert, weil die höheren Bits keine Information mehr haben.
Bürovorsteher schrieb: > Lossless: > http://www.analog.com/en/audiovideo-products/video... Wie kommst Du darauf, dass der Lossless ist? Zitat: "visually loss-less"... Auf der anderen Seite eroeffnet der TO: > Es ist halt auch viel Rauschen und niederfrequente Überlagerung drin, dass erst in nachfolgenden System weggerechnet werden kann und soll. Der Baustein macht eine auf JPEG2000 besierende Wafeletreansformation und eine daraufbasierende Reduktion von Frequenzanteilen. Wenn ich den TO richtig verstehe, darf ich da im Voraus nicht eingreifen. Sprich der ADV601 faellt dann eher aus?! Wirklich Lossless waere z.B. im JPEG-LS festgelegt. Da gibt es auch entsprechende Cores zu kaufen.
> Wie kommst Du darauf, dass der Lossless ist?
Weil der in professionellen D1-MAZ von Sony bzw Thomson eingesetzt
wurde, deren Kompression als verlustlos beworben wurde. Bei niedrigen
Kompressionsraten bis etwa 1 zu 10 hat das wohl auch sehr gut
funktioniert,
diese MAZ waren vor 10 Jahren der Goldstandard aller Fernsehsender.
Möglicherweise liegen die Anforderungen des TO wesentlich höher, als ich
annehme, dann ist der Schaltkreis nicht einsetzbar. Ein Versuch mit der
Video-Pipe-Baugruppe könnte hier schnell zur Klärung beitragen.
Eine Bandbreitenerhöhung erscheint mir einfacher zu sein. Hierzu gibt es
eine nette AN von Avagotech "Fiber Optic Components Cookbook". Dort sind
Billiglösungen bis 160 Mbit/s vorgestellt.
Unsinn. D1 Maschine waren bei Sendern nie groß verbreitet. Digi-Beta und IMX dagegen schon (Kompression ca. 3 oder 2 zu 1) D1 und auch Ampex DCT waren eher bei Filmabtastungen und hochwertigen Bearbeitungen zu finden, aber nicht bei Sendern.
Du hast recht, nicht die Sender waren es. Ich hatte für Entwicklungsarbeiten beim digitalen Fernsehen ein von der Telekom bereitgestelltes Gerät, deswegen meine falsch globalisierende Aussage.
Rauschen kann man nicht Verlußtfrei Komprimieren. Und wenn Rauschen + Signal komprimiert werden Sollen dann kann dein Signal nur so gut wie das Rauschen komprimiert werden.
Bürovorsteher schrieb: >> Wie kommst Du darauf, dass der Lossless ist? > Weil der in professionellen D1-MAZ von Sony bzw Thomson eingesetzt > wurde, deren Kompression als verlustlos beworben wurde. Bei niedrigen > Kompressionsraten bis etwa 1 zu 10 hat das wohl auch sehr gut > funktioniert, > diese MAZ waren vor 10 Jahren der Goldstandard aller Fernsehsender. Na, dass die D1 nicht bei den Broadcastern verbreitet war, ging ja jetzt schon durch, is aber auch egal. Wenn in der Qualitaetseingangskontrolle schon alles als fehlerhaftes Sourcematerial zurueckgeweist, was zu hohe Frequenzanteile aufweist, so laesst sich eine 2:1 kompression natuerlich relativ einfach "verkaufen"...
Die Daten scheinen sich ja durchaus komprimieren zu lassen, wie die Anmerkung des OP (ZIP, RAR) andeutet. Also gibt es in den Daten Redundanz. Ich empfehle, die Daten mal genau zu analysieren, denn wie ebenfalls angemerkt wurde, lässt sich Rauschen nicht so ohne Weiteres wegoptimieren und RLE-Codieren, weil es kaum idente Muster gibt. Huffman ist natürlich denkbar, erfordert aber grosse Tabellen, in denen gesucht und sortiert wird, was im FPGA auch nicht so einfach ist und sofort auf die Latenz geht. Eine einfache Bilddatenkompression gibt es eben nicht.
Uwe schrieb: > Rauschen kann man nicht Verlußtfrei Komprimieren. Und wenn Rauschen + > Signal komprimiert werden Sollen dann kann dein Signal nur so gut wie > das Rauschen komprimiert werden. Yep, aber wenn, wie bei üblichem Bildrauschen, die Amplitude vom Rauschen gering ist, dann sind Bilddifferenzverfahren mit statischer Huffman-Codierung der Differenz durchaus erfolgversprechend. Letztlich ist das die Grundlage von MPEG, nur kommen dort noch Bewegungserkennung und Unterdrückung von Bits hinzu.
> Huffman ist natürlich denkbar, erfordert aber grosse Tabellen, in denen > gesucht und sortiert wird, was im FPGA auch nicht so einfach ist und > sofort auf die Latenz geht. Es werden keine großen Tabellen angelegt. Da würden die FPGAs auch platzen. Die Anzahl der Knoten ist beschränkt. Die Wertebereiche werden nur komprimiert. Jedem Huffman codewort folgt eine Zahl die dem Offset von dem richtigen Wert entspricht. Es gibt nicht für jeden Wert ein Code wort! So wird Huffman in der Praxis angewandt.
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.