scene op• Datenarten: table → pairs
• Aufruf: import fullseye as fs; fs.ledger.light_wavelengths(light: 'dict', samples: 'int' = 5) (die Implementierung direkt: import optscene; optscene.light_wavelengths(light: 'dict', samples: 'int' = 5); aus dem Register: opsoptics.get("light_wavelengths"))
Reduziert das Spektrum einer Quelle auf die wenigen Wellenlängen und Gewichte, die für die Abbildung genutzt werden.
Laser = 1 Linie, LED = einige schmalbandige Linien, Halogen = einige breitbandige Linien. Selbst bei derselben Oberfläche ändert sich die Aufteilung zwischen spiegelnd und gestreut mit der Wellenlänge, daher wird breitbandiges Licht korrekt durch Überlagerung aufgenommen.
Vorgehen: light["wavelength_nm"] (550, falls fehlend) ist das Zentrum λ, light["bandwidth_nm"] (0, falls fehlend) die volle Breite bw, und k = max(samples, 1) Linien werden äquidistant über λ ± bw/2 gelegt. Die Gewichte sind gaußförmig exp(-0.5 (2x)^2) (x ist die auf [-1, 1] normierte Position, die Enden liegen bei 2σ) und so normiert, dass ihre Summe 1 ist. Bei bw <= 0 (Laser) oder k == 1 eine einzige λ mit Gewicht 1.
• light: das Ergebnis von light_spec (ein dict). Fehlende Schlüssel nehmen Default-Werte an (ist es kein dict, ValueError; das verhindert, dass eine Zeilenliste der Sorte table hineinläuft).
• samples: Anzahl der Linien. Default 5. Werte unter 1 werden auf 1 gesetzt. Eine ungerade Zahl enthält die Zentralwellenlänge.
• Rückgabewert: (wavelengths (k,), weights (k,)), 2 float64-Arrays. Eine Näherung, die die reale Spektralform (Asymmetrie der LED, Schwarzkörperverteilung des Halogens) nicht nachbildet.
layout_capture ruft dies mit spectral_samples Linien auf und summiert die Ergebnisse je Wellenlänge mit diesen Gewichten.
Jeder optics-Operator prüft seine Eingabe vor der Berechnung (nichts rutscht stillschweigend durch):
• Einheiten stecken im Argumentnamen — _mm / _um / _deg / _mrad. Eine Verwechslung von mm und µm stürzt nicht ab, sondern liefert eine plausibel aussehende falsche Antwort; der Name verhindert das. Aus der Größenordnung wird nie auf die Einheit geschlossen.
• Strings lösen ValueError aus — float('50') gelingt, sodass ein ungeparster Konfigurationswert als Länge durchrutschen würde (gemessen: thin_lens('50', '200') lieferte plausible 66,667 mm). bool wird als implizite Hochstufung True == 1 ebenfalls abgelehnt.
• complex / Masked Arrays lösen ValueError aus (nur reelle Slots; das stille Verwerfen des Imaginärteils bzw. Abstreifen der Maske wird abgelehnt). NaN/Inf löst bei jeder Eingabe ValueError aus.
• Division durch null und Verwandtes wird namentlich abgelehnt: Brennweite 0, Krümmungsradius 0, Brechzahl <= 0, undurchlässige Blende (alles 0, die Normierung wird 0/0), PSF mit Summe <= 0, Stokes-Vektor mit S0 = 0 und ein Objekt im vorderen Brennpunkt (Bild im Unendlichen).
• Nur zwei Operatoren liefern einen nicht-endlichen Wert, und beide halten das vertraglich fest: depth_of_field liefert jenseits der hyperfokalen Distanz far_mm = inf (genau das bedeutet die hyperfokale Distanz), und gaussian_beam liefert an der Taille wavefront_radius_mm = inf (der Krümmungsradius einer ebenen Wellenfront). Beide liefern zusätzlich einen endlichen Partner (far_is_infinite / curvature_per_mm). Jedes andere stille NaN/Inf wird intern erkannt und löst ValueError aus — "float64 ist übergelaufen" und "die Antwort ist unendlich" sind verschiedene Aussagen; die erste wird nie im Gewand der zweiten geliefert.
• Größenobergrenzen: erzeugte Gitter durch optics.MAX_GRID (4096), übergebene Felder/PSFs/Blenden durch optics.MAX_FIELD_ELEMENTS (2^24), ABCD-Elementketten durch optics.MAX_SYSTEM_ELEMENTS (1024), Zernike durch MAX_ZERNIKE_TERMS (512) / MAX_ZERNIKE_ORDER (40) / MAX_ZERNIKE_BASIS (2^25). Damit werden Pfade fail-closed geschlossen, in denen ein kleines Argument eine riesige interne Allokation auslöst (gemessen: n_max=40 × 4096² braucht 108 GB).
• Physikalisch unmögliche Zustände werden ebenfalls abgelehnt: Stokes-Vektor mit Polarisationsgrad > 1, negative Transmission, negative Intensität und ungültige Zernike-Indizes wie ungerades n-|m|.
• Leitfaden zur Familie optics_imaging
• dataset_conventions — Konventionen für Trainingsdatensätze — COCO / YOLO / VOC und Fallstricke in der Sichtprüfung
• mv_cameras — Hersteller von Industriekameras (Sensorzuordnung, Zeilenkamera / TDI)
• mv_illumination_practice — Beleuchtung in der Praxis — Wellenlänge, Polarisation, Ansteuerung, Fremdlicht, Sicherheit
• mv_image_sensors — Industrielle Bildsensoren (vorwiegend aktuelle Produkte)
• virtual_machine_vision — Virtuelle Bildverarbeitung — Parameter erfassen und Objektmodell
• Katalog der Beispieldaten (Download-URLs / Lizenzen) — 2-D nutzt skimage.data (BSD/Public Domain) plus synthetische Bilder, 3-D nennt Download-URLs echter Datenquellen (Stanford, PDS, …).
• Herkunft und Literatur der Operatoren — die Quellen der Forschung/Verfahren, auf denen diese Operatorfamilie beruht.
• Der kanonische Algorithmus (Autor, Jahr) und seine Anwendungen stehen im Familienleitfaden oben.
• vision_layout_from_catalog — py -3.11 examples/vision_layout_from_catalog.py
pairs als Eingabe)scene)scene_material · scene_plane · scene_sphere · scene_box · scene_cylinder · surface_defect · surface_finish · random_defects
*Provenance: optscene.py — OPTICS Operator-Registry. Diese Notiz wird von tools/opdocs.py md erzeugt (nicht von Hand bearbeiten).*
© 2026 Kazufumi Furuse — Fullseye operator documentation. Licensed under Apache-2.0.