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.
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.
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?
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.
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.
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.
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.
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.
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.
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.
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.
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:-)
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...
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.
pixel_element.gif
(2,2 KB)
