Note de l’auteur : les modes 2K/4K de gpt-image-2.6-all sont des modes de suréchantillonnage (super-résolution). La réponse peut ne pas renvoyer size, et les pixels réels s’écartent parfois de la taille demandée. Cet article explique pourquoi, puis présente une méthode simple : enregistrer l’image, lire sa largeur et sa hauteur réelles, et seulement ensuite lancer la mise en page.
Quand on branche une API de génération d’images sur un modèle d’affiche, une image principale de fiche produit ou une chaîne de création de miniatures vidéo, on lit souvent directement le champ size de la réponse pour calculer le canevas et la mise en page. Avec les modes 2K/4K de gpt-image-2.6-all, c’est risqué. Dans la description du modèle publiée le 2026-11-11, APIYI (apiyi.com) précise que les modes 2K/4K sont des modes de suréchantillonnage : la réponse peut ne pas renvoyer size, et dans certains cas les pixels réels diffèrent de ce qui était attendu. La taille de référence est la largeur et la hauteur réelles du fichier image : c’est la conclusion de la documentation.
Ce problème a un impact direct sur la mise en page. Une image de 1365x2048 traitée comme du 9:16 dans un modèle vertical produira des marges vides ou un étirement, et le sujet risque même d’être rogné.
L’essentiel : après avoir lu cet article, vous saurez pourquoi il ne faut pas se fier aux champs de la réponse pour les modes 2K/4K, et vous pourrez lire les pixels réels après l’enregistrement de l’image, avant de les passer à votre logique de mise en page.
gpt-image-2.6-all 2K/4K : les points clés sur la taille
Le tableau ci-dessous récapitule les informations de la documentation liées à la taille. Le code et les solutions de mise en page qui suivent s’appuient tous dessus.
| Point clé | Explication | Impact sur la mise en page |
|---|---|---|
| 2K/4K sont des paliers de suréchantillonnage | Le fichier final passe par une étape de super-résolution, et c’est elle qui détermine le nombre de pixels | On ne peut pas déduire la taille finale à partir des paramètres de la requête |
| Le champ size peut ne pas être renvoyé | Dans la réponse, les paliers 2K/4K peuvent ne pas contenir le champ size | Si votre code en dépend, il lira une valeur vide ou lèvera une erreur |
| Écarts ponctuels de pixels | En 9:16, on obtient parfois 1365x2048 ; en 4K, parfois 4096x2731 |
Le rapport largeur/hauteur peut différer de celui demandé |
| quality=low donne des résultats différents | Le palier 2K peut produire du 2048x1153 |
On se retrouve avec un côté impair, ce qui fait planter certains flux d’encodage vidéo |
| Seules les dimensions réelles comptent | La documentation indique clairement qu’il faut se fier à la largeur et à la hauteur réelles du fichier image | Lire les pixels après avoir enregistré l’image est la seule source de données fiable |
Pourquoi le champ size n’est pas fiable avec gpt-image-2.6-all en 2K/4K
On peut voir le palier de super-résolution comme un processus en deux temps : le modèle génère d’abord une image de base, puis l’agrandit en 2K ou en 4K. Les pixels du fichier final sont déterminés par l’étape de suréchantillonnage, et le champ size de la réponse n’est pas forcément synchronisé avec eux. Pour le 2K/4K, la documentation parle d’un size qui « peut ne pas être renvoyé ». Autrement dit, avec le même code, vous pouvez lire ce champ une fois et pas la suivante.
Le cas vraiment gênant, c’est quand le champ existe mais ne correspond pas au fichier. Le code ne plante pas, la valeur a l’air normale, et l’erreur n’apparaît qu’une fois la mise en page produite. Mieux vaut donc ne pas utiliser size comme source de la taille : au mieux, il sert à comparer dans les logs. Pour la mise en page, la largeur et la hauteur doivent toujours être lues directement dans le fichier image enregistré.
Écarts de pixels connus avec gpt-image-2.6-all en 2K/4K
La documentation liste plusieurs cas de pixels qui apparaissent de façon sporadique. Le tableau ci-dessous convertit ces dimensions en ratios largeur/hauteur, pour voir plus facilement leur impact sur la mise en page.
| Scénario | Pixels réels possibles | Ratio converti | Risque pour la mise en page |
|---|---|---|---|
| Ratio 9:16 | 1365x2048 |
environ 0,667, proche de 2:3 | Placée dans un gabarit 9:16, l’image laisse des marges sur les côtés ou se retrouve rognée |
| Niveau 4K | 4096x2731 |
environ 1,5, proche de 3:2 | Le petit côté ne correspond pas à l’attendu, un canevas fixe provoque un décalage |
| Niveau 2K + quality=low | 2048x1153 |
environ 1,776, proche de 16:9 | La hauteur est impaire, les flux d’encodage qui exigent des dimensions paires échouent |
Ces exemples montrent que le grand côté tombe généralement sur 2048 ou 4096, alors que le petit côté, lui, n’est pas fixe. Dans le premier cas, l’écart de ratio saute aux yeux : 9:16 vaut environ 0,5625, contre environ 0,667 pour 1365x2048. Si votre code calcule le canevas à partir du 9:16 demandé, les marges seront très visibles. Dans le troisième cas, le ratio ne change presque pas, mais 1153 est un nombre impair. Les formats de pixels courants pour l’encodage vidéo exigent une largeur et une hauteur paires : utiliser directement cette image comme couverture ou première image d’une vidéo peut donc provoquer une erreur au transcodage.
Ces situations sont « sporadiques » : en test, quelques images générées peuvent très bien passer sans problème, et c’est seulement une fois en production que vous tomberez dessus. La logique de vérification doit donc s’exécuter après chaque génération, et pas seulement sous forme d’échantillonnage pendant la phase de test.
Prise en main rapide de gpt-image-2.6-all en 2K/4K : lire les pixels réels
L’idée tient en une phrase : on récupère d’abord le contenu binaire de l’image et on l’enregistre, puis on lit sa largeur et sa hauteur avec une bibliothèque d’images. L’exemple ci-dessous utilise le SDK Python compatible OpenAI et Pillow. Pour la syntaxe exacte des paramètres de requête (niveau 2K/4K, ratio, etc.), reportez-vous à la documentation d’APIYI : l’exemple n’en garde que des emplacements réservés.
Exemple minimal : comparer le size de la réponse et les pixels réels
Ce code génère une image, puis affiche à la fois le champ de la réponse et les pixels réels, pour voir directement l’écart entre les deux.
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="一张竖版城市夜景海报"，
# Paramètres du niveau 2K/4K à renseigner selon la documentation APIYI
）
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） # (largeur, hauteur)
print（"响应 size:"， getattr（resp， "size"， None）） # Peut valoir None en 2K/4K
Le code utilise getattr pour lire size, afin de ne pas lever d’exception si le champ est absent. Il gère aussi les deux formes de retour, URL et base64, et la suite de la logique ne dépend que du contenu binaire de l’image. Si, d’après la documentation, votre mode d’accès passe par une autre interface, il suffit de remplacer l’étape « récupérer le contenu de l’image » : la partie qui lit les pixels n’a pas besoin de changer.
Implémentation complète : sauvegarder, valider, puis générer les paramètres de mise en page
En production, mieux vaut regrouper dans une seule fonction les étapes suivantes : sauvegarder le fichier, lire la largeur et la hauteur réelles, les comparer avec les champs de la réponse, vérifier la dérive de ratio et les dimensions impaires, puis calculer le redimensionnement à partir de la taille réelle.
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",
）
# Les paramètres des paliers 2K/4K, des ratios, etc. sont à vérifier dans la doc APIYI ; ici, simple espace réservé
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 # La seule source fiable pour les dimensions
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））
Trois choix de conception méritent quelques explications :
- Les dimensions réelles figurent dans le nom du fichier : les services en aval n’ont pas besoin de décoder à nouveau l’image, le nom du fichier suffit pour connaître sa taille.
declared_matchne sert qu’aux logs : il vous permet de mesurer la fréquence des champs manquants ou incohérents, mais n’entre pas dans le calcul de mise en page.odd_dimensionintercepte le problème en amont : une image comme2048x1153peut être rognée ou complétée d’un pixel avant de passer à l’encodage vidéo.
🚀 Conseil pour bien démarrer : sur APIYI (apiyi.com), prenez une seule clé API et lancez les paliers 2K et 4K l’un après l’autre. Affichez le
reportci-dessus pour observer la fréquence réelle des champs manquants et de la dérive de ratio, puis fixez vos seuils de tolérance en production. La plateforme utilise une interface compatible OpenAI : il suffit d’adapterbase_urldans l’exemple de code pour l’exécuter.
Adapter la mise en page de gpt-image-2.6-all en 2K/4K
Récupérer les pixels réels n’est que la première étape. Ensuite, il faut faire reposer toute la logique de mise en page sur ces données. Commençons par comparer trois sources d’information sur la taille, pour voir laquelle peut vraiment servir à prendre des décisions.
| Source d’information | Fiabilité | Comportement en 2K/4K | Usage recommandé |
|---|---|---|---|
| Le niveau et le ratio choisis dans la requête | Faible | Après suréchantillonnage, les pixels réels peuvent s’écarter de la valeur demandée | Exprimer l’intention, servir de référence pour mesurer la dérive du ratio |
| Le champ size de la réponse | Faible | Peut ne pas être renvoyé, ou différer du fichier réel | À consigner dans les journaux, pour les statistiques uniquement |
| La largeur et la hauteur réelles du fichier image | Élevée | La documentation indique explicitement que c’est la référence | Seule base pour la mise en page, le recadrage et l’encodage |
Lire la largeur et la hauteur réelles de gpt-image-2.6-all en 2K/4K à chaque étape
Une image peut être générée côté back-end, affichée côté front-end, puis transmise à un outil vidéo. À chaque étape, il existe un moyen de lire les pixels réels : inutile de faire circuler l’information de taille d’un bout à l’autre de la chaîne.
| Étape | Méthode de lecture | Points d’attention |
|---|---|---|
| Back-end Python | Image.open(...).size de Pillow |
Seul l’en-tête du fichier est lu pour obtenir les dimensions, le coût est très faible |
| Front-end navigateur | img.naturalWidth / img.naturalHeight |
À lire après onload, et non la taille de rendu CSS |
| Ligne de commande ou transcodage | ffprobe ou identify d’ImageMagick |
Avant l’encodage, vérifiez au passage que les côtés sont de longueur paire |
| Stockage d’objets | Écrire la largeur et la hauteur dans les métadonnées ou le nom de fichier lors de l’envoi | Les services en aval les lisent directement, sans avoir à décoder à nouveau |
Le front-end est l’étape où l’on tombe le plus facilement dans le piège. Beaucoup de composants imposent une largeur et une hauteur fixes à l’image : ce que vous lisez alors, c’est la taille de rendu, pas les pixels de l’image elle-même. Pour savoir si l’image d’origine est proche du 9:16, utilisez naturalWidth et naturalHeight.
Stratégies de gestion de la dérive de ratio avec gpt-image-2.6-all en 2K/4K
On ne peut pas éliminer complètement la dérive de ratio. Ce qu’on peut faire, c’est décider à l’avance comment la traiter quand elle se produit. Les trois stratégies ci-dessous sont classées du moins risqué au plus risqué.
| Stratégie | Méthode | Cas d’usage | Coût |
|---|---|---|---|
| Adaptation « contain » | Redimensionner proportionnellement selon la largeur et la hauteur réelles, pour que l’image tienne entièrement dans le canevas | Affiches, pages produit : tout cas où le sujet ne doit pas être rogné | Des marges vides peuvent apparaître ; il faut les remplir avec une couleur de fond ou une image d’arrière-plan floutée |
| Recadrage « cover » | Agrandir proportionnellement pour remplir le canevas, puis rogner ce qui dépasse | Couvertures, bannières : cas où les informations en périphérie importent peu | Risque de couper le sujet s’il est proche du bord |
| Nouvel essai en cas de dérive | Regénérer l’image dès que la dérive de ratio dépasse un seuil | Modèles de mise en page très stricts sur le ratio | Un appel supplémentaire, donc un coût et un temps d’attente en plus |
Pour les dimensions impaires, mieux vaut les traiter de façon uniforme avant l’étape d’encodage : rogner 1 pixel, ou ajouter une bordure de 1 pixel d’une couleur unie. Une image de 2048x1153 rognée en 2048x1152 donne exactement du 16:9 standard, et la différence est pratiquement invisible à l’œil.
FAQ gpt-image-2.6-all 2K/4K : questions fréquentes
Q1 : Qu’est-ce que le palier 2K/4K de gpt-image-2.6-all ?
D’après la description du modèle publiée par APIYI le 2026-11-11, les paliers 2K/4K sont des paliers de super-résolution : l’image finale est suréchantillonnée avant d’être renvoyée. C’est ce qui explique pourquoi la gestion des dimensions diffère des paliers classiques : la réponse peut ne pas renvoyer le champ size, et les pixels réels s’écartent parfois de la valeur attendue.
Q2 : Pour les paliers 2K/4K, faut-il se fier au size de la réponse ou aux dimensions réelles du fichier ?
Au fichier. La documentation indique clairement que ce sont la largeur et la hauteur réelles de l’image qui font foi. Avec les paliers 2K/4K, le size de la réponse peut être absent ; même quand il est présent, il ne sert qu’à alimenter les logs. Ne l’utilisez pas pour calculer un canevas, une zone de recadrage ou des paramètres d’encodage.
Q3 : Quelles dimensions inattendues a-t-on déjà observées ?
La documentation mentionne notamment : en 9:16, un `1365×2048` occasionnel ; en 4K, un `4096×2731` occasionnel ; avec quality=low sur le palier 2K, une sortie possible en `2048×1153`. Ces cas sont sporadiques, donc la vérification doit s’exécuter après chaque génération, et pas seulement en échantillonnage pendant les tests.
Q4 : Peut-on se contenter de vérifier quelques images pendant les tests, puis ne plus rien contrôler en production ?
Ce n’est pas recommandé. Avec un petit échantillon de test, il est tout à fait possible de ne jamais tomber sur le problème. Lire la largeur et la hauteur coûte très peu : Pillow n’a besoin que d’analyser l’en-tête du fichier. Intégrer la vérification directement dans la fonction de génération vous fera gagner bien du temps par rapport à la chasse aux mises en page décalées après coup.
Q5 : Comment appeler rapidement gpt-image-2.6-all via l’API et vérifier les dimensions ?
Voici les étapes :
1. Créez un compte sur APIYI (apiyi.com), puis récupérez votre clé API et le crédit de test offert aux nouveaux utilisateurs
2. Dans le code d’exemple, définissez base_url sur `https://api.apiyi.com/v1` et renseignez le paramètre de palier selon la documentation
3. Lancez le code complet, puis consultez dans le report les champs declared_match, ratio_drift et odd_dimension
Q6 : Quel impact a une hauteur impaire sur le palier 2K ?
Pour un simple affichage d’image fixe, généralement aucun. En revanche, si vous utilisez l’image comme première image d’une vidéo, comme couverture ou comme source de transcodage, de nombreuses chaînes d’encodage exigent une largeur et une hauteur paires. Face à une dimension comme `2048×1153`, mieux vaut rogner ou ajouter 1 pixel avant de la transmettre à l’encodeur.
Q7 : Comment gpt-image-2.6-all est-il facturé ?
La documentation indique une facturation à l’appel, à 0,025 $ par appel. Si vous adoptez une stratégie du type « on relance dès que la dérive de ratio dépasse un seuil », pensez à intégrer le nombre de relances dans votre coût. Vous pouvez d’abord mesurer la fréquence de dérive avec le crédit de test sur APIYI (apiyi.com), puis décider de la sévérité du seuil.
gpt-image-2.6-all 2K/4K : les points clés (Key Takeaways)
- Le 2K/4K est un palier de super-résolution : les pixels finaux dépendent de l’étape de super-résolution, on ne peut donc pas les déduire des paramètres de la requête.
- Ne vous fiez pas au champ size : les réponses en 2K/4K ne renvoient pas toujours la taille. Au mieux, ce champ sert à comparer avec vos logs.
- Les écarts sont sporadiques et difficiles à reproduire : en production, on peut voir apparaître
1365x2048,4096x2731ou2048x1153. - Enregistrez d’abord, lisez les pixels ensuite : avec Pillow ou naturalWidth, lisez la largeur et la hauteur réelles du fichier avant de faire votre mise en page.
- Gérez les dimensions impaires en amont : avant l’encodage vidéo, rognez ou complétez d’un pixel.
- Utilisez un crédit de test pour fixer vos seuils : sur APIYI (apiyi.com), mesurez sur un petit lot la fréquence des écarts, puis définissez votre stratégie de nouvelle tentative.
Résumé
Les points à retenir pour gérer les dimensions du 2K/4K avec gpt-image-2.6-all :
- Ne faites pas confiance au champ size de la réponse : le palier de super-résolution peut ne pas le renvoyer, et quand il est présent, il peut différer du fichier réel.
- Prenez la largeur et la hauteur réelles de l’image comme référence : après avoir enregistré l’image, lisez ses pixels. C’est le critère que la documentation indique explicitement.
- Rendez votre logique de mise en page tolérante aux écarts : utilisez contain, cover ou une stratégie de nouvelle tentative pour absorber les écarts de proportions, et gérez les dimensions impaires en amont.
Si vous intégrez la lecture des pixels réels directement dans votre fonction de génération, vous évitez les décalages de mise en page dès la source, et le reste de la chaîne n’a plus à se demander si le champ de la réponse est fiable. Nous vous conseillons de passer par APIYI (apiyi.com) pour dérouler le processus de vérification ci-dessus avec une seule clé API, et de vérifier que le palier 2K/4K reste stable dans vos modèles avant la mise en production.
📚 Références
- Note de lancement d’APIYI pour gpt-image-2.6-all : paliers de suréchantillonnage 2K/4K, écho du paramètre size et pixels réellement générés
- Lien :
docs.apiyi.com/live/2026-11/gpt-image-2-6-all-launch -
Description : définition des paliers de suréchantillonnage, cas occasionnels de résolution différente, précision selon laquelle seules la largeur et la hauteur réelles font foi, et tarification à l’appel
-
Documentation officielle de Pillow : bibliothèque Python de lecture d’images
- Lien :
pillow.readthedocs.io -
Description : utilisation de
Image.openet de l’attributsize, pratique pour lire les pixels réels côté backend -
Documentation MDN sur HTMLImageElement : propriétés d’image côté navigateur
- Lien :
developer.mozilla.org/docs/Web/API/HTMLImageElement - Description : signification de naturalWidth et naturalHeight, et différence avec la taille de rendu
Auteur : l’équipe technique d’APIYI
Échanges techniques : n’hésitez pas à nous contacter depuis la page d’accueil du site APIYI. Pour plus de ressources, rendez-vous dans le centre de documentation docs.apiyi.com
