Der Anwendungsfall: vom Foto zur neuen Beleuchtung
Wir entwickeln eine PhotoCraft-Verarbeitungskette aus vorhandenen Fotos, Netzvorbereitung, UV-Projektion, Blender-Szene, Beleuchtung und Bildprüfungen. Verarbeitungsschritte werden auf drei lokalen Rechnern ausgeführt. Die Integration und die Bewertungsverfahren sind in Entwicklung. Dieser Beitrag beschreibt eine Iteration, kein bereits gesichertes industrielles Ergebnis.
Ein Foto enthält bereits Reflexionen und Schatten. Wird es auf Geometrie projiziert und erneut beleuchtet, können sich zwei Beleuchtungen überlagern. Eine teilweise verdeckte Fläche kann zudem eine Textur erhalten, die beim Drehen der Kamera doppelt erscheint. Ein besserer Prompt löst dieses Problem nicht allein.
Der Harness: ein überprüfbarer Ausführungsrahmen
Der Harness bildet den Rahmen des Agenten: erlaubte Werkzeuge, Kontext, Anweisungen, Ausführung, Protokolle und Prüfungen. Für eine Bildverarbeitungskette muss dieser Rahmen auch Eingaben, Skript- und Modellversionen, Parameter, erwartete Ausgaben und Abbruchbedingungen festlegen.
Eine Versuchskennung verbindet Quelldateien, Prüfsummen, Einstellungen und Ergebnisse. Eine Skriptkopie auf einem anderen Rechner muss vor dem Rendervergleich geprüft werden. Sonst kann ein Versionsunterschied als algorithmische Verbesserung erscheinen. Diesen Rahmen für reproduzierbare Versuche bauen wir um die Entwicklung auf.
CPU-Prüfungen — und Tests für die Prüfungen
Mit CPU-Judge meinen wir hier eine berechnete, reproduzierbare Prüfung, getrennt von der Einschätzung eines Sprachmodells. In der beobachteten Iteration werden unter anderem erhaltene Pixel im Referenzwinkel, Doppelungen, unbekannte Bereiche und Textverformungen erfasst.
Ein Modell kann einen Fehler entdecken oder eine Korrektur vorschlagen. Für die Freigabe müssen jedoch Bilder, Messungen und Kontrollfälle herangezogen werden. Ein absichtlich verschlechtertes Netz ist aufschlussreich: Bewertet die Prüfung es fast gleich wie das korrigierte Netz, trennt sie die Fälle nicht ausreichend.
Ein gemessener Fortschritt mit Gegenwirkung
Bei demselben Versuch bei +10° sinkt der interne Doppelungsindikator von 5,06 % auf 1,72 %. Gleichzeitig steigt die als unbekannt eingestufte Fläche von 11,8 % auf 13,2 %. Der Anteil identischer Pixel bei 0° bleibt bei 99,71 %. Diese Werte gelten nur für diesen Versuch und seine internen Messverfahren. Sie sind kein allgemeiner Benchmark.
Die Korrektur vermeidet Texturprojektionen auf bestimmte nicht sichtbare Flächen. Sie reduziert Wiederholungen, lässt aber mehr Bereiche ohne Information. Dieser Zielkonflikt muss sichtbar bleiben, statt in einer Gesamtnote zu verschwinden.
Der Kontrollfall mit verschlechtertem Netz erreicht dennoch 1,79 % Doppelungen, nahe an den 1,72 % des korrigierten Ergebnisses. Daraus folgt für diese Iteration: Dieser Indikator allein reicht nicht für die Freigabe des nächsten Schritts.
| Interne Messung | Vorher | Nachher |
|---|---|---|
| Doppelungen bei +10° | 5,06 % | 1,72 % |
| Unbekannte Fläche bei +10° | 11,8 % | 13,2 % |
| Identische Pixel bei 0° | 99,71 % | 99,71 % |
UV, Normalen und Relighting: unterschiedliche Aufgaben
UV-Abwicklung ordnet Oberfläche und Textur einander zu. Sie legt keine Bildbereiche frei, die im Foto fehlen. Eine Normalenkarte beeinflusst die Lichtreaktion. Sie erzeugt allein weder ein reales Volumen noch eine verlässliche Silhouette aus einem neuen Blickwinkel.
Die laufende Arbeit untersucht auch Tiefen-, Normalen- und Erscheinungsschätzungen mit den Marigold-Pipelines von Diffusers. Verfügbare Ausgaben hängen vom gewählten Modell ab. Es bleiben Schätzungen: Ein vorhergesagtes Material oder angedeutetes Relief ist keine Produktmessung.
Als Nächstes sollen Objekt, empfindliche Details und Lichtumgebung möglichst getrennt behandelt werden. Beschriftungen und funktionale Elemente benötigen eigene Prüfungen. Ein generierter Hintergrund kann der Inszenierung dienen; er darf nicht mit einer dokumentierten Rekonstruktion des Objekts verwechselt werden.
Drei Rechner, ein vergleichbarer Versuch
Python und Blender liefern Ausführungsbausteine. Lokale Modelle können Analyse und Steuerung unterstützen. Die parallele Verarbeitung muss Aufgaben verteilen, ohne die Arbeitsplätze zu überlasten, und vergleichbare Ergebnisse zurückliefern.
Dafür braucht die Kette eine Aufgabenwarteschlange, CPU-, RAM- und VRAM-Budgets pro Rechner, Fristen und kontrollierte Wiederholungen. Der Speicher von drei Rechnern wird nicht automatisch zu einem gemeinsamen Speicher. Eine niedrige Prozesspriorität begrenzt allein nicht die CPU-Nutzung.
Roh-Rendering, beleuchtetes Rendering und Endergebnis müssen separat vergleichbar bleiben. Werden Geometrie, Material und Licht gleichzeitig verändert, lässt sich die Fehlerursache kaum isolieren.
ECC, Hermes, MCP und llama.cpp: getrennte Rollen
ECC stellt Ressourcen für die Agentenarbeit bereit, etwa Skills, Hooks und Regeln. Hermes Agent kann sich über MCP mit Werkzeugservern verbinden. MCP beschreibt den Austausch mit Werkzeugen. Es ersetzt weder die Renderplanung noch die Freigabekriterien.
llama.cpp ermöglicht lokale Modellausführung mit CPU- und GPU-Möglichkeiten je nach Konfiguration. In der angestrebten Architektur schlägt das Modell Aktionen vor, Werkzeuge führen sie aus und Prüfungen entscheiden über die Fortsetzung. Diese Bausteine sind Integrationsansätze; ihre Nennung bedeutet nicht, dass alle bereits mit PhotoCraft verbunden sind.
Vollständig lokal: die Grenzen prüfen
Ziel ist, Bilder und Verarbeitung auf den lokalen Rechnern zu halten. Dafür müssen konfigurierte Modellanbieter, anfängliche Downloads, Telemetrie, entfernte Werkzeuge und mögliche Ersatzanbieter geprüft werden. Ein MCP-Server oder ein installiertes Modell allein garantiert keinen Betrieb ohne externe Verbindungen.
Neue Entwicklungen zu verfolgen gehört zur Arbeit. Ein neuer Baustein lohnt sich aber erst, wenn er einen reproduzierbaren Versuch verbessert: gleiche Quellen, bekannte Versionen, klare Vergleiche und sichtbare Grenzen. Darum geht es bei PhotoCraft: Bilder erzeugen, deren Veränderungen erklärbar und überprüfbar sind.