FLUX.2 Klein Tutorial: Entwickle eine App zum Erstellen und Bearbeiten von Bildern mit Gradio

Schritt 1: Umgebung einrichten

Bevor wir unsere App zum Erstellen und Bearbeiten von Bildern entwickeln, müssen wir eine saubere Umgebung mit der neuesten Diffusers-Bibliothek einrichten. Für dieses Tutorial machen wir alles auf einer Google Colab-Instanz mit einer A100-GPU, damit die Bilder schneller generiert werden. Allerdings läuft dieselbe Konfiguration auch auf schwächeren GPUs wie einer T4, nur mit etwas weniger Leistung.

Wir fangen damit an, alle vorhandenen Versionen von Diffusers zu deinstallieren, um Versionskonflikte zu vermeiden, und installieren dann die neueste Entwicklungsversion direkt von GitHub. Wir installieren auch die Bibliotheken, die man zum Laden von Modellen, Checkpoint-Verwaltung und Beschleunigung braucht.

!pip -q uninstall -y diffusers
!pip -q install -U git+https://github.com/huggingface/diffusers.git
!pip -q install -U accelerate safetensors transformers huggingface_hub

Sobald die Installation fertig ist, schauen wir uns die installierte Diffusers-Version an und checken dann, ob die Klasse „ Flux2KleinPipeline “ erfolgreich importiert werden kann.

import diffusers
print("diffusers:", diffusers.__version__)
from diffusers import Flux2KleinPipeline
print("Flux2KleinPipeline import OK")

Das zeigt, dass unsere Umgebung richtig eingerichtet ist. Als Nächstes laden wir das FLUX.2 Klein-Modell auf die GPU und machen es für die lokale Bilderzeugung und API-basierte Bearbeitungsabläufe bereit.

Schritt 2: Lade FLUX.2 Klein 4B 

Bevor du das Modell laden kannst, brauchst du einen API-Schlüssel von Black Forest Labs. Um loszulegen, logg dich bitte in dein Black Forest Labs-Konto ein und leg unter dem Reiter„Guthaben ” Guthaben an . Die Mindesteinzahlung liegt bei etwa zehn Dollar, womit man ungefähr tausend Credits bekommt. Sobald die Credits hinzugefügt wurden, klick auf„ “, dann auf„Create Key“, gib ihm einen aussagekräftigen Namen und speicher ihn sicher.

Wenn du deinen API-Schlüssel hast, musst du als Nächstes das FLUX.2 Klein 4B-Modell laden und es für zwei verschiedene Verwendungszwecke vorbereiten: lokale Bilderstellung und API-basierte Bildbearbeitung. 

import os, time, base64, io, requests
import gradio as gr
import torch
import nest_asyncio
from PIL import Image
from diffusers import Flux2KleinPipeline
from google.colab import userdata
nest_asyncio.apply()
# =============================
# LOAD via API
# =============================
MODEL_ID = "black-forest-labs/FLUX.2-klein-4B"
BFL_API_KEY = userdata.get("BFL_API_KEY")
BFL_CREATE_URL = "https://api.bfl.ai/v1/flux-2-klein-4b"
print(f"Loading model to GPU: {torch.cuda.get_device_name(0)}")
# =============================
# LOAD via LOCAL HF PIPELINE
# =============================
dtype = torch.float16 
pipe = Flux2KleinPipeline.from_pretrained(MODEL_ID, torch_dtype=dtype).to("cuda")

Zuerst richten wir den API-Schlüssel als Colab-Geheimnis ein, damit er nie im Notebook-Code auftaucht. Wir legen auch die Modell-ID und den Klein-Bearbeitungsendpunkt fest, die wir später aufrufen werden. 

Als Nächstes machen wir „ nest_asyncio “, bevor wir die Gradio-Benutzeroberfläche starten, um Konflikte in der Ereignisschleife zu vermeiden.

Lade zum Schluss die lokale FLUX.2 Klein-Pipeline für die Erstellung des Basisbildes. Wir nutzen „ Flux2KleinPipeline “ mit „ float16 “ für eine breite GPU-Kompatibilität (A100 und T4 funktionieren beide gut) und verlagern dann die Pipeline für eine schnelle Inferenz auf CUDA. Diese lokale Pipeline wird nur zum Erstellen des ersten Bildes benutzt, während Änderungen über die API gemacht werden.

Anmerkung: An dieser Stelle fragst du dich vielleicht, warum wir das Modell lokal laden und auch den API-Zugriff einrichten. Der Grund ist die Trennung der Zuständigkeiten:

• Die lokale Hugging Face-Pipeline ist super für die iterative Text-zu-Bild-Generierung und die volle Kontrolle über die Inferenz-Einstellungen.
• Die Black Forest Labs API bietet erweiterte Bildbearbeitungsfunktionen für FLUX.2 Klein, die in der Open-Weight-Implementierung noch nicht verfügbar sind, wie zum Beispiel promptbasierte Bildbearbeitungen mit mehreren Referenzbildern.

Wenn wir beide Ansätze kombinieren, kriegen wir das Beste aus beiden Welten: lokale Generierungsgeschwindigkeit und Bearbeitungsunterstützung.

Schritt 3: Hilfsfunktionen

Bevor wir alles mit der Gradio-Schnittstelle verbinden, brauchen wir ein paar kleine Hilfsfunktionen. Da unsere App Bilder lokal erstellt, sie aber über die API bearbeitet, brauchen wir eine Möglichkeit, Bilder für API-Anfragen in Base64 zu kodieren, eine Möglichkeit, bearbeitete Bilder, die als URLs zurückgegeben werden, herunterzuladen, und eine lokale Generierungsfunktion, die das ursprüngliche Basisbild erzeugt.

def pil_to_b64_png(img: Image.Image) -> str:
    buf = io.BytesIO()
    img.convert("RGB").save(buf, format="PNG")
    return base64.b64encode(buf.getvalue()).decode()
def url_to_pil(url: str) -> Image.Image:
    r = requests.get(url, timeout=60)
    r.raise_for_status()
    return Image.open(io.BytesIO(r.content)).convert("RGB")
def local_generate(prompt: str):
    if not prompt.strip():
        raise gr.Error("Prompt is empty.")
    out = pipe(
        prompt=prompt.strip(),
        width=1024,
        height=1024,
        num_inference_steps=4,
        guidance_scale=1.0,
        output_type="pil",
    )
    return out.images[0].convert("RGB")

Der obige Code macht drei wichtige Hilfsfunktionen klar:

• Die Funktion „ pil_to_b64_png() ” wandelt ein PIL-Bild in eine Base64-kodierte PNG-Zeichenkette um. Das ist nötig, weil die FLUX.2-Bearbeitungs-API das Basisbild und die Referenzbilder entweder als URLs oder als Base64-Zeichenfolgen akzeptiert. 
• Die Funktion „ url_to_pil() “ macht das Gegenteil. Die Bearbeitungs-API gibt eine signierte URL für die erstellte Ausgabe zurück, also holen wir uns diese URL mit „ requests “, checken die Antwort und wandeln die heruntergeladenen Bytes wieder in ein PIL-Bild um. Dadurch kann das bearbeitete Ergebnis direkt in unserer Gradio-Oberfläche angezeigt und im Verlauf gespeichert werden.
• Schließlich ist die Funktion „ local_generate() “ unser lokaler Einstiegspunkt für die Umwandlung von Text in Bilder. Es überprüft, ob die Eingabeaufforderung leer ist, und ruft dann die lokale Funktion „ Flux2KleinPipeline “ mit festen Einstellungen wie Auflösung, Schrittanzahl und Führungsskala auf. Die Ausgabe wird als sauberes RGB-PIL-Bild zurückgegeben, das als Basisbild für spätere Bearbeitungen dient.

Probier ruhig mal die FLUX-Pipeline-Einstellungen aus, wie Bildauflösung, Diffusionsschritte und Führungsskala, um verschiedene Kompromisse zwischen Qualität und Geschwindigkeit zu entdecken und besser zu verstehen, wie jeder Parameter das endgültige Bild beeinflusst. 

Die Flux 2-Bildbearbeitungs-Dokumentation Dokumentation ist ein guter Ort, um mehr über diese Einstellungen zu erfahren.

Als Nächstes werden wir diese Tools nutzen, um mit FLUX.2 Klein API-basierte Bildbearbeitung zu machen.

Schritt 4: Bearbeiten über die BFL-API

Dieser Schritt ist der Hauptunterschied zwischen einem reinen Hugging Face-Workflow und dem hybriden Ansatz, den wir in diesem Tutorial verwenden. Anstatt zu versuchen, die Bildbearbeitung lokal durchzuführen, überlassen wir die Bearbeitungen der API, die promptbasierte Bearbeitungen und optionale Multi-Referenz-Konditionierungen zuverlässig abwickelt.

Im Großen und Ganzen braucht die FLUX.2 Klein-Bearbeitungs-API eine Textanweisung, die die Bearbeitung beschreibt, ein Basisbild, das geändert werden soll, und optionale Referenzbilder, die als zusätzliche Eingaben bereitgestellt werden. Die API läuft asynchron, das heißt, wir schicken eine Anfrage und checken dann die zurückgegebene URL, bis das bearbeitete Bild fertig ist.

POLL_INTERVAL_S = 1.0
POLL_TIMEOUT_S = 120
def bfl_edit(edit_prompt, base_img, ref_imgs=None):
    if not BFL_API_KEY:
        raise gr.Error("Missing BFL_API_KEY in Colab Secrets.") 
    payload = {
        "prompt": edit_prompt.strip(),
        "input_image": pil_to_b64_png(base_img),
        "output_format": "png",
    }
    if ref_imgs:
        for i, ref in enumerate(ref_imgs[:3], start=2):
            payload[f"input_image_{i}"] = pil_to_b64_png(ref)
    create = requests.post(
        BFL_CREATE_URL,
        headers={"x-key": BFL_API_KEY, "accept": "application/json"},
        json=payload,
        timeout=60,
    )
    create.raise_for_status()
    job = create.json()
    polling_url = job.get("polling_url")
    if not polling_url:
        raise gr.Error(f"API Error: {job}")
    t0 = time.time()
    while True:
        if time.time() - t0 > POLL_TIMEOUT_S:
            raise gr.Error("BFL API polling timed out.")  
        time.sleep(POLL_INTERVAL_S)
        res = requests.get(polling_url, headers={"x-key": BFL_API_KEY})
        res.raise_for_status()
        j = res.json()
        if j["status"] == "Ready":
            return url_to_pil(j["result"]["sample"])
        if j["status"] in ("Error", "Failed"):
            raise gr.Error(f"Generation Failed: {j}")

Die Funktion „ bfl_edit() “ macht drei wichtige Sachen:

• Es braucht drei Eingaben: die Bearbeitungsaufforderung, das Basisbild, das wir ändern wollen, und eine optionale Liste mit Referenzbildern. 
• Wir erstellen eine JSON-Nutzlast mit der Bearbeitungsaufforderung und dem Basisbild, das als base64 PNG verschlüsselt ist. Wenn Referenzbilder zur Verfügung gestellt werden, fügen wir sie mithilfe des indizierten Formats der API an. Dadurch können wir bis zu drei Referenzbilder neben dem Basisbild liefern, was für viele praktische Arbeitsabläufe wie die Übertragung von Farbpaletten, die Verankerung von Stilen oder die Objektverankerung völlig ausreicht.
• Als Nächstes schicken wir die Anfrage an den API-Endpunkt und analysieren die Antwort. Die API gibt einen „ polling_url “ zurück, den wir immer wieder abfragen müssen, bis der Job fertig ist. Wir machen das mit einer einfachen Abfrageschleife mit zwei Sicherheitsvorkehrungen: einem Abfrageintervall, das zu viele Anfragen vermeidet, und einer Zeitüberschreitung, die verhindert, dass das Notebook ewig wartet.

Sobald der Status auf „ Ready “ (Ausgabe-URL verfügbar) springt, hat die API-Antwort eine signierte URL zum Ausgabebild. Wir laden dieses Bild mit unserer vorherigen Hilfsfunktion „ url_to_pil() “ runter und geben es als PIL-Bild zurück.

Als Nächstes machen wir die Sitzungshistorie, damit die Nutzer alle erstellten oder bearbeiteten Ausgabedaten nochmal anschauen können.

Schritt 5: Geschichte hinzufügen 

Jetzt brauchen wir nur noch eine leichte Session-Speicherschicht, damit die Nutzer frühere Ergebnisse wieder aufrufen können, bevor wir die Benutzeroberfläche erstellen. Wir setzen die Historie mit zwei Gradio-Statusobjekten um:

• base_img_state Speichert das aktuelle Arbeitsbild (das Bild, auf das zukünftige Bearbeitungen angewendet werden).
• history_state speichert jede erstellte oder bearbeitete Version als Liste von Wörterbüchern, die jeweils ein Bild und eine kurze Bezeichnung enthalten.

def update_history(history):
    choices = [f"{i}: {h['label']}" for i, h in enumerate(history or [])]
    return gr.update(choices=choices, value=choices[-1] if choices else None)
def on_generate(prompt, history):
    img = local_generate(prompt)
    new_history = list(history or [])
    new_history.append({"img": img, "label": "Generated Base"})
    return img, img, new_history, update_history(new_history), "Base image generated."
def on_edit(edit_prompt, ref2, ref3, ref4, base_img, history):
    if base_img is None:
        raise gr.Error("Please generate a base image first.")
    refs = [r.convert("RGB") for r in (ref2, ref3, ref4) if r is not None]
    out = bfl_edit(edit_prompt, base_img, refs)
    new_history = list(history or [])
    new_history.append({"img": out, "label": f"Edit: {edit_prompt[:20]}..."})
    return out, out, new_history, update_history(new_history), "Edit successful."
def on_load(choice, history):
    if not history or not choice:
        return None, None, "No history to load."
    idx = int(choice.split(":")[0])
    img = history[idx]["img"]
    return img, img, f"Loaded entry #{idx}."
def on_clear():
    return None, None, [], gr.update(choices=[], value=None), "Cleared everything."

Die oben genannten Funktionen sind die Hauptlogik für die Verwaltung des Bildverlaufs in unserer Demo:

• Die Funktion „ update_history() “ formatiert den Sitzungsverlauf als Dropdown-Menü. Jeder Eintrag hat eine Nummer und eine kurze Beschreibung, und das Dropdown-Menü zeigt standardmäßig den neuesten Eintrag an. Dadurch bleibt die Benutzeroberfläche synchron, ohne dass manuell aktualisiert werden muss.
• Der Callback „ on_generate() “ führt „ local_generate() “ aus, um das anfängliche Basisimage zu erstellen. Dann fügt es das Ergebnis als „ {"img": img, "label": "Generated Base"} “ zum Verlauf hinzu. Die Funktion gibt sowohl das Bild als auch den aktualisierten Verlaufszustand zurück, zusammen mit einer Dropdown-Aktualisierung, sodass der neue Eintrag sofort sichtbar wird.
• Der Callback „ on_edit() “ ist ähnlich, ruft aber stattdessen „ bfl_edit() “ auf. Es nimmt das aktuelle Arbeitsbild und ein paar optionale Referenzbilder, macht die Bearbeitung über die API und fügt das Ergebnis zum Verlauf hinzu. base_img_stateAußerdem wird die bearbeitete Ausgabe als neue Version zurückgegeben, was bedeutet, dass zukünftige Änderungen auf das aktuellste Bild angewendet werden, es sei denn, der Benutzer lädt explizit eine ältere Version.
• Der Callback „ on_load() ” analysiert den ausgewählten Dropdown-Eintrag, ruft das passende Bild von history_state ab und macht dieses Bild wieder zum aktiven Arbeitsbild. Damit können Leute ihre Änderungen von jedem vorherigen Checkpoint aus verzweigen.
• Zum Schluss setzt die Funktion „ on_clear() “ alles zurück. Es löscht die Ausgabe, setzt den Basisbildstatus zurück, löscht die Verlaufsliste und leert die Dropdown-Auswahlmöglichkeiten.

Lass uns diese Funktionen in eine Gradio-Schnittstelle mit zwei Textfeldern, optionalen Referenz-Uploads und einem Verlaufs-Workflow einbauen.

Schritt 6: Gradio-Benutzeroberfläche

Dieser Schritt verbindet unsere Generierungs-, Bearbeitungs- und Verlaufslogik mit einer einfachen Gradio-Schnittstelle. Die Benutzeroberfläche wurde mit „ gr.Blocks “ erstellt, was uns eine detaillierte Kontrolle über das Layout ermöglicht. 

with gr.Blocks() as demo:
    gr.Markdown("## FLUX.2 Klein: Generate & Edit Images")
    with gr.Row():
        with gr.Column(scale=1):
            gen_prompt = gr.Textbox(label="1. Generate Base Image", placeholder="A young boy riding a scooter...")
            gen_btn = gr.Button("Generate Base Image", variant="primary")
            edit_prompt = gr.Textbox(label="2. Describe Edits", placeholder="Add the red hat and yellow glasses from the references...")
            with gr.Accordion("Reference Images (Optional)", open=False):
                r2 = gr.Image(label="Ref 1", type="pil")
                r3 = gr.Image(label="Ref 2", type="pil")
                r4 = gr.Image(label="Ref 3", type="pil")
            edit_btn = gr.Button("Apply Edit", variant="secondary") 
            history_dd = gr.Dropdown(label="Session History", choices=[])
            with gr.Row():
                load_btn = gr.Button("Load Selected")
                clear_btn = gr.Button("Clear All")
            status = gr.Textbox(label="Status", interactive=False)
        with gr.Column(scale=1):
            output_view = gr.Image(label="Current Image", type="pil")
    base_img_state = gr.State(None)
    history_state = gr.State([])
    gen_btn.click(
        on_generate, 
        [gen_prompt, history_state], 
        [output_view, base_img_state, history_state, history_dd, status]
    ) 
    edit_btn.click(
        on_edit, 
        [edit_prompt, r2, r3, r4, base_img_state, history_state], 
        [output_view, base_img_state, history_state, history_dd, status]
    ) 
    load_btn.click(
        on_load, 
        [history_dd, history_state], 
        [output_view, base_img_state, status]
    )
    clear_btn.click(
        on_clear, 
        None, 
        [output_view, base_img_state, history_state, history_dd, status]
    )
demo.launch(share=True, inline=True, debug = True)

Wir haben die Benutzeroberfläche in zwei Spalten aufgeteilt, wobei die linke Spalte Eingaben und Aktionen enthält, während die rechte Spalte das aktuelle Bild anzeigt. So erstellen wir die Gradio-App:

• Das erste Textfeld sammelt die Eingabe für die Generierung, und die Schaltfläche„Generate Base Image ” startet die Funktion „ on_generate() ”. Dieser Callback führt die lokale Generierung durch, speichert die Ausgabe im Verlauf und aktualisiert sowohl das angezeigte Bild als auch das aktuelle Arbeitsbild, das unter base_img_state gespeichert ist.
• Das zweite Textfeld sammelt eine Eingabeaufforderung für eine Bearbeitungsanweisung. Wenn der Benutzer auf„ Apply Edit ” klickt, rufen wir die Funktion „ on_edit() ” auf, die das aktuelle Arbeitsbild als Basisbild verwendet und die bearbeitete Ausgabe zurückgibt. Die bearbeitete Ausgabe wird auch an den Verlauf angehängt und wird zum neuen Arbeitsbild für die nächsten Bearbeitungen.
• Damit der Workflow die Sitzung berücksichtigt, haben wir auch ein Dropdown-Menü„Sitzungsverlauf“ eingebaut , sodass jeder Eintrag einer gespeicherten Version des Bildes entspricht. Der Button„ “ (Ausgewähltes Bildladen) startet „ on_load() “, das das ausgewählte Bild aus dem Verlauf wiederherstellt und es wieder als aktuelles Arbeitsbild einstellt. 
• Schließlich Schaltfläche „Alles löschen“ wird alles über die Funktion „ on_clear() “ zurückgesetzt, einschließlich der Ausgabeanzeige, des Basisbildzustands und des gespeicherten Verlaufs.

Die folgenden zwei Gradio-State-Objekte sorgen dafür, dass alles einheitlich bleibt:

• base_img_state sorgt dafür, dass jede Änderung am richtigen Bild gemacht wird.
• history_state Speichert die komplette Zeitachse der Ausgaben für Wiedergabe und Verzweigungen.

Schließlich startet „ demo.launch() “ die App in Colab, gibt einen Link zum Teilen raus, rendert sie inline und aktiviert Debug-Protokolle, um Probleme während der Entwicklung zu diagnostizieren.

FLUX.2 Klein Beispiele und Beobachtungen

Um zu verstehen, wie sich FLUX.2 Klein in der Praxis verhält. Ich hab ein paar kleine Experimente mit der finalen Generate- und Edit-App gemacht. Ich habe drei Hauptinteraktionsmuster getestet: die Erstellung von Basisbildern, die Bearbeitung nur anhand von Eingabeaufforderungen und die referenzgesteuerte Bearbeitung unter Verwendung eines oder mehrerer Bilder. Ich habe auch den Ablauf der Sitzungshistorie überprüft, um sicherzugehen, dass ich jede vorherige Ausgabe wiederherstellen und von diesem Punkt aus weiterarbeiten kann.

Bildgenerierung

Ich hab mit einer einfachen Eingabeaufforderung angefangen, um ein sauberes Basisbild zu erstellen. Das Modell hat ein einheitliches Motiv mit gleichmäßiger Beleuchtung, scharfen Gesichtsdetails und einem stabilen Szenenlayout erzeugt. Das Basisbild der Ausgabe sah gut aus und schien eher für spätere Änderungen als für eine Neugenerierung nützlich zu sein.

Bildbearbeitung mit nur einem Referenzbild

Als Nächstes habe ich ein einzelnes Referenzbild als Farbquelle getestet und eine Bearbeitungsanweisung wie „Ändere die Farbe des Kleides in die Farbe des Referenzbildes“ verwendet. Die Bearbeitung hat die gewünschte Farbe gut rübergebracht und dabei die ursprüngliche Szenenstruktur größtenteils beibehalten.

Ich finde, dass die Einzelreferenzbearbeitungen am besten funktionieren, wenn die Eingabeaufforderung eng gefasst und begrenzt ist. Farbübertragung und Umfärben von Kleidungsstücken sind besonders zuverlässig, weil sie keine großen Änderungen an der Geometrie brauchen. Wenn die Bearbeitungsanweisung sich auf ein Attribut konzentriert, bleiben die Identität des Subjekts und die Hintergrunddetails unverändert.

Bildbearbeitung mit einer einzigen Eingabeaufforderung

Dann habe ich versucht, nur mit Eingabeaufforderungen zu bearbeiten, mit einer semantischen Änderung wie „Hintergrund durch einen Strand ersetzen“. Das Modell hat den Hintergrund super ersetzt und dabei das Motiv ziemlich gleich gelassen. 

Wenn sich der Hintergrund ändert, passt das Modell oft die Farbtemperatur und die Schattenintensität an, damit das Ergebnis fotorealistisch bleibt. Das ist meistens ein Feature, aber es heißt, dass das bearbeitete Bild eher wie ein anderes Fotoshooting aussieht als wie ein einfacher Ausschnitt und Einfügen.

Posenanleitung

Ich hab's mal mit einer pose-basierten Bearbeitung versucht, mit einem Referenzbild, das die Körperhaltung zeigt, und dazu den Hinweis „Passe eine Pose aus einem Referenzbild an“. Das Ergebnis ist ein Bild, bei dem die Pose des Motivs verändert wurde, während die Identität und der Stil ähnlich geblieben sind.

Hier ist das Referenzbild, das ich als Vorlage für die Pose benutzt habe:

Die Posenkorrekturen sind machbar, aber sie sind empfindlicher als Farbkorrekturen. Jede Änderung der Pose kann andere Änderungen nach sich ziehen, wie zum Beispiel die Faltenbildung des Stoffes, die Position der Gliedmaßen und den Bildausschnitt der Kamera. Ich musste ein paar Mal probieren, bis ich diese Pose richtig hinbekommen habe, und hatte trotzdem noch Probleme mit der Position der Beine.

Bildbearbeitung mit mehreren Referenzbildern

Zum Schluss habe ich Multi-Referenz-Bearbeitungen mit verschiedenen Eingaben getestet, wie zum Beispiel einer Farbpalettenreferenz und einer Bearbeitungsaufforderung, die ausdrücklich besagt: „Ändere nur die Hintergrundfarben mit der Palette aus den Referenzbildern.“ Ersetz den Hintergrund nicht durch die Referenzbilder. 

Zu meiner Überraschung hat die Mehrfachreferenzbearbeitung

g ist am effektivsten, wenn jedes Referenzbild eine klare Aufgabe hat. 

Palettenreferenzen funktionieren gut, wenn in der Eingabeaufforderung ausdrücklich „nur Palette“ steht und das Modell nicht angewiesen wird, den Referenzinhalt als Ersatz zu verwenden. 

Wenn Referenzen nicht eindeutig sind, kann das Modell Textur- oder Layoutmerkmale übernehmen, statt nur Farben.  Bei meinem Durchlauf habe ich ein paar kleine Artefakte bemerkt, bei denen Elemente, die den Referenzbildern ähnelten, leicht in die Szene durchgeschlagen sind, aber das Gesamtergebnis sah trotzdem stark und optisch konsistent aus.

Ein praktischer Vorteil dieser Demo ist, dass jedes erstellte und bearbeitete Bild im Sitzungsverlauf gespeichert wird. Du kannst jeden früheren Eintrag laden und genau an dieser Stelle mit der Bearbeitung weitermachen. Das macht das Experimentieren viel schneller. Du kannst Änderungen aus einer früheren Version verzweigen, mehrere Bearbeitungsrichtungen vergleichen und vermeiden, dass ein gutes Zwischenergebnis verloren geht. 

Fazit

In diesem Tutorial haben wir mit FLUX.2 Klein 4B einen kompletten Workflow für die Erstellung und Bearbeitung von Bildern erstellt. Durch die Kombination der lokalen Text-zu-Bild-Generierung über Diffusers mit der von Black Forest Labs gehosteten Bearbeitungs-API konnten wir einen interaktiven Bildeditor entwickeln.

FLUX.2 Kleins Funktionen für die Generierung und Bearbeitung mit geringer Latenz und die Unterstützung mehrerer Referenzen machen es besonders gut für so einen interaktiven Arbeitsablauf geeignet. Von hier aus kannst du die App um Funktionen wie Stapelbearbeitung, Parametersteuerung, Persistenz über Sitzungen hinweg oder sogar einen LLM-gesteuerten Agenten erweitern, der automatisch Bearbeitungsvorschläge macht.