Synthetische Bilddaten für das Training von Bildverarbeitungsmodellen (seltene Defekte, Grenzfälle)

Modelle für die Sichtprüfung brauchen viele beschriftete Beispiele von Defekten, doch gut laufende Produktionslinien erzeugen wenige Defekte, und gerade die seltenen sind am wichtigsten. Generative Modelle (Diffusion, GAN, steuerbares Inpainting) und prozedurales 3D-Rendering können aus wenigen echten Proben realistische, automatisch beschriftete Defektbilder erzeugen. Sorgfältig eingesetzt und an echten zurückgehaltenen Daten validiert, senkt das die Zahl der benötigten echten Defektbilder und beschleunigt die Inbetriebnahme von Prüfsystemen.

Problem & Nutzen

• Heute: Qualitätsteams warten Monate, bis genug Defektbilder gesammelt sind, oder beschriften sie von Hand. Für seltene Defektklassen (Risse, Verunreinigungen, das Kratzermuster eines neuen Lieferanten) und neue Produkt- varianten gibt es kaum Daten. Die Modelle übersehen dann genau diese Defekte oder erzeugen Fehlausschuss.
• KI-Nutzen: Defekte mit kostenlos erzeugten Masken auf Gutteile einmalen (Inpainting) oder rendern, Variationen bei Licht/Pose/Material abdecken und Klassenhäufigkeiten ausgleichen. Industrieanbieter berichten, dass Prüfmodelle mit erzeugten Defekten aus kleinen echten Probensätzen trainiert werden können [1][2]; akademische Arbeiten zur Erzeugung von Defektbildern zeigen Gewinne vor allem bei knappen echten Daten [3].
• Ehrliche Einordnung: Synthetische Daten ergänzen echte Daten; sie ersetzen keinen echten Validierungsdatensatz. Die Gewinne hängen vom Domain Gap ab, und es sollte keine allgemeine Zahl angenommen werden. Messen Sie an Ihren eigenen Teilen.

Varianten

• Defekt-Inpainting auf echten Gutteilen: Ein Diffusionsmodell mit Maskensteuerung fügt Kratzer, Dellen, Flecken in echte Bilder ein (in der Fertigung am häufigsten).
• Prozedurales 3D-Rendering: CAD + physikalisch basiertes Rendering mit Domain-Randomisierung (Licht, Pose, Textur); die Beschriftungen sind exakt. Eingesetzt für Montageprüfungen (VIS-002), Logistik, Robotik.
• Few-Shot-Defektsynthese: ein kleines LoRA/einen Adapter auf 10-50 echten Defekt-Ausschnitten feintunen.
• Generierung von Grenzfall-Szenen: seltenes Wetter, Lichtverhältnisse, Verdeckungen für Wahrnehmung im Automobil- und Drohnen- bereich; Video-Weltmodelle erzeugen Fahr- oder Baustellenszenarien.
• Medizin, Landwirtschaft/Lebensmittel, private Nutzung: seltene Pathologien, Fremdkörper oder Hobby-Datensätze; synthetische seltene Pathologien oder Zellbilder (stark forschungslastig; strenge Validierung).

So funktioniert es

1. real samples (good + few defects) + defect taxonomy + CAD (optional)
2. generator choice (inpainting | LoRA-tuned diffusion | procedural render | GAN)
3. controlled generation (mask/position/size/severity prompts, ControlNet-style conditioning)
4. automatic labels (mask
5. box/class) + quality filters (realism score, duplicate, plausibility)
6. human expert review of a sample (is this defect physically possible and correctly named?)
7. train detector/segmenter/anomaly model on real + synthetic mix
8. validate ONLY on held-out real images (domain-gap check)
9. iterate

• Generatoren: latente Diffusion mit Inpainting und struktureller Konditionierung (ControlNet, Tiefe, Kanten), GAN-Varianten für schmale Texturen, Rendering-Engines mit Randomisierung.
• Übertragung der Beschriftungen: Die erzeugte Maske definiert die Beschriftung, daher sinken die Annotationskosten; prüfen Sie die Randgenauigkeit, denn weiche Diffusionsränder können die tatsächliche Ausdehnung verschieben.
• Mensch-in-der-Schleife (Human-in-the-Loop): Qualitätsingenieure geben Defektdefinitionen frei und prüfen Stichproben; echte Validierungsbilder werden nie in synthetische Trainingspools gemischt.

Datenaufbereitung

Die Daten sind der schwierige Teil. Echte Defekt- und Gutteilbilder liegen auf Prüf-PCs, in Kamerasystemen, MES-/QMS-Datenbanken, auf USB-Sticks und in Qualitätsberichten; CAD-Modelle stammen aus PLM oder von Dateiablagen. Defektinformationen stehen oft nur in Freitext-Reklamationsdatensätzen oder auf Papier.

Typische Lücken: sehr wenige Defektbeispiele, uneinheitliche Kameraeinstellungen, fehlende oder widersprüchliche Beschriftungen, Duplikate, kein Defektkatalog mit abgestimmten Klassendefinitionen und kein sauberer zurückgehaltener echter Validierungsdatensatz. Die Zugriffsrechte sind auf Produktion, Qualität und Lieferanten verstreut.

Aufbereitungsschritte: (1) Bildquellen inventarisieren und mit Zeitstempeln, Linien- und Teile-IDs exportieren; (2) Defektklassen mit dem Qualitätspersonal definieren und die Beschriftungsrichtlinie festlegen; (3) mit Fachleuten ein kleines Gold-Set beschriften; (4) vor jeder synthetischen Erzeugung einen echten Validierungsdatensatz abtrennen und nie einmischen; (5) die Herkunft jedes synthetischen Bildes protokollieren; (6) Beschriftungen nach Möglichkeit aus vorhandenen Qualitätsaufzeichnungen gewinnen. Werkzeuge: CVAT oder Label Studio, DVC zur Versionierung, Blender oder Omniverse zum Rendern.

Grober Aufwandsanteil: 50 bis 60 Prozent des Projekts. Siehe PREP-018 zu Evaluierungsdatensätzen, PREP-019 zu Kategorienschemata, PREP-020 zur Gewinnung von Beschriftungen und PREP-005 zum Herauslösen von Daten aus Altsystemen.

Umsetzungswege

Welcher Weg für wen

• smb: Weg B, weil der Generator zu den eigenen Teilen, Kameras und Defektklassen passen muss und kein Standardprodukt dies für Kleinserien abdeckt.
• enterprise: Weg C, weil Produktionsbilder Betriebsgeheimnisse sind, das Volumen hoch ist und eine gemeinsame interne ML-Plattform Diffusion und Rendering auf HW2 und darüber betreiben kann.
• developer: Weg C, weil offene Diffusionsmodelle, Blender und ähnliche Werkzeuge volle Kontrolle über Beschriftungen und Domain-Gap-Experimente geben.

Weg A - Kaufen (Standardsoftware)

• Prüfplattformen mit integrierter Synthese: UnitX (GenX / Defekterzeugung) [1], Overview.ai (Defect Creator) [2], dazu allgemeine Plattformen wie Landing AI LandingLens, Cognex (z. B. ViDi/In-Sight), Zebra Aurora, MVTec HALCON (EU, Deutschland), Neurocle, Sualab.
• Dienste für synthetische Daten: Partner von NVIDIA Omniverse Replicator, Unity Computer Vision; EU: Anyverse (Spanien, Automobil-/Sensorsimulation). Anbieter für Tabellendaten gehören zu DATA-005.
• A wählen, wenn: Sie ein Prüfsystem wollen und kein ML-Team haben; EU-Hosting und On-Premises-Option für Bilder Ihrer Produkte (Betriebsgeheimnisse) prüfen.

Weg B - Auf Cloud-KI-Diensten aufbauen

• Bildmodelle mit Inpainting-/Bearbeitungs-APIs: Black Forest Labs FLUX (EU-Unternehmen, FLUX Fill / Kontext zur Bearbeitung) [4], Stability AI Stable-Diffusion-Familie, Google Imagen/Gemini-Bildbearbeitung, OpenAI-Bildbearbeitung, Adobe Firefly (kommerziell unbedenkliche Trainingsdaten) für nicht-technische Inhalte.
• Pipeline: Cloud-Speicher in einer EU-Region, Orchestrierung mit Python/Airflow, ein VLM (Claude, Gemini, Mistral, GPT) als „Richter“, der unrealistische oder falsch beschriftete Ausgaben markiert, dann Training auf Azure ML, Vertex AI oder SageMaker (EU-Regionen).
• Prüfen: Lizenzbedingungen für erzeugte Ausgaben, kein Training des Anbieters mit Ihren Bildern, Kosten pro Bild bei 10^4-10^5 Bildern.
• B wählen, wenn: schnelle Piloten, vielfältige Produkte, kein GPU-Team.

Weg C - Selbst betreiben (Open Source)

• Modelle: FLUX.1 [dev] / Fill mit offenen Gewichten (nicht-kommerzielle Lizenz, kommerzielle Bedingungen prüfen [4]), Stable Diffusion 3.5 / SDXL (Community-Lizenz), diffusers-Bibliothek mit ControlNet- und Inpainting- Pipelines [5]; Segmentierung mit SAM 2 zur Maskenverfeinerung; Detektoren über Ultralytics YOLO (AGPL), RT-DETR, Anomalie-Bibliotheken wie Anomalib (Intel, Apache-2.0) [6].
• Prozedural: Blender (BlenderProc [7]), NVIDIA Omniverse Replicator [8], NVIDIA Isaac Sim, Unity Perception.
• Hardware: HW2 (GPU mit 24-32 GB) für Inpainting und LoRA-Feintuning von SDXL-Klasse und FLUX quantisiert; HW3 für FLUX in voller Präzision bei hohem Volumen; Rendering profitiert von RTX-GPUs.

Weg D - Eigenes Training

Lohnt sich bei einer wiederkehrenden Produktfamilie und einem stabilen Defektkatalog. Ein Diffusionsmodell oder LoRA auf 20-500 echten Defekt-Ausschnitten je Klasse (von Fachleuten beschriftet) feintunen oder ein bedingtes GAN für schmale Texturen trainieren. Einen sauberen echten Testdatensatz bewahren; jeden synthetischen Stapel mit Generatorversion, Seed und Prompts nachverfolgen.

Stand der Technik (2026)

• Maskenkonditioniertes Diffusions-Inpainting ist der praktische Standard; es übertrifft ältere GANs bei Realismus und Vielfalt. Neuere Arbeiten zur Defekterzeugung konzentrieren sich auf Few-Shot-, maskenausgerichtete Erzeugung und auf die Überprüfung, ob der Defekt der Zielklasse gleicht [3].
• Prozedurales Rendering mit Domain-Randomisierung bleibt dort am stärksten, wo Geometrie und exakte Beschriftungen zählen (Montage, Robotik, Logistik); generative Modelle verbessern den Texturrealismus.
• Welt-/Videomodelle (z. B. NVIDIA Cosmos [8]) dienen dazu, Fahr- und Roboterszenen um unterschiedliche Bedingungen zu erweitern; die Ausgaben brauchen weiterhin eine Validierung mit echten Daten.
• Alternativen: Anomalieerkennung (PatchCore-Familie, Anomalib [6]) braucht nur Gutbilder und kann den Bedarf an Defektdaten ganz senken; synthetische Anomalien speisen auch diese Verfahren.
• Grenzen und Fehlerbilder: physikalisch unmögliche Defekte; Beschriftungsrauschen an Maskenrändern; Mode Collapse und geringe Vielfalt; das Modell lernt Artefakte des Generators („Shortcut Learning“) und schneidet auf synthetischen Bildern gut, auf echten schlecht ab; Verzerrung durch die wenigen Seeds, die über Tausende Bilder kopiert werden; Benchmark-Gewinne auf Datensätzen wie MVTec AD garantieren keine Leistung an der Linie.

Gemeinsame Bausteine & Kombinationen

• Gleicher Stack (Bildgenerierung + Segmentierung + Objekterkennung): GEN-011 Bildbearbeitung und Inpainting, GEN-008 3D-Asset-Erzeugung (CAD-/Asset-Quellen zum Rendern), GEN-001 Produktbilder.
• Abnehmer: VIS-001 (Prüfung), VIS-002 (Montage), VIS-056 (Wafer-Karten), VIS-057 (additive Fertigung), VIS-043 (Abwasserkanäle); ROBO-010 (Simulation für Robotertraining).
• Abgrenzung: DATA-005 behandelt synthetische Tabellen-/Textdaten; dieser Eintrag behandelt die Synthese auf Bildebene.

Aufwand, Kosten & Kennzahlen

• Weg A: Wochen; Lizenz je Linie/Kamera, oft im Prüfsystem enthalten.
• Weg B: 1-3 Monate für einen Piloten; die Kosten der Bilderzeugung sind meist klein gegenüber GPU-Training und dem Zeitaufwand für die Prüfung durch Fachleute.
• Weg C: 2-4 Monate; eine GPU-Workstation, ML-Ingenieur, Zeit eines Qualitätsingenieurs für die Prüfung.
• Kennzahlen: Recall seltener Defekte auf dem echten Testdatensatz, Fehlausschussrate, Zahl der echten Defektbilder, die für einen Ziel-Recall nötig sind, Zeit bis zur Inbetriebnahme einer neuen Produktvariante, Anteil der von Prüfern abgelehnten erzeugten Bilder, Domain Gap (synthetischer vs. echter Wert).

Menschen & Veränderung

Beziehen Sie die Geschäftsleitung für Budget und Risikobereitschaft ein, die Qualitäts- oder Produktionsleitung als Prozessverantwortliche, die Prüfer, die die Defekte kennen und die Ergebnisse validieren, die IT für GPU und Speicher sowie die Dateneigner der Bild- und CAD-Quellen. Recht bzw. Compliance sollte Lieferantenverträge und Kundenvertraulichkeit prüfen, denn Produktionsbilder gehören oft dem Kunden.

Betriebsrat: in der Regel keine Mitbestimmung, da das Erzeugen von Trainingsbildern keine Beschäftigten überwacht (§87 Abs. 1 Nr. 6 BetrVG); es wird relevant, wenn Bilder Arbeitende zeigen oder später in eine Leistungsbeurteilung einfließen. Der Betriebsrat ist über geplante KI-gestützte Arbeitsabläufe rechtzeitig zu informieren (§90 Abs. 1 Nr. 3) und kann einen KI-Sachverständigen hinzuziehen (§80 Abs. 3). Eine DSFA ist selten nötig; prüfen Sie dies, wenn Bilder Personen zeigen könnten, und fragen Sie die bzw. den Datenschutzbeauftragten.

KI-Kompetenz: Schulen Sie das Qualitätspersonal zu Domain Gap, Verzerrung synthetischer Daten und dazu, warum die echte Validierung verpflichtend bleibt (Art. 4 KI-Verordnung: Maßnahmen zur Förderung der Kompetenz). Beginnen Sie als Pilot mit einer Defektklasse an einer Linie. Typische Sorge: „Synthetische Daten machen die Prüfung unzuverlässig“. Begegnen Sie dem mit einem dokumentierten Vergleich auf echten Testdaten und einem Go/No-go-Gate. Menschen verantworten die Defektdefinitionen und Freigabeentscheidungen.

Siehe GUIDE-009 zu Piloten, GUIDE-003 zur Datenreife und GUIDE-008 zur Akzeptanz.

Risiken, Regulierung & Compliance

• KI-Verordnung (AI Act): typischerweise minimales Risiko bei der Qualitätsprüfung. Es wird hochriskant, wenn das Modell eine Sicherheitskomponente eines Produkts nach Rechtsvorschriften des Anhangs I ist (z. B. Maschinen, Medizinprodukte, Fahrzeuge) oder in kritischer Infrastruktur eingesetzt wird; dann gilt Art. 10 Daten-Governance, einschließlich der Dokumentation der Datenherkunft und der Prüfung auf Verzerrungen, was zur Herkunftsdokumentation synthetischer Daten passt [9]. Die Kennzeichnungspflichten nach Art. 50 betreffen Inhalte, die Menschen gezeigt werden (Deepfakes); interne Trainingsbilder fallen meist nicht darunter, kennzeichnen Sie sie aber trotzdem als synthetisch. Art. 4 KI-Kompetenz gilt für das Personal.
• DSGVO: Auf Teilebildern sind meist keine personenbezogenen Daten; sie entstehen bei Bildern von Arbeitenden, Gesichtern, Kfz-Kennzeichen oder Patienten. Verwenden Sie keine auf echten Gesichtern feingetunten Generatoren ohne Rechts- grundlage; bei medizinischen Daten Anonymisierung und DSFA anwenden. Erzeugte Bilder, die Trainings- beispiele auswendig lernen, können personenbezogene Daten preisgeben.
• Geistiges Eigentum und Lizenzen: Modelllizenzen (FLUX dev nicht-kommerziell, SD Community), Urheberrecht an Trainingsdaten in Generatoren, CAD-Daten und Betriebsgeheimnisse von Kunden - nicht an externe APIs senden.
• Sicherheitsrisiko: Zu großes Vertrauen in synthetische Gewinne kann zu übersehenen echten Defekten in sicherheitskritischen Teilen führen.
• Gegenmaßnahmen: echter zurückgehaltener Testdatensatz aus der Produktion, gestufter Rollout im Schattenbetrieb, Drift- Überwachung, Datensatzkarten mit Generatorversion und Anteil synthetischer Daten, Freigabe durch Fachleute.

Erste Schritte

1. Defektklassen und die Kosten übersehener Defekte definieren; vorhandene echte Proben sammeln und einen echten Validierungsdatensatz festlegen, der nie für die Erzeugung verwendet wird.
2. Eine Baseline nur auf echten Daten trainieren (oder ein Anomaliemodell wie PatchCore über Anomalib).
3. 500-2000 Defektbilder je Klasse per maskengeführtem Inpainting erzeugen; einen Qualitätsingenieur 5-10 % prüfen lassen.
4. Mit mehreren Verhältnissen von echten zu synthetischen Daten neu trainieren; auf dem echten Testdatensatz vergleichen und das Verhältnis behalten, das hilft.
5. Die Herkunft dokumentieren und im Schattenbetrieb laufen lassen, bevor es an die Linie freigegeben wird.

Quellen

1. UnitX - synthetic defect generation (GenX) - https://www.unitxlabs.com/
2. Overview.ai - Defect Creator - https://overview.ai/
3. Zhang et al. - "DefectGAN: Synthesizing Data for Industrial Defect Inspection" and later diffusion-based defect generation (arXiv) - https://arxiv.org/abs/2103.01593
4. Black Forest Labs - FLUX models and licensing - https://bfl.ai/ and https://huggingface.co/black-forest-labs
5. Hugging Face Diffusers - inpainting and ControlNet - https://huggingface.co/docs/diffusers
6. Anomalib (open-edge-platform) - https://github.com/open-edge-platform/anomalib
7. BlenderProc - https://github.com/DLR-RM/BlenderProc
8. NVIDIA - Omniverse Replicator and Cosmos - https://developer.nvidia.com/omniverse/replicator and https://github.com/nvidia-cosmos
9. Regulation (EU) 2024/1689 (AI Act), Art. 10 and Art. 50 - https://eur-lex.europa.eu/eli/reg/2024/1689/oj