Сжатие изображений и выходное разрешение

​

Две совершенно разные вещи

​

Сжатие качества или сжатие размеров? Что именно сжимает «компрессия»

• Фотография с iPhone 16 Pro имеет размер 4284×5712 (около 24 мегапикселей — очень много), но файл всего 4.6 MB, потому что система уже применила эффективное кодирование с потерями при сохранении;
• Фотография с тем же количеством пикселей, экспортированная в высоком качестве, может достигать 30 MB.

• Размеры в пикселях задают верхнюю границу того, сколько информации модель может «увидеть», и стоимость декодирования/понимания;
• Размер файла влияет на стоимость передачи: примерно 33% раздувание из-за Base64, время загрузки и ограничение в 20 MB на один файл относятся именно к байтам.

​

Разрешение вывода задается параметром размера, а не prompt

​

Пример: gemini-3-pro-image

{
  "contents": [ /* prompt text + input images (if any) */ ],
  "generationConfig": {
    "responseModalities": ["IMAGE"],
    "imageConfig": {
      "aspectRatio": "16:9",
      "imageSize": "4K"
    }
  }
}

​

Серия GPT image использует строку размера в пикселях

{
  "model": "gpt-image-...",
  "prompt": "...",
  "size": "2048x2048"
}

​

Ухудшает ли сжатие входного изображения резкость результата? В основном нет

1. Результат пересоздаётся, а не является увеличенной версией вашего изображения.
   Модель создаёт новое изображение в заданном вами размере. Разрешение результата зависит только от imageSize/size, а не от того, сколько пикселей было у входного изображения. Неважно, было ли входное изображение 3000px или сжато до 2000px: если вы выберете 4K, вы получите 4K.
2. Поле сжатия входа и поле размера результата независимы.
   Сжатие меняет только объём/количество пикселей в поле “image data” в запросе — оно никогда не затрагивает поле параметра размера. Эти два поля в запросе не связаны.
3. Рекомендуемое сжатие мягкое — значительно выше того, что модели нужно, чтобы “видеть” изображение.
   На практике сжатие референсного изображения до длинной стороны примерно 2048px при JPEG quality около 0.9 более чем достаточно, чтобы модель поняла композицию, цвета, стиль и детали объекта — эти модели всё равно внутренне уменьшают входные изображения до умеренного разрешения перед кодированием.

​

Чтобы быть строгими: пограничный случай

Разумное сжатие (длинная сторона 2048px, quality 0.9) → без заметного влияния на резкость результата;
только крайнее чрезмерное сжатие может вызвать потерю деталей в сценариях тонкой правки.

​

Практические настройки сжатия входных изображений

​

Сгенерированные изображения, поступающие в последующий workflow: обрабатывайте их тоже

​

Дополнительные рекомендации по обработке изображений

• Встраивайте ориентацию EXIF в пиксели: фотографии с телефона часто хранят сведения о повороте в теге EXIF Orientation, а не в самих пикселях. Некоторые конвейеры обработки игнорируют этот тег, поэтому модель видит изображение, повернутое набок или вверх ногами. Примените поворот к пикселям перед загрузкой (большинство библиотек сжатия делают это автоматически при повторном кодировании).
• Удаляйте приватные метаданные EXIF перед загрузкой: оригинальные фотографии часто содержат координаты GPS, модель устройства и время съемки в EXIF. Удаляйте метаданные перед отправкой пользовательских фотографий в сторонний API — повторное кодирование обычно делает это как побочный эффект, но следите за порядком: сначала примените ориентацию, затем удалите метаданные.
• Совместимость форматов: формат HEIC/HEIF по умолчанию на iPhone не поддерживается большинством image API — сначала конвертируйте в JPEG/PNG; используйте PNG/WebP для прозрачности; у анимированных GIF обычно считывается только первый кадр.
• Конвертируйте цветовое пространство в sRGB: фотографии устройств Apple часто используют Display P3. Конвейеры, которые игнорируют цветовой профиль, будут давать сдвиги цветов — перед загрузкой конвертируйте в sRGB.
• Выбирайте способ передачи под сценарий: на входной стороне Base64 — самый надежный вариант; загрузка по URL (fileUri) требует строгих условий CDN — см. Руководство разработчика серии Nano Banana, чтобы оценить компромиссы. На выходной стороне используйте Nano Banana OSS группу, чтобы получать URL вместо Base64.
• Выбирайте нужный вам уровень выходных данных: не запрашивайте 4K, если результат этого не требует — генерация будет медленнее, файлы больше, а последующая передача и обработка дороже. Сначала итеративно работайте в 1K/2K и переходите к 4K только для финального рендера.
• Своевременно сохраняйте URL-выходы: URL изображений, возвращаемые API, истекают. Переносите их в свое хранилище сразу после получения — никогда не воспринимайте временный URL как постоянный ресурс.

​

Краткая справка

• Выходное разрешение = параметр размера (imageSize / size / aspect_ratio), а не текст в prompt. Нужен 4K? Укажите параметр — не пишите это в prompt.
• gemini-3-pro-image использует imageSize с уровнями 1K / 2K / 4K (по умолчанию 1K); серия изображений GPT использует строку пикселей size.
• Сжатие входных данных и выходное разрешение не связаны — это два независимых поля в запросе.
• Размеры в пикселях и размер файла — это разные вещи: сжатие = сначала изменить размер (длинная сторона 2048px), затем перекодировать (quality 0.9); используйте размер файла как триггер (только выше 1.5MB).
• Разумное сжатие входных данных (длинная сторона 2048px, quality 0.9) не влияет на четкость выхода; только экстремальное чрезмерное сжатие может привести к потере деталей при тонком редактировании.
• Рекомендуемое сжатие входных данных: сжимайте только выше 1.5MB, длинная сторона ≤2048px, quality 0.9, сохраняйте исходный формат, общий размер нескольких изображений ≤6MB, один файл ≤20MB, при сбое используйте исходный файл.
• Сжимайте сгенерированные изображения перед передачей их в downstream workflows: изображение Nano Banana Pro 4K занимает примерно 9–18 MB на изображение (зависит от канала) — если отправлять его как есть, лимиты легко будут превышены.
• Обрабатывайте EXIF и формат перед загрузкой: встраивайте ориентацию в пиксели, удаляйте GPS и другие метаданные, связанные с конфиденциальностью, преобразуйте HEIC в JPEG, преобразуйте Display P3 в sRGB.

​

Связанные документы

• Руководство разработчика по серии Nano Banana
• Поля использования и объяснение вывода
• Руководство по обработке ошибок Gemini Image API