Forum: Digitale Signalverarbeitung / DSP Bayer-Bild zurecht rücken


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Bonzo (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Es geht um die richtige Ansteuerung eines Mehrfarbendisplays aus LEDs 
aus einem Sensor heraus. Der Sensor hat einen programmierbaren DSP. Das 
Display liefert einen realen Ausschnitt des Farbsensors mit Zoom von 
1:2, 1:3, 1:4 etc.

Da das Farbdisplay eine besondere Farbansteuerung der Pixel hat, möchte 
ich das Bild farbrichtig verschieben. Als Beispiel für RGB nehme ich mal 
die erste Zeilen, die so aussehen wie im Pixelelement.

Um die Leuchtkraft für die einzele LED zu ermitteln, ermittle ich über 
ihre Position ein Verhältnis zur Interpolation der RGB-Pixel. Das 
funktioniert schon mit einem Testbild. Von Weitem sieht es sehr gut aus, 
d.h. Kante liegt auf Kante, bis auf das Ausfransen. Die Offsets durch 
die Lage der Pixel werden also wegkompensiert.

Dabei ist mir aber aufgefallen, dass der Sensor (Bayer) auch solche 
Offsets hat.

Wie wird das bei der Bayerconversion gemacht?
Nehme ich einfach ein 4-Farbbayerpixel und mittle die beiden grünen, 
dann liege ich geometrisch genau zwischen den blauen und roten, die 
ihrerseits in den Ecken des Qarees liegen.

Beziehe ich mich auf die Koordinate des Grünen, dann haben rot und blau 
jeweils einen halben Endpixel Versatz nach zur Seite und in der Höhe.

Müsste man das nicht korregieren?

Wie ist das bei TFTs? Wenn man dort einfach RGB ausgibt, haben die 3 
Bilder, die entstehen, ja auch diesen Halbpixelversatz.

von Bonzo (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ich zeichne nochmals auf, was ich meine anhand einer Linie über 3 Pixel:

Nehe ich einfach die Pixelwerte aus dem Sensor, dann rückt das rote und 
das blaue Bild virtuell zur Seite und in der Höhe und ändert die Werte 
ab. Das wirkt sich auch auf das endliche Bild aus.

von Valérien Wankelmut (Gast)


Bewertung
0 lesenswert
nicht lesenswert
De-Mosaicing Algo's gibt es fast soviel wie Idioten am Kalten Buffet:
https://www.google.de/search?ei=oAFxXbKSC4mYjLsPk7e12Aw&q=De-Mosaicing

von Hamburger (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Bonzo schrieb:
> Dabei ist mir aber aufgefallen, dass der Sensor (Bayer) auch solche
> Offsets hat.
In der Tat hat der das. Das weiss der Sensor aber zunächst nicht, weil 
er von den Farbfiltern nichts weiß und nur Helligkeit abgibt.

> Wie wird das bei der Bayerconversion gemacht?
Das wäre deine Aufgabe sage ich einfach.

Bonzo schrieb:
> Wie ist das bei TFTs? Wenn man dort einfach RGB ausgibt, haben die 3
> Bilder, die entstehen, ja auch diesen Halbpixelversatz.
Ich nehme an, dass die die Hersteller berücksichtigen und die 
Pixelprozessoren die Bilder anpassen, wenn sie skalieren. Beim 
unskalierten Bild 1:1 sehe ich aber das Problem, dass dann der Kontrast 
nicht voll auszusteuern wäre, weil ein 01 ja irgendwie interpoliert 
werden müsste.

Wer weiß es?

von Jemand (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hamburger schrieb:
> Ich nehme an, dass die die Hersteller berücksichtigen und die
> Pixelprozessoren die Bilder anpassen, wenn sie skalieren. Beim
> unskalierten Bild 1:1 sehe ich aber das Problem, dass dann der Kontrast
> nicht voll auszusteuern wäre, weil ein 01 ja irgendwie interpoliert
> werden müsste.
>
> Wer weiß es?

Die Unterteilung in Subpixel wird außer für Textdarstellung und 
besonders hochqualitative Grafikdarstellung üblicherweise überhaupt 
nicht berücksichtigt.

von Bonzo (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Jemand schrieb:
> Die Unterteilung in Subpixel wird außer für Textdarstellung und
> besonders hochqualitative Grafikdarstellung üblicherweise überhaupt
> nicht berücksichtigt.

Wie sollte das auch (z.B. für Textdarstellung) berücksichtigt werden?
Das erforderte eine Behandlung in der Verarbeitung des Bildes.
Ich mache das auch nur, weil die LEDs eine Sonderanordnung haben.

von Fitzebutze (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Verstehe ich dich richtig: Du willst die Artefakte vom Bayer-Pattern auf 
die Ausgabe-LED minimieren, bzw. die Auflösung optimieren, willst aber 
nicht den Weg Bayer -> RGB-Wert -> Ausgabe gehen, sondern für deinen 
speziellen Fall direkt konvertieren?
Dazu müsste man eben schon die gesamte Pattern-Anordnung und 
Farbcharakteristik deines LED-Arrays anschauen. Und oft bringt das 
genannte Subpixel-Smoothing für ein Farbbild gar nicht so viel. 
(Subpixel-Rendering wäre das Stichwort, zu dem du eine Menge Source 
findest).

Im Prinzip kannst du per bilineare Interpolation die Eingangs-Werte 
einer Farbe auf den zugehörigen Ausgang verteilen, damit hast du den 
Versatz auch abgefrühstückt, aber der simple Filter sorgt halt für 
Übersprechen. Du hast halt immer das Problem Auflösung versus Artefakte.
Das grössere Problem hätte ich jetzt aber eher beim Farbabgleich 
gesehen, denn die LEDs haben eine ganz andere Charakteristik als dein 
Bayer-Filter.

von Jürgen S. (engineer) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Fitzebutze schrieb:
> Dazu müsste man eben schon die gesamte Pattern-Anordnung und
> Farbcharakteristik deines LED-Arrays anschauen.

Das ist das Problem. Das Display bekommt bereits einen fertigen 
Datenstrom im 1:1 Format. Dann macht Subpixel-Interpolation keinen Sinn.

Auf der Sensor-Seite ist das was anderes. Selbstredend wird das in 
Betracht gezogen. Entweder durch ganzzahliges Overscan oder durch 
Interpolation. Bei meinem BC steckt es in den umschaltbaren 
Filterkurven. Wenn man nicht nur den Sensor, sondern auch die Anwendung 
/ Optik kennt, kann man diese auf die Bayer-Conversion anpassen.

von Bonzo (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Fitzebutze schrieb:
> Verstehe ich dich richtig: Du willst die Artefakte vom Bayer-Pattern auf
> die Ausgabe-LED minimieren, bzw. die Auflösung optimieren, willst aber
> nicht den Weg Bayer -> RGB-Wert -> Ausgabe gehen, sondern für deinen
> speziellen Fall direkt konvertieren?
Nein, RGB soll schon gemacht werden. Ich wüsste auch nicht, wie man das 
umgehen könnte und warum man es sollte. Ich kam nur wegen Bayer auf den 
Trichter, das umgekehrt auch für das Display zu tun.

Fitzebutze schrieb:
> (Subpixel-Rendering wäre das Stichwort, zu dem du eine Menge Source
> findest).
Schaue ich mal, danke!

Fitzebutze schrieb:
> Das grössere Problem hätte ich jetzt aber eher beim Farbabgleich
> gesehen, denn die LEDs haben eine ganz andere Charakteristik als dein
> Bayer-Filter.
Das macht eigentlich wieder der Monitor. Der Hersteller wieß doch um das 
Verhalten seiner LEDs und kann es anpassen.

von Jürgen S. (engineer) Benutzerseite


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Es gibt Fälle, in denen es sinnvoll ist, das Bild umzurechnen und auf 
die Darstellungsmatrix anzupassen, wie z.B. bei LED-Wänden, die eine 
besondere Anordnung der LEDs haben.

Bild aus meinem FPGA-Sensor-Emulator.

von Fitzebutze (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Jürgen S. schrieb:
> Das ist das Problem. Das Display bekommt bereits einen fertigen
> Datenstrom im 1:1 Format. Dann macht Subpixel-Interpolation keinen Sinn.

Doch, sie macht dann Sinn, wenn man die Artefakte minimieren will. Genau 
das machen die Subpixel-Renderer, und zwar vom Sensor direkt zur 
Ausgabe, unter den bestehenden Randbedingungen. Man muss halt das 
Mapping kennen.

von Bonzo (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Fitzebutze schrieb:
> Man muss halt das
> Mapping kennen.

Und woher kennt man das? Funktionieren alle Monitore gleich?

von Fitzebutze (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Nee, fängt schon mal an mit RGB/BGR. Dann gibt es Exoten, wie die Dinger 
von Pixel Qi (eine Weile her). Die Standard-Subpixelrendering-Libs muss 
man dann entsprechend konfigurieren, die können aber typischerweise nur 
einfache RGB/BGR order, sobald da spezielle Pixel dazukommen, ist Sense 
und die Artefakte werden teils schlimmer als ohne SPR.
Man findet sonst noch so einiges in Patentschriften diverser 
Kamerasensorenhersteller, wenn die Datenblätter nix hergeben.
In deinem Fall kennst du ja das Mapping deiner LED-Wand sowieso, und das 
des Sensors vermutlich auch. Und hast das Problem des Farbabgleichs 
(unter Annahme, dass die Ausgabe linearisiert ist) nur noch auf 
Bayer-Seite.
Dafür gibt's aber fertige IP-Cores.

von Bonzo (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Fitzebutze schrieb:
> Man findet sonst noch so einiges in Patentschriften diverser
> Kamerasensorenhersteller,

Du meinst die Displayhersteler, oder?

von Fitzebutze (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Da auch, aber Display hat man vielleicht schneller mal unter die Lupe 
gelegt :-)

von Bonzo (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Wäre die Frage, ob man da viel erkennen kann ...

von Hugo H. (hugohurtig1)


Bewertung
0 lesenswert
nicht lesenswert
Fitzebutze schrieb:
> Da auch, aber Display hat man vielleicht schneller mal unter die Lupe
> gelegt :-)

Noch schneller kann man rote, grüne und blaue Flächen aufnehmen und sich 
jeweils die Helligkeit der einzelnen Pixel anschauen:-)

von Jürgen S. (engineer) Benutzerseite


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ja, kann man: Hier ein Bild meines AOC:

Überraschung?

Fitzebutze schrieb:
> das machen die Subpixel-Renderer, und zwar vom Sensor direkt zur
> Ausgabe, unter den bestehenden Randbedingungen. Man muss halt das
> Mapping kennen.

Eben und das kennt man ja nur, wenn man die Bildverarbeitung selber in 
Händen hat. Meine Aussage von oben bezog sich auf das, was der 
Monitorhersteller tun kann. Und der darf diesbezüglich eigentlich nichts 
tun, um nicht die Bandbreite zu reduzieren, zumindest bei der nativen 
Auflösung. Eine maximale Steigung von 0101 lässt sich nicht 
subpixelverschieben.

Wohl geht es natürlich beim Umskalieren...

: Bearbeitet durch User
von Jürgen S. (engineer) Benutzerseite


Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
Um nochmal auf die eventuelle Verschiebung beiM Bayer-pattern 
einzugehen:

Bei Bayer ist es am Einfachsten (und von der Position am Richtigsten!), 
man fährt die Auflösung exakt mit der Anzahl der Graupixel und 
interpoliert die fehlenden Farben. Dann gibt es keinen Versatz zwischen 
empfangenem und wiedererzeugtem Bild.

Danach geht man idealerweise mit einer Ganzzahl-Dezimation auf die 
benötigte Auflösung runter. Beides, Interpolation und Dezimation 
erfordern jeweils Tiefpassfilter mit entsprechender Ausdehnung. Leider 
bekommt man dabei nur ein Bild mit einer "analogen" Schärfe im Bereich 
von 1/4 der Graubildauflösung. Dies entspricht zwar der echten Qualität 
der Information, reicht aber oft nicht, daher gibt es die 
unterschiedlichsten Ansätze, die fehlenden Pixel zu erraten.
Das erfordert etliche Annahmen über Kantenverläufe, Farben im 
Originalbild und genau genommen auch die Bewegung bei der Aufnahme. 
Kanten lassen sich recht gut mit parallelen Annahmen realisieren und die 
unschönen Farbsäume durch Interpretation des Bildes im YUV-Raum, was 
besonders Grautönen hilft, nicht zu verfärben.

In einem FPGA hat es auch ausreichend Parallelität, um das in Echtzeit 
rechnen zu können. Mein Converter z.B. arbeitet mit dreifacher 
Interpolation, also 9 Pixel je Graupixel und 36 Subpixeln je Farbpixel. 
Betrachtet werden immer mindestens 3 volle Pixel in jeder Richtung. Der 
Filter hat 17x17 Plätze, ist also etwas größer, als der übliche 5x5.
Danach kann leicht dezimiert werden, um zu einer Auflösung zu kommen, 
die im Zeitbereich bei voller Bandbreite ausgegeben - und auf die 
benötigte Auflösung umgerechnet werden kann, z.B. für kontinuierlichen 
Zoom. Im Beispiel 3:5, also z.B. 1600x1200 auf 960 x 720 für ein HD 
Bild. Zudem kann der Interpolationsfilter zum Rekonstruieren defekter 
Sensorpixel herangezogen werden.

In der Wikipedia ist im Bayer-Sensor-Artikel ein Bild meines Autos zu 
finden, das ich auf diese Weise prozessiert hatte.

Inzwischen läuft der Filter auf 19x19 / 21x21 oder 23x23, was der FPGA 
hergibt und vom Bildmaterial sinnvoll ist. Damit hat es eine effektive 
7x7 Graupixelbetrachtung. Für die höheren Videostandards heute passt das 
auch besser.

: Bearbeitet durch User

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.