Krieg dem Pixelfehler!

[Cherry]

Hallo Liebe Proggen - Community!


Ich bin 25 Jahre alt und zur Zeit stecke ich mitten in meiner schulischen Ausbildung zum Techniker.
Ich würde euch heute gerne mein Techniker-Projekt vorstellen, da ich unbedingt ein bisschen Hilfestellung und Inspiration brauche.






Mein Projekt zusammengefasst:

Ziel:

Alles in allem lässt sich meine Aufgabe sehr einfach beschreiben. Ich muss für einen Prüfplatz eine Steuerung/einen Prüfvorgang entwickeln, der ein fertiges Gerät, nennen wir es mal Gerät X, nach seiner Produktion, final auf die volle Funktion des Displays prüft. Dabei sollen Pixelfehler, der Ausfall von ganzen Reihen oder andere Fehlfunktionen auf dieser Ebene festgestellt werden.
Der Prüfplatz wird Speziell für dieses Gerät X entwickelt, es wird kein universeller Prüfplatz!



Meine Konzepte oder eher Gedankengänge bis jetzt:

Idee 1)
Ich baue ein Gestell und werde über dieses Gestell einen Arm fahren lassen, auf dem sich wiederum ein unabhängig bewegbarer Schlitten befindet, auf dem eine Kamera sitzt. Man kann sich das vorstellen wie bei den großen Kränen die man in Werkstätten oder Lagerhallen findet. Diese Kamera lass ich über das Display fahren um das Display Pixelreihe für Pixelreihe abzusuchen. Das Gerät X wird so lange in einem Testprogramm laufen, bis Rot, Blau und Grün getestet wurde.

Idee 1 - Problem)
Soweit hört sich diese Lösung, zumindest für mich, sehr solide an. Ich bin auch in der Lage alles so weit zur realisieren und zu programmieren. Angesteuert wird die 'Kamerabahn' erstmal über einen Arduino. Programmiert wird auf Assembler. Mein grundlegendes Problem hierbei befindet sich allerding in der Software zur Auswertung der Pixel/Pixelreihe. Ich nehme mit der Kamera ein Liveansicht auf und dann? Wie verarbeite ich das Signal, wie werte ich es aus? Für die Lösung dieses Problems muss nicht der Arduino verwendet werden. Es darf auch eine externe Recheneinheit genutzt werden, kein Problem.


Idee 2)
Ähnlich zur ersten Idee, wird es auch hier wieder eine Kamera über dem Display geben. Diesmal allerdings fest montiert und ausgerichtet. Die Kamera nimmt ein hochauflösendes Bild auf und speichert es. Das gespeicherte Bild wird auf Pixelfehler oder Anzeigefehler im Gesamten abgesucht.

Idee 2 - Problem)
Auch wieder ähnlich zur ersten Idee, kann ich soweit alles realisieren. Problem auch hier, wie werte ich das Bild aus? Gibt es für solche Zwecke vielleicht schon eine Software? Ist es überhaupt möglich eine Kamera mit einer X - beliebigen Software anzusteuern?



Meine Kompetenzen in Punkto Bildverarbeitungssoftware o.Ä. sind nicht sehr ausgeprägt. Ich schätze meine Stärken und Defizite haben durch meine geäußerten Probleme, einen groben Umriss bekommen. Ich brauche niemand der meine Hausaufgaben macht und ich möchte mich später auch nicht mit den Lorbeeren eines anderen schmücken. Was ich mir hier erhoffe, ist ein wenig Hilfe in den richtigen Punkten, ein kleiner oder womöglich auch größerer Schupser in die richtige Richtung und vielleicht sogar die ein oder andere Person die sich für ein ähnliches Gebiet begeistert und von der ich Lernen kann.

Meine groben Konzepte sind keine festen Vorgaben. Ich stehe ganz am Anfang und kann meine Ideen noch nach Belieben umstrukturieren. Sollte jemand eine bessere Idee haben oder produktive Vorschläge bzw. Verbesserungen haben, bin ich für alles offen und nehme mich jeder Kritik dankend an.

Danke für eure Zeit.

Mit freundlichen Grüßen,
Cherry

[Xin]

Moin Moin

Meine Konzepte oder eher Gedankengänge bis jetzt:

Idee 1)
Ich baue ein Gestell und werde über dieses Gestell einen Arm fahren lassen, auf dem sich wiederum ein unabhängig bewegbarer Schlitten befindet, auf dem eine Kamera sitzt. Man kann sich das vorstellen wie bei den großen Kränen die man in Werkstätten oder Lagerhallen findet. Diese Kamera lass ich über das Display fahren um das Display Pixelreihe für Pixelreihe abzusuchen. Das Gerät X wird so lange in einem Testprogramm laufen, bis Rot, Blau und Grün getestet wurde.

Hmm... die Kamera würde viele sehr unterschiedliche Bilder aufnehmen, die über sehr viel redundante Informationen verfügen. Viele Pixel würden ja etliche Male abfotographiert und der Aufbau ist sehr komplex und eigentlich acuh fehleranfällig. Bewegliche Teile gehen nunmal gerne kaputt.
Der einzige Vorteil, den ich hier sehe, wäre dass ein Pixelfehler der Kamera ausgeglichen werden könnte. Aber wir gehen wohl mal davon aus, dass das Prüfgerät in der Regel funktioniert.

Idee 2)
Ähnlich zur ersten Idee, wird es auch hier wieder eine Kamera über dem Display geben. Diesmal allerdings fest montiert und ausgerichtet. Die Kamera nimmt ein hochauflösendes Bild auf und speichert es. Das gespeicherte Bild wird auf Pixelfehler oder Anzeigefehler im Gesamten abgesucht.

Klingt sinnvoller. Eine einfache Webcam hat bereits eine gute Auflösung. Sie muss natürlich mindestens über der Auflösung des Displays liegen. Man schiebt das Display in den Bereich der Cam und Foto.

Idee 2 - Problem)
Auch wieder ähnlich zur ersten Idee, kann ich soweit alles realisieren. Problem auch hier, wie werte ich das Bild aus? Gibt es für solche Zwecke vielleicht schon eine Software? Ist es überhaupt möglich eine Kamera mit einer X - beliebigen Software anzusteuern?

Spontan fällt mir hier ein, einen Raspberry Pi zu nehmen, eine Kamera dran zu setzen und ihn als Webcam einzusetzen. Wenn Du also auf eine URL ansteuerst, macht der Pi ein Bild und schickt Dir das. Schon hast Du erstmal das Bild.

Deine Software kannst Du unabhängig davon programmieren, indem sie ein Bild anfordert statt eben den Pi zu fragen, einfach eins von der Platte lädt. Wenn das Display Hinweise hat, wo es positioniert ist (zum Beispiel den Rand, der anders aussieht), kannst Du das Sichtfeld auf dem Bild bestimmen. Du könntest beispielsweise ein Foto machen mit abgeschalteten Display und mit maximal hellen Display. Zwei Fotos. Das Display ist viereckig, also muss sich ein viereckiger Bereich auf den beiden Fotos unterscheiden. Er muss definitiv viereckig sein, ein Überstrahlen sollte also durch das Wissen, dass vier Ecken mit vier geraden Linien verbunden werden müssen, regeln lassen.
Anhand der Linien kannst Du ausrechnen, wo welcher Pixel auf dem Foto ist. Anschließend machst Du die relevanten Bilder: rot, grün, blau, weiß, schwarz. Und gehst die Reihen durch. Wenn zum Beispiel beim roten Bild eine deutliche Abweichung nach schwarz ist, ist der Bereich verdächtig, einen Pixelfehler zu haben. Je stärker der Punkt von gesuchten Rot abweicht, um so höher die Chance eines Pixelfehlers. Zwischen den Pixeln ist das Display schwarz. Da deine Cam mehr Punkte aufzeichnet als das Display Punkte hat, wirst Du also zwischen den Pixeln Helligkeits-Schwankungen haben. Und weil Du mehr Punkte aufzeichnst, als das Display Auflösung hat, wird jeder Pixel des Displays mit mehreren Pixeln auf dem Foto repräsentiert. Wenn sich also eine deutliche Schwankung auf mehreren Pixeln ergibt, dann bekommst Du eine Anhäufung von beisammen liegenden verdächtigen Punkten, die eine unüblich hohe Wahrscheinlichkeit eines Fehlers signalisieren, während der Rest eher minimal und vor allem gleichförmig von erwarteten Farbe abweicht.

Meine Kompetenzen in Punkto Bildverarbeitungssoftware o.Ä. sind nicht sehr ausgeprägt. Ich schätze meine Stärken und Defizite haben durch meine geäußerten Probleme, einen groben Umriss bekommen. Ich brauche niemand der meine Hausaufgaben macht und ich möchte mich später auch nicht mit den Lorbeeren eines anderen schmücken. Was ich mir hier erhoffe, ist ein wenig Hilfe in den richtigen Punkten, ein kleiner oder womöglich auch größerer Schupser in die richtige Richtung und vielleicht sogar die ein oder andere Person die sich für ein ähnliches Gebiet begeistert und von der ich Lernen kann.

Ich habe von Bildverarbeitung nur wenig Ahnung. Ich habe mal eine bildverarbeitende Programmiersprache geschrieben und dafür ein paar kleine Filter. Die meisten waren aber dazu da, aus 3D-Daten Bilder zu rendern. Da waren auch einige dabei, die rauschunterdrückend wirkten. Dein Pixelfehler ist in meiner Vorstellung quasi das gesuchte Signal im Rauschen der korrekten Pixel.
Das war's schon.

[cloidnerux]

Bewegte Teile sind meistens keine gute Lösung, Bewegung kostet Zeit, ist fehleranfällig und man muss Datenaufnahme und Bewegung gescheit koordinieren.

Tue dir Assembler nicht an, das bringt keine Vorteile und ist meist Fehleranfälliger. Microcontroller kann man heutzutage mit C/C++, Java, Python, C# und anderen Sprachen programmieren. Assembler ist da eher so 1980.

Zu deinem Problem: Ein Bild ist ein Tensor(Matrix mit 3 Dimensionen), was du suchst ist ein Pixel/Fleck im Bild, der abweicht. Solche Probleme lassen sich super mit Python(numpy, scipy und openCV) lösen, alternativ auch Matlab, daher auf einem Windows PC. Generell würde ich dir raten, das ganze mit 1-4 Kameras und einem Windows PC aufzubauen, dass kann man einfach Kaufen und hat minimalen Aufwand.

Als Randbedingung gilt, dass deine Kamera + Objektiv besser Auflösen als deine Pixeldichte und Anzahl, damit ein Pixelfehler nicht übersehen wird. Wenn 4k Kameras zu teuer sind, probiere es doch mit mehren. Gibt da von AlliedVision/µEye und anderen gute USB oder Ethernet Kameras.

Die einfachste Auswertung besteht darin, dass du Refernzbilder aufnimmst und diese dann von dem Bild deines DuT abziehst. Im Idealfall ist das resultierende Bild überall 0, außer es existiert ein Pixelfehler. Daher du wendest einen Peak-Detect Algorithmus mit einem Schwellwert(Rauschunterdrückung) an.
Problem bei sowas sind Unterschiede in der Beleuchtung, der DuT Helligkeit sowie umgebungseinflüsse.

Alternativ kannst du mehrere einfarbige Bilder auf dem DUT anzeigen. Dann packst du ein Histogramm auf dein Aufgenommenes Bild, um die "Hauptfarbe" zu bestimmen. Diese ziehst du dann ab und erhälst wieder eine Karte der Abweichungen. Auch hier dann wieder nach Maxima suchen.

Dann kann man sicherlich auch eine FFT auf das ganze Werfen, aber probier erstmal einfachere Lösungen.

[koshamo]

FFT habe ich die ganze Zeit schon im Sinn... da haben wir Ende letzten Jahrtausends ganze Qualitätssicherungsprodukte in C mit geschrieben.

Ich denke, um die FFT wirst du ohnehin nicht drumherum kommen, denn du wirst die Displaygrenzen, wie von Xin geschrieben, aus dem Bild erkennen müssen, um zu wissen, wo dein zu erkennendes Bild liegt. Hier kannst du mit Hilfe der FFT wunderbar eine Kantenerkennung laufen lassen und den passenden Bildausschnitt für das eigentliche Testbild festlegen.
Danach würde ich tatsächlich Testbilder pro Farbe aufnehmen und wieder per FFT Kanten bzw. Artefakte suchen. Hast du ein Artefakt gefunden, hast du einen Pixelfehler. Hast du keines, ist alles gut.

Ich könnte mir aber tatsächlich gut vorstellen, dass du heute für jede weit verbreitete Sprache einige Bibliotheken findest, die dich unterstützen, um Farbveränderungen / Histogramme zu identifizieren. Das Kantenproblem bleibt weiterhin

[cloidnerux]

Ich denke, um die FFT wirst du ohnehin nicht drumherum kommen, denn du wirst die Displaygrenzen, wie von Xin geschrieben, aus dem Bild erkennen müssen, um zu wissen, wo dein zu erkennendes Bild liegt. Hier kannst du mit Hilfe der FFT wunderbar eine Kantenerkennung laufen lassen und den passenden Bildausschnitt für das eigentliche Testbild festlegen.
Dafür braucht man keine FFT. Hugh-Transformation, Blob-Erkennung oder eine simple Gradientenerkennung würden wrsl schon ausreichen. Bzw wenn man alles Fix aufbaut und eine Aufnahme für das DUT hat, kann man einfach fix die Grenzen des Displays abstecken.

Interessant ist FFT wenn man genug Auflösung hat, um das Pixel-Grid zu sehen. Dann kann man quasi das Grid Berechnen und abziehen, sodass man jedes einzelne Pixel für sich haben kann. Aber das würde wrsl eine 10-Fach höhere Auflösung in jede Richtung im Vergleich zu der Auflösung im Display erfordern.

[Cherry]

Vielen Dank für eure Antworten!

Ich glaube mir fehlt die Zeit wirklich alles zu kommentieren, deswegen werde ich meine Antworten auf Zusammenfassungen beschränken.

Ich bin eurer Meinung dass bewegende Teile fehleranfälliger sind. Idee gestrichen.
Ich kann keine der Programmiersprachen die ihr aufgezählt habt. Sie werden uns schlichtweg nicht unterrichtet. Ich habe aber kein Problem mir eine neue Programmiersprache anzueignen. Es wäre vielleicht nur von Vorteil, wenn ich wüsste, mit was ich mich die nächsten Wochen auseinander setzen muss/sollte. Präferenzen?

Die Idee mit dem Histogramm finde ich sehr gut. Sowas hatte ich auch schon im Hinterkopf. Ich dachte allerdings bis jetzt, dass Histogramme zur Bestimmung der Helligkeit eines Bildes genutzt werden. Würde dann aber mit dem Verwendungszweck den ihr dafür vorgesehen habt, nicht passen. Also wo ist meine Bildungslücke?

FFT? Ich habe das zwar schon mal gehört, dachte aber immer das ist zur Aufschlüsselung von Signalen in ihre Bestandteile(Frequenzen)? Wie würde das hier Verwendung finden?

Auch um die Bestimmung der Ränder habe ich mir Gedanken gemacht. Ich dachte allerdings ich könne das lösen, indem ich eine Kamera fest ausrichte. Außerdem könnte ich dem ganzen Gerät, für den Test, eine Art konischen Zylinder übersetzen, um die Lichtverhältnisse immer gleich zu halten.

Und ja, es wird definitiv eine Prüfung pro Farbe geben.

Das Display wird wohl eine Auflösung haben die irgendwo bei 640p liegt (ca.-Angabe)


Liebe Grüße
Cherry

[koshamo]

Mit Histogrammen bin ich nicht so sonderlich bewandert, aber letztlich entspricht jede Farbe ja einer Helligkeit und du kannst die einzelnen Farbkanäle auswählen. Wenn alles in einem Bereich ist, passt das. Hast du Peaks im unteren oder oberen Bereich, hast du eine Anomalie.

Mit der FFT ist das ähnlich. Ein Farbwert ist ja letztlich ein Signal. Wenn das Signal gleichförmig ist, hast du keinen Pixelfehler. Hast du irgendwo Peaks, dann beschreibt das Pixelfehler.

Was die Ränder angeht, ist das aus meiner Sicht schwierig, das rein Hardware-technisch zu lösen. Einerseits wirst du nicht so genau positionieren können, andererseits hast du im Randbereich, verursacht durch die Linse, immer potentielle Schwierigkeiten im Bild. Und es lässt sich kaum nachvollziehen, ob du die Pixelreihen am Rand tatsächlich im Bild hast. Daher sollte die Kamera einen größeren Ausschnitt als das eigentlich Display aufnehmen, um die Probleme zu umgehen. Dann musst du allerdings den relevanten Bildausschnitt erst erkennen.

Was die Sprache angeht: Nimm das, was dir am sympathischsten ist. Du wirst für FFT und Histogramme sicherlich in jeder bekannten Sprache Bibliotheken finden oder deine ausgewählte Sprache bietet eine Schnittstelle, um z.B. C-Bibliotheken einzubinden.
Aus meiner Sicht könnten insbesondere C, C++, Java, Python, Scala, Kotlin, C# (und die komplette .NET Plattform) interessant sein, wobei ich tatsächlich die Finger von Assembler für den µ-Controller lassen würde und diesen in C programmieren würde

[cloidnerux]

Präferenzen?

Ganz klar Python.
Lade dir Anaconda herunter, da hast du alles was du brauchst.
Du kannst quasi alles was du brauchst mit 3 - 4 Zeilen Code lösen und wenn du das dann mal doch in eine andere Sprache übertragen sollst, kannst du dir den Quellcode anschauen und kopieren.
Du kannst wrsl selbst ohne Vorkentnisse deine Anwendung grob an einem Tag zusammenschustern.
Schau dir einfach mal Beispiele an:
https://scikit-image.org/
https://docs.opencv.org/3.0-beta/doc/py ... lines.html