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
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 :-)
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
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
