Nano Banana 2.1: Tutorial zur mehrstufigen Bildbearbeitung – 3 Rückgabe-Elemente, damit bei zwei aufeinanderfolgenden Bildbearbeitungen keine Details verloren gehen

Anmerkung des Autors: Anhand eines vollständigen Beispiels – „Krone durch rote Mütze ersetzen und anschließend das rosa Herz blau färben“ – wird erklärt, welche Gesprächshistorie, welches Bild aus der vorherigen Runde und welche Thought-Signature bei jeder Runde der mehrstufigen Bearbeitung mit Nano Banana 2.1 zurückgesendet werden müssen. So bleiben frühere Änderungen bei lokalen Anpassungen erhalten.

Viele Entwickler stoßen bei ihren ersten Bildbearbeitungen mit gemini-nano-banana-2.1 auf dasselbe Problem: Die Änderung in der ersten Runde gelingt gut, doch bei einer kleinen Anpassung in der zweiten Runde wird das vorherige Ergebnis überschrieben oder der Stil des gesamten Bildes neu interpretiert. Dieser Artikel zeigt dir die richtige Art, Daten bei der mehrstufigen Bearbeitung mit Nano Banana 2.1 zurückzusenden. So kannst du ein Bild in zwei aufeinanderfolgenden Runden bearbeiten, ohne Details zu verlieren.

Dies ist kein weiterer Artikel mit einer bloßen Einführung in die Grundlagen, sondern ein nachvollziehbares Beispiel: In der ersten Runde wird die Krone auf dem Kopf der Figur durch eine rote Mütze ersetzt. In der zweiten Runde wird nur das rosa Herz blau gefärbt, während die rote Mütze erhalten bleibt. Wir zeigen den vollständigen Code für beide Anfragen und erklären, welche Daten in jeder Runde mitgesendet werden müssen.

Das Wichtigste: Nach der Lektüre verstehst du, wie die mehrstufige Bearbeitung mit Nano Banana 2.1 funktioniert, kennst die drei Elemente, die bei jeder Anfrage zurückgesendet werden müssen, und kannst die Beispiele direkt für aufeinanderfolgende lokale Bildbearbeitungen verwenden.

Zentrale Punkte zur mehrstufigen Bearbeitung mit Nano Banana 2.1

Zunächst sollten wir den Begriff präzisieren. Was oft als „native mehrstufige“ Bearbeitung mit Nano Banana 2.1 bezeichnet wird, lässt sich genauer als „fortlaufende Bearbeitung“ beschreiben: Jede Runde ist eine eigenständige API-Anfrage. Dass sich das Modell scheinbar merkt, was in der vorherigen Runde geändert wurde, liegt daran, dass Sie den vollständigen Kontext in der Anfrage erneut mitsenden – nicht daran, dass der Server die Sitzung für Sie speichert.

Warum bei der mehrstufigen Bearbeitung mit Nano Banana 2.1 Details verloren gehen

Der häufigste Fehler: In der zweiten Runde senden Sie nur die Anweisung „Ändere das rosa Herz in Blau“ und fügen das Originalbild hinzu. Für das Modell ist dann weiterhin das Original mit der Krone sichtbar. Es behält die Krone daher bei, während der rote Hut aus der ersten Runde verschwindet. Ein weiterer Fehler besteht darin, nur das Bild aus der ersten Runde anzuhängen, ohne den Gesprächsverlauf mitzusenden. Zwar erhält das Modell dadurch die Version mit dem roten Hut, weiß aber nicht, dass dieser Hut gerade bewusst geändert wurde und erhalten bleiben soll. Deshalb kann es bei der zweiten Runde nebenbei auch die Farbe oder Form des Huts verändern.

Am zuverlässigsten ist es, die vollständige Interaktion aus der ersten Runde als Gesprächsverlauf zurückzusenden: Was der Nutzer gesagt hat, welches Bild das Modell zurückgegeben hat und welche Signatur an der Modellantwort angehängt war. Auch die offizielle Google-Dokumentation beschreibt mehrstufige Szenarien zur Bildbearbeitung auf diese Weise: Das Modell führt den Kontext seiner Schlussfolgerungen mithilfe der Signatur im Verlauf fort und ändert so nur den angegebenen Bildausschnitt.

Aufbau einer Anfrage für die mehrstufige Bearbeitung mit Nano Banana 2.1

Das contents-Feld der zweiten Anfrage ist ein chronologisch geordnetes Array und enthält mindestens drei Abschnitte: die user-Nachricht aus der ersten Runde (Originalbild und Anweisung), die model-Antwort aus der ersten Runde (Ausgabebild und Signatur) sowie die neue user-Anweisung für die zweite Runde. Entscheidend ist, den Abschnitt mit der model-Antwort unverändert wiederzugeben. Wenn Sie nur das Base64-Bild extrahieren und neu zusammensetzen, geht das Signaturfeld bei der Umwandlung leicht verloren.

Schnellstart: Mehrstufige Bearbeitung mit Nano Banana 2.1

Im Folgenden rufen wir das native Gemini-Format generateContent direkt mit Python und der Bibliothek requests auf. Wir verwenden nicht das OpenAI-kompatible Chat-Format, weil bei der mehrstufigen Bearbeitung die Thought-Signatur und Bild-Parts zurückgesendet werden müssen. Das native Format erhält die ursprüngliche Struktur dieser Felder bestmöglich.

Checkliste zur Vorbereitung

Minimalbeispiel: In Runde 1 die Krone durch einen roten Hut ersetzen

Die erste Runde ist eine gewöhnliche Bildbearbeitungsanfrage: Eine User-Nachricht enthält das Originalbild und die Anweisung. Wichtig ist, den gesamten Inhalt der Antwort des Modells zu speichern, damit er in der nächsten Runde verwendet werden kann.

import base64, requests

BASE_URL = "https://api.apiyi.com/v1"  # APIYI 统一接口，原生格式路径以文档中心说明为准
API_KEY = "YOUR_API_KEY"
MODEL = "gemini-nano-banana-2.1"
URL = f"{BASE_URL}/models/{MODEL}:generateContent"
HEADERS = {"Authorization": f"Bearer {API_KEY}", "Content-Type": "application/json"}

img_b64 = base64.b64encode(open("origin.png", "rb").read()).decode()
user1 = {"role": "user", "parts": [
    {"inline_data": {"mime_type": "image/png", "data": img_b64}},
    {"text": "把角色头上的皇冠换成一顶红色的帽子，其他内容保持不变。"}]}

resp = requests.post(URL, headers=HEADERS, json={
    "contents": [user1],
    "generationConfig": {"responseModalities": ["TEXT", "IMAGE"]}}).json()
model1 = resp["candidates"][0]["content"]  # 原样保存，含图片和 thoughtSignature

Besonders wichtig ist die letzte Zeile: model1 übernimmt das gesamte Objekt candidates[0].content und nicht nur die darin enthaltenen Bilddaten. Die Parts dieses Objekts können Text, Bilder und das Feld thoughtSignature enthalten. Wenn Sie das Objekt unverändert speichern, geht nichts davon verloren.

Vollständiges Beispiel: In Runde 2 nur das rosa Herz blau färben und den roten Hut beibehalten

Im zweiten Durchgang werden die Inhalte zu [user1, model1, user2] zusammengesetzt. Der vollständige Code unten enthält beide Aufrufe, eine Prüfung der Signatur und das Speichern der Bilder – Sie können ihn direkt ausführen.

import base64
import requests

BASE_URL = "https://api.apiyi.com/v1"  # Aufruf über APIYI; der Pfad im nativen Format ist in docs.apiyi.com dokumentiert
API_KEY = "YOUR_API_KEY"
MODEL = "gemini-nano-banana-2.1"
URL = f"{BASE_URL}/models/{MODEL}:generateContent"
HEADERS = {"Authorization": f"Bearer {API_KEY}", "Content-Type": "application/json"}
GEN_CONFIG = {"responseModalities": ["TEXT", "IMAGE"]}


def call(contents):
    """Sendet eine generateContent-Anfrage und gibt das vollständige content-Objekt der Modellantwort zurück."""
    r = requests.post(URL, headers=HEADERS,
                      json={"contents": contents, "generationConfig": GEN_CONFIG},
                      timeout=180)
    r.raise_for_status()
    return r.json()["candidates"][0]["content"]


def save_image(content, path):
    """Entnimmt der Modellantwort das Bild und speichert es."""
    for part in content.get("parts", []):
        data = part.get("inlineData") or part.get("inline_data")
        if data:
            open(path, "wb").write(base64.b64decode(data["data"]))
            return True
    return False


def has_signature(content):
    """Prüft, ob die Antwort eine Denksignatur enthält."""
    return any("thoughtSignature" in p or "thought_signature" in p
               for p in content.get("parts", []))


# ---------- Runde 1: Krone → roter Hut ----------
img_b64 = base64.b64encode(open("origin.png", "rb").read()).decode()
user1 = {"role": "user", "parts": [
    {"inline_data": {"mime_type": "image/png", "data": img_b64}},
    {"text": "Ersetze die Krone auf dem Kopf der Figur durch einen roten Hut. Alles andere soll unverändert bleiben."}]}

model1 = call([user1])
save_image(model1, "round1_red_hat.png")
print("Signatur in Runde 1 vorhanden:", has_signature(model1))

# ---------- Runde 2: rosa Herz → blaues Herz, roten Hut beibehalten ----------
user2 = {"role": "user", "parts": [
    {"text": "Ändere auf Grundlage des vorherigen Bildes nur das rosa Herz auf der Brust zu Blau."
             " Der rote Hut und alle anderen Details sollen unverändert bleiben."}]}

# Wichtig: vollständiger Verlauf und model1 unverändert zurückgeben (einschließlich Bild und Signatur aus der vorherigen Runde)
history = [user1, model1, user2]
model2 = call(history)
save_image(model2, "round2_blue_heart.png")
print("Signatur in Runde 2 vorhanden:", has_signature(model2))

# Für eine dritte Runde einfach ergänzen: history += [model2, user3]

🚀 Schnellstart: Führen Sie den Code für beide Runden am besten zuerst mit dem kostenlosen Testkontingent auf APIYI apiyi.com aus. Prüfen Sie, ob der rote Hut im Bild aus Runde 2 erhalten bleibt und nur das Herz die Farbe wechselt. Anschließend können Sie den Code in Ihren eigenen Ablauf integrieren.

Tipps zur Formulierung der Anweisung für die zweite Runde

Ob eine mehrstufige Bearbeitung wirklich nur einzelne Bereiche verändert, hängt nicht nur von der Rückgabe der Struktur ab, sondern auch davon, wie die Anweisung formuliert ist. Für die zweite Runde empfehlen wir, drei Dinge klar zu benennen: Auf welchem Bild die Änderung basieren soll, was geändert werden soll und was unverändert bleiben muss. Zum Beispiel ist „Ändere auf Grundlage des vorherigen Bildes nur das rosa Herz in ein blaues; die rote Mütze und alle anderen Details sollen unverändert bleiben“ deutlich zuverlässiger als ein schlichtes „Ändere es in Blau“.

Füge das Originalbild in der zweiten Runde außerdem nicht erneut hinzu. Das Original ist bereits in user1 enthalten. Wird es in user2 noch einmal eingefügt, könnte das Modell es als neue Referenz verstehen und stattdessen wieder zur Version mit der Krone zurückkehren.

Vergleich von drei Möglichkeiten, den Verlauf bei mehrstufigen Bearbeitungen mit Nano Banana 2.1 erneut zu übermitteln

Um zu zeigen, warum alle drei Elemente vorhanden sein müssen, vergleichen wir die drei gängigen Varianten. Die Tabelle beschreibt qualitativ, wie sich die jeweilige Übermittlungsmethode verhält. So kannst du schnell erkennen, welche Variante dein Code verwendet.

Vergleich im Detail

Analyse zu Methode A: Methode A ist besonders einfach umzusetzen, da jede Runde eine eigenständige Anfrage darstellt. Das Modell sieht jedoch das Ergebnis der ersten Runde nicht. Im Grunde wird die Bearbeitung also noch einmal von Grund auf in einer einzelnen Runde durchgeführt. Bei einer erneuten Übermittlung des vollständigen Verlaufs kann die zweite Runde dagegen auf dem Ergebnis der ersten aufbauen.

Analyse zu Methode B: Methode B spart beim Anfrageumfang, da nur ein Bild übermittelt wird. Dem Modell fehlt jedoch der Kontext, dass der rote Hut gezielt hinzugefügt wurde, und es erhält auch keine Signatur. Daher ist die Konsistenz einzelner Bildbereiche nicht gewährleistet. Für Szenarien wie die kontinuierliche Feinarbeit an Entwürfen oder Produktbildern für den E-Commerce ist Methode C nach wie vor die zuverlässigere Wahl.

💡 Empfehlung: Wenn dein Anwendungsfall mehr als zwei aufeinanderfolgende Bearbeitungsrunden umfasst, solltest du direkt Methode C verwenden. Auf APIYI apiyi.com kannst du alle drei Varianten mit demselben Code ausführen und die Ausgabebilder vergleichen – die Unterschiede sind deutlich zu erkennen.

Nano Banana 2.1 im Vergleich zu Modellen derselben Reihe

Auf APIYI gibt es mehrere Modelle der Nano-Banana-Reihe. Die fortlaufende Bearbeitung ist eine erweiterte Anwendung der Bearbeitungsfunktionen. Die folgende Tabelle hilft dir bei der Auswahl eines passenden Modells innerhalb der Reihe.

Häufige Fehler bei der mehrstufigen Bearbeitung mit Nano Banana 2.1

In der Praxis lassen sich die meisten Fälle, in denen Änderungen „verloren gehen“, auf einige typische Ursachen zurückführen. Die folgende Checkliste ist nach Häufigkeit sortiert und hilft bei der Fehlersuche.

1. Signatur geht verloren: Wenn Sie die Modellantwort in eine eigene Datenstruktur umwandeln und anschließend wieder zusammensetzen, können sich die Groß- und Kleinschreibung von Feldnamen oder die Verschachtelung ändern. Dadurch wird thoughtSignature nicht mitgesendet. Speichern Sie stattdessen das ursprüngliche content-Objekt direkt und geben Sie es unverändert zurück.
2. Falsche Rolle: Wenn Sie die Modellantwort der ersten Runde mit der Rolle user kennzeichnen, behandelt das Modell seine eigene Ausgabe wie ein neu vom Nutzer hochgeladenes Bild. Modellantworten müssen die Rolle role: model behalten.
3. Reihenfolge vertauscht: contents muss chronologisch geordnet sein: user1, model1, user2 und so weiter. Neue Anweisungen dürfen nicht an den Anfang gesetzt werden.
4. Formate gemischt: Wenn Sie in einer Runde das OpenAI-kompatible Format und in der nächsten das native Format verwenden, können bei der Umwandlung der Felder Signaturen verloren gehen. Verwenden Sie für den gesamten mehrstufigen Ablauf möglichst einheitlich das native Gemini-Format.
5. Zu viel Verlauf: Mit jeder weiteren Runde steigt die Zahl der Bilder, die in der Anfrage mitgesendet werden – dadurch nehmen auch Datenvolumen und Verarbeitungszeit zu. Bei längeren Abläufen mit mehr als zwei oder drei Runden können Sie das aktuelle Ergebnis an einem wichtigen Zwischenpunkt als neues Originalbild verwenden und einen neuen Verlauf beginnen.

🎯 Technischer Tipp: Geben Sie bei der Fehlersuche zunächst die parts-Struktur von model1 aus und prüfen Sie, ob das Feld thoughtSignature tatsächlich vorhanden ist. Kontrollieren Sie anschließend, ob es im Textkörper der zweiten Anfrage unverändert enthalten ist. Im Dokumentationszentrum von APIYI unter apiyi.com finden Sie Beispiele für das native Gemini-Format und den Aufbau mehrstufiger Dialoge.

Häufig gestellte Fragen (FAQ)

Nano Banana 2.1: Kernaussagen zur mehrstufigen Bearbeitung

• Im Kern handelt es sich um fortlaufende Bearbeitung: Jede Runde ist eine eigenständige Anfrage. Der Client hält den Kontext aufrecht, indem er ihn erneut mitsendet.
• Drei Elemente sind unverzichtbar: der vollständige Gesprächsverlauf, das Bild aus der vorherigen Runde und die Denk-Signatur.
• Den Inhalt von model unverändert zurücksenden: Speichern Sie direkt candidates[0].content, damit die Signatur nicht verloren geht.
• Das native Format verwenden: Die contents-Struktur von generateContent eignet sich am besten, um Bilder und Signaturen zurückzusenden.
• Klar benennen, was erhalten bleiben soll: Geben Sie in der zweiten Runde ausdrücklich an, „was geändert werden soll und was unverändert bleibt“. So gelingen lokale Änderungen zuverlässiger.
• Das Originalbild nicht erneut anhängen: Andernfalls kann das Modell in der zweiten Runde zum Stand vor der Änderung zurückkehren.
• Kostengünstig testen: Führen Sie den zweistufigen Ablauf zunächst mit dem kostenlosen Kontingent von APIYI auf apiyi.com aus.

Zusammenfassung

Die wichtigsten Punkte zur mehrstufigen Bearbeitung mit Nano Banana 2.1:

1. Funktionsweise: Bei der mehrstufigen Bearbeitung handelt es sich um fortlaufende Bearbeitung auf Basis der vom Client zurückgesendeten Inhalte. Ob sich der Server den Kontext automatisch merkt, ist nicht verifiziert – darauf sollten Sie sich nicht verlassen.
2. Zurückzusendende Inhalte: Die zweite Anfrage muss user1, das unveränderte model1 (einschließlich Bild und Denk-Signatur) sowie user2 enthalten.
3. Praxistipps: Verwenden Sie einheitlich das native Gemini-Format, nennen Sie in der Eingabeaufforderung, was erhalten bleiben soll, und hängen Sie das Originalbild in der neuen Runde nicht erneut an.

Wenn Sie diese drei Punkte beachten, lassen sich zweistufige Bildbearbeitungen wie „die Krone durch einen roten Hut ersetzen und anschließend das rosa Herz blau färben“ zuverlässig wiederholen. Dieselbe Struktur lässt sich auch auf weitere Runden ausweiten.

Mit APIYI auf apiyi.com können Sie die Ergebnisse schnell überprüfen. Die Plattform bietet Schnittstellen im OpenAI-kompatiblen und nativen Gemini-Format. Mit einem einzigen API-Schlüssel können Sie Nano Banana und andere gängige Modelle aufrufen. Die Abrechnung erfolgt nutzungsbasiert – ideal, um zunächst im kleinen Maßstab zu testen und die Lösung anschließend schrittweise in die Produktion zu übernehmen.

📚 Referenzen

1. Dokumentation zur Bildgenerierung und -bearbeitung mit der Google Gemini API: Offizielle Beschreibung der mehrstufigen Bildbearbeitung
2. Link: ai.google.dev/gemini-api/docs/image-generation

3. Erläuterung: Beschreibt den Aufbau von Anfragen zur Bildbearbeitung und die dialogbasierte Vorgehensweise bei aufeinanderfolgenden Bearbeitungsschritten

4. Dokumentation zu Thought Signatures der Google Gemini API: Erläuterung des Mechanismus für Thought Signatures

5. Link: ai.google.dev/gemini-api/docs/thought-signatures

6. Erläuterung: Erklärt die Funktion der Signaturen und wie sie in mehrstufigen Anfragen zurückgesendet werden

7. APIYI-Dokumentationszentrum: Entwicklungsleitfäden für die Nano-Banana-Reihe, Anleitungen zur Implementierung mehrstufiger Dialoge und Leitfäden für Aufrufe im nativen Gemini-Format

8. Link: docs.apiyi.com
9. Erläuterung: Enthält Informationen zu API-Endpunkten, Pfaden für das native Format und Beispiele für die Zusammenstellung des Gesprächsverlaufs. Sie dienen als Referenz für die praktische Umsetzung des Codes in diesem Artikel.

Autor: Technisches Team von APIYI
Technischer Austausch: Kontaktieren Sie uns gerne über die Startseite der APIYI-Website. Weitere Informationen zur Anbindung der Nano-Banana-Reihe finden Sie im Dokumentationszentrum unter docs.apiyi.com.

Weiterführende Artikel

• Nano Banana 2 vs. 2.1: Textrendering im Vergleich – Praxistest mit 5 Poster-Sets und Auswahl-Checkliste: Alle sagen, dass Nano Banana 2.1 Texte besser rendert – warum halten manche die zweite Generation für präziser? Erkläre anhand von fünf reproduzierbaren Posterszenarien, Abnahmekriterien und Preisen pro Nutzung, wann man wechseln sollte und wann nicht.
• Was wurde bei Nano Banana 2.1 verbessert? Die 6 großen Upgrades im Detail und ein Leistungsvergleich mit Nano Banana Pro: Nano Banana 2.1 ist ein Upgrade von Nano Banana 2 und übertrifft bei offiziellen Benchmarks bereits Nano Banana Pro – doch kann es bei der Bilderzeugung tatsächlich mithalten, und welche der sechs wichtigsten Verbesserungen, offiziellen und unabhängigen Testergebnisse sowie Empfehlungen zur Auswahl je nach Anwendungsfall sprechen für Nano Banana 2.1 oder Pro?
• Nano Banana 2.1: Preise im Überblick – 5 wichtige Unterschiede zu Nano Banana 2 und Berechnung des Sparpotenzials: Analyse der Preise von Nano Banana 2.1 anhand der offiziellen Google-Preisseite: Der Preis pro Bildausgabe halbiert sich, während Eingabe- und Denk-Token teurer werden, der Verbrauch bei 4K steigt und die 0,5K-Stufe entfällt; enthalten sind Einzelbildkosten für 1K/2K/4K, Batch-Preise, der Break-even-Punkt und Migrationsempfehlungen.
• Ein einziges Bild täuschte 3 Millionen Menschen? Eine Anleitung in 2 Schritten, um mit GPT Image 2.5 satirische, KI-generierte pseudo-dokumentarische Reisebilder zu erstellen: Analysiere Wytse Koetses satirisches Paris-Video: Erstelle zuerst mit GPT strukturierte Eingabeaufforderungen und produziere dann mit gpt-image-2.5-sunburst oder gemini-nano-banana-2.1 stapelweise pseudo-dokumentarische Standbilder im Stil einer „gefälschten Tourismuswerbung“.