|

gpt-image-2.6-all: Bei 2K/4K nicht auf die zurückgegebene Größenangabe (size) verlassen

VonShark
gpt-image-2.6-all: Bei 2K/4K nicht auf die zurückgegebene Größenangabe (size) verlassen

Hinweis des Autors: Bei gpt-image-2.6-all sind 2K/4K Upscaling-Stufen. Die Antwort gibt size womöglich nicht zurück, und die tatsächliche Pixelgröße weicht gelegentlich ab. Dieser Artikel erklärt die Ursache und zeigt, wie Sie das Bild speichern, die echte Breite und Höhe auslesen und erst dann das Layout berechnen.

Wer eine Bilderzeugungs-Schnittstelle in eine Poster-Vorlage, ein Produkthauptbild für den Onlineshop oder eine Video-Cover-Pipeline einbindet, liest meist direkt das Feld size aus der Antwort und berechnet daraus Canvas und Layout. Bei den 2K/4K-Stufen von gpt-image-2.6-all ist das riskant. In der Modellbeschreibung, die APIYI (apiyi.com) am 2026-11-11 veröffentlicht hat, steht: 2K/4K sind Upscaling-Stufen, die Antwort gibt size womöglich nicht zurück, und in Einzelfällen weicht auch die tatsächliche Pixelgröße vom Erwarteten ab. Maßgeblich ist die tatsächliche Breite und Höhe der Bilddatei, so lautet die Schlussfolgerung der Dokumentation.

Das Problem wirkt sich direkt auf das Layout aus. Ein Bild mit 1365x2048, das als 9:16 in eine Hochformat-Vorlage gesetzt wird, erzeugt Leerflächen oder Verzerrungen, und das Hauptmotiv kann abgeschnitten werden.

Der Nutzen für Sie: Nach der Lektüre wissen Sie, warum Sie sich bei den 2K/4K-Stufen nicht auf Antwortfelder verlassen sollten. Außerdem lernen Sie, nach dem Speichern des Bildes die echten Pixelmaße auszulesen und diese an die Layout-Logik zu übergeben.

gpt-image-2-6-all-2k-4k-real-image-size-de-image-0

gpt-image-2.6-all 2K/4K: Die wichtigsten Punkte zur Bildgröße

Die folgende Tabelle fasst zusammen, was die Dokumentation zur Bildgröße sagt. Der Code und das Layout-Konzept weiter unten basieren auf diesen Angaben.

Punkt Erläuterung Auswirkung auf das Layout
2K/4K sind Upscaling-Stufen Die finale Datei durchläuft ein Upscaling, die Pixelmaße legt dieser Schritt fest Die endgültige Größe lässt sich nicht aus den Anfrageparametern ableiten
size wird eventuell nicht zurückgegeben In der Antwort der 2K/4K-Stufen fehlt das Feld size möglicherweise Wenn Ihr Code sich auf dieses Feld verlässt, erhält er leere Werte oder wirft einen Fehler
Gelegentliche Pixelabweichungen Bei 9:16 kommt gelegentlich 1365x2048 vor, bei 4K gelegentlich 4096x2731 Das Seitenverhältnis kann vom angefragten Verhältnis abweichen
quality=low verhält sich anders Die 2K-Stufe gibt womöglich 2048x1153 aus Ungerade Kantenlängen führen in manchen Video-Encoding-Pipelines zu Fehlern
Maßgeblich ist die tatsächliche Breite und Höhe Laut Dokumentation zählen die realen Maße der Bilddatei Erst das Bild speichern und dann die Pixel auslesen – nur so bekommen Sie verlässliche Daten

Warum das size-Feld bei gpt-image-2.6-all 2K/4K nicht verlässlich ist

Stellen Sie sich die Upscaling-Stufen als zwei Schritte vor: Zuerst entsteht ein Basisbild, das anschließend auf 2K oder 4K vergrößert wird. Die Pixelmaße der finalen Datei bestimmt der Upscaling-Schritt. Das size-Feld in der Antwortstruktur ist damit nicht zwingend synchron. Die Dokumentation formuliert es für 2K/4K so, dass size „möglicherweise nicht zurückgegeben wird“. Derselbe Code kann das Feld also mal lesen und mal nicht.

Heikler ist der Fall, in dem das Feld zwar vorhanden ist, aber nicht zur Datei passt. Dann gibt es keinen Fehler, und die Werte sehen unauffällig aus – das Problem fällt erst auf, wenn das Layout fertig ist und schiefsitzt. Sicherer ist es deshalb, size gar nicht als Quelle für die Bildgröße zu verwenden. Allenfalls taugt es als Vergleichswert im Log. Für das Layout lesen Sie Breite und Höhe immer aus der gespeicherten Bilddatei aus.

gpt-image-2.6-all 2K/4K: Bekannte Pixelabweichungen im Überblick

In der Dokumentation sind einige gelegentlich auftretende Pixelabweichungen aufgeführt. Die folgende Tabelle rechnet diese Pixelwerte in Seitenverhältnisse um, damit sich leichter einschätzen lässt, wie sie sich aufs Layout auswirken.

Szenario Mögliche tatsächliche Pixelgröße Umgerechnetes Seitenverhältnis Layout-Risiko
9:16-Verhältnis 1365x2048 ca. 0,667, nahe 2:3 Bei Platzierung in einer 9:16-Vorlage entstehen seitliche Ränder oder der Rand wird abgeschnitten
4K-Stufe 4096x2731 ca. 1,5, nahe 3:2 Die kurze Seite weicht von der Erwartung ab, feste Zeichenflächen verrutschen
2K-Stufe + quality=low 2048x1153 ca. 1,776, nahe 16:9 Die Höhe ist ungerade, Encoder-Workflows mit geraden Kantenlängen schlagen fehl

Diese Beispiele zeigen: Die lange Seite liegt meist bei 2048 oder 4096, die kurze Seite dagegen ist nicht festgelegt. Im ersten Fall ist die Abweichung beim Seitenverhältnis deutlich: 9:16 entspricht etwa 0,5625, 1365x2048 dagegen etwa 0,667. Wenn der Code die Zeichenfläche anhand des angeforderten 9:16 berechnet, fallen die Ränder sofort ins Auge. Im dritten Fall bleibt das Seitenverhältnis fast unverändert, aber 1153 ist eine ungerade Zahl. Gängige Pixelformate für Videocodierung verlangen gerade Werte für Breite und Höhe. Wer so ein Bild direkt als Videocover oder erstes Frame verwendet, kann beim Transcodieren auf Fehler stoßen.

Alle diese Fälle treten nur „gelegentlich“ auf. Bei ein paar Testbildern läuft vielleicht alles glatt, und erst nach dem Livegang tauchen sie auf. Deshalb gehört die Validierung nach jeder einzelnen Generierung in den Code und nicht nur als Stichprobe in die Testphase.

gpt-image-2-6-all-2k-4k-real-image-size-de-image-1

gpt-image-2.6-all 2K/4K Schnellstart: Echte Pixelmaße auslesen

Die Kernidee in einem Satz: Zuerst holen Sie sich den Binärinhalt des Bildes und speichern ihn, dann lesen Sie Breite und Höhe mit einer Bildbibliothek aus. Das folgende Beispiel verwendet das OpenAI-kompatible Python-SDK und Pillow. Wie die Anfrageparameter für die 2K/4K-Stufen, Seitenverhältnisse usw. genau aussehen, entnehmen Sie bitte der APIYI-Dokumentation. Im Beispiel stehen dafür nur Platzhalter.

Minimalbeispiel: Antwortfeld size und echte Pixel im Vergleich

Dieser Code erzeugt ein Bild und gibt anschließend sowohl das Antwortfeld als auch die echten Pixelmaße aus. So sehen Sie den Unterschied direkt.

import base64， io， requests
from openai import OpenAI
from PIL import Image

client = OpenAI（api_key="YOUR_API_KEY"， base_url="https://api.apiyi.com/v1"）

resp = client.images.generate（
    model="gpt-image-2.6-all"，
    prompt="一张竖版城市夜景海报"，
    # 2K/4K-Stufenparameter gemäß APIYI-Dokumentation eintragen
）
item = resp.data[0]
raw = base64.b64decode（item.b64_json） if item.b64_json else requests.get（item.url， timeout=120）.content

img = Image.open（io.BytesIO（raw））
print（"真实像素："， img.size）                       # (Breite, Höhe)
print（"响应 size:"， getattr（resp， "size"， None））   # bei 2K/4K möglicherweise None

Im Code wird size per getattr gelesen, damit keine Exception auftritt, falls das Feld fehlt. Außerdem deckt der Code beide Rückgabeformen ab, URL und Base64, sodass die weitere Logik nur vom Binärinhalt des Bildes abhängt. Falls Ihr Zugang laut Dokumentation über eine andere Schnittstelle läuft, tauschen Sie einfach den Schritt „Bildinhalt holen“ aus. Der Teil, der die Pixelmaße ausliest, bleibt komplett unverändert.

Vollständige Implementierung: Nach dem Speichern prüfen und Layout-Parameter erzeugen

In der Produktion empfiehlt es sich, mehrere Schritte in einer einzigen Funktion zu bündeln: Datei speichern, die tatsächliche Breite und Höhe auslesen, sie mit den Antwortfeldern abgleichen, auf Seitenverhältnis-Drift und ungerade Kantenlängen prüfen und anschließend das Skalierungsergebnis anhand der echten Größe berechnen.

import base64
import io
from pathlib import Path
from uuid import uuid4

import requests
from openai import OpenAI
from PIL import Image

client = OpenAI（
    api_key="YOUR_API_KEY"，
    base_url="https://api.apiyi.com/v1",
）

# Parameter wie 2K/4K-Stufe und Seitenverhältnis richten sich nach der APIYI-Dokumentation; hier nur ein Platzhalter
TIER_PARAMS = {}


def fetch_image_bytes（item） -> bytes:
    if getattr（item， "b64_json"， None）:
        return base64.b64decode（item.b64_json）
    return requests.get（item.url， timeout=120）.content


def parse_declared_size（resp）:
    size = getattr（resp， "size"， None）
    if not size or "x" not in str（size）.lower（）:
        return None
    w， h = str（size）.lower（）.split（"x"）
    return int（w）， int（h）


def generate_and_measure（prompt， expected_ratio=None， out_dir="outputs"）:
    resp = client.images.generate（
        model="gpt-image-2.6-all"，
        prompt=prompt，
        **TIER_PARAMS，
    ）
    raw = fetch_image_bytes（resp.data[0]）
    img = Image.open（io.BytesIO（raw））
    width， height = img.size  # Einzige verlässliche Quelle für die Bildgröße

    Path（out_dir）.mkdir（exist_ok=True）
    ext = （img.format or "png"）.lower（）
    path = Path（out_dir） / f"{uuid4（）.hex[:8]}_{width}x{height}.{ext}"
    path.write_bytes（raw）

    declared = parse_declared_size（resp）
    report = {
        "path": str（path），
        "width": width，
        "height": height，
        "declared": declared，
        "declared_match": （declared == （width， height）） if declared else None，
        "odd_dimension": width % 2 == 1 or height % 2 == 1，
    }
    if expected_ratio:
        real_ratio = width / height
        report["ratio_drift"] = round（abs（real_ratio - expected_ratio） / expected_ratio， 4）
    return report


def fit_into_box（width， height， box_w， box_h， mode="contain"）:
    if mode == "contain":
        scale = min（box_w / width， box_h / height）
    else:
        scale = max（box_w / width， box_h / height）
    return round（width * scale）， round（height * scale）


if __name__ == "__main__":
    r = generate_and_measure（"竖版城市夜景海报"， expected_ratio=9 / 16）
    print（r）
    if r.get（"ratio_drift"， 0） > 0.01:
        print（"比例漂移超过 1%，建议改用 contain 或重新生成"）
    print（fit_into_box（r["width"]， r["height"]， 1080， 1920））

Drei Designentscheidungen in dieser Implementierung verdienen eine kurze Erklärung:

  • Die echte Breite und Höhe stehen im Dateinamen: Nachgelagerte Dienste müssen das Bild nicht erneut dekodieren, sondern lesen die Größe direkt aus dem Dateinamen ab.
  • declared_match dient nur dem Logging: Damit lässt sich erfassen, wie oft Felder fehlen oder nicht übereinstimmen. In die Layout-Berechnung fließt der Wert aber nicht ein.
  • odd_dimension fängt Problemfälle früh ab: Bei Bildern wie 2048x1153 können Sie vor der Videokodierung 1 Pixel abschneiden oder auffüllen.

🚀 Tipp für den schnellen Einstieg: Testen Sie zunächst auf APIYI (apiyi.com) mit einem einzigen Schlüssel beide Stufen, 2K und 4K, und geben Sie den obigen report aus. So sehen Sie, wie häufig Felder fehlen und das Seitenverhältnis driftet, und können danach die Fehlertoleranz-Schwellenwerte für den Livebetrieb festlegen. Die Plattform nutzt eine OpenAI-kompatible Schnittstelle, der Beispielcode läuft also, sobald Sie base_url angepasst haben.

gpt-image-2.6-all 2K/4K Layout-Anpassung

Die echten Pixelmaße zu kennen, ist erst der erste Schritt. Als Nächstes soll die gesamte Layout-Logik auf genau diesen Daten aufbauen. Dazu vergleichen wir zunächst drei Quellen für Größenangaben und klären, welche davon sich als Entscheidungsgrundlage eignet.

Informationsquelle Zuverlässigkeit Verhalten bei 2K/4K Empfohlene Verwendung
Beim Request gewählte Stufe und Seitenverhältnis Niedrig Die tatsächlichen Pixel nach dem Upscaling können abweichen Als erwarteter Wert, dient als Referenz für Seitenverhältnis-Drift
Das Feld size in der Antwort Niedrig Wird womöglich nicht zurückgegeben oder stimmt nicht mit der Datei überein Nur ins Log schreiben, für Statistiken
Echte Breite und Höhe der Bilddatei Hoch Laut Dokumentation maßgeblich Einzige Grundlage für Layout, Zuschnitt und Kodierung

Echte Breite und Höhe von gpt-image-2.6-all 2K/4K in den einzelnen Phasen auslesen

Ein Bild wird womöglich im Backend erzeugt, im Frontend angezeigt und am Ende an ein Video-Tool übergeben. In jeder Phase gibt es eine passende Methode, die echten Pixelmaße auszulesen. Die Größenangaben müssen also nicht durch die gesamte Kette durchgereicht werden.

Phase Auslesemethode Hinweise
Python-Backend Image.open(...).size von Pillow Es wird nur der Dateikopf gelesen, um Breite und Höhe zu bekommen – der Aufwand ist minimal
Browser-Frontend img.naturalWidth / img.naturalHeight Erst nach onload auslesen, nicht die per CSS gerenderte Größe verwenden
Kommandozeile oder Transkodierung ffprobe oder identify von ImageMagick Vor dem Kodieren gleich prüfen, ob die Seitenlängen gerade sind
Objektspeicher Beim Upload Breite und Höhe in Metadaten oder Dateinamen schreiben Nachgelagerte Dienste lesen sie direkt aus, ohne erneut zu dekodieren

Das Frontend ist die Stelle, an der man am leichtesten in die Falle tappt. Viele Komponenten setzen für Bilder eine feste Breite und Höhe. Dann liest man die gerenderte Größe aus und nicht die Pixel des Bildes selbst. Ob das Originalbild nahe an 9:16 liegt, sollten Sie daher über naturalWidth und naturalHeight prüfen.

Umgang mit Seitenverhältnis-Drift bei gpt-image-2.6-all in 2K/4K

Die Drift beim Seitenverhältnis lässt sich nicht vollständig vermeiden. Man kann aber vorab festlegen, wie man damit umgeht. Die folgenden drei Strategien sind nach steigendem Risiko geordnet.

Strategie Vorgehen Geeignet für Preis, den man zahlt
contain-Anpassung Das Bild wird proportional auf die tatsächliche Breite und Höhe skaliert und passt vollständig in die Zeichenfläche Poster, Produktdetailseiten und andere Fälle, in denen das Motiv nicht beschnitten werden darf Es können Leerflächen entstehen, die mit einer Hintergrundfarbe oder einem unscharfen Hintergrundbild gefüllt werden müssen
cover-Beschnitt Das Bild wird proportional vergrößert, bis es die Zeichenfläche ausfüllt, überstehende Teile werden abgeschnitten Titelbilder, Banner und andere Fälle, in denen Randinformationen unwichtig sind Liegt das Motiv am Rand, wird es womöglich angeschnitten
Neuerzeugung bei Drift Überschreitet die Abweichung beim Seitenverhältnis einen Schwellenwert, wird das Bild neu erzeugt Vorlagen mit strengen Anforderungen ans Seitenverhältnis Ein zusätzlicher Aufruf kostet Geld und Wartezeit

Bei ungeraden Kantenlängen empfiehlt es sich, diese vor dem Encoding einheitlich zu behandeln: Entweder schneidet man 1 Pixel ab oder fügt einen 1 Pixel breiten einfarbigen Rand hinzu. Wird 2048x1153 auf 2048x1152 zugeschnitten, ergibt sich exakt das Standardformat 16:9, und optisch ist der Unterschied kaum zu erkennen.

gpt-image-2-6-all-2k-4k-real-image-size-de-image-2

gpt-image-2.6-all 2K/4K: Häufige Fragen (FAQ)

Q1: Was ist die 2K/4K-Stufe von gpt-image-2.6-all?

Laut der Modellbeschreibung von APIYI vom 11.11.2026 sind 2K/4K Upscaling-Stufen: Das fertige Bild wird per Super-Resolution hochskaliert und erst dann ausgegeben. Deshalb verhalten sich die Größen anders als bei den normalen Stufen: Die Antwort gibt `size` unter Umständen nicht zurück, und die tatsächlichen Pixelmaße weichen gelegentlich ab.

Q2: Welcher Größe soll ich vertrauen: dem `size` in der Antwort oder den echten Maßen der Datei?

Der Datei. In der Dokumentation steht ausdrücklich, dass die tatsächliche Breite und Höhe des Bildes maßgeblich sind. Das `size` in der Antwort kann bei 2K/4K fehlen. Selbst wenn es vorhanden ist, taugt es nur fürs Logging. Verwenden Sie es nicht, um Canvas, Zuschnittsbereiche oder Encoding-Parameter zu berechnen.

Q3: Welche Abweichungen von der erwarteten Größe sind bekannt?

In der Dokumentation werden folgende Fälle genannt: Bei 9:16 kommt gelegentlich `1365×2048` heraus, bei 4K gelegentlich `4096×2731`, und mit quality=low kann die 2K-Stufe `2048×1153` liefern. Das passiert nur sporadisch. Deshalb sollte die Prüfung nach jeder Generierung laufen und nicht nur stichprobenartig in der Testphase.

Q4: Reicht es, in der Testphase ein paar Bilder zu prüfen und nach dem Livegang nicht mehr?

Davon raten wir ab. Sporadische Probleme tauchen bei kleinen Testmengen sehr wahrscheinlich kein einziges Mal auf. Das Auslesen von Breite und Höhe kostet kaum etwas, denn Pillow muss nur den Dateikopf parsen. Bauen Sie die Prüfung direkt in die Generierungsfunktion ein. Das ist deutlich weniger Aufwand, als später verschobene Layouts zu suchen.

Q5: Wie rufe ich gpt-image-2.6-all schnell per API auf und prüfe die Größe?

So gehen Sie vor:

1. Registrieren Sie ein Konto bei APIYI (apiyi.com) und holen Sie sich Ihren API-Schlüssel sowie das Testguthaben für Neukunden.
2. Setzen Sie `base_url` im Beispielcode auf `https://api.apiyi.com/v1` und tragen Sie den Stufenparameter gemäß der Dokumentation ein.
3. Führen Sie den vollständigen Beispielcode aus und sehen Sie sich im Report `declared_match`, `ratio_drift` und `odd_dimension` an.

Q6: Welche Folgen hat eine ungerade Höhe in der 2K-Stufe?

Für die reine Anzeige als statisches Bild meist keine. Wenn Sie das Bild aber als erstes Videobild, Cover oder Ausgangsmaterial für die Transkodierung verwenden, verlangen viele Encoding-Pipelines gerade Werte für Breite und Höhe. Bei Maßen wie `2048×1153` empfehlen wir, 1 Pixel abzuschneiden oder aufzufüllen, bevor das Bild an den Encoder geht.

Q7: Wie wird gpt-image-2.6-all abgerechnet?

Laut Dokumentation wird pro Aufruf abgerechnet, mit 0,025 $ je Aufruf. Wenn Sie die Strategie „Wiederholen, sobald die Seitenverhältnis-Abweichung den Schwellenwert überschreitet“ einsetzen, müssen Sie die Wiederholungen in die Kosten einrechnen. Sie können zunächst mit dem Testguthaben bei APIYI (apiyi.com) ermitteln, wie häufig die Abweichungen auftreten, und danach entscheiden, wie streng der Schwellenwert sein soll.

gpt-image-2.6-all 2K/4K: Die wichtigsten Punkte (Key Takeaways)

  • 2K/4K ist eine Upscaling-Stufe: Die endgültigen Pixelmaße ergeben sich erst im Upscaling-Schritt und lassen sich nicht aus den Anfrageparametern ableiten.
  • Verlassen Sie sich nicht auf das Feld size: Bei 2K/4K-Antworten wird size unter Umständen nicht zurückgegeben. Höchstens taugt es für den Abgleich im Log.
  • Abweichungen treten sporadisch auf und sind schwer reproduzierbar: 1365x2048, 4096x2731 und 2048x1153 können im Live-Betrieb alle vorkommen.
  • Erst speichern, dann die Pixel auslesen: Lesen Sie die tatsächliche Breite und Höhe der Datei mit Pillow oder naturalWidth aus, bevor Sie das Layout berechnen.
  • Ungerade Kantenlängen früh behandeln: Schneiden Sie vor der Videokodierung 1 Pixel ab oder füllen Sie 1 Pixel auf.
  • Schwellenwerte mit Testguthaben bestimmen: Ermitteln Sie über APIYI (apiyi.com) in kleinen Stichproben, wie häufig die Abweichungen auftreten, und legen Sie danach Ihre Retry-Strategie fest.

Fazit

Worauf es bei der Größenverarbeitung von gpt-image-2.6-all in 2K/4K ankommt:

  1. Vertrauen Sie nicht dem size-Wert in der Antwort: Bei der Upscaling-Stufe fehlt er unter Umständen, und selbst wenn das Feld vorhanden ist, kann es von der Datei abweichen.
  2. Maßgeblich sind die tatsächlichen Maße des Bildes: Lesen Sie nach dem Speichern die Pixel aus. Genau das schreibt die Dokumentation ausdrücklich als Entscheidungsgrundlage vor.
  3. Die Layoutlogik sollte Abweichungen tolerieren: Fangen Sie Seitenverhältnis-Abweichungen mit contain, cover oder einer Retry-Strategie ab und behandeln Sie ungerade Kantenlängen frühzeitig.

Wenn Sie das Auslesen der echten Pixel direkt in Ihre Generierungsfunktion einbauen, vermeiden Sie Layoutfehler schon an der Quelle. Die nachgelagerten Schritte müssen sich dann nicht mehr darum kümmern, ob die Felder der Antwort zuverlässig sind. Wir empfehlen, den obigen Prüfablauf über APIYI (apiyi.com) mit nur einem API-Schlüssel durchzuspielen und erst dann live zu gehen, wenn die 2K/4K-Stufe in Ihrer Vorlage stabil funktioniert.

📚 Referenzen

  1. APIYI gpt-image-2.6-all – Einführungshinweise: 2K/4K-Upscaling-Stufen, Rückgabe von size und tatsächliche Pixelmaße
  2. Link: docs.apiyi.com/live/2026-11/gpt-image-2-6-all-launch

  3. Beschreibung: Enthält die Definition der Upscaling-Stufen, Hinweise zu gelegentlichen Pixelabweichungen, den Hinweis, dass die tatsächliche Breite und Höhe maßgeblich sind, sowie den Preis pro Aufruf

  4. Offizielle Pillow-Dokumentation: Python-Bibliothek zum Lesen von Bildern

  5. Link: pillow.readthedocs.io

  6. Beschreibung: Verwendung von Image.open und dem Attribut size, geeignet zum Auslesen der echten Pixelmaße im Backend

  7. MDN-Dokumentation zu HTMLImageElement: Beschreibung der Bildeigenschaften im Browser

  8. Link: developer.mozilla.org/docs/Web/API/HTMLImageElement
  9. Beschreibung: Bedeutung von naturalWidth und naturalHeight sowie der Unterschied zur gerenderten Größe

Autor: APIYI Technikteam
Austausch: Kontaktieren Sie uns gern über die Startseite von APIYI. Weitere Informationen finden Sie im Dokumentationszentrum unter docs.apiyi.com

Weiterführende Artikel

Ähnliche Beiträge