Примечание автора: у gpt-image-2.6-all режимы 2K/4K работают через апскейл (супер-разрешение), поэтому в ответе поле size может не вернуться, а реальное количество пикселей иногда отличается от ожидаемого. В статье объясняю, почему так происходит, и показываю, как сохранить картинку, считать её настоящие ширину и высоту и только после этого верстать.
Многие подключают API генерации изображений к шаблонам постеров, главным картинкам для маркетплейсов или конвейеру обложек для видео и берут из ответа поле size, чтобы рассчитать холст и макет. Для режимов 2K/4K у gpt-image-2.6-all так делать рискованно. В описании модели, которое APIYI (apiyi.com) опубликовал 2026-11-11, прямо сказано: 2K/4K относятся к режимам с апскейлом, в ответе поле size может не вернуться, а в отдельных случаях реальные пиксели не совпадают с ожидаемыми. Ориентироваться нужно на фактические ширину и высоту файла изображения — таков вывод документации.
Эта проблема напрямую влияет на результат верстки. Если картинку 1365x2048 принять за 9:16 и поставить в вертикальный шаблон, в кадре появятся пустые поля или искажения, а главный объект могут обрезать.
Главная польза: после прочтения вы поймёте, почему в режимах 2K/4K нельзя полагаться на поля ответа, и научитесь считывать реальные пиксели после сохранения картинки, а затем передавать их в логику верстки.
Ключевые моменты по размерам gpt-image-2.6-all в 2K/4K
В таблице собрано всё, что документация говорит о размерах. Код и схемы вёрстки дальше опираются именно на эти сведения.
| Ключевой момент | Описание | Влияние на вёрстку |
|---|---|---|
| 2K/4K — это режимы с апскейлом | Итоговый файл проходит апскейл (суперразрешение), а число пикселей определяется на этом этапе | Итоговый размер нельзя вычислить по параметрам запроса |
| size может не возвращаться | В ответе для режимов 2K/4K поля size может не быть | Если код зависит от этого поля, он получит пустое значение или упадёт с ошибкой |
| Иногда пиксели отличаются от ожидаемых | Для 9:16 иногда приходит 1365x2048, для 4K — 4096x2731 |
Соотношение сторон может не совпасть с запрошенным |
| quality=low даёт отличия | В режиме 2K возможен результат 2048x1153 |
Появляются нечётные стороны, из-за которых часть видеокодеков выдаёт ошибку |
| Ориентируйтесь на реальные ширину и высоту | Документация прямо говорит: верить нужно фактическим ширине и высоте файла | Единственный надёжный источник данных — прочитать размеры пикселей после сохранения изображения |
Почему поле size у gpt-image-2.6-all в режимах 2K/4K ненадёжно
Режим с суперразрешением удобно представлять как два шага: сначала генерируется базовое изображение, затем оно увеличивается до 2K или 4K. Итоговые пиксели файла определяются на этапе апскейла, а поле size в структуре ответа с ним не обязательно синхронизировано. В документации про 2K/4K сказано, что size «может не возвращаться». Это значит, что один и тот же код иногда это поле прочитает, а иногда нет.
Хуже всего, когда поле есть, но не совпадает с реальным файлом. Код не падает, значения выглядят нормально, а ошибка вылезает только тогда, когда вы уже увидите результат вёрстки. Поэтому надёжнее вообще не использовать size как источник размеров: максимум — сверять его с логами. Ширину и высоту для вёрстки всегда берите из сохранённого файла изображения.
Известные отклонения в пикселях у gpt-image-2.6-all в режимах 2K/4K
В документации перечислено несколько случаев, когда размер в пикселях выходит нестандартным. В таблице ниже эти размеры пересчитаны в соотношения сторон, чтобы было проще понять, как они влияют на вёрстку.
| Сценарий | Возможный реальный размер в пикселях | Пересчитанное соотношение сторон | Риск для вёрстки |
|---|---|---|---|
| Соотношение 9:16 | 1365x2048 |
около 0,667, близко к 2:3 | При размещении в шаблоне 9:16 появятся поля по бокам или изображение обрежется |
| Режим 4K | 4096x2731 |
около 1,5, близко к 3:2 | Короткая сторона не совпадает с ожидаемой, фиксированный холст «поедет» |
| Режим 2K + quality=low | 2048x1153 |
около 1,776, близко к 16:9 | Высота нечётная, кодирование, которому нужны чётные стороны, завершится ошибкой |
Из этих примеров видно, что длинная сторона обычно равна 2048 или 4096, а короткая «плавает». В первом случае отклонение пропорций очень заметно: для 9:16 это примерно 0,5625, а у 1365x2048 — около 0,667. Если код считает холст исходя из запрошенных 9:16, поля будут бросаться в глаза. В третьем случае пропорции почти не изменились, но 1153 — нечётное число. Распространённые пиксельные форматы для видеокодирования требуют чётной ширины и высоты, так что если взять такое изображение как обложку или первый кадр видео, при транскодировании может возникнуть ошибка.
Все эти случаи «эпизодические»: при тестовом прогоне нескольких картинок всё может работать, а проблемы проявятся уже после запуска в продакшен. Поэтому проверку нужно делать после каждой генерации, а не только выборочно на этапе тестирования.
Быстрый старт с gpt-image-2.6-all в 2K/4K: читаем реальные пиксели
Идея в одном предложении: сначала получаем бинарное содержимое картинки и сохраняем его, а потом читаем ширину и высоту через библиотеку для работы с изображениями. В примере ниже используются OpenAI-совместимый Python SDK и Pillow. Как именно задавать параметры запроса (режимы 2K/4K, соотношение сторон и т. д.), смотрите в документации APIYI, в примере оставлены только заглушки.
Минимальный пример: сравниваем size из ответа и реальные пиксели
Этот код генерирует одну картинку, а затем печатает и поле из ответа, и реальный размер в пикселях. Так сразу видно, чем они отличаются.
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 заполняйте по документации 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） # (ширина, высота)
print（"响应 size:"， getattr（resp， "size"， None）） # В режимах 2K/4K может быть None
В коде size читается через getattr, чтобы не получить исключение, если поля нет. Заодно поддерживаются оба варианта ответа: URL и base64. Дальнейшая логика зависит только от бинарного содержимого картинки. Если по документации у вас используется другой эндпоинт, достаточно заменить шаг «получение содержимого картинки». Часть, где читаются пиксели, менять не нужно.
Полная реализация: проверка после сохранения и расчёт параметров вёрстки
В продакшене лучше собрать всё в одной функции: сохранить файл, прочитать реальные ширину и высоту, сверить их с полями ответа, проверить дрейф пропорций и нечётные стороны, а затем посчитать масштабирование по реальному размеру.
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",
）
# Параметры для уровней 2K/4K, пропорции и прочее берите из документации APIYI, здесь это лишь заглушка
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 # Единственный надёжный источник размеров
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））
В этой реализации стоит отметить три проектных решения:
- Реальные ширина и высота в имени файла: downstream-сервисам не нужно заново декодировать картинку — размеры видны прямо из имени.
- declared_match нужен только для логов: он помогает собирать статистику, как часто поле отсутствует или не совпадает с реальностью, но в расчёте вёрстки не участвует.
- odd_dimension перехватывает проблему заранее: у картинки вроде
2048x1153перед отправкой в видеокодер можно обрезать или добавить 1 пиксель.
🚀 Совет для быстрого старта: заведите один ключ на APIYI (apiyi.com) и прогоните оба режима — 2K и 4K. Распечатайте report, о котором шла речь выше, и посмотрите, как часто на практике пропадают поля и «плывут» пропорции. Только после этого выбирайте пороги отказоустойчивости для продакшена. Платформа работает через OpenAI-совместимый интерфейс, так что в примерах кода достаточно поменять base_url — и всё заработает.
Как адаптировать верстку под 2K/4K в gpt-image-2.6-all
Получить реальные пиксели — это только первый шаг. Дальше нужно, чтобы вся логика верстки опиралась именно на эти данные. Сначала сравним три источника информации о размере и решим, какому из них можно доверять при принятии решений.
| Источник информации | Надежность | Как ведет себя на 2K/4K | Для чего использовать |
|---|---|---|---|
| Режим и пропорции, выбранные в запросе | Низкая | После апскейла реальные пиксели могут отличаться | Фиксировать ожидание и служить эталоном для оценки дрейфа пропорций |
| Поле size в ответе | Низкая | Может не возвращаться вовсе или не совпадать с файлом | Только писать в лог для статистики |
| Реальные ширина и высота файла изображения | Высокая | В документации прямо сказано, что приоритет у них | Единственная основа для верстки, кадрирования и кодирования |
Как прочитать реальную ширину и высоту gpt-image-2.6-all в 2K/4K на разных этапах
Картинка может генерироваться на бэкенде, показываться на фронтенде, а потом попадать в видеоинструмент. На каждом этапе есть свой способ узнать реальные размеры в пикселях, так что тащить информацию о размерах через всю цепочку не нужно.
| Этап | Способ чтения | На что обратить внимание |
|---|---|---|
| Бэкенд на Python | Pillow: Image.open(...).size |
Для получения ширины и высоты читается только заголовок файла, так что накладные расходы минимальны |
| Браузерный фронтенд | img.naturalWidth / img.naturalHeight |
Читайте после onload и не берите размер, который получился после CSS-рендеринга |
| Командная строка или транскодирование | ffprobe или identify из ImageMagick |
Перед кодированием заодно проверьте, что стороны чётные |
| Объектное хранилище | При загрузке записывайте ширину и высоту в метаданные или в имя файла | Последующие сервисы читают их напрямую, без повторного декодирования |
Фронтенд — самое коварное место. Многие компоненты задают картинке фиксированные ширину и высоту, и тогда вы читаете размер после рендеринга, а не реальные пиксели изображения. Чтобы понять, близок ли оригинал к 9:16, используйте naturalWidth и naturalHeight.
Как справляться с дрейфом пропорций в gpt-image-2.6-all при 2K/4K
Полностью избавиться от дрейфа пропорций не получится. Зато можно заранее решить, что делать, когда он случится. Ниже три стратегии, от наименее рискованной к наиболее рискованной.
| Стратегия | Как делать | Когда подходит | Цена |
|---|---|---|---|
| Вписывание (contain) | Пропорционально масштабируем по реальной ширине и высоте, чтобы изображение целиком поместилось на холст | Постеры, карточки товаров и другие случаи, где главный объект нельзя обрезать | Могут появиться пустые поля, их придётся залить цветом фона или размытой подложкой |
| Обрезка по холсту (cover) | Пропорционально увеличиваем, чтобы закрыть весь холст, а лишнее обрезаем | Обложки, баннеры и другие случаи, где информация по краям не важна | Если объект расположен у края, его могут обрезать |
| Повторная генерация при дрейфе | Если дрейф пропорций превышает порог, генерируем изображение заново | Шаблоны со строгими требованиями к пропорциям | Лишний вызов: дополнительные расходы и время ожидания |
Если сторона получилась нечётной, лучше обработать это до кодирования: обрежьте 1 пиксель или добавьте рамку в 1 пиксель однотонного цвета. Например, 2048x1153 после обрезки до 2048x1152 становится точным 16:9, и на глаз разницы почти не видно.
gpt-image-2.6-all 2K/4K: часто задаваемые вопросы (FAQ)
Q1: Что такое режим 2K/4K в gpt-image-2.6-all?
Согласно описанию модели, опубликованному APIYI 2026-11-11, 2K/4K — это режимы с апскейлингом: готовое изображение проходит суперразрешение и только потом отдаётся. Отсюда и отличия в поведении размеров по сравнению с обычными режимами: в ответе может не быть поля size, а реальное разрешение иногда немного отклоняется от ожидаемого.
Q2: Чему верить в режиме 2K/4K: size из ответа или реальному размеру файла?
Файлу. В документации прямо сказано, что ориентироваться нужно на фактическую ширину и высоту изображения. В режимах 2K/4K поле size в ответе может отсутствовать, а если оно есть — годится только для логов. Не используйте его для расчёта холста, областей обрезки или параметров кодирования.
Q3: Какие неожиданные размеры уже известны?
В документации перечислены такие случаи: для 9:16 иногда получается `1365×2048`, для 4K иногда `4096×2731`, а при quality=low в режиме 2K может прийти `2048×1153`. Всё это случается эпизодически, поэтому проверку нужно запускать после каждой генерации, а не только выборочно на этапе тестов.
Q4: Можно ли проверить несколько картинок на тестах, а в продакшене проверку убрать?
Не стоит. На небольшой тестовой выборке эпизодические сбои вполне могут ни разу не проявиться. Чтение ширины и высоты почти ничего не стоит: Pillow достаточно разобрать заголовок файла. Встроить проверку прямо в функцию генерации намного проще, чем потом разбираться, почему поехала вёрстка.
Q5: Как быстро вызвать gpt-image-2.6-all через API и проверить размер?
Шаги такие:
1. Зарегистрируйтесь на APIYI (apiyi.com), получите API-ключ и тестовый баланс для новых пользователей
2. В примере кода укажите base_url `https://api.apiyi.com/v1`, а параметр режима заполните по документации
3. Запустите полный код реализации и посмотрите в report значения declared_match, ratio_drift и odd_dimension
Q6: Чем опасна нечётная высота в режиме 2K?
Для статичных картинок обычно ничем. Но если изображение пойдёт в качестве первого кадра видео, обложки или исходника для транскодирования, многие кодировщики требуют чётной ширины и высоты. Если вы получили размер вроде `2048×1153`, лучше обрезать или добавить 1 пиксель, а потом отдавать кодировщику.
Q7: Сколько стоит gpt-image-2.6-all?
В документации указана оплата за вызов: $0.025 за каждый. Если вы используете стратегию «повторять запрос, когда дрейф пропорций выше порога», количество повторов нужно закладывать в стоимость. Сначала можно оценить частоту дрейфа на тестовом балансе APIYI (apiyi.com), а уже потом решать, насколько строгий порог выставлять.
gpt-image-2.6-all 2K/4K: ключевые выводы (Key Takeaways)
- 2K/4K — это режим с апскейлом: итоговое число пикселей определяется на этапе суперразрешения, поэтому вычислить его по параметрам запроса нельзя.
- Не полагайтесь на поле size: в ответах для 2K/4K оно может не возвращаться, так что максимум — использовать его для сверки в логах.
- Отклонения случаются редко и плохо воспроизводятся: размеры
1365x2048,4096x2731и2048x1153могут появиться в продакшене. - Сначала сохраните, потом читайте пиксели: возьмите реальную ширину и высоту файла через Pillow или
naturalWidthи только после этого занимайтесь версткой. - Заранее обрабатывайте нечётные стороны: перед кодированием в видео обрежьте или добавьте 1 пиксель.
- Подберите пороги на тестовом балансе: прогоните небольшую партию через APIYI (apiyi.com), оцените частоту «дрейфа» размеров и только потом выбирайте стратегию повторных попыток.
Итоги
Что важно помнить при работе с размерами 2K/4K в gpt-image-2.6-all:
- Не верьте полю size в ответе: в режиме с апскейлом оно может не возвращаться, а если возвращается — может не совпадать с файлом.
- Ориентируйтесь на реальные размеры изображения: сохраните картинку и прочитайте пиксели. Именно этот критерий прямо указан в документации.
- Делайте верстку устойчивой к дрейфу: справляйтесь с отклонениями пропорций через contain, cover или повторные запросы, а нечётные стороны обрабатывайте заранее.
Если зашить чтение реальных пикселей прямо в функцию генерации, вы избавитесь от сбитой верстки в самом источнике, и дальше по пайплайну уже не придётся думать, насколько надёжны поля ответа. Рекомендую прогнать описанную выше проверку через APIYI (apiyi.com) с одним API-ключом и убедиться, что режимы 2K/4K стабильно работают в ваших шаблонах, а уже потом выкатывать в продакшен.
📚 Справочные материалы
- Описание запуска APIYI gpt-image-2.6-all: режимы 2K/4K со сверхразрешением, эхо-значение size и реальные пиксели
- Ссылка:
docs.apiyi.com/live/2026-11/gpt-image-2-6-all-launch -
Описание: определение режимов со сверхразрешением, случайные отклонения в пикселях, пояснение о том, что ориентироваться нужно на фактическую ширину и высоту, а также цена за один вызов
-
Официальная документация Pillow: библиотека Python для работы с изображениями
- Ссылка:
pillow.readthedocs.io -
Описание: как пользоваться
Image.openи атрибутомsize; подходит, чтобы читать реальные пиксели на бэкенде -
Документация MDN по HTMLImageElement: описание свойств изображений в браузере
- Ссылка:
developer.mozilla.org/docs/Web/API/HTMLImageElement - Описание: что означают naturalWidth и naturalHeight и чем они отличаются от размеров отрисовки
Автор: техническая команда APIYI
Обратная связь: пишите нам через главную страницу сайта APIYI, а больше материалов найдёте в центре документации docs.apiyi.com
