Vorlagenbasierte Bildgenerierung mit Genviso und BetterToken

Ein gelungenes Bild ist noch kein Produktionsprozess. Für ein einzelnes Motiv kann man den Prompt mehrfach umschreiben, Ergebnisse prüfen und eines davon manuell auswählen. Bei Hunderten von SKUs wird daraus eine teure Reihe von Versuchen. Jede Änderung an Licht, Blickwinkel oder Material erzeugt eine weitere Anfrage, während die Ursache für das gute Ergebnis nur im Kopf des Autors bleibt.

Bereit, den Bild-Workflow mit Ihrem eigenen Key auszuführen? BetterToken-Konto erstellen

Teilen Sie die Arbeit in zwei Schleifen. Zuerst testet das Team die visuelle Richtung und dokumentiert wiederholbare Regeln. Danach setzt das Backend Geschäftsdaten in die freigegebene Vorlage ein, sendet Anfragen, speichert Ergebnisse und behandelt Fehler. Die kreative Suche bleibt außerhalb der Produktionswarteschlange; eine Änderung der Komposition verlangt keine Anpassung am Servercode mehr.

Warum Prompt-Debugging im Code außer Kontrolle gerät

Zu viele Variablen hängen zusammen

Das Modell reagiert gleichzeitig auf Motiv, Umgebung, Beleuchtung, Kameraposition, Material, Schärfentiefe und Farbpalette. Bei einem Foto einer Serumflasche unterscheiden sich zum Beispiel:

• Frontalansicht und eine 45-Grad-Aufsicht;
• hartes gerichtetes Licht und weiches Streulicht;
• Glas mit deutlichen Reflexionen und eine matte Oberfläche;
• Travertin, Metall oder einfarbiges Papier als Hintergrund;
• eine 85-mm-Makroanmutung und eine Weitwinkelkomposition.

Wenn mehrere Faktoren zugleich geändert werden, ist nicht erkennbar, welche Formulierung geholfen hat. Wenn sie einzeln geändert werden, wächst die Zahl der Anfragen schnell. Ein Backend mit BetterToken kann die Vorlage über die Image API ausführen, doch ein zu früher Start der Warteschlange vervielfältigt nur eine ungeprüfte visuelle Hypothese.

Jede Aufgabe braucht eine eigene visuelle Grammatik

Eine Produktkarte benötigt eine klare Silhouette, kontrollierte Reflexionen und Platz für das Layout. Eine 3D-Illustration stellt andere Anforderungen an Form und Material. Ein Social-Media-Poster lebt von Hierarchie, Kontrast und sicheren Bereichen. Ein universeller Prompt sammelt daher häufig widersprüchliche Adjektive.

Praktischer sind mehrere Vorlagenfamilien:

skincare_product
luxury_watch
food_photography
3d_illustration
social_poster

Jede Familie legt eigene Pflichtfelder und Abnahmekriterien fest. Die Anwendung wählt anhand der Kategorie die passende Vorlage und setzt anschließend die Daten des Produkts oder der Kampagne ein.

Exploration und Produktion brauchen unterschiedliche Regeln

In der Exploration sind viele Varianten und subjektive Vergleiche erlaubt. Die Produktion braucht einen verlässlichen Vertrag, eine Vorlagenversion, begrenzte Wiederholungen, eine Job-ID und ein eindeutiges Abnahmeergebnis.

Prompt im Code ändern
→ API-Anfrage senden
→ Bild öffnen
→ Code erneut ändern
→ nächste Anfrage senden

In diesem Ablauf gibt es keinen Punkt, an dem die visuelle Entscheidung freigegeben ist. Jede Designbesprechung greift deshalb in das Backend und seine Warteschlange ein.

Architektur: von der visuellen Hypothese zur CMS-Datei

Während der visuellen Erkundung vergleicht das Team in Genviso Varianten in der visuellen Prompt-Galerie, prüft Komposition, Licht und Stil und bewahrt die Struktur des erfolgreichen Prompts. Bei der Serverausführung nutzt die Anwendung BetterToken mit der OpenAI-kompatiblen Base URL und dem eigenen API Key des Benutzers, setzt Daten ein, ruft ein aktuell verfügbares Modell auf und erfasst das Ergebnis. Zwischen den Stufen wird eine Version des Prompt Templates übergeben, nicht ein ausgewähltes Bild oder eine mündliche Anweisung.

Um diese Grenze vor dem Anschluss einer Warteschlange zu testen, erstellen Sie Ihren eigenen API Key, führen Sie eine Kontrollanfrage mit der freigegebenen Vorlage aus und gleichen Sie Modell, Status und tatsächliche Abbuchung sofort im Dashboard ab. Damit ist der Serverweg bestätigt, ohne die visuelle Erkundung in Produktionsanfragen zu verwandeln.

visuelle Erkundung
    ↓
Prompt Template validieren
    ↓
Variablen und Grenzen festlegen
    ↓
PIM- / CMS- / SKU-Daten einsetzen
    ↓
Image-API-Anfrage im Backend
    ↓
Datei, Status und Metadaten speichern
    ↓
visuelle Abnahme

Jeder Übergang muss ein prüfbares Ergebnis liefern:

Stufe	Ergebnis	Ausgangsbedingung
Visuelle Erkundung	Gute und verworfene Varianten	Einflussreiche Parameter sind bekannt
Validierung	Prompt mit benannten Variablen	Funktioniert mit mehreren repräsentativen Produkten
Integration	Renderfunktion und Eingabeschema	Pflichtfelder werden vor der API geprüft
Test	Eine gespeicherte Datei und Anfrage	Datei öffnet sich, Modell und Status stimmen
Produktion	Job mit template_id, Version und job_id	Wiederholungen sind begrenzt, Ergebnis gehört zum SKU

Stufe 1: die visuelle Entscheidung als Vorlage festhalten

Eine Ausgangsstruktur für Studioaufnahmen von Kosmetik kann so aussehen:

Commercial studio product photography of {subject}.

Environment:
{environment}

Visual style:
{visual_style}

Lighting:
{lighting}

Composition:
{composition}

Color palette:
{color_palette}

Crisp reflections, premium material texture,
high-end commercial editorial photography.

Reihenfolge und visuelle Dimensionen bleiben stabil. Die Werte für subject, environment, visual_style, lighting, composition und color_palette ändern sich unabhängig voneinander.

Vor der Übergabe an die Entwicklung sollten vier Punkte feststehen:

1. Pflichtfelder. Ohne subject oder composition darf keine Anfrage gesendet werden.
2. Zulässige Werte. Wenn drei Blickwinkel freigegeben sind, ist ein Enum besser als freier CMS-Text.
3. Verbotene Kombinationen. Transparente Verpackung vor einem Spiegel kann eine eigene Vorlage benötigen.
4. Abnahmekriterien. Die Silhouette ist lesbar, das Logo nicht verzerrt, das Produkt nicht abgeschnitten und der Hintergrund für das Layout geeignet.

Speichern Sie den Prompt neben einem maschinenlesbaren Vertrag:

{
  "template_id": "skincare_product_v3",
  "required_variables": [
    "subject",
    "environment",
    "visual_style",
    "lighting",
    "composition",
    "color_palette"
  ],
  "output_size": "1024x1024"
}

Die Version in template_id sorgt für Reproduzierbarkeit. Ändert das Design Licht oder Komposition, erhalten neue Jobs die nächste Version; vorhandene Inhalte bleiben mit der vorherigen verknüpft.

Stufe 2: die Vorlage mit dem Backend verbinden

Für den ersten Test benötigen Sie das offizielle Python-SDK openai, Ihren eigenen BetterToken API Key und eine aktuelle Modell-ID aus der Image-API-Dokumentation. Schlüssel und Modell-ID gehören in die Umgebung:

python -m pip install openai

export BETTERTOKEN_API_KEY="your_api_key_here"
export BETTERTOKEN_IMAGE_MODEL="current_image_model_id"

Speichern Sie einen echten Schlüssel nie im Repository, Prompt, Screenshot oder Log. Verwenden Sie in der Produktion einen Secret Manager und getrennte Schlüssel für Anwendungen oder Umgebungen.

Dieses Beispiel rendert die Vorlage, sendet eine Anfrage und speichert ein PNG aus b64_json:

import base64
import os
from pathlib import Path
from typing import Mapping
from openai import OpenAI

client = OpenAI(
    base_url="https://www.bettertoken.ai/v1",
    api_key=os.environ["BETTERTOKEN_API_KEY"],
)

def render_product_prompt(variables: Mapping[str, str]) -> str:
    return f"""
Commercial studio product photography of {variables['subject']}.

Environment:
{variables['environment']}

Visual style:
{variables['visual_style']}

Lighting:
{variables['lighting']}

Composition:
{variables['composition']}

Color palette:
{variables['color_palette']}

Crisp reflections, premium material texture,
high-end commercial editorial photography.
""".strip()

product = {
    "subject": "frosted amber glass serum bottle with a minimalist gold dropper",
    "environment": "organic travertine pedestal surrounded by subtle water ripples",
    "visual_style": "high-end botanical skincare editorial",
    "lighting": "warm directional morning rim light with soft diffused fill",
    "composition": "centered 85mm macro product photography with shallow depth of field",
    "color_palette": "earthy amber, warm beige and subtle gold",
}

response = client.images.generate(
    model=os.environ["BETTERTOKEN_IMAGE_MODEL"],
    prompt=render_product_prompt(product),
    size="1024x1024",
    n=1,
    output_format="png",
    response_format="b64_json",
)

image_base64 = response.data[0].b64_json
if not image_base64:
    raise RuntimeError("Image API response does not contain b64_json")

output_path = Path("serum-product.png")
output_path.write_bytes(base64.b64decode(image_base64))
print(f"Saved: {output_path}")

client.images.generate(...) und die Dekodierung von b64_json entsprechen dem aktuellen SDK-Vertrag. Das Modell kommt aus BETTERTOKEN_IMAGE_MODEL und kann dadurch gewechselt werden, ohne Prompt Template oder Geschäftslogik umzuschreiben.

Minimale Schleife für einen Batch-Job

Der folgende Block ist bewusst ausführlicher Integrationspseudocode. save_job, generate_image und ApiError stehen für Adapter des Speichers und API-Clients; sie sind keine zusätzlichen SDK-Methoden.

MAX_ATTEMPTS = 3
RETRYABLE_STATUS = {429, 500, 502, 503, 504}

for sku in sku_rows:
    variables = validate_variables(sku)  # vor jedem API-Aufruf
    prompt = render_product_prompt(variables)
    job_id = uuid4().hex
    prompt_hash = sha256(prompt.encode()).hexdigest()
    save_job(job_id=job_id, sku_id=sku["id"],
             template_id="skincare_product_v3",
             prompt_hash=prompt_hash, status="pending")

    for attempt in range(1, MAX_ATTEMPTS + 1):
        save_job(job_id=job_id, status="running", attempt=attempt)
        try:
            result = generate_image(prompt)
        except ApiError as error:
            if error.status_code in {400, 401}:
                save_job(job_id=job_id, status="failed", error_code=error.status_code)
                break
            if error.status_code not in RETRYABLE_STATUS or attempt == MAX_ATTEMPTS:
                save_job(job_id=job_id, status="failed", error_code=error.status_code)
                break
            sleep(min(2 ** attempt, 8))
            continue
        except TimeoutError:
            save_job(job_id=job_id, status="unknown", error_code="timeout")
            break  # Dashboard und Speicher vor erneutem Senden prüfen

        if not result.b64_json:
            save_job(job_id=job_id, status="failed", error_code="empty_output")
            break
        output_path = persist_png(job_id, result.b64_json)
        save_job(job_id=job_id, status="succeeded", output_path=output_path,
                 model=result.model, attempt=attempt)
        break

Die lokale job_id verbindet SKU, Vorlage und Datei, macht die externe Anfrage aber nicht idempotent. Lassen Sie den Status nach einem Timeout auf unknown, suchen Sie die Anfrage nach Uhrzeit im Dashboard und prüfen Sie den Speicher, bevor Sie genau eine erneute Übermittlung erlauben.

Reihenfolge der Fehlersuche

Symptom	Zuerst prüfen	Korrektur	Erneute Prüfung
400	Pflichtvariablen, aktuelle Modell-ID und unterstützte size	Daten oder Parameter korrigieren; nicht automatisch wiederholen	Einen Kontroll-SKU ausführen und PNG öffnen
401	Geladene Schlüsselvariable, Eigentümer und Protokoll	Schlüssel ersetzen oder neu erstellen, ohne ihn zu protokollieren	Minimalanfrage senden und Status im Dashboard finden
429	Parallelität und Aufgabenrate	Neue Jobs anhalten, Parallelität senken, begrenzten Backoff nutzen	Eine Anfrage passieren lassen, Last danach langsam erhöhen
5xx	Anfragezeit und bisherige Versuche	Nur bis MAX_ATTEMPTS wiederholen; Zeit und Status speichern	Nach einer Pause testen, ohne die freigegebene Vorlage zu ändern
Timeout	Dashboard und Speicher	unknown beibehalten; Fehler nicht unterstellen	Fehlen Eintrag und Datei, eine Übermittlung mit derselben lokalen job_id erlauben
Leeres b64_json oder Dekodierfehler	Antwortformat, Modell und aktuelle Parameter	Fehler ohne Schlüsseldaten speichern, Parsing oder Konfiguration korrigieren	Einen SKU wiederholen und prüfen, ob das PNG geöffnet wird

Was vor der Seriengenerierung fehlt

Daten vor der Anfrage validieren

Ein leeres material, unerwartetes Markup in product_name oder freier Text anstelle einer freigegebenen Palette verändert den Prompt. Prüfen Sie Pflichtfelder, Längen und zulässige Werte. Speichern Sie finalen Prompt-Hash, template_id und SKU-Kennung beim Job.

Wiederholungen begrenzen

Eine Wiederholung nach einem Timeout kann ein weiteres Bild erstellen, obwohl die Anwendung die erste Antwort nicht erhalten hat. Legen Sie eine endliche Zahl von Versuchen, eine Wartezeit und eine job_id fest. Wiederholen Sie 400-, 401- oder Modellkonfigurationsfehler nicht endlos; korrigieren Sie zuerst Daten, Schlüssel oder Konfiguration.

Technische und visuelle Abnahme trennen

HTTP 200 und ein gültiges PNG bestätigen den technischen Erfolg. Komposition, Produktverzerrung und Markenpassung werden separat bewertet. Der automatische Job speichert Datei und Metadaten; die nächste Stufe wendet die visuellen Kriterien an.

Anfrage und Nutzung abgleichen

Suchen Sie die Kontrollgenerierung im Dashboard nach Uhrzeit. Prüfen Sie Modell, Status und Abbuchung; verfügbare Nutzungsfelder zeigen Eingabe-, Ausgabe- und Cache-Token. Das Dashboard enthält Nutzungs- und Ausgabenmetadaten, nicht den vollständigen Prompt oder die Antwort. Planen Sie mit der aktuellen Modell- und Preisseite und entnehmen Sie die tatsächlichen Testkosten dem Anfrageneintrag.

Beispielablauf für einen Produktkatalog

PIM / SKU-Datenbank
↓
Produktkategorie → template_id
↓
Name / Material / Farbe / Hintergrund
↓
Pflichtfeldprüfung
↓
Prompt Template rendern
↓
Generierungsjob mit job_id
↓
Image API
↓
Objektspeicher
↓
visuelle Abnahme
↓
CMS / Medienbibliothek

Der Prompt wird zu einem versionierten Produktionsobjekt. Sie können erkennen, welche Vorlage eine Datei erzeugt hat, Ablehnungen je Version vergleichen und eine schlechte Änderung zurücknehmen, ohne die gesamte Integration anzupassen.

Checkliste vor dem Start

• Die Vorlage wurde mit typischen Produkten und Grenzfällen geprüft.
• template_id, Pflichtvariablen und Abnahmekriterien sind definiert.
• Der API Key bleibt außerhalb von Quellcode und Logs.
• Die Modell-ID kommt aus Umgebung oder Konfiguration.
• Eine Testanfrage erzeugt eine gültige Datei in erwarteter Größe.
• 400/401 führen vor einer neuen Anfrage zu einer Korrektur.
• Für 429/5xx gibt es begrenzte Wiederholungen.
• Jeder Job gehört zu SKU, job_id, Vorlagenversion und Speicherort.
• Technische Prüfung und visuelle Abnahme sind getrennt.
• Modell, Status und Testkosten wurden im Dashboard geprüft.

Wie die Rollenverteilung die Zusammenarbeit verbessert

Genviso übernimmt die interaktive Schleife: visuelle Richtung finden, Prompts vergleichen und die Vorlage vor der Entwicklerübergabe validieren. BetterToken übernimmt die Serverschleife: API Key, OpenAI-kompatible Verbindung, Aufruf eines verfügbaren Modells und Nutzungsaufzeichnung. Beide Teams einigen sich auf einen Vertrag – Prompt Template, Variablen, Version und Abnahmekriterien.

Um die freigegebene Vorlage in ein funktionierendes Backend zu übernehmen und die Kosten an einem repräsentativen SKU zu prüfen, erstellen Sie Ihren eigenen API Key, führen Sie die kleinste Anfrage aus der Image-API-Referenz aus und prüfen Sie Modell, Status und Abbuchung im Dashboard, bevor Sie die Warteschlange verbinden.