Bildverarbeitung ist kein Monolith
Viele Bildverarbeitungsprojekte entstehen zunächst als Proof-of-Concept – oft mit einer einzelnen Bildquelle, ein paar vordefinierten Verarbeitungsschritten und direkter Anzeige des Ergebnisses. Das mag für einfache Aufgaben ausreichen, führt in der Praxis aber schnell zu unübersichtlichem, schlecht testbarem Code. Sobald mehrere Bilderquellen, unterschiedliche Analysepfade oder anpassbare Parameter hinzukommen, wächst die Komplexität exponentiell – und aus einem einfachen Pipeline-Skript wird ein unbeherrschbarer Monolith.
Wer Anwendungen für die Industrie entwickelt, kennt die Anforderungen: Der Prozess muss nachvollziehbar, erweiterbar und robust sein – nicht nur unter Laborbedingungen, sondern im 24/7-Einsatz. Genau hier zahlt sich ein modularer Aufbau der Bildverarbeitungspipeline aus. Jeder Verarbeitungsschritt wird als eigenständige, wiederverwendbare Komponente implementiert, die ihre Aufgabe isoliert und nachvollziehbar erledigt. Das erlaubt nicht nur gezieltes Testen und Debugging, sondern auch dynamische Konfiguration, Live-Visualisierung und
Was eine saubere Bildverarbeitungspipeline ausmacht
Eine funktionierende Bildverarbeitungslösung ist nicht automatisch gut strukturiert. Was im Testlauf oder während der Entwicklung mit einem verketteten Ablauf von Methoden noch beherrschbar wirkt, skaliert in einem realen Anwendungskontext oft nicht. Eine saubere Bildverarbeitungspipeline zeichnet sich nicht durch die Anzahl der Filter oder Algorithmen aus, sondern durch ihren strukturellen Aufbau und die Fähigkeit, Änderungen kontrolliert und mit minimalem Risiko umzusetzen.
Grundlegend ist die Trennung in klar definierte Verarbeitungsschritte. Jeder Schritt hat eine eindeutig beschriebene Aufgabe – beispielsweise das Laden eines Bildes, die Konvertierung in ein bestimmtes Format, die Normalisierung von Kontrasten, die Extraktion von Kanten oder die Berechnung geometrischer Merkmale. Diese Schritte sollen voneinander unabhängig bleiben, sowohl im Hinblick auf Code als auch auf Datenfluss. Nur so lassen sie sich testen, isoliert austauschen oder in anderer Reihenfolge verwenden. Die Kopplung zwischen den Modulen muss minimal bleiben: Der Output des einen Schritts ist der definierte Input des nächsten, idealerweise in Form eines strukturierten Objekts (z. B. einer eigenen Bildstruktur oder Analyseklasse).
Ein weiteres Merkmal robuster Pipelines ist die Möglichkeit zur Visualisierung, Protokollierung und Parametersteuerung auf Schrittbasis. Statt eine komplexe Bildverarbeitung als Blackbox zu behandeln, sollte jeder Verarbeitungsschritt in der Lage sein, seine Eingaben, Ausgaben und Kennzahlen bereitzustellen – sei es zur Laufzeit, im Debug-Modus oder im Logfile. Nur mit dieser Transparenz lässt sich das System im Betrieb überwachen und bei Fehlern gezielt analysieren.
Besonders in industriellen Anwendungen ist außerdem entscheidend, dass jeder Schritt unabhängig von einer konkreten Hardwareumgebung funktioniert. Das bedeutet: Der Einstiegspunkt in die Pipeline – das Bild selbst – muss abstrahiert sein. Eine Pipeline, die ein Mat-Objekt oder ein HImage verarbeitet, aber nicht weiß, ob es von einer Kamera, aus einer Datei oder aus einem Netzwerkstream stammt, bleibt universell einsetzbar. Die Quelle wird durch ein separates Interface gekapselt. Das ermöglicht das Austauschen von Kameras, Simulieren von Bilddaten und Testen mit Referenzbildern – ohne Änderungen am Pipelinecode.
Eine weitere zentrale Anforderung ist die Stabilität gegenüber ungültigen oder variierenden Eingabedaten. Jeder Schritt muss entweder selbst für Vorbedingungen sorgen oder auf nicht erfüllte Annahmen explizit reagieren. Das betrifft z. B. Bildauflösung, Farbkanäle oder das Vorhandensein bestimmter Objekte. Fehlertoleranz und kontrolliertes Abbrechen einzelner Schritte sind essenziell, um Gesamtausfälle zu verhindern und Fehler reproduzierbar zu machen.
Pipeline-Grundstruktur in C#
Damit eine Bildverarbeitungspipeline modular und erweiterbar bleibt, muss ihre Struktur auf klaren Schnittstellen basieren. Ziel ist es, Verarbeitungsschritte so zu kapseln, dass sie sich wie Bausteine zusammenfügen lassen – unabhängig davon, ob sie mit Emgu CV, Halcon oder einem eigenen Algorithmus arbeiten. Jeder Schritt sollte eine definierte Aufgabe übernehmen und dabei ein strukturiertes Eingabe- und Ausgabeformat verwenden, etwa ein Bildobjekt, eine Zwischenstruktur oder ein Analyseergebnis.
Ein gängiger Ansatz ist es, eine generische Schnittstelle für Verarbeitungsschritte zu definieren. Diese nimmt ein Eingabeobjekt entgegen und liefert ein Ergebnisobjekt zurück. Ein einfaches Beispiel für Bild-zu-Bild-Transformationen könnte so aussehen:
public interface IImageStep
{
Mat Process(Mat input);
}
Ein konkreter Schritt, zum Beispiel ein Graustufenfilter, implementiert diese Schnittstelle direkt:
public class GrayscaleStep : IImageStep
{
public Mat Process(Mat input)
{
var output = new Mat();
CvInvoke.CvtColor(input, output, ColorConversion.Bgr2Gray);
return output;
}
}
Die einzelnen Schritte lassen sich in einer zentralen Pipeline-Klasse ausführen. Diese verwaltet die Reihenfolge und reicht die Ausgaben eines Schritts direkt an den nächsten weiter:
public class ImagePipeline
{
private readonly List<IImageStep> _steps = new();
public void AddStep(IImageStep step) => _steps.Add(step);
public Mat Execute(Mat input)
{
var current = input;
foreach (var step in _steps)
{
current = step.Process(current);
}
return current;
}
}
Ein Vorteil dieses Ansatzes ist, dass sich Verarbeitungsschritte dynamisch zusammensetzen lassen – zur Laufzeit, per Konfiguration oder zur Testzwecken. Jeder Schritt kann für sich allein getestet werden, besitzt keine globale Abhängigkeit und kennt nur sein definiertes Eingabeformat. Neben der Mat-basierten Version lassen sich auch Varianten für Halcon HImage oder eigene Bildstrukturen definieren, indem man die Schnittstelle generisch macht oder mehrere Pipelines parallel betreibt.
Zur Erweiterung können Decorators eingesetzt werden, um Logging, Visualisierung oder Timing-Informationen an einzelnen Schritten zu erfassen – ohne den Kernalgorithmus zu verändern. Auch die Wiederverwendung einzelner Module in verschiedenen Pipelines wird dadurch möglich, ohne Seiteneffekte befürchten zu müssen.
Emgu CV: Praxiseinstieg mit Beispielschritten
Emgu CV ist ein .NET-Wrapper für OpenCV und eignet sich besonders gut für performante Bildverarbeitung in C#. Die Bibliothek bietet direkten Zugriff auf die umfangreiche Funktionalität von OpenCV – von der Bildvorverarbeitung über Feature-Detection bis zur Objektverfolgung. In Kombination mit einer modularen Pipeline-Architektur lassen sich komplexe Analyseketten übersichtlich und testbar abbilden. Die folgenden Beispiele zeigen exemplarisch, wie man einzelne Verarbeitungsschritte als eigenständige IImageStep-Implementierungen umsetzt.
Der Einstiegspunkt ist ein Bild, das entweder von einer Kamera, aus einer Datei oder einem Netzwerkstream stammt. In der Pipeline liegt es in Form eines Mat-Objekts vor. Der erste Schritt ist häufig eine Konvertierung in ein Grauwertbild, da viele Algorithmen auf Intensitätswerten basieren:
public class GrayscaleStep : IImageStep
{
public Mat Process(Mat input)
{
var output = new Mat();
CvInvoke.CvtColor(input, output, ColorConversion.Bgr2Gray);
return output;
}
}
In vielen Fällen folgt auf die Graustufenumwandlung ein Weichzeichner, etwa um Rauschen zu reduzieren oder Kanten homogener zu gestalten. Dafür bietet sich ein Gauß-Filter an:
public class GaussianBlurStep : IImageStep
{
private readonly Size _kernelSize;
private readonly double _sigma;
public GaussianBlurStep(Size kernelSize, double sigma)
{
_kernelSize = kernelSize;
_sigma = sigma;
}
public Mat Process(Mat input)
{
var output = new Mat();
CvInvoke.GaussianBlur(input, output, _kernelSize, _sigma);
return output;
}
}
Nach der Glättung kann die Kantenextraktion erfolgen, etwa mit dem Canny-Algorithmus. Auch dieser wird in einen isolierten Schritt gekapselt, was das Testen mit parametrisierten Grenzwerten erleichtert:
public class CannyEdgeStep : IImageStep
{
private readonly double _threshold1;
private readonly double _threshold2;
public CannyEdgeStep(double threshold1, double threshold2)
{
_threshold1 = threshold1;
_threshold2 = threshold2;
}
public Mat Process(Mat input)
{
var output = new Mat();
CvInvoke.Canny(input, output, _threshold1, _threshold2);
return output;
}
}
Alle diese Schritte lassen sich zur Laufzeit beliebig kombinieren. So kann etwa eine typische Emgu CV-Pipeline wie folgt aufgebaut werden:
var pipeline = new ImagePipeline();
pipeline.AddStep(new GrayscaleStep());
pipeline.AddStep(new GaussianBlurStep(new Size(5, 5), 1.0));
pipeline.AddStep(new CannyEdgeStep(100, 200));
var input = CvInvoke.Imread("sample.jpg", ImreadModes.Color);
var result = pipeline.Execute(input);
CvInvoke.Imshow("Result", result);
CvInvoke.WaitKey(0);
Jeder dieser Schritte ist unabhängig, wiederverwendbar und einfach testbar. Zusätzliche Visualisierungen oder Performance-Messungen können über Decorators ergänzt werden, ohne den Schritt selbst zu verändern. Auch die Parameter der einzelnen Module lassen sich gezielt konfigurieren oder während der Laufzeit aktualisieren – z. B. aus einer externen Konfigurationsquelle oder über eine Benutzeroberfläche.
Halcon: Integration und Kontrast zu Emgu CV
Während Emgu CV direkt auf OpenCV basiert und eher low-level arbeitet, bietet Halcon eine deutlich höhere Abstraktion – insbesondere im Bereich der Objektanalyse, Merkmalsextraktion und industriellen Bildverarbeitung. Halcon verfolgt ein deklaratives Paradigma: Statt einzelne Pixel zu manipulieren, arbeitet man mit Operatoren, Regionen und Symbolik. Das verändert die Struktur der Verarbeitungsschritte grundlegend – nicht im Sinne ihrer Funktion, aber in der Art, wie Ergebnisse erzeugt, weitergegeben und verwendet werden.
Ein typischer Verarbeitungsschritt in Halcon besteht nicht nur aus einem Funktionsaufruf, sondern oft aus einer Sequenz logisch zusammenhängender Operationen. Diese lassen sich ebenso in einem modularen Pipelineansatz kapseln, indem man eigene Klassen als IImageStep-Implementierungen für HImage oder strukturierte Zwischenergebnisse schreibt. Beispielhaft kann ein Thresholding-Schritt zur Segmentierung heller Objekte so umgesetzt werden:
public class ThresholdStep : IHalconImageStep
{
private readonly int _minGray;
private readonly int _maxGray;
public ThresholdStep(int minGray, int maxGray)
{
_minGray = minGray;
_maxGray = maxGray;
}
public HImage Process(HImage input)
{
var region = input.Threshold(_minGray, _maxGray);
var result = input.PaintRegion(region, new HTuple(255), "fill");
return result;
}
}
Wie bei Emgu CV bleibt auch hier die Regel erhalten: Jeder Schritt verarbeitet seine Eingabe, liefert eine neue Ausgabe und bleibt in sich abgeschlossen. Das erleichtert spätere Modifikationen, etwa durch Ersetzen des Thresholdings durch eine adaptive Variante, ohne die restliche Pipeline verändern zu müssen.
Halcon erfordert in der Regel eine genauere Behandlung von Objekten, Regionen und Konturen. Ein Beispiel für eine Objektdetektion auf Basis geometrischer Merkmale könnte auf eine Regionserkennung, anschließendes Blob-Labeling und danach eine Merkmalsfilterung hinauslaufen. Auch diese Schritte lassen sich in einzelne Pipelinekomponenten auslagern – mit klaren Input- und Outputtypen, z. B. in Form von HRegion-Listen oder strukturierten Analyseobjekten.
Im Vergleich zu Emgu CV ist Halcon oft weniger imperativ. Viele Funktionen erzeugen neue Objekte, statt bestehende zu verändern. Dadurch wird das Erstellen unveränderlicher Pipelines erleichtert, die sich deterministisch ausführen und validieren lassen – ein großer Vorteil in produktionskritischen Anwendungen mit Versionierung oder Offline-Simulationen.
Auch wenn Halcon und Emgu CV unterschiedliche Paradigmen verfolgen, lässt sich der grundlegende Pipeline-Ansatz problemlos auf beide Technologien anwenden. Entscheidend ist, dass die einzelnen Schritte jeweils innerhalb ihres Frameworks abgeschlossen sind und nur über definierte Schnittstellen miteinander kommunizieren. Der Wechsel von Emgu CV zu Halcon (oder umgekehrt) in einzelnen Schritten bleibt damit technisch isoliert und damit langfristig wartbar.
Kombinierte Pipelines: Halcon und Emgu CV mischen
In vielen industriellen Anwendungen ist es sinnvoll, Halcon und Emgu CV nicht als Alternativen, sondern als sich ergänzende Werkzeuge zu verwenden. Während Halcon durch seine integrierten Operatoren, robuste Geometrieanalyse und Hardwareintegration punktet, bietet Emgu CV deutlich mehr Flexibilität beim direkten Zugriff auf Pixeldaten, insbesondere für Vorverarbeitung, benutzerdefinierte Filter oder komplexe Matrizenoperationen. Um beide Frameworks innerhalb derselben Pipeline nutzen zu können, müssen Bilddaten in geeigneter Form konvertierbar und die Verarbeitungsschritte klar voneinander abgegrenzt sein.
Der Schlüssel zur Integration ist eine zentrale Definition des Bildformats, das als Austauschformat zwischen den Frameworks dient. In der Praxis bedeutet das: Die Pipeline kennt nicht nur Schritte, die mit Mat oder HImage arbeiten, sondern abstrahiert den Datentyp über Schnittstellen oder Wrapper. Eine mögliche Strategie besteht darin, ein eigenes Interface IImageData einzuführen, das sowohl Mat als auch HImage einkapseln kann. Konvertierungslogik wird in dedizierten Klassen gekapselt, um Fehler durch implizite Annahmen zu vermeiden.
Ein Beispiel: Emgu CV übernimmt die Bildvorverarbeitung – etwa Normalisierung, Glättung, Histogrammangleichung. Danach wird das Bild in ein Halcon-kompatibles Format überführt und zur Form- oder Merkmalsanalyse an Halcon weitergereicht. Die Konvertierung erfolgt explizit, beispielsweise so:
public static class ImageConverter
{
public static HImage ConvertMatToHImage(Mat mat)
{
Bitmap bitmap = mat.ToBitmap();
return new HImage(bitmap);
}
public static Mat ConvertHImageToMat(HImage hImage)
{
Bitmap bmp = hImage.ToBitmap();
return bmp.ToMat();
}
}
Alternativ zur Konvertierung über Bitmap ist unter bestimmten Voraussetzungen auch ein direkter Zugriff auf den Speicherbereich möglich. Sowohl OpenCV als auch Halcon können mit einer identischen Pixelstruktur im Speicher arbeiten, wenn die Bilddaten im 8-Bit-Graustufen- oder RGB-Format vorliegen und korrekt ausgerichtet sind. In diesem Fall lässt sich ein Bild mit beiden Frameworks parallel verwenden – ohne zusätzliche Kopiervorgänge. Das spart Performance und Speicher, insbesondere bei hochauflösenden Bilddaten.
Halcon erlaubt die Initialisierung eines HImage direkt aus einem Zeiger auf ein bestehendes Datenarray, z. B. aus einem Mat-Objekt von Emgu CV. Voraussetzung ist, dass die Speicherstruktur und der Zugriff konsistent sind. Das folgende Beispiel zeigt, wie man ein OpenCV-Mat direkt an Halcon übergibt:
public static HImage WrapMatAsHImage(Mat mat)
{
IntPtr dataPtr = mat.DataPointer;
int width = mat.Width;
int height = mat.Height;
int stride = mat.Step;
// Achtung: Nur für Graustufenbilder oder 3-Kanal RGB geeignet
return new HImage("byte", width, height, dataPtr);
}
Diese Methode erzeugt keinen neuen Bildspeicher, sondern weist Halcon an, auf die vorhandenen Pixeldaten im Speicher des Mat zuzugreifen. Der Vorteil: Die Verarbeitung durch beide Bibliotheken kann direkt auf denselben Bilddaten basieren. Der Nachteil: Änderungen an den Bilddaten müssen sorgfältig koordiniert werden, da beide Frameworks auf dieselbe Speicherstelle zugreifen. In sicherheitskritischen oder threadbasierten Anwendungen empfiehlt sich daher weiterhin eine explizite Kopie.
Damit Halcon- und Emgu CV-Schritte in einer gemeinsamen Pipeline koexistieren können, müssen sie getrennte Pipelinesegmente bilden, die durch eine Übergabe konnektiert sind. Diese Übergabe kann über eine dedizierte Schnittstelle oder ein gemeinsames Modellobjekt erfolgen. Wichtig ist, dass jeder Schritt klar angibt, welches Datenformat er erwartet und liefert. Dadurch bleiben auch gemischte Pipelines stabil und langfristig wartbar – selbst wenn einzelne Framework-Versionen oder Operatoren ausgetauscht werden müssen.
In der Praxis ergibt sich daraus ein hybrides Modell: Emgu CV wird für schnelle, flexible Vorverarbeitung eingesetzt, Halcon übernimmt die strukturierte, hochrobuste Analyse. Die Trennung der Verantwortung spiegelt sich direkt im Code wider – und ermöglicht es, die Stärken beider Werkzeuge gezielt zu kombinieren, ohne die Wartbarkeit der Anwendung zu gefährden.
Erweiterbarkeit: Logging, Live-View, Parameter-Tuning
Eine gute Bildverarbeitungspipeline endet nicht bei der korrekten Abarbeitung ihrer Schritte. In produktionsnahen Anwendungen muss sie sich auch zur Laufzeit beobachten, justieren und debuggen lassen – ohne den eigentlichen Code zu verändern. Erweiterbarkeit ist dabei kein nachträgliches Feature, sondern ein struktureller Aspekt: Logging, Visualisierung und Parametrisierung müssen von Anfang an mitgedacht, aber konsequent von der Verarbeitung getrennt werden.
Ein häufiger Anwendungsfall ist die protokollierte Ausführung jedes Verarbeitungsschritts. Statt Log-Ausgaben direkt im Schritt zu platzieren, bietet sich ein Decorator-Muster an. Dabei wird der Schritt nicht verändert, sondern durch eine Hülle ergänzt, die vor und nach der Ausführung Logik einfügt – etwa zur Zeitmessung oder zur Ausgabe des aktuellen Status.
public class LoggingImageStep : IImageStep
{
private readonly IImageStep _inner;
private readonly ILogger _logger;
public LoggingImageStep(IImageStep inner, ILogger logger)
{
_inner = inner;
_logger = logger;
}
public Mat Process(Mat input)
{
_logger.Log($"Executing step: {_inner.GetType().Name}");
var result = _inner.Process(input);
_logger.Log($"Completed step: {_inner.GetType().Name}");
return result;
}
}
Mit dieser Technik lässt sich die gesamte Pipeline zur Laufzeit vollständig transparent machen – ohne die Algorithmen selbst anzufassen. Das gilt auch für Performance-Messung, Bild-Zwischenspeicherung oder das automatische Speichern von Zwischenergebnissen für spätere Fehleranalysen. Jeder Schritt bleibt testbar und isoliert, während die Erweiterungen über externe Schichten kontrolliert werden.
Ein zweites zentrales Thema ist die Visualisierung: Entwickler, Tester oder Maschinenbediener wollen häufig einen Zwischenstand der Verarbeitung sehen – etwa nach der Kantenextraktion oder Segmentierung. Auch hier ist die Trennung zwischen Berechnung und Anzeige wichtig. Die Visualisierung erfolgt nicht im Schritt selbst, sondern durch eine Komponente, die Bilddaten an ein Frontend oder ein Logging-Interface weiterleitet. In einer WPF-Anwendung könnte dies ein IImageSink-Interface übernehmen, das für jeden Schritt registriert ist und die Ergebnisse asynchron anzeigt.
Besonders im Kontext der Parametrisierung wird die strukturelle Trennung entscheidend. Wer seine Schritte so modelliert, dass Parameter zur Laufzeit austauschbar sind – etwa über IConfigurableStep mit einem Configure()-Aufruf oder über Dependency Injection mit IOptions<T> – kann dieselben Module in unterschiedlichen Kontexten wiederverwenden: mit festen Parametern im Livebetrieb, konfigurierbar im Debug-Modus, oder automatisch angepasst im Trainingsprozess.
Ein typischer Anwendungsfall wäre ein ThresholdStep, dessen Grenzwerte während der Laufzeit über eine GUI angepasst werden können. Der Schritt selbst bleibt unverändert, reagiert aber auf veränderte Eingaben aus der Konfigurationsquelle. Dieses Prinzip erlaubt iteratives Tuning im Livebetrieb – etwa beim Kalibrieren einer Kamera oder beim Anpassen an wechselnde Lichtverhältnisse – ohne Neucompilierung oder Neustart.
Diese Trennung von Funktion, Kontrolle und Anzeige ermöglicht es, dieselbe Pipeline in Entwicklung, Produktion und Simulation zu betreiben – mit unterschiedlichen Aufrufen, aber identischer Logik. Erweiterbarkeit entsteht also nicht durch zusätzliche Features, sondern durch Struktur: Jeder Schritt tut exakt das, was er soll – nicht mehr und nicht weniger – und lässt sich beliebig beobachten, parametrisieren und erweitern.
Testing und Simulation einzelner Schritte
Eine saubere Pipeline-Architektur entfaltet ihren Nutzen erst dann voll, wenn jeder Verarbeitungsschritt unabhängig getestet werden kann. Gerade in der Bildverarbeitung ist es entscheidend, einzelne Module auch ohne vollständiges Kamerasystem, Lichtsetup oder externe Abhängigkeiten prüfen zu können – sei es während der Entwicklung, im CI-Prozess oder zur gezielten Fehleranalyse im Betrieb.
Der zentrale Ansatz besteht darin, jedem Schritt ein konstantes Eingabeformat zu garantieren. Wenn ein Schritt mit einem Mat oder HImage arbeitet, dann muss es möglich sein, dieses Bild auch unabhängig vom eigentlichen Kamera-Input bereitzustellen – etwa aus Testdaten, Dateien oder simulierten Inputs. Der Schritt kennt weder die Quelle noch das Ziel, sondern verarbeitet nur das, was ihm übergeben wird.
Für Unit Tests lassen sich gezielt Bilder aus einem Resources-Ordner laden oder synthetisch erzeugen. Beispielhaft kann ein einfacher Canny-Edge-Detection-Step wie folgt getestet werden:
[Fact]
public void CannyStep_Should_DetectEdges()
{
var input = CvInvoke.Imread("test_images/sharp_edges.png", ImreadModes.Grayscale);
var step = new CannyEdgeStep(50, 150);
var result = step.Process(input);
Assert.NotNull(result);
Assert.Equal(input.Size, result.Size);
}
Einzelne Schritte mit Analysefunktion – etwa Objektzählung, Formklassifikation oder Regionsanalyse – können zusätzlich mit Referenzbildern und erwarteten Ergebnissen verglichen werden. Eine ShapeAnalyzer-Klasse, die bestimmte Konturen extrahiert, kann in der Testumgebung gezielt gegen gespeicherte Erwartungswerte laufen – etwa die Anzahl der gefundenen Objekte, deren Größe oder Position.
Zur Fehlerreproduktion in laufenden Systemen empfiehlt sich die Speicherung von Input- und Outputdaten jedes Schritts im Fehlerfall. Wenn ein Modul ein leeres Ergebnis liefert oder abstürzt, können die zugehörigen Bilddaten versioniert gespeichert und später lokal im Debug-Modus reproduziert werden. In Verbindung mit Logging-Decorators und Dateinamenskonventionen lässt sich daraus eine automatische Reproduktionsum
