• de
  • en
  • fr
  • it
  • cn
Home > Support > Glossar

Glossar

B

Bayer-Mosaic

Der Begriff Bayer-Mosaic wird oft in Verbindung mit Einchip-CCD-Sensoren verwendet, die einen Farbfilter aufgebracht bekommen. Dieser Filter bewirkt, dass einzelne Pixel unterschiedlich auf die Wellenlängen des Lichtes reagieren. Da zu jedem Bildpunkt nur eine Farbkomponente gegeben ist, muss man um ein RGB-Pixel zu erhalten, die fehlenden Farbkomponenten ermitteln.

Der angehängt Artikel erläutert, wie ein Bayer-Mosaic-Filter aufgebaut ist und welche Konvertierungsmethoden zu RGB möglich sind.

Bildfehler bei Sensoren

Aufgrund von zufälligen Prozessabweichungen können Sensorhersteller nicht garantieren, dass sich alle Pixel bei gleichen Bedingungen auch gleich verhalten. Obwohl die Sensorhersteller hierauf keinen Einfluss haben, wird von Bildfehlern gesprochen. Bekannt sind hierbei

  • Defekte Pixel,
  • Dunkelstrom und
  • Unterschiedliche Empfindlichkeit von Pixeln.

Mit unterschiedlichen Korrekturverfahren ist es möglich, diese Bildfehler einfach herauszurechnen. Das angehängte PDF beschreibt die Herkunft der einzelnen Fehlern und zeigt, wie man diese mithilfe von wxPropView korrigerieren kann.

Bildverarbeitungsstandards

Der angehängte Artikel erläutert die Consumer-Schnittstellen-Standards 

  • GenICam
  • GigE Vision
  • USB3 Vision

C

C-Mount 1" Zoll (inch) x 32 TPI UN 2A

Standard-Anschluss für Objektive an CCD-Kameras, mit einem einheitlichen Anschlussgewinde (am Objektiv: Außengewinde 1"-32UN-2A) mit einem einheitlichen Auflagenmaß von 17,526 mm.

Eine der bekanntesten Schnittstellen in der industriellen Bildverarbeitung ist CameraLink (CL). Spezifiziert für schnelle Bildübertragungen unterstützt die Schnittstelle zwischen 8 und 16 Bit Bitbreite pro Pixel sowie eine maximale Pixelfrequenz von 85 MHz.

CameraLink gibt es in drei Varianten:

  • BASE (maximal 24 Bit pro Takt)
  • MEDIUM (maximal 48 Bit pro Takt)
  • FULL (maximal 64 Bit pro Takt)

MATRIX VISION hat folgende CameraLink Frame Grabber im Portfolio:

Merkmale   mvGAMMA-CL mvTITAN-CL mvHYPERION-CLb mvHYPERION-CLe mvHYPERION-CLm mvHYPERION-CLf
Unterstützte Konfiguration 1x BASE ja ja ja ja ja ja
  2x BASE       ja ja  
  1x MEDIUM         ja ja
  1x FULL           ja
Treiber (mvIMPACT Acquire) Windows® XP, Vista, 7
32 / 64 Bit
XP, Vista, 7
32 / 64 Bit
XP, Vista, 7
32 / 64 Bit
XP, Vista, 7
32 / 64 Bit
XP, Vista, 7
32 / 64 Bit
XP, Vista, 7
32 / 64 Bit
  Linux®     32 / 64 Bit 32 / 64 Bit 32 / 64 Bit 32 / 64 Bit
Bus PCI 32 Bit / 33 MHz Rev. 2.1 32 Bit / 33 MHz Rev. 2.1        
  PCI Express®     x1 x1 x4 x4
Kontinuierliche Datenrate MB/s 95 100
mvTITAN-CL/110: 110
200 200 640 640
Max. Pixeltakt MHz 66 66 85 85 85 85
tl_files/mv11/images/info/powerovercameralink.jpg
      ja ja ja ja
CCD vs. CMOS

Es gibt zwei Sensortechnologien auf dem Markt: CCD und CMOS.

CCD-Sensoren haben in der Regel die bessere Bildqualität, ein geringeres Rauschen und keine Fehlpixel (Fixed Pattern Noise). CMOS-Sensoren sind dagegen günstiger und haben oft zusätzliche Eigenschaften, die in CCD-Technologie nicht integrierbar sind. Häufig zeichnen sich CCD-Sensoren durch eine höhere Dynamik aus; ein enormer Vorteil vor allem bei Applikationen mit großen Helligkeitsunterschieden. Ob ein Farb- oder ein Grau-Sensor zum Einsatz kommt, hängt meist von der zu erfüllenden Aufgabe ab. Manche Sensoren sind allerdings nur in der einen oder anderen Ausführung erhältlich. Farbsensoren haben vor der lichtempfindlichen Sensormatrix Farbfilterstrukturen, d.h. dass bestimmte Pixel nur Licht einer bestimmten Farbe aufnehmen. Diese Filterstrukturen sind durchlässig für IR-Licht. Um Farbverfälschungen bei Farbaufnahmen zu vermeiden, wird ein zusätzlicher IR- Sperrfilter gebraucht. Bei farbigen Objekten führt dessen Einsatz jedoch aufgrund des pixelweisen Farbwechsels zu einer geringeren Ortsauflösung. Ist eine hohe Farbgenauigkeit wie bei der Farbprüfung von Ausdrucken gefragt oder ist eine hohe farbliche Ortsauflösung nötig, so ist die Verwendung einer 3-Chip-Kamera sinnvoll, bei der für die Farben Rot, Grün, und Blau ein eigener Chip verwendet wird. Ein weiterer Gesichtspunkt ist der Verschluss (Shutter). CCD- und CMOS-Sensoren gibt es mit Global-Shutter (Full-Frame), einfache CMOS-Sensoren haben meist einen Rolling-Shutter. Letzteres führt bei Aufnahmen von schnell bewegten Objekten zu geometrischen Verzerrungen durch die Bewegung während der Belichtungszeit.

Merkmale CCD CMOS
Signal am Pixelausgang Elektronenpaket Spannung
Signal am Chipausgang Spannung (analog) Bits (digital)
Signal am Kameraausgang Bits (digital) Bits (digital)
Füllfaktor / Apertur Hoch Mittel
Verstärkungsstörungen Keine Mittel
Systemrauschen Niedrig Mittel
Systemkomplexität Hoch Niedrig
Sensorkomplexität Niedrig Hoch
Kamerakomponenten PCB + verschiedene Chips + Linse Chip + Linse
Forschungs- und Entwicklungskosten Anwendungsabhängig Anwendungsabhängig
Systemkosten Anwendungsabhängig Anwendungsabhängig
Leistung CCD CMOS
Reaktivität Mittel Etwas besser
Dynamik Hoch Mittel
Pixelgleichheit (Uniformität) Hoch Niedrig bis mittel
Uniforme Belichtungszeit Schnell, zusammen Schwach
Geschwindigkeit Mittel bis hoch Höher
Windowing Begrenzt Erweitert
Antiblooming Hoch bis gar nicht Hoch
Spannungsversorgung und Taktung Hohe Spannung, verschieden Niedrige Spannung, einfach

Kurz

CCD-Sensoren liefern die bessere Bildqualität, haben eine höhere Empfindlichkeit und Dynamik und eine synchrone Belichtungssteuerung aller Pixel, CMOS-Kameras sind meist kompakter, ermöglichen eine höhere Bildrate und sind erwas variabler einsetzbar.

CS-Mount 1" Zoll (inch) x 32 TPI UN 2A

Entspricht mit Ausnahme des Auflagemaßes dem C-Mount. Beim CS-Mount beträgt das Auflagemaß 12,5 mm. Der CS-Mount-Standard ist die "jüngere" Norm, die dem Wunsch nach kurzen Bauformen Rechnung trägt.

D

Dual-GigE

Aktuelle Schnittstellen wie GigE, USB 2.0, etc. haben eine natürliche Grenze: die Bandbreite. Diese Grenze verhindert schnellere Kameras mit höheren Auflösungen. Dual-GigE Kameras schaffen hier Abhilfe und bieten die doppelte Bandbreite (≤ 240 Mbyte) bei gleichzeitiger Transparenz in der Software, d.h., die Dual-GigE Kamera erscheint als ein Gerät. Hierbei ist keine neue Standardisierung oder Technik nötig. GigE Vision 2.0 definiert Dual-GigE und somit können diese Kameras auf einen etablierten und ausgereiften Standard zurückgreifen. Die einfachere Programmierung und der geringere Stromverbrauch im Vergleich zu 10-GigabitEthernet sowie die Möglichkeit bestehende Netzwerk-Infrastrukturen zu nutzen (10-GigabitEthernet Netzwerk-Infrastruktur sind noch nicht weit verbreitet und eine Umstellung noch teuer), machen diesen Entwicklungsschritt sinnvoll und sind weitere Vorteile von Dual-GigE auch im Vergleich zu anderen Schnittstellen wie USB3, CoaXPress und Camera Link HS.

G

GenICam
Ausschnitt einer GenICam Beschreibungsdatei (in XML)
Ausschnitt einer XML GenICam Beschreibungsdatei

GenICam steht für GEN eric programming I nterface for CAM eras und ist eine generische Schnittstelle, welche einen einheitlichen Zugriff auf Parameter von Geräten (bspw. Kameras) ermöglicht und eine Modifkation derer erlaubt. Ein GenICam konformes Gerät stellt eine GenICam Beschreibungsdatei zur Verfügung, die sich eventuell im lokalen Speicher des Geräts, lokal auf Festplatte oder auf einer Website befinden kann. Eine GenICam Beschreibungsdatei ist vergleichbar mit einem maschinenlesbaren Gerätehandbuch. Es stellt die lesbaren Namen und den Wertebereich von Parametern bereit, die das Gerät zum Lesen und Schreiben unterstützt, sowie eine Anleitung, welche Befehle an ein Gerät gesendet werden müssen, damit ein Parameter  geändert oder gelesen wird. Die Beschreibungsdateien sind XML-Dateien.

Weitere Informationen können Sie der Website http://www.genicam.org entnehmen.

GenTL

GenTL (Transport Layer) ist die Transport-Schicht des GenICam Standards und ist für den Transport der Kamera-Daten in die Benutzer-Anwendung verantwortlich.

GigE Vision

GigE Vision ist ein Netzwerk-Protokoll für die Kommunikation zwischen Bilderfassungsgerät und Anwendung. Das Protokoll deckt dabei folgende Funktionen ab:

  • Geräteerkennung
  • Datenübertragung
    • Bilddaten
    • zusätzliche Daten
  • Lesen / Schreiben von Parametern.

GigE Vision verwendet UDP für die Datenübertragung, was den Overhead im Vergleich zu TCP verringert.

Hinweis: UDP garantiert weder die Reihenfolge, wie Pakete ankommen, noch ob Pakete überhaupt beim Client ankommen. Jedoch bietet GigE Vision einen Mechanismus an, um verloren gegangene Pakete zu erkennen. Somit kann durch entsprechende Resend-Methoden im Treiber dem entgegengewirkt werden. Weitere Informationen erhalten Sie auf folgender Website: http://www.machinevisiononline.org/public/articles/index.cfm?cat=167

Alle MATRIX VISION GigE Vision Treiber-Lösungen stellen einen Resend-Mechanismus zur Verfügung, sodass verlorene Pakete erkannt werden und nahezu alle Daten rekonstruiert werden können. Dieser Mechanismus erweitert natürlich nicht die Bandbreite, daher kann es trotzdem vorkommen, falls die Übertragung zu lange überladen war, dass Pakete trotzdem verloren gehen.

Die Treiber von MATRIX VISION ermöglichen ein Fine-Tuning des Resend-Mechanismus und stellen Information über verlorene Daten sowie über die erneut angeforderten Daten bereit. Diese Informationen / Konfigurationen sind Teil des Treiber-SDKs. Weitere Informationen stehen in den jeweiligen Schnittstellen-Beschreibungen zur Verfügung.

H

High Dynamic Range

Der HDR-Modus (High Dynamic Range) dient der Erhöhung des nutzbaren Kontrastumfangs. Dies wird erreicht, indem die Integrationsphase in zwei bis drei Phasen aufgeteilt wird. Der Belichtungszeitanteil der drei Phasen kann dabei getrennt eingestellt werden. Ferner kann eingestellt werden, wie viel Signal innerhalb der jeweiligen Phase angesammelt wird.

Funktion

tl_files/mv11/images/support/faq/HDR_mode_01.gif

Abbildung 1: Diagramm zum HDR-Modus des Sensors -x00w

Beschreibung

  • Phase 0
    • Während T1 werden alle Pixel integriert, bis sie einen durch den 1. Knee-Point definierten Signalpegel erreicht haben.
    • Falls ein Pixel diesen Pegel erreicht, wird die Integration hier gestoppt.
    • Kein Pixel kann also während T1 einen Pegel größer P1 erreichen.
  • Phase 1
    • Während T2 werden alle Pixel integriert, bis sie einen durch den 2. Knee-Point definierten Signalpegel erreicht haben.
    • T2 ist immer kleiner als T1, sodass der prozentuale Anteil an der Belichtungszeit hier geringer ist.
    • Der Signalzuwachs ist somit während T2 geringer als während T1.
    • Der max. Signalpegel des 2. Knee-Points ist immer größer als beim 1. Knee-Point.
  • Phase 2
    • Während T3 werden alle Pixel bis zur evtl. Sättigung integriert.
    • T3 ist immer kleiner als T2, sodass der prozentuale Anteil an der Belichtungszeit hier noch geringer ist.
    • Der Signalzuwachs ist somit während T3 geringer als während T2.

Dies führt dazu, dass dunklere Pixel während der gesamten Belichtungszeit integrieren können und der Sensor hier seine volle Empfindlichkeit erreicht. Pixel, die an den jeweiligen Knee-Points limitiert werden, verlieren einen Teil ihrer Belichtungszeit - umso mehr, je heller sie sind.

tl_files/mv11/images/support/faq/HDR_mode_02.gif

Abbildung 2: Verlauf der Integration von unterschiedlich hellen Pixeln

In dem Diagramm sieht man den Signalverlauf von drei unterschiedlich hellen Pixeln. Die Steigung hängt nur von der Lichtintensität ab und ist somit hier pro Pixel immer gleich (bei angenommener, zeitlich konstanter Lichtintensität).
Da das sehr helle Pixel jedoch früh an den Signalschwellen S1 und S2 limitiert wird, ist seine gesamte Belichtungszeit geringer als beim dunkleren Pixel.
In der Praxis sind die Anteile der Belichtungszeit stark unterschiedlich. T1 ist zum Beispiel 95% von Ttotal, T2 nur noch 4% und T3 nur noch 1%. Dadurch wird eine starke Abschwächung von sehr hellen Pixeln erreicht. Gleichzeitig bedeutet dies, dass für eine Drittelteilung der Integrationsschwellen, d. h. S2 = 2 x S1 und S3 = 3 x S1, die hundertfache Helligkeit beim Sprung eines Pixels von S2 bis S3, gegenüber dem Sprung von 0 bis S1, benötigt wird.

Nutzung beim Produkten mit CMOS-Sensor -x00w

Abbildung 3 zeigt die Nutzung des HDR-Modus. Hier wurde eine Bildsequenz mit Belichtungszeiten von 10µs bis 100ms erzeugt. Man sieht die drei Steigungen des HDR-Modus. Die "Wellen" kommen von der Rundung der Belichtungszeit während der drei Belichtungsphasen. Diese können nämlich immer nur in Anteilen einer Zeilendauer des Sensors verstellt werden.

tl_files/mv11/images/support/faq/HDR_mode_03.gif

Abbildung 3: wxPropView HDR Screenshot

Hinweise zur Nutzung der mvBlueFOX-200w HDR-Modi

  • Im aktiven HDR-Modus wird die Grund-Verstärkung um ca. 0,7 reduziert, um einen großen, dynamischen Bereich des Sensors auszunutzen.
  • Wird der manuelle Gain angehoben, wird dieser Effekt wieder rückgängig gemacht.
  • Zu geringe Belichtungszeiten sind im HDR-Modus nicht sinnvoll. Wenn in der dritten Phase die Belichtungszeit den Bereich des möglichen Minimums erreicht (eine Zeilenzeit), ist hier eine sinnvolle untere Grenze erreicht.

Einstellungsmöglichkeiten beim mvBlueFOX-200w

HDREnable

  • Off : Std-Modus
  • On : HDR-Modus ein., Verstärkung reduziert
    • HDRMode:
      • Fixed: Fixe Einstellung mit 2 Knee-Points. Aussteuerung Phase 0 bis 33% / 1 bis 66% / 2 bis 100%
        • Fixed0: Phase 1 Belichtung 12,5% , Phase 2 31,25% der Gesamtbelichtung
        • Fixed1: Phase 1 Belichtung 6,25% , Phase 2 1,56% der Gesamtbelichtung
        • Fixed2: Phase 1 Belichtung 3,12% , Phase 2 0,78% der Gesamtbelichtung
        • Fixed3: Phase 1 Belichtung 1,56% , Phase 2 0,39% der Gesamtbelichtung
        • Fixed4: Phase 1 Belichtung 0,78% , Phase 2 0,195% der Gesamtbelichtung
        • Fixed5: Phase 1 Belichtung 0,39% , Phase 2 0,049% der Gesamtbelichtung
      • User: Variable Einstellung des Kneepoint (1..2), Schwellen und Belichtungszeitanteile
        • HDRKneePointCount: Anzahl Kneepoints (1..2)
        • HDRKneePoints
          • HDRKneePoint-0
            • HDRExposure_ppm: Anteile der Phase 1 an der Gesamtbelichtung in Parts Per Million (ppm)
            • HDRControlVoltage_mV: Steuerspannung für Belichtungsschwelle des ersten Knee-Points (3030mV entspricht ca. 33%)
          • HDRKneePoint-1
            • HDRExposure_ppm: Anteile der Phase 1 an der Gesamtbelichtung in Parts Per Million (ppm)
            • HDRControlVoltage_mV: Steuerspannung für Belichtungsschwelle des ersten Knee-Points (2630mV entspricht ca. 66%)
HRTC

MATRIX VISIONs Hardware Real-Time Controller kurz HRTC ist ein im FPGA der entsprechenden Kamera implementierter Bestandteil zur zeitkritischen I/O- und Erfassungssteuerung. Aufgrund dessen macht der HRTC in vielen Fällen eine SPS zur Kamera- und Prozesssteuerung überflüssig bzw. ersetzt diese.
Ein HRTC-Programm besteht aus einer Sequenz von Bearbeitungsschritten, die der Controller abarbeitet. Zur Erstellung der Sequenzen kann beispielsweise das GUI Tool wxPropView verwendet werden.

tl_files/mv11/images/support/faq/wxPropView_HRTC_programm.jpg

Abbildung 1: Eingabe eines Hardware Real-Time Controller Programms in wxPropView

Das Beispiel in Abbildung 1 zeigt, wie eine feste Bildfrequenz von 10 Bildern pro Sekunde in fünf Programmschritten erzielt werden kann.
Weitere Informationen finden Sie im Kapitel "HRTC - Hardware Real-Time Controller" des entsprechenden Produkthandbuchs (hier die mvBlueFOX).

Hinweis: Um den HRTC verwenden zu können, muss der korrekte Trigger-Modus (TriggerMode) sowie die korrekte Trigger-Quelle (TriggerSource) eingestellt sein (C++ Syntax):

CameraSettings->triggerMode = ctmOnRisingEdge
CameraSettings->triggerSource = ctsRTCtrl

In wxPropView:

tl_files/mv11/images/support/faq/wxPropView_HRTC_setting.jpgAbbildung 2: HRTC als Trigger-Quelle setzen

Einsatzgebiete und Anwendungen

Der Trend bei Digitalkameras führt zur Verwendung von Bussystemen wie IEEE1394, USB, Gigabit Ethernet, die nicht echtzeitfähig sind. Werden bei Applikationen mit digitalen Kameras trotzdem komplexe Trigger- und Blitzsteuerung benötigt, kommen Kameras mit I/O- und Triggereingängen zum Einsatz oder es müssen zusätzlich separate I/O-Karten genutzt werden. Durch die Verwendung einer I/O-Karte bleibt gleichwohl eine gewisse Unsicherheit aufgrund der Latenzzeit der Bussysteme vorhanden. Sinnvoller ist es daher, die echtzeit-relevanten Eigenschaften in die Kamera zu übertragen und dadurch das lokale System zu vereinfachen.
Denkbare Anwendungsmöglichkeiten (Auszug) sind:

  • >Erzeugung von Triggersignalen
  • Synchronisation mehrerer Kameras
  • Schnelle Erzeugung von Bildsequenzen mit unterschiedlichen Blitz- und Belichtungseinstellungen
  • Dunkel- und Hellbildaufnahmen zur Referenzbildsubstraktion
  • Belichtungssteuerung bei Bildern mit unterschiedlichen Wellenlängen (R/G/IR)

tl_files/mv11/images/support/faq/Server_camera_de.jpg

Abbildung 3: Verarbeitungskette vom Sensor bis zum Server: je mehr zwischengeschaltete Komponenten, desto größer der Reibungsverlust

Beispiel: Belichtungsverzögerung von nachfolgenden Kameras

Wird bei einer Anwendung eine Belichtungsverzögerung zwischen den einzelnen Kameras (hier die mvBlueFOX) benötigt, kann der HRTC die Synchronisation übernehmen.

In diesem Fall muss eine Kamera die Führung als Master übernehmen. Ein externes Triggersignal wird die Erfassung starten und muss an einen der digitalen Eingänge der Kamera angeschlossen werden. Ein digitaler Ausgang dieser Kamera muss an einen der digitalen Eingänge der Folgekamera angeschlossen werden usw. Somit triggert die Vorgängerkamera deren Nachfolger. Das Szenario sieht wie folgt aus:

tl_files/mv11/images/support/faq/HRTC_sample_connection.jpg

Abbildung 4: Anschlussbeispiel für definierte Verzögerungen

Ist das externe Triggersignal am digitalen Eingang 0 angeschlossen und der digitale Ausgang 0 am digitalen Eingang 0 der Folgekamera, dann sieht das HRTC-Programm der ersten Kamera wie folgt aus:

0. WaitDigin DigIn0->On
1. TriggerSet 0
2. WaitClocks <Triggertaktbreite>
3. TriggerReset
4. WaitClocks <delay time>
5. SetDigout DigOut0->On
6. WaitClocks 100µs
7. SetDigout DigOut0->Off
8. Jump 0

<Triggertaktbreite> sollte nicht kleiner als 100µs sein.

Falls die Kameras ihre Belichtung nach einer steigenden Flanke des Signals beginnen sollen, dann muss von der gewünschten Verzögerungszeit noch die <Triggertaktbreite> abgezogen werden. Bei jeder weiteren Kamera (bis auf die letzte), die gleich betrieben werden soll, kann das gleiche HRTC-Programm verwendet werden. Hierbei können die Verzögerungszeiten natürlich angepasst werden.

tl_files/mv11/images/support/faq/HRTC_sample_diagram.jpg

Abbildung 5: Verzögerung des Belichtungsstarts der nachfolgenden Kamera 

Produkte

Folgende Produkte besitzen einen HRTC:

I

Industrielle Bildverarbeitung

Unter "industrielle Bildverarbeitung" oder "digitale Bildverarbeitung" versteht man die digitale Verarbeitung von Bilddaten. Im Gegensatz zur manuellen Bearbeitung von Bildern bei der digitalen Bild-be-arbeitung gilt in der digitalen Bild-ver-arbeitung i. A. folgendes:

  • aus den Bilddaten werden bestimmte Merkmale zur Weiterverarbeitung oder Auswertung gewonnen
  • die Bilddaten werden oft nicht weiter benötigt und werden teilweise nicht einmal angezeigt
  • die Aufnahme und Verarbeitung erfolgt automatisiert nach vordefinierten Verfahren und Abläufen in geschlossen Systemen
  • die Komplexität der Algorithmen erfordert teilweise besondere Hardware zur Verarbeitung der Bilddaten

Einsatzgebiete und Anwendungen

Nachfolgend sind einige Beispielanwendungen aus verschiedenen Einsatzgebieten aufgeführt:

Automatisierung, Industrie

  • Prüfung von Werkstücken auf Maßhaltigkeit, Vollständigkeit
  • Prüfung von Oberflächen auf korrekten Druck, Fehlerfreiheit
  • Bestückungskontrolle von Leiterplatten
  • Steuerung und Überwachung von Materialflüssen
  • Visualisierung von Prozessabläufen in einer Leitstelle

Mikroskopie (Medizin, Forschung)

  • Verbesserung und Auswertung von lichtmikroskopischen Aufnahmen
  • Erfassung und Berechnung von elektronenmikroskopischen Bildern
  • Gewinnung von Laserscan-Aufnahmen z.B. bei der Augenheilkunde

Medizin

  • Augendiagnose (s.o.)
  • Klassifizierung von Brandwunden
  • Erfassung von Zahnprofilen

Sicherheitstechnik

  • Komprimierung und Aufzeichnung von Bildsequenzen in Banken, Tankstellen
  • Auswertung von Objekten im Bild (Videosensorik)
  • Infrarot-Kameratechnologie
  • Aufzeichnung von Vorgängen am Bankautomaten

Verkehrstechnik

  • Überwachung, Zählung und Steuerung von Verkehrsflüssen
  • Parkhausgebührenabrechnung über Kennzeichen-OCR
  • Kameras im Kfz : Abstandsmessung, elektr. Rückspiegel, Verkehrszeichenerfassung
  • Überwachung/Überprüfung von gefährdeten Elementen (Flugzeugturbinen)

Handel

  • Leergutkontrolle
  • Ermittlung von Käuferströmen zur Steuerung des Personaleinsatzes

M

MARTIX VISION SDKs / Schnittstellen

mvSDK

  • älteste Schnittstelle
  • hardwarenah
  • Gestaltung zeitintensiv
  • pro Hardwarefamilie eigene Treiber-DLL
  • nicht objektorientiert
  • aktiver Support ist eingestellt

mvAcquireControl

  • Nachfolger von mvSDK
  • basiert auf grabber.dll (im Hintergrund läuft mvSDK)
  • C und C++ Schnittstelle für Anwender verfügbar
  • aktiver Support ist eingestellt 

mvIMPACT Acquire

  • aktuelle Schnittstelle seit 2004
  • nicht kompatibel zu mvSDK oder mvAcquireControl
  • objektorientiert
  • C und .NET Wrapper für Anwender verfügbar
  • Anwendungen mit mvIMPACT Acquire kompatibel zu allen Produktfamilien
MvIMPACT Acquire

mvIMPACT Acquire ist die aktuelle Programmierschnittstelle für MATRIX VISION Hardware. Eine Vielzahl aktueller Sprachen wird unterstüzt, u.a.:

  • C,
  • C++,
  • C# und
  • VB.NET

R

Rolling Shutter

Die von MATRIX VISION bei Industriekameras sowie intelligenten Kameras verwendeten CMOS-Sensoren verfügen zum Teil über einen Rolling-Shutter, zu Deutsch etwa "rollender Verschluss". Dies bedeutet, dass die Belichtung der Zeilen eines Bildes zu unterschiedlichen Zeitpunkten startet bzw. endet (siehe Abbildung 1).

tl_files/mv11/images/support/faq/Rolling_shutter_01.gif

Abbildung 1: Belichtung der Zeilen startet und endet unterschiedlich

Die Abbildung 1 ist in zwei Seiten aufgeteilt. Die linke Seite zeigt zwei Zustände eines Sensors mit einem Zeilenblock, der sich über den Sensor schiebt. Der weiß dargestellte Bereich stellt die lichtempfindliche Fläche dar. Diese schiebt sich zeilenweise von oben nach unten durch das Bild. Stellt man z. B. die Belichtungszeit von 100 Zeilen ein, dann ist dieser Bereich 100 Zeilen hoch. Schiebt sich das Integrationsfenster in die nächste Zeile, muss die Zeile zunächst gelöscht werden ("Reset line", in der Abbildung 1 blau dargestellt). Am oberen Rand des Fensters wird die Zeile, nachdem diese schon 100 Zeilen lang belichtet wurde, ausgelesen ("Read line", in der Abbildung 1 rot dargestellt). Jede Zeile ist entsprechend der eingestellten Integrationszeit offen, allerdings findet die Belichtung zeitversetzt statt. Die rechte Seite der Abbildung 1 versucht dies, mit einem Zeilen/Zeit-Diagramm zu verdeutlichen. Zeile für Zeile verschiebt sich zeitlich der Start der Belichtung ("Exposure time"), d. h. im Diagramm nach rechts. Die rechte Seite der Abbildung verdeutlicht ferner die Phasen der Bilderfassung des Rolling-Shutters. Jede Zeile vollzieht einen Löschvorgang ("Reset sequence"), eine Belichtungsphase ("Exposure time") und eine Transferphase ("Transfer time"). Der Start der Transferphase der ersten Zeile und das Ende der Transferphase der letzten Zeile bestimmen die Bildrate ("Frame rate"). Kurz:

  
                       1
Bildrate = ------------------------
           Transferzeit * Bildhoehe

 

Ist die Belichtungsphase länger als die Transferphase, so wird in der Formel zum Berechnen der Bildrate die Transferzeit durch die Belichtungszeit ersetzt.

Aufnahme-Effekte bei horizontaler Bewegung

Bei einer horizontalen Bewegung eines Objektes ergibt sich bei der Bildaufnahme eine Bildverschiebung. Abbildung 2 zeigt, wie ein Objekt sich von links nach rechts bewegt. Die "rollende Aufnahme" des Sensors, welcher zur Veranschaulichung nur aus drei Zeilen besteht, bekommt durch die zeitversetzte zeilenweise Erfassung nur Teile des Objekts an anderer Position mit. Das Bild der zusammengefügten Aufnahme offenbart die Bildverschiebung. Durch die Bewegung des Objekts kommt es zu einer kleinen Unschärfe.

tl_files/mv11/images/support/faq/Rolling_shutter_02.gif

Abbildung 2: Bildverschiebung bei horizontaler Objektbewegung

Betrachtet man nun die zeilenweise Bewegung des beobachteten Objektes, ist es erstaunlich, wie kurz der zurückgelegte Weg ist.
Als Beispiel: Bei einem Rolling-Shutter-Sensor mit einer Höhe von 480 Pixel und einer Bildrate von 30Hz (30 Bilder pro Sekunde) legt ein Objekt mit einer Geschwindigkeit von 10 Metern pro Sekunde (36 km/h) pro Zeilenwechsel einen Weg von nur 0,694 Millimetern zurück.
Pro Sekunde werden 14400 Zeilen ausgelesen:

  
                                            Zeilen
Ausgelesene Zeilen = 30Hz * 480 Zeilen = 14400 ------
                                              s

Daraus ergibt sich alle 0,0000694 Sekunden ein Zeilenwechsel:

  
                  1
Zeilenwechsel = ----- = 0,0000694 s
                14400

Ist das Objekt nun 10 m/s schnell, wird ein Weg pro Zeilenwechsel von 0,694mm zurückgelegt:

  
s = v * t 
        m
s = 10 --- * 0,0000694 s
        s
s = 0,000694 m = 0,694 mm

Aus diesem Grund lässt sich ein Rolling-Shutter-Sensor ideal für Bewegungsanalysen mit hohen Frameraten verwenden.

Aufnahme-Effekte bei vertikaler Bewegung

Bei einer vertikalen Bewegung eines Objektes ergibt sich bei der Bildaufnahme je nach Bewegungsrichtung eine Stauchung oder eine Streckung. In Abbildung 3 bewegt sich ein Objekt vertikal entgegen der Aufnahmerichtung des Sensors, welcher zur Veranschaulichung nur aus drei Zeilen besteht. Dies bewirkt, wie das Bild der zusammengefügten Aufnahme beweist, dass ein Objekt gestaucht wird.

tl_files/mv11/images/support/faq/Rolling_shutter_03.gif

Abbildung 3: Stauchung bei vertikaler Objektbewegung

Der Rolling-Shutter-Effekt kann positiv genutzt werden. Die zeilenweise Integration vermindert bei schnell bewegten Objekten die Bewegungsunschärfe. Infolgedessen kann mit einer doppelten Integrationszeit gearbeitet werden.

tl_files/mv11/images/support/faq/Rolling_shutter_04.gif

Abbildung 4: Verminderte Bewegungsunschärfe mit Rolling-Shutter

Blitzsteuerung bei CMOS-Sensoren mit Rolling-Shutter

Die Blitzsteuerung eines CMOS-Sensors mit einem Rolling-Shutter unterliegt Einschränkungen. Damit alle Zeilen gleichzeitig geblitzt werden können, muss die Belichtungszeit ("Exposure time") ausreichend lang sein, sodass sich die belichteten Zeilen überlappen (siehe Abbildung 5 "All row integration"). Der Blitzzeitpunkt muss im Bereich der "All row integration" liegen und die Blitzzeit darf nicht länger als "All row integration" sein.

tl_files/mv11/images/support/faq/Rolling_shutter_05.gif

Abbildung 5: Möglicher Blitzbereich

Bei dieser Vorgehensweise muss beachtet werden, dass während der Belichtung ("Exposure time") der Zeilen kein Fremdlicht vorhanden ist.

S

Smear-Effekt (CCD)

Der Smear-Effekt ist ein bekanntes Phänomen bei CCD-Sensoren, bei dem es beim vertikalen Verschieberegister zu einer  Überbelichtung kommt. Durch schnelleres Verschieben zwischen Leerlauf und Belichtung, kann der Smear reduziert werden. MATRIX VISION bietet einen schnellen Verschiebe-Modus an: mvSmearReduction. 

Die angehängte Application Note beschreibt das Phänomen und den mvSmearReduction Modus.

SNFC

Standard Feature Naming Convention von GenICam.

Die aktuellste GenICam Eigenschaften-Liste wird auf folgender Internetseite zur Verfügung gestellt: http://www.emva.org/genicam/genicam%E2%84%A2_document_download

Die Datei heißt "GenICam™ Standard Features Naming Convention (PDF)".

U

USB vs. Firewire

Als Ersatz für analoge Kameras mit Frame Grabber auf PC-Basis haben sich inzwischen viele digitale Kameras mit unterschiedlichen Schnittstellen-Standards auf dem Bildverarbeitungsmarkt positioniert. Während am oberen Ende des Leistungsspektrums noch spezielle Frame Grabber-Lösungen benötigt werden, breiten sich im unteren Bereich vor allem die kostengünstigen USB 2.0- und FireWire-Lösungen aus.

Warum haben wir uns bei der Wahl der Schnittstelle unserer Industriekamera für USB entschieden?

Die USB-Technik bietet im Vergleich zu FireWire einige Vorteile:

  • Die USB-Schnittstelle ist an jedem aktuellem Laptop, PC und vielen embedded Industriesystemen vorhanden.
  • Die USB-Schnittstelle garantiert eine gesicherte Übertragung.
  • Die Bandbreitenzuteilung ist dynamisch (Im Gegensatz zu DCAM [1894-based Digital Camera Specification], bei der isochron gearbeitet wird).

Welche Vorteile bietet mir speziell die industrielle USB 2.0 Kamera mvBlueFOX von MATRIX VISION?

Neben den allgemeinen Vorteilen der USB-Schnittstelle und einer einfachen Handhabung besitzt die mvBlueFOX zusätzliche Vorteile:

  • Die Kameras ermöglichen mittels HRTC (Hardware Real-Time Controller) eine flexible digitale I/O-Steuerung.
  • Flexible Triggermöglichkeiten sind vorhanden.
  • Die Kameras unterstützen eine dynamische Kamerasteuerung (Parameterwechsel "on-the-fly").
  • Jedes Bild kann mit eigenen Parametern angefordert werden.
  • Ein industrieller USB-Anschluss ist verfügbar.Die Kameras werden über die USB-Schnittstelle mit Strom versorgt.
  • Die CCD-Sensors werden justiert. Damit wird eine Positionsgenauigkeit von unter einem Prozent erreicht.
  • Die Kameras sind als OEM-Module erhältlich.
  • Benutzerdaten können auf der Kamera abgespeichert werden.
  • Die Treiber sind leistungsfähig und stellen viele Bildverarbeitungsfunktionalitäten zur Verfügung.
  • Eine einheitliche Treiberarchitektur für alle MATRIX VISION Produkte (Frame Grabber, Kameras) und zukünftige Produkte von MATRIX VISION ist vorhanden.
  • Die Treiber sind für Linux verfügbar (auch für Embedded Systeme wie ARM, PPC usw.).
USB3 Vision

USB3 Vision ist ein Standard in der Bildverarbeitungsindustrie, welcher die Kommunikation zwischen Bilderfassungsgerät und Anwendung über USB 3.0 regelt. Das Protokoll deckt dabei folgende Funktionen ab:

  • Geräteerkennung
  • Datenübertragung
    • Bilddaten
    • zusätzliche Daten
  • Lesen / Schreiben von Parametern.