gpt-image-2.6-all de 2K/4K: no te fíes del size que devuelve la respuesta

Nota del autor: en gpt-image-2.6-all, los niveles 2K/4K son de superresolución, así que la respuesta puede no devolver size y los píxeles reales a veces se desvían de lo esperado. Este artículo explica el motivo y muestra cómo guardar la imagen, leer su ancho y alto reales y solo entonces maquetar.

Mucha gente integra la API de generación de imágenes en pipelines de plantillas de póster, imágenes principales de e-commerce o portadas de vídeo, y lee directamente el campo size de la respuesta para calcular el lienzo y el diseño. Con los niveles 2K/4K de gpt-image-2.6-all, eso es arriesgado. En la descripción del modelo que APIYI (apiyi.com) publicó el 2026-11-11 se indica que 2K/4K son niveles de superresolución, que la respuesta puede no devolver size y que, en algunos casos, los píxeles reales también difieren de los esperados. El tamaño real es el ancho y alto del archivo de imagen, y esa es la conclusión de la documentación.

Este problema afecta directamente al resultado de la maquetación. Si una imagen de 1365x2048 se trata como 9:16 y se mete en una plantilla vertical, aparecerán márgenes en blanco o deformaciones, y hasta puede quedar recortado el sujeto principal.

Valor central: al terminar el artículo sabrás por qué no conviene depender de los campos de la respuesta en los niveles 2K/4K, y aprenderás a leer los píxeles reales tras guardar la imagen y pasárselos a la lógica de maquetación.

---

Puntos clave de los tamaños 2K/4K en gpt-image-2.6-all

La siguiente tabla resume la información de la documentación relacionada con el tamaño. El código y el esquema de maquetación posteriores se basan en estos datos.

Punto clave	Descripción	Impacto en la maquetación
2K/4K son niveles de superresolución	El archivo final pasa por un proceso de superresolución, y los píxeles los determina esa etapa	No se puede calcular el tamaño final a partir de los parámetros de la solicitud
Puede que size no se devuelva	En los niveles 2K/4K, es posible que la respuesta no incluya el campo size	Si el código depende de ese campo, obtendrá un valor vacío o lanzará un error
Desviaciones ocasionales de píxeles	En 9:16 aparece a veces 1365x2048, y en 4K a veces 4096x2731	La relación de aspecto puede diferir de la proporción solicitada
quality=low da resultados distintos	En el nivel 2K puede devolver 2048x1153	Aparecen lados con longitud impar, y algunos flujos de codificación de vídeo fallan
Lo que manda es el ancho y alto reales	La documentación indica claramente que se toma como referencia el ancho y alto reales del archivo de imagen	Guardar la imagen y leer sus píxeles después es la única fuente de datos fiable

Por qué el campo size de gpt-image-2.6-all no es fiable en 2K/4K

Puedes entender los niveles de superresolución como dos pasos: primero se genera una imagen base y luego se amplía a 2K o 4K. Los píxeles del archivo final los decide la etapa de superresolución, y el campo size de la respuesta no tiene por qué estar sincronizado con ella. La documentación describe el comportamiento en 2K/4K como «puede que no se devuelva size». Es decir, con el mismo código, a veces podrás leer este campo y a veces no.

El caso realmente problemático es cuando el campo existe pero no coincide con el archivo. El código no lanza ningún error, los valores parecen normales y el fallo solo se descubre cuando ya tienes el resultado de la maquetación. Por eso lo más seguro es no usar size como fuente del tamaño; como mucho, sirve para contrastarlo en los logs. El ancho y el alto que uses para maquetar deben leerse siempre del archivo de imagen guardado.

Interpretación de las desviaciones de píxeles conocidas en gpt-image-2.6-all 2K/4K

La documentación enumera varios casos de píxeles que aparecen de forma ocasional. La siguiente tabla convierte esos píxeles a relación de aspecto, para que sea más fácil valorar cómo afectan a la maquetación.

Escenario	Píxeles reales que pueden aparecer	Relación de aspecto calculada	Riesgo para la maquetación
Relación 9:16	1365x2048	Aprox. 0,667, cercana a 2:3	Al colocarla en una plantilla 9:16 quedan márgenes laterales o se recorta
Nivel 4K	4096x2731	Aprox. 1,5, cercana a 3:2	El lado corto no coincide con lo esperado y un lienzo fijo se desajusta
Nivel 2K + quality=low	2048x1153	Aprox. 1,776, cercana a 16:9	La altura es impar, y los flujos de codificación que exigen lados pares fallarán

Estos ejemplos muestran que el lado largo normalmente cae en 2048 o 4096, mientras que el lado corto no es fijo. En el primer caso la desviación de proporción es evidente: 9:16 equivale a unos 0,5625, y 1365x2048 es de aproximadamente 0,667. Si tu código calcula el lienzo según el 9:16 solicitado, los márgenes en blanco se notarán mucho. En el tercer caso la proporción casi no cambia, pero 1153 es un número impar. Los formatos de píxel habituales en la codificación de vídeo exigen que el ancho y el alto sean pares, así que si usas esa imagen directamente como portada o primer fotograma de un vídeo, la transcodificación puede dar error.

Todos estos casos son «ocasionales»: al probar con unas pocas imágenes puede que todo vaya bien, y los problemas solo aparecen una vez en producción. Por eso la lógica de validación debe ejecutarse después de cada generación, y no limitarse a revisiones puntuales durante la fase de pruebas.

---

Guía rápida de gpt-image-2.6-all en 2K/4K: leer los píxeles reales

La idea central se resume en una frase: primero obtén el contenido binario de la imagen y guárdalo, y luego lee el ancho y el alto con una librería de imágenes. El ejemplo de abajo usa el SDK de Python compatible con OpenAI y Pillow. Para saber cómo escribir exactamente los parámetros de la solicitud (nivel 2K/4K, relación de aspecto, etc.), consulta la documentación de APIYI; en el ejemplo solo dejo un marcador.

Ejemplo mínimo: comparar el size de la respuesta con los píxeles reales

Este código genera una imagen e imprime a la vez el campo de la respuesta y los píxeles reales, para que veas de un vistazo en qué se diferencian.

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="一张竖版城市夜景海报"，
    # Los parámetros del nivel 2K/4K se rellenan según la documentación de 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）                       # (ancho, alto)
print（"响应 size:"， getattr（resp， "size"， None））   # En 2K/4K puede ser None

En el código uso getattr para leer size y así evitar que se lance una excepción si el campo no existe. Además, el código admite tanto la respuesta con URL como la respuesta en base64, de modo que el resto de la lógica depende solo del contenido binario de la imagen. Si en la documentación tu forma de integración usa otro endpoint, solo tienes que cambiar el paso de «obtener el contenido de la imagen»; la parte que lee los píxeles no necesita ningún cambio.

Implementación completa: validar tras guardar y generar parámetros de maquetación

En producción conviene reunir en una sola función todo esto: guardar el archivo, leer el ancho y alto reales, compararlos con los campos de la respuesta, comprobar la deriva de proporción y los lados de longitud impar, y calcular el resultado del escalado con las dimensiones reales.

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",
）

# Los parámetros de nivel 2K/4K, proporciones, etc. dependen de la documentación de APIYI; aquí son solo un marcador de posición
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 única fuente fiable del tamaño

    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））

Esta implementación tiene tres decisiones de diseño que merece la pena explicar:

• El nombre del archivo incluye el ancho y alto reales: los servicios posteriores no necesitan decodificar la imagen otra vez; con mirar el nombre ya tienen las dimensiones.
• declared_match solo sirve para los logs: te ayuda a medir con qué frecuencia faltan campos o no coinciden, pero no interviene en el cálculo de la maquetación.
• odd_dimension actúa como filtro temprano: una imagen como 2048x1153 se puede recortar o rellenar 1 píxel antes de pasar al codificador de vídeo.

🚀 Recomendación para empezar: con una sola clave en APIYI (apiyi.com) puedes ejecutar los niveles 2K y 4K, imprimir el report de arriba y ver con qué frecuencia faltan campos o aparece deriva de proporción. Con esos datos decides el umbral de tolerancia en producción. La plataforma usa una interfaz compatible con OpenAI, así que el código de ejemplo funciona con solo cambiar base_url.

---

Adaptación del diseño para gpt-image-2.6-all en 2K/4K

Obtener los píxeles reales es solo el primer paso. El siguiente es que toda la lógica de maquetación funcione con esos datos. Primero comparemos las tres fuentes de información sobre el tamaño y veamos cuál sirve para tomar decisiones.

Fuente de información	Fiabilidad	Comportamiento en 2K/4K	Uso recomendado
Nivel y proporción elegidos en la solicitud	Baja	Tras el superescalado, los píxeles reales pueden desviarse	Expresar lo esperado y servir de referencia para detectar desvíos de proporción
Campo size de la respuesta	Baja	Puede que no aparezca o que no coincida con el archivo	Solo para registros y estadísticas
Ancho y alto reales del archivo de imagen	Alta	La documentación indica expresamente que es el valor de referencia	Única base para maquetación, recorte y codificación

Cómo leer el ancho y alto reales de gpt-image-2.6-all en 2K/4K en cada etapa

Una imagen puede generarse en el backend, mostrarse en el frontend y, al final, pasar a una herramienta de vídeo. Cada etapa tiene su propia forma de leer los píxeles reales, así que no hace falta arrastrar la información de tamaño de un extremo a otro.

Etapa	Método de lectura	Observaciones
Backend en Python	Image.open(...).size de Pillow	Solo lee la cabecera del archivo para obtener el ancho y alto, con un coste muy bajo
Frontend en el navegador	img.naturalWidth / img.naturalHeight	Léelos después de onload; no uses el tamaño renderizado por CSS
Línea de comandos o transcodificación	ffprobe o identify de ImageMagick	Aprovecha para comprobar, antes de codificar, que los lados tengan longitud par
Almacenamiento de objetos	Guarda el ancho y alto en los metadatos o en el nombre del archivo al subirlo	Los servicios posteriores los leen directamente, sin volver a decodificar

El frontend es donde más fácil se cae en la trampa. Muchos componentes asignan un ancho y alto fijos a la imagen, y entonces lo que lees es el tamaño renderizado, no los píxeles de la imagen en sí. Para saber si la imagen original se acerca a 9:16, hay que usar naturalWidth y naturalHeight.

Cómo gestionar la deriva de proporción en gpt-image-2.6-all a 2K/4K

La deriva de proporción no se puede eliminar del todo. Lo que sí puedes hacer es decidir de antemano qué harás cuando aparezca. Estas tres estrategias van ordenadas de menor a mayor riesgo.

Estrategia	Cómo funciona	Cuándo usarla	Coste
Ajuste contain	Escala la imagen manteniendo la proporción real de ancho y alto, de modo que quepa completa en el lienzo	Pósters, páginas de detalle de producto y otros casos donde el sujeto no se puede recortar	Pueden aparecer márgenes vacíos; hay que rellenarlos con un color de fondo o una imagen de fondo desenfocada
Recorte cover	Amplía la imagen manteniendo la proporción hasta cubrir todo el lienzo y recorta lo que sobresale	Portadas, banners y otros casos donde la información de los bordes no es importante	Si el sujeto está pegado al borde, se corre el riesgo de que se recorte
Reintento por deriva	Si la deriva de proporción supera un umbral, se vuelve a generar la imagen	Plantillas con requisitos estrictos de proporción	El coste de una llamada adicional y más tiempo de espera

Para los lados con longitud impar, te recomiendo tratarlos de forma uniforme antes de pasar al proceso de codificación: recorta 1 píxel o añade un borde de 1 píxel de color sólido. Si recortas 2048x1153 a 2048x1152, obtienes un 16:9 estándar exacto, y a simple vista casi no se nota la diferencia.

---

Preguntas frecuentes (FAQ) sobre 2K/4K en gpt-image-2.6-all

Q1: ¿Qué son los niveles 2K/4K de gpt-image-2.6-all?

Según la descripción del modelo que APIYI publicó el 2026-11-11, los niveles 2K/4K son niveles de superresolución: la imagen final se genera tras un proceso de superresolución. Por eso el comportamiento del tamaño es distinto al de los niveles normales: puede que la respuesta no devuelva `size`, y de vez en cuando los píxeles reales presentan desviaciones.

Q2: En los niveles 2K/4K, ¿en qué me fío más: el size de la respuesta o el tamaño real del archivo?

En el archivo. La documentación dice claramente que prevalece el ancho y alto reales de la imagen. En los niveles 2K/4K, el `size` de la respuesta puede no aparecer, y aunque esté, solo sirve para registrarlo en los logs: no lo uses para calcular el lienzo, las zonas de recorte ni los parámetros de codificación.

Q3: ¿Qué tamaños inesperados se han detectado ya?

La documentación menciona estos casos: a veces 9:16 sale como `1365×2048`, 4K a veces da `4096×2731`, y con quality=low en el nivel 2K puede salir `2048×1153`. Son casos esporádicos, así que la validación debe ejecutarse después de cada generación, no solo como una comprobación puntual durante las pruebas.

Q4: ¿Puedo validar solo unas cuantas imágenes en pruebas y no hacerlo en producción?

No lo recomendamos. Con una muestra pequeña es muy probable que el problema esporádico no aparezca ni una sola vez. Leer el ancho y el alto cuesta muy poco: Pillow solo necesita analizar la cabecera del archivo. Meter la validación directamente en la función de generación te ahorra mucho más trabajo que investigar a posteriori una maquetación descuadrada.

Q5: ¿Cómo invoco gpt-image-2.6-all por API y verifico el tamaño rápidamente?

Sigue estos pasos:

1. Regístrate en APIYI (apiyi.com) y obtén tu clave API junto con el crédito de prueba para nuevos usuarios
2. Configura el `base_url` del código de ejemplo como `https://api.apiyi.com/v1` y rellena el parámetro del nivel según la documentación
3. Ejecuta el código completo y revisa en el report los campos declared_match, ratio_drift y odd_dimension

Q6: ¿Qué efecto tiene una altura impar en el nivel 2K?

Para mostrar imágenes estáticas normalmente no pasa nada. Pero si vas a usar la imagen como primer fotograma de un vídeo, como portada o como material para transcodificar, muchos flujos de codificación exigen que el ancho y el alto sean pares. Si te sale un tamaño como `2048×1153`, te recomendamos recortar o rellenar 1 píxel antes de pasárselo al codificador.

Q7: ¿Cómo se factura gpt-image-2.6-all?

La documentación indica facturación por invocación, a $0.025 cada una. Si aplicas una estrategia de «reintentar cuando la desviación de proporción supere el umbral», tendrás que sumar los reintentos al coste. Puedes empezar usando el crédito de prueba en APIYI (apiyi.com) para medir la frecuencia de las desviaciones y, a partir de ahí, decidir lo estricto que quieres que sea el umbral.

---

gpt-image-2.6-all 2K/4K: puntos clave (Key Takeaways)

• 2K/4K es un nivel de superresolución: los píxeles finales los decide la etapa de superresolución, así que no se pueden deducir a partir de los parámetros de la solicitud.
• No dependas del campo size: las respuestas de 2K/4K pueden no devolver el valor de size; como mucho sirve para comparar en los logs.
• Las desviaciones son esporádicas y difíciles de reproducir: en producción pueden aparecer tamaños como 1365x2048, 4096x2731 o 2048x1153.
• Primero guarda, luego lee los píxeles: usa Pillow o naturalWidth para leer el ancho y el alto reales del archivo y después haz la maquetación.
• Trata los lados impares con antelación: antes de pasar al codificador de vídeo, recorta o rellena 1 píxel.
• Usa el crédito de prueba para fijar umbrales: con un lote pequeño en APIYI (apiyi.com) mide la frecuencia de la deriva y luego define tu estrategia de reintentos.

---

Resumen

Lo esencial para manejar los tamaños 2K/4K de gpt-image-2.6-all:

1. No te fíes del size de la respuesta: el nivel de superresolución puede no devolverlo y, si el campo existe, tampoco tiene por qué coincidir con el archivo.
2. Guíate por el ancho y el alto reales de la imagen: guarda la imagen y lee sus píxeles; es el criterio que indica expresamente la documentación.
3. Haz que tu lógica de maquetación tolere la deriva: usa contain, cover o una estrategia de reintentos para absorber las diferencias de proporción, y resuelve los lados impares desde el principio.

Si incorporas la lectura de los píxeles reales a tu función de generación, evitarás los desajustes de maquetación desde el origen y el resto del flujo ya no tendrá que preocuparse de si el campo de la respuesta es fiable. Te recomendamos usar APIYI (apiyi.com), con una sola clave API, para ejecutar el flujo de validación anterior y comprobar que los niveles 2K/4K se comportan de forma estable en tu plantilla antes de pasar a producción.

---

📚 Referencias

1. Nota de lanzamiento de gpt-image-2.6-all en APIYI: niveles de superresolución 2K/4K, eco del parámetro size y explicación de los píxeles reales
2. Enlace: docs.apiyi.com/live/2026-11/gpt-image-2-6-all-launch

3. Descripción: incluye la definición de los niveles de superresolución, los casos ocasionales en que los píxeles no coinciden, la aclaración de que prevalece el ancho y alto reales, y el precio por llamada

4. Documentación oficial de Pillow: biblioteca de Python para leer imágenes

5. Enlace: pillow.readthedocs.io

6. Descripción: uso de Image.open y del atributo size, ideal para leer los píxeles reales desde el backend

7. Documentación de HTMLImageElement en MDN: propiedades de imagen en el navegador

8. Enlace: developer.mozilla.org/docs/Web/API/HTMLImageElement
9. Descripción: qué significan naturalWidth y naturalHeight, y en qué se diferencian del tamaño renderizado

---

Autor: Equipo técnico de APIYI
Intercambio técnico: puedes contactarnos desde la página principal de APIYI; encontrarás más información en el centro de documentación docs.apiyi.com

Artículos relacionados

• Cómo elegir el canal de GPT-Image: diferencias entre los 3 tipos de canales (oficial directo y oficial inverso, -all, -vip), fallos históricos y 5 estrategias de respaldo: Comparar las diferencias entre los tres tipos de canales de GPT-Image (oficial, -all y -vip) en facturación, tamaños y edición local, revisar las fallas históricas de abril a octubre de 2026 y proponer una solución de respaldo con reintentos limitados, cortacircuitos y canal alterno.