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.
Angehängte Dateien:
-
pixel_element.gif
2,2 KB
Angehängte Dateien:
-
pixel_interpolation.gif
81 KB
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.
De-Mosaicing Algo's gibt es fast soviel wie Idioten am Kalten Buffet: https://www.google.de/search?ei=oAFxXbKSC4mYjLsPk7e12Aw&q=De-Mosaicing
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.
Angehängte Dateien:
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.
Fitzebutze schrieb: > Man muss halt das > Mapping kennen. Und woher kennt man das? Funktionieren alle Monitore gleich?
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: > Man findet sonst noch so einiges in Patentschriften diverser > Kamerasensorenhersteller, Du meinst die Displayhersteler, oder?
Da auch, aber Display hat man vielleicht schneller mal unter die Lupe gelegt :-)
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:-)
Angehängte Dateien:
-
monitor_nahaufnahme.jpg
210 KB
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
Angehängte Dateien:
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
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.