Wir möchten Bilder, die herunterskaliert wurden, im Nachhinein schärfen. Wie könnte man dies am Einfachsten tun? Die Test-Bilder liegen als TIFF(16 Bit je Farbe) vor, später wird es aber ein kontinuierlicher Bilderstrom über GIG-E-Vision. Welcher Prozessor eignet sich dafür und wie programmiert man den? Wieviel Pixel muss man dazu gleichzeitig betrachten und verrechnen? Wie vermeidet man Übersteuerungen beim Schärfen, die zu unnatürlichen Darstellungen führen?
Also ich habe mich bei meinen Tests nach dieser Seite gerichtet: http://www.dspguide.com/ch24/2.htm Ich denke, das es sich dabei um den Sobel-Operator handelt: https://de.wikipedia.org/wiki/Sobel-Operator Bei meinen Versuchen habe ich aber festgestellt, dass man es dabei nicht übertreiben sollte. Oft sehen die Bilder nach zweimaliger Anwendung schon unnatürlich aus. Nach ca. 20-maliger Anwendung würde sogar Andy Warhol vor Neid erblassen. Das mit der Übersteuerung ist bei der Bildmanipulation ein allgemeines Problem. Eine generelle Lösung dafür gibt es glaube ich nicht. Es hilft aber, wenn man die Pixeldaten in einem ausreichend grossen Datenwert abspeichert und weiter verarbeitet. Dann kann man auf dem Ziel-Image entweder clippen (war bei mir bisher ausreichend) oder komplett neu skalieren (habe ich noch nicht versucht). Und ich hoffe mal, das die Bilder keinen Alpha Kanal haben, denn dann wird es richtig kompliziert. Die Artefakte dazu habe ich schon gesehen, aber die Lösung habe ich noch nicht geschafft (es gibt dabei Farbränder).
Moin, Mr. C schrieb: > Wir möchten Bilder, die herunterskaliert wurden, im Nachhinein > schärfen. > Wie könnte man dies am Einfachsten tun? Ich wuerd' erstmal mit ImageMagick anfangen. Und keine Wunder erwarten. > Die Test-Bilder liegen als TIFF(16 Bit je Farbe) vor, später wird es > aber ein kontinuierlicher Bilderstrom über GIG-E-Vision. Welcher > Prozessor eignet sich dafür und wie programmiert man den? Irgendein x86(_64) wird wohl das guenstigste Preis/Leistung/Exotik-Verhaeltnis haben. Die Aufgabe kommt mir jetzt nicht so exotisch vor, dass man irgendeinen Spzialprozessor dafuer braeuchte. Die tiffs werden wohl gut per Batch und ImageMagick handelbar sein; bei GIG-E-Vision wirds halt spziell, geheim und damit wohl teurer. > Wieviel Pixel > muss man dazu gleichzeitig betrachten und verrechnen? Je mehr, desto besser wirds wohl gehen. > Wie vermeidet man Übersteuerungen beim Schärfen, die zu unnatürlichen > Darstellungen führen? Durch einen cleveren Filteralgorithmus? Gruss WK
Am einfachsten ist es wie schon erwähnt ImageMagick zu verwenden. Wenn es richtig gute ergebnisse geben soll bleibt nur der weg über hochkomplexe neuronale netze die anhand von einigen 100mio bildern den inhalt rekonstruieren können...
Mr. C schrieb: > Wir möchten Bilder, die herunterskaliert wurden, im Nachhinein schärfen. > Wie könnte man dies am Einfachsten tun? Beim Herunterskalieren geht eigentlich hochfrequenze Information verloren und es muss gefiltert werden, dass es hierbei nicht zu Fehlern kommt. Später ist das Bild frequenzmäßig eher am Limit, also vorher - daher frage Ich mich, was da nun durch post-Prozessierung nachgeschäft werden soll. Künstliche Schärfung braucht man eigentlich nur beim up-scaling, z.B. bei der Wandlung von SD auf HD.
Fuer Einzelbilder gibt es einen Entrope Entrauscher, der ist als iterativer Algorithmus eher aufwendig in Sachen Rechenzeit. Eine bessere Kamera und nicht runterskalieren ist die bessere Loesung.
Die aktuellen Kameras machen das aber auch in Signalverarbeitung und nicht nur etwa durch bessere Optiken oder Sensoren. Da wird auch viel betrogen.
Kamera-d schrieb: > Da wird auch viel > betrogen. Aber nicht bei GigE Vision, da bekommt man die Rohdaten der Pixel. Die schnellen X64 schaffen da einiges, mit den Intel Bibliotheken wie IPP oder mit der OpenCV bekommt man schon stark optimierte Algorithmen. Zum Bildeinzug per GigE liefert entweder der Kamerahersteller sein Framework oder man nimmt generische von Stemmer (CVB), MatrixVision, Halcon oder ähnliche.
Johannes S. schrieb: > Aber nicht bei GigE Vision, da bekommt man die Rohdaten der Pixel. Das glaubst auch nur Du. GigE Vision und andere Formate kommen nicht aus dem Sensor raus sondern werden entweder durch einen programmierbaren image processor (Nikon) einen ASIC-Chip (Leica) oder einen FPGA gemacht (Hasselblad). Die Sensordaten haben bei den hohen Auflösungen unzählige Fehler (oft mehrere Tausen kaputte Pixel, Dutzende kaputte Linie) und stark abweichende Zeilen-pattern. Dazu kommen optische Effekte wie Aberation. All das wird vorher wegkorrigiert, damit der Kunde nicht merkt, was er für Krüppelware hat bzw er was mit dem Bild anfangen kann. Besonders die Linseneffekte müssen von der Kamera weggemacht werden, weil man das nur anhand von Messungen kann. Ein späterer Bildalgorithmus hat keine Chance das zu erkennen. In der Regel wird auch schon Bayer-Dedodierung vollzogen und die Chromakorrektur des Sensors. Die Objektive haben unterschiedliche Vergütungen und Farbfehler, die wegkorrigiert werden müssen. Bei der Gelegenheit werden auch kaputte Pixel ersetzt, non uniformity eledigt und das Rauschen der Elektronik rausgerechnet. Obendrauf kommen Schärfungsalgorithmen, welche die flache Optik billiger Kammeras aufwerten. 30% vom Bildinhalt sind komplett erstunken und erlogen. Bei billigen Kameras unter 2000,- ist es noch mehr, weil die ziemlich auf die Kosten der Sensoren achten müssen und bei Sensoren unter 200,- abwärts kriegt man fast nur den Ausschuss, der übrig bleibt, wenn die obersten 30% der Charge an die Tophersteller gegangen ist. Ein mir bekannter Hersteller hat mal 3 Kameraproduzenten gleichzeitig beliefert und der Tophersteller hat aus ein und derselben Charge einfach die oberen 7% der Ausbeute zum Dreifachen Grundpreis abgezogen. Die hatten dann weniger als soundsoviele Fehler. Maximal 100 Pixel und nur eine Zeile z.B. Alles zwischen 8% und 33% ging an uns, der Rest zu halben Preis an die preiswerten Hersteller.
Kamera-d schrieb: > GigE Vision und andere Formate kommen nicht aus > dem Sensor raus sondern werden entweder durch einen programmierbaren > image processor (Nikon) einen ASIC-Chip (Leica) oder einen FPGA gemacht > (Hasselblad). GigE Vision ist kein Format sondern ein Standard für Machine Vision. Die Kameras die den Standard implementieren haben alle FPGAs drin, aber nicht von Nikon oder Hasselblad. Die sind für Fotoknippsen und nicht für Kameras für Inspektions- oder Messaufgaben. Nikon oder HB werden zwar auch für Photogrammetrie eingesetzt, das hat dann aber wieder nix mit GigE Vision zu tun. Kamera-d schrieb: > Die Objektive haben unterschiedliche > Vergütungen und Farbfehler, die wegkorrigiert werden müssen. ja, aber wie soll der Kamerahersteller sowas machen wenn er gar nicht weiss welches Objektiv ich einsetze? Eine Kommunikationn zwischen Kamera und Objektiv ist da nicht Standard. Kamerakalibrierung muss man da mühselig selber machen. Und Farbfehler gibts nur bei Farbkameras, für MV setzt man eher monochrome Kameras ein. Kamera-d schrieb: > Bei billigen Kameras unter 2000,- ist es noch mehr, weil die ziemlich > auf die Kosten der Sensoren achten müssen und bei Sensoren unter 200,- Kameras mit grossflächigen CCDs kosten 5stellig, eben weil die Sensoren selektiert und damit teurer sind. Bei Kodak/OnSemi findet man für die grossen Sensoren Angaben zu defekten Pixeln, die liegen bei einem 10 M Sensor aber eher bei <20, Pixel mit kleineren Spannungsfehler bei <1000 oder 2000, je nach Klasse. Und die Preisdifferenz zwischen Class1/2 ist ordentlich. Kameras oder Sensoren mit 30% Pixelfehlern oder interpolierten Pixelwerten wären ganz einfach Schrott. Das würde sofort auffallen und sich nicht am Markt halten.
Johannes S. schrieb: > GigE Vision ist kein Format sondern ein Standard für Machine Vision. Du hast den OT gelesen? Er hat Bilder im 16Bit Format die er bearbeiten will und dann händisch versenden will. Ich sehe hier keine MV-Applikation und auch nicht die von Dir angeführten Schwarz-Weiss-Bildsensoren für Video. 10M mit 20 Fehlern mag sein, wenn man sie selektiert, aber in Kameras werden Sensoren bis 80M eingesetzt und da steigt die Fehlerzahl mindestens linear mit. Wären also schon 160, wenn Du nachrechnen möchtest. Mit Blick auf die Ausbeute der Wafer und der größeren Fläche dieser Sensoren sieht es gleich nochmal schlechter aus. >Pixelinterpolation Kein "Schrott", wie Du schreibst, sondern Standard! Wir haben Sensoren aller erdenklichen Hersteller vermessen. Es gibt keinen einzigen, der völlig fehlerfrei ist und es kommt auch kein Hersteller, der völlige fehlerfreie Sensoren zusichern möchte. Zudem ist es so, dass die Sensoren im Laufe der Zeit auch noch welche hinzubekommen, daher macht es am Ende keinen Unterschied, ob er 40 oder 140 Fehler hat. Ein mir bekannter Hersteller für Consumer-Kameras lässt bei seinen Modellen der 2k-Klasse Fehler bis zu 10.000 zu. Allerdings bei einem 50M-Sensor. Die werden alle durch Einzelabgleich in der Kamera erfasst, im flash hinterlegt und beim Auslesen des Bildes weginterpoliert. Jeder mit einer für ihn optimierten Strategie. Heraus kommt ein lupenreines Rohbild. Auf das wird dann die Objektivkorrektur losgelassen und dieses ist es, was man als angebliches Rohdatenbild auf der SD-Karte findet. Die Objektivkorrektur muss zuerst erfolgen, bevor man hergeht und Bayer macht, weil dann falsche Farbinformationen eingetragen würden. Wenn Du erst ein Farbbild machst und dieses dann A-korrigierst, kriegst Du die intuitiven Farbsäume an den Rändern der SW-Übergänge. Und für all das MUSS das Objektiv bekannt sein. Wenn du es so handhabst, wie Du beschreibst, nämlich "die Kamera weiss nicht welches Objektiv verwendet wird" , dann hast Du keine Chance auf ein sinnvolles Bild.
Kamera-d schrieb: > Die Objektivkorrektur muss zuerst erfolgen, bevor man hergeht und Bayer > macht, weil dann falsche Farbinformationen eingetragen würden. Warum sollte das so sein? Ob Ich erst die fehlenden Farben rekonstruiere und dann deren Position, ist eigentlich egal. Interpolieren muss man so oder so. Und man muss ein bischen intelligent raten.
Also wenn das Ausmaß der Aberration mehre Pixel übersteigt, ist das schon ein Problem, weil die Interpolation meistens statisch mit einem definierten Feld, z.B. 7x7 oder 9x9 arbeitet. Dazwischen wird eine lineares Verhalten der Farbschwerpunkte angenommen.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.