Ich habe still Images von etlichen Megapixels zu übertragen und mir geht die Bandbreite aus. Daher möchte ich die Daten ohne Verluste komprimieren bevor sie rausgehen. Die Daten haben 16 Bit und kommen seriell. Ich kann etwa 6 Zeilen mit allen 4000 Pixel speichern und verzoegern. Das Lesen und Ausgeben muss aber in Echtzeit erfolgen, was auf 297 MHz hinauslaeuft. Optimal waere wenn ich es so komprimieren könnte das aus 16bit 10bit wrden womit ich unter 200Mhz am Ausgang hatte Welches Verfahren wäre denkbar?
Kameramann schrieb: > Welches Verfahren wäre denkbar? kommt auf das Bild an. Wenn recht viele Pixel die gleiche Farbe auf einer Zeile haben kann man mit LZW arbeiten. Bei gleichmäßigen Rauschen ist das aber nicht sinnvoll.
Und was passiert, wenn die Daten gerade mal nicht komprimierbar sind? Stürzt dann die Kamera ab? Nehme mal an, dass es sich um eine fixe Framerate handelt. Da wäre es doch eigentlich schlauer, einen schnelleren Bus zu nehmen
Kameramann schrieb: > Daher möchte ich die Daten ohne Verluste komprimieren > könnte das aus 16bit 10bit wrden womit ich unter 200Mhz am Ausgang hatte Denk mal nach, das kann so mit unbekannten Bilddaten nicht funktionieren. Es wäre höchstens bei (bekannten und garantierten!) simplen Bildinformationen denkbar - oder eben bei verlustbehafteter Kompression.
Moin, Natuerlich teile ich die Bedenken der vorhergehenden Posts, werfe aber trotzdem mal ein Huffyuv-codec in den Raum. Bei 297MHz Ausgangstakt werf' ich weiterhin noch "Tico Lightweight compression" und VC-2 hinterher, aber ich glaub', die sind etwas verlustbehaftet. Gruss WK
Das Bandbreitenproblem möchte ich durch einen Fifo lösen. Dankeschön für die Stichworte
Man koennte sich eine Kompression vorstellen, die mit einer nichtlinearen Kennlinie laeuft. Erst wuerd ich aber entrauschen. Dh Bild-Entrauschen. Bedeutet aber einen Bildspeicher. Dann einen Algorithmus drueber zum Entrauschen, und einen fuer die Kennlinie. Natuerlich verlustbehaftet, aber eh noetig. Deswegen verwendet man heute Quadcore mit 64 bit.... dh heisst ich wuerde die gesammte Bild-Vorbearbeitung in den Controller verschieben. Dass das andere Ende nur ein paar Parameter zum anpassen hinsendet.
Oder D. schrieb: > Man koennte sich eine Kompression vorstellen, die mit einer > nichtlinearen Kennlinie laeuft. Das hat man bei Audiosamples früher mal gemacht, als Speicher noch teuer war und so 16Bit-samples auf 12 Bit gespeichert. Bei Video müsste das gehen. Aber: > Erst wuerd ich aber entrauschen. Schon das ist nicht mehr verlustfrei möglich. > Deswegen verwendet man heute > Quadcore mit 64 bit.... dh heisst ich wuerde die gesammte > Bild-Vorbearbeitung in den Controller verschieben. Wenn es eine offline-Bearbeitung ist, die das Bild mehrfach auswerten muss, in jedem Fall. Bei allen linearen Verfahren geht es im FPGA besser. Da geht durchaus "Hexacore mit 128 bit" wenn es sein muss :-)
Nachdem Ich mir die einzelnen Verfahren angesehen habe stelle ich fest dass ich entweder mit Verlusten leben muss oder mehr Leitungen brauche. Mist.
Ich würd mir ja erst mal anschauen was der Sensor überhaupt an sinnvollen Daten liefert. Keine Vollformat-Spiegelreflex-Digitalkamera ob aktuell oder älteres Modell füllt 16 Bit mit sinnvollen Daten. Da ist Kompression keine Schande... Was ist es denn für ein Sensor? 4000 Pixel (je Zeile?) hört sich nach 4*3=12MP an. Sensorgröße? Werden die Bilder irgendwie messtechnisch verarbeitet /mehrere Bilder zur Rauschreduzierung übereinandergelegt oder sind sie fürs menschliche Auge bestimmt? Bei fürs Auge: - man geht von so 200 wahrnehmbaren Helligkeitsabstufungen aus - mit Reserven für Bayer-Interpolation, empfindliche Augen, etc. sollten 1000 Abstufungen dick reichen - je Blendenstufe (doppelte Helligkeit) reichen so 30 Abstufungen (zzgl. dick Reserve insgesamt 150) - die SRGB-Kennlinie (8 Bit) kann da als sinnvoller Anhaltspunkt dienen Der Sensor: - Beispiel Canon 1DX, Sensor 36x24mm, 18MP - max. 90000 Photonen je Pixel Kapazität (http://www.clarkvision.com/articles/digital.sensor.performance.summary/#full_well) - optisches Rauschen bei 90000 Photonen: 300 Photonen (Standardabweichung) - 90000 Photonen = 65535 LSB, +-300 Photonen = +- 219 LSB - 22500 Photonen (1/4 Beleuchtung) = 16383 LSB, +-150 Photonen = +- 109 LSB - 5625 Photonen (1/16 Beleuchtung) = 4095 LSB, +-75 Photonen = +- 55 LSB - die Rauschwerte von ADC, Verstärker, etc. kommen dazu Eine Datenspeicherung mit 16 Bit macht hier in den oberen Beleuchtungsstufen schlicht keinen Sinn. Die oberste Stufe codiert >16000 Werte von denen allerhöchstens 150 Abstufungen wahrnehmbar sind und jeder einzelne Wert mit +-155...219 Standardabweichung stochastisch schwankt. Wenn du Quantisierungsschritte mit 1/3 der unvermeidbaren Rausch-Standardabweichung machst erhöhst du das Gesamtrauschen von A auf maximal sqrt(A^2 + (A*1/3*0,5)^2) = A * 1,0138 (+1,38%). Die 0,5 fürs Quantisierungsrauchen sind dabei zu hoch angesetzt. Zu lange her... Bei Schritten mit 1/2 Sensorrauschen sinds <+3,1%. Bei Schritten mit 1/1 Sensorrauschen sinds <+11,8%. Die Kompression je nach Readout natürlich angepasst. Das Rauschen hängt ja davon ab. Für den Canon1DX-Sensor und Quantisierung mit 2/5 Sensorrauschen kommst du etwa bei 1024 Symbolen je Pixel raus (=10 Bit). Im hellen Bereich ließen sich wegen der Wahrnehmungsschwelle nochmal 200 Symbole problemlos einsparen. (zusätzliches Rauschen dadurch im oberen Bereich < 10%) Wenn dein Sensor kleiner / schlechter ist wirds einfacher, weil der Rauschanteil noch höher ist. Funktioniert mit wenig Speicher und "CPU-Power". Stephan
Hmm, steht an der anderen Seite denn genug Rechenkapazität zur Verfügung?! Wenn ja, möglicherweise gibt es ja Kameras, wo man an die Daten vor Bayer-Pattern-Interpolation herankommt und die dann nachher selbst durchführt. Spart 2/3 der Bandbreite...
Horst schrieb: > wo man an die Daten vor > Bayer-Pattern-Interpolation herankommt und die dann nachher selbst > durchführt. Spart 2/3 der Bandbreite... Es gibt eine Reihe von Kameras - zumindest Industriekameras - an deren Daten man herankommt und in der Tat kann man das Prozessieren auslagern. Z.B. lässt sich ein Datenstrom 8x parallel verarbeiten, um 8 Prozessorplatinen ins Spiel zu bringen. Aber warum bist Du der Ansicht, dass man 2/3 der Bandbreite einsparen könnte? Das Bayerpattern ist ja komplett gefüllt - quasi ein Schwarz-Weiss-Bild mit eben besonderen Bedeutungen der Pixelpositionen.
FPGA-Ingenieur schrieb im Beitrag #4337961: > Aber warum bist Du der Ansicht, dass man 2/3 der Bandbreite einsparen > könnte? Das Bayerpattern ist ja komplett gefüllt - quasi ein > Schwarz-Weiss-Bild mit eben besonderen Bedeutungen der Pixelpositionen. Klar ist das Pattern gefüllt, aber eben mit nur einem Wert quasi. Also ich habe für jedes Pixel nur 8/10/12/14 Bit als Helligkeitswert für die jeweilige vom Filter durchgelassene Farbe. Durch die Bayer-Pattern-Interpolation wird aus den umliegenden Pixeln jeweils auch für die nicht vom Filter durchgelassenen Farben ein Helligkeitswert errechnet, sodass ich dann pro Pixl 3 (RGB) * 8/10/12/14 Bit habe. Korrigiert mich, wenn ich falsch liege.
Ich erkenne immer noch nicht, wo man etwas weglassen kann und mit welcer Begründung. Richtig, ist, dass nicht das komplette Licht in einen Pixel fliesst, sondern nur ein "Drittel" oder die Hälfte beim Grün. Von daher wird nur ein kleinerer Teil der möglichen Information ausgewertet. Aber man darf davon ausgehen, dass der Sensor komplett belichtet wird und daher sie Pixel ausgesteuert sind. Tatsache ist, dass aus dem Sensor ein Wert kommt, und zwar für jeden Takt einer. Wie und durch welche Interpretation will man da etwas weglassen?
FPGA-Ingenieur schrieb im Beitrag #4339509: > Ich erkenne immer noch nicht, wo man etwas weglassen kann und mit > welcer Begründung. Richtig, ist, dass nicht das komplette Licht in einen > Pixel fliesst, sondern nur ein "Drittel" oder die Hälfte beim Grün. Von > daher wird nur ein kleinerer Teil der möglichen Information ausgewertet. > Aber man darf davon ausgehen, dass der Sensor komplett belichtet wird > und daher sie Pixel ausgesteuert sind. > Tatsache ist, dass aus dem Sensor ein Wert kommt, und zwar für jeden > Takt einer. Wie und durch welche Interpretation will man da etwas > weglassen? Im Bild nachher sind 3 Werte pro Pixel, nicht nur einer, der tatsächlich gemessen wird
Aber trotzdem müssen doch diese Rohwerte, aus denen (weiter oben) dann noch mehr künstlich erfunden! werden, einmal transportiert werden.
Nun hab ich probiert die Bilder zu zippen. Werden etwa auf die Hälfte geschrumpft. Kriegt man das in VHDL hin?
Kameramann schrieb: > Nun hab ich probiert die Bilder zu zippen. Werden etwa auf die > Hälfte > geschrumpft. > > Kriegt man das in VHDL hin? Natürlich kann man das ZIP Format auf deinem FPGA umsetzen, verwendet übrigens auch PNG. Von Grund auf neu schreiben, ist möglich, aber ohne Vorwissen doch recht zeitaufwändig. Üblich sind Umsetzungen mit Hashtabellen, und dann eben die Huffman Codierung.
Kameramann schrieb: > Nun hab ich probiert die Bilder zu zippen. Werden etwa auf die Hälfte > geschrumpft. > > Kriegt man das in VHDL hin? Natürlich. Spätestens mit einem Softcore und externem Speicher. Ohne Speicher läuft das ganze vmtl. auf eine statische Codetabelle raus. Und Bilddaten können grundsätzlich auch rein zufällig sein. Wenn 1000 Bilder auf 50% komprimiert werden kann das 1001ste nach Kompression 101% Speicher/Bandbreite brauchen - den es nicht gibt. Grade bei statischen Codetabellen sind Ausreißer auch deutlich nach oben (120%) wahrscheinlich. Aber sag uns doch mal um was für Daten es sich handelt: - Abmessungen in Pixel - Farbe / SW - RGB RAW YUV / ... - Bildfrequenz - Bild-Sensor oder gar das geheime Kameramodell Dann kann auch fundiert geholfen werden. Stephan
Kameramann schrieb: > Nun hab ich probiert die Bilder zu zippen. Werden etwa auf die Hälfte > geschrumpft. Der Zipper arbeitet aber auch nicht in Echtzeit, sondern kurvt über mehrere Daten, um sie zu reduzieren. Nur beim Auspacken funktioniert das in Echtzeit. Dafür durfte die Zeit nicht reichen, bzw die Fläche im FPGA. Du bräuchtest eine Architektur, die parallel alle verfügbaren Symbole testet und den hash code ermittelt.
Stephan H. schrieb: > Und Bilddaten können grundsätzlich auch rein zufällig sein. Wenn 1000 > Bilder auf 50% komprimiert werden kann das 1001ste nach Kompression 101% > Speicher/Bandbreite brauchen - den es nicht gibt. > Grade bei statischen Codetabellen sind Ausreißer auch deutlich nach oben > (120%) wahrscheinlich. Hier weiss man immer noch zu wenig über das Anwendungsgebiet der Kamera. Oben stehende Bedenken treffen auf eine Handykamera sicher zu. Wenn die Kamera aber immer ähnliche Bilder aufnimmt (z.B. Produktionsstrasse) könnte man durchaus erfolgreich mit fixen Huffman-Tabellen arbeiten.
Also wenn es sich um Bewegtbilder geht kannst Du auch mal anschauen was zum Beispiel die BBC in den 1980gern gemacht hat. Die habne ganz grob einen Prädiktionscoder für Video gebaut, und dann die Differenz übertragen. Sprich Du hast einen Bildspeicher (oder zur Not Zeilenspeicher) aus dem Du für jeden neuen Pixel den Du übertragen möchtest einen geschätzten Wert berechnest. Zum Beispiel könnte der neue Pixel der Durchschnittswert aus dem Pixel links davon und dem darüber sein. Dann bestimmst Du die Differenz aus diesem Schätzwert und dem realen Pixelwert. In aller Regel wird diese Differenz nahe 0 sein, was Du mit einem Huffmanncode mit weniger Bits übertragen kannst als den unwahrscheinlich Fall, dass Du ganz grob daneben bist. So was, allerdings noch mit dem vorherigen Bild als Referenz, hat die BBC schon in den 1980gern in diskreter Logik und verlustbehaftet gebaut. Die kamen damit auf 64 MBit für ein Bild in Fernsehqualität.
Verlustfreie Video-Kompression funzt m.E. nicht mit nur einer einzigen, simplen Kompressionsstrategie - es kommt drauf an, was auf dem Video drauf ist. Bei einer Überwachungskamera beispielsweise kommt im Wesentlichen immer dasselbe Bild. Wenn dann mal ausnahmsweise einer durch selbiges schlurft, macht es Sinn, jeweils immer nur die Differenzen zum vorigen Frame zu übertragen. Mit dem Ansatz fliegt man voll auf die Fresse, wenn abwechselnd komplett weiße und komplett schwarze Frames übertragen werden sollen, während sich solche Bilder (z.B. mit simplem RLE) ganz leicht und effektiv auf andere Weise komprimieren lassen. M.E. müssen deswegen mindestens zwei Strategien angewandt werden und eine vernünftige, schnelle Logik dazu, die sich abhängig vom Bildinhalt jeweils für die richtige entscheidet.
Moin, ZIP-style-kompression (PNG, GIF, etc.) macht auf dem FPGA nicht wirklich Spass/Sinn im Vergleich zu JPG zB. Ersteres lässt sich nicht einfach in eine Pipeline quetschen und der Bedarf der Code-Tabellen lässt sich nicht abschätzen. Du kannst natürlich den Standard verstümmeln... JPEG-Encoding habe ich auf dem FPGA mal umgesetzt und auch mit anderen Verfahren experimentiert. Interessant sind da einige Wavelet-Transformationen, die sich ähnlich wie die DCT in ein Pipeline quetschen lassen. Hintendran hat man immer den klassischen Huffman-Encoder, der prima in Hardware passt. Das Streaming/Bit-Slicing ist dann bei gegebener Durchsatzrate knifflig, mit den kleinen FPGAs ist da schon mal nix zu holen. Und auch mit was dickeren dürfte es eine Multi-Tap-Geschichte werden bei der Bandbreite. Für Stills würde ich es am ehesten noch mit Wavelets versuchen. Aber: Da geht locker mal ein Jahr an Eigenentwicklung drauf, das macht man nicht mal eben so. Dementsprechend kostet auch so ein Core. Was "lossless" angeht: Es gehen immer ein paar Bits verloren und ein Sensor rauscht auch mal gerne korreliert (mit anderen Signalen), also wäre ich da etwas relaxter.. Grüsse, - Strubi
Egal wie man es dreht und wendet, Bilddaten können potentiell zu 100% stochastisch sein und damit unkomprimierbar. Solange man nicht Details über die Bilddaten und den Sensor weiß kann man da nichts machen / empfehlen. Nach den bisherigen Vorgaben ist auch eine Mittelwertbetrachtung nicht relevant. Die Kompression muss beliebige 6 aufeinanderfolgende Bildzeilen auf maximal 62,5% eindampfen, für mehr reicht der Speicher nicht. Ich hatte jedenfalls schon praktische Bilder (Fotos) bei denen die 16-Bit-Rohdaten (vor Interpolation) sich nicht verlustfrei auf 10-Bit oder weniger bringen ließen. Rauschanteil zu hoch... Und ich kann sagen, dass mit für den Menschen visuell niemals wahrnehmbaren Informationsverlusten die 10-Bit-Grenze kein Problem sein wird. Auch bei dem begrenzten Speicher. Für Empfehlungen dazu fehlen aber die Infos ... Christian B. schrieb: > Zum Beispiel könnte der neue Pixel der Durchschnittswert aus dem Pixel > links davon und dem darüber sein. Dann bestimmst Du die Differenz aus > diesem Schätzwert und dem realen Pixelwert. Bei Codierung der Differenzen zwischen zwei Pixeln (Nachbarpixel, vorheriger Frame ist egal) erhöht sich das Rauschen (für die Huffmann-Tabelle) erstmal um sqrt(2). Hatte ich mal probiert und wieder sein lassen. Stephan
Stephan H. schrieb: > Und ich kann sagen, dass mit für den Menschen visuell niemals > wahrnehmbaren Informationsverlusten die 10-Bit-Grenze kein Problem sein > wird. Auch bei dem begrenzten Speicher. Auf welche Ausgabe beziehst Du Dich dabei? Bei Monitoren sind ja bei Weitem keine 10 Bit zu transportieren.
Jürgen S. schrieb: > Stephan H. schrieb: >> Und ich kann sagen, dass mit für den Menschen visuell niemals >> wahrnehmbaren Informationsverlusten die 10-Bit-Grenze kein Problem sein >> wird. Auch bei dem begrenzten Speicher. > > Auf welche Ausgabe beziehst Du Dich dabei? Bei Monitoren sind ja bei > Weitem keine 10 Bit zu transportieren. Ich sag ja 10 Bit sind kein Problem. Die gängigen 8 Bit sind aber (bei der üblichen sRGB-Kurve) manchmal schon kritisch. Langsame Farbübergänge im dunklen Bereich produzieren da ab und an sichtbares Banding. Hängt natürlich vom Monitor und den Einstellungen ab... Evtl. will man ja auch mal die Helligkeit hochziehen oder die Tonwerte spreizen. Da sollten die Abstufungen in der Kodierung möglichst unter dem "netürlichen" Rauschen liegen. Hängt natürlich von dem unbekannten Anwendungsszenario ab. Aber wir wissen ja noch nicht einmal ob es sich um Rohdaten/RGB handelt. Oder YUV mit reduzierter Abtastfrequenz für die Farben. Oder ein lineares Profil oder eines mit Gamma-Kurve. In die 10 Bit bekommt man jedenfalls ein (lineares, nicht interpoliertes) Rohsignal bei den aktuell gängigen Sensoren rein ohne groß Daten zu verlieren. Messtechnische Auswertung ausgeschlossen, denn da können in hellen Bereichen - die den Großteil des Datenvolumens ausmachen - weit mehr Werte differenziert werden als das Auge schafft. Ich glaub aber der TE hat aufgegeben. Stephan
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.