이미지 압축 및 출력 해상도

​

두 가지 전혀 다른 것

​

품질을 압축하는가, 차원을 압축하는가? “압축”이 실제로 줄이는 것

• iPhone 16 Pro로 찍은 사진은 4284×5712(약 2400만 픽셀로 매우 큽니다)인데도 파일은 4.6 MB에 불과합니다. 저장할 때 이미 효율적인 손실 인코딩이 적용되었기 때문입니다;
• 같은 픽셀 수의 사진이라도 높은 품질로 내보내면 30 MB에 이를 수 있습니다.

• 픽셀 차원은 모델이 “볼 수 있는” 정보의 상한과 디코딩/이해 비용을 정합니다;
• 파일 크기는 전송 비용을 좌우합니다. 약 33%의 Base64 부풀림, 업로드 시간, 20 MB 단일 파일 상한은 모두 바이트를 기준으로 합니다.

​

출력 해상도는 prompt가 아니라 size 매개변수로 정해집니다

​

예시: gemini-3-pro-image

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

​

GPT image 시리즈는 size 픽셀 문자열을 사용합니다

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

​

입력 이미지를 압축해도 출력 선명도가 떨어지나요? 사실상 아닙니다

1. 출력은 업스케일이 아니라 새로 생성됩니다. 모델은 지정한 크기대로 새 이미지를 그려냅니다. 출력 해상도는 imageSize/size에만 따라 결정되며, 입력 이미지의 픽셀 수와는 무관합니다. 입력이 3000px이든 2000px로 압축되었든, 4K를 선택하면 4K가 출력됩니다.
2. 입력 압축 필드와 출력 크기 필드는 서로 독립적입니다. 압축은 요청의 “image data” 필드의 용량/픽셀 수만 바꾸며, 크기 파라미터 필드에는 절대 영향을 주지 않습니다. 요청에서 두 항목은 서로 관련이 없습니다.
3. 권장 압축은 완만하며, 모델이 이미지를 “보는” 데 필요한 수준보다 훨씬 높습니다. 실제로 참조 이미지를 긴 변 기준 약 2048px, JPEG 품질 약 0.9로 압축하는 것만으로도 모델이 구도, 색상, 스타일, 주제 세부 사항을 이해하기에 충분합니다. 이런 모델들은 내부적으로 인코딩하기 전에 입력 이미지를 어차피 적당한 해상도로 축소합니다.

​

엄밀히 보자면: 예외 사례

적절한 압축(긴 변 2048px, 품질 0.9) → 출력 선명도에 체감 가능한 영향 없음; 극단적인 과압축만이 세밀 편집 시나리오에서 디테일 손실을 일으킬 수 있습니다.

​

입력 이미지에 대한 실용적인 압축 설정

​

후속 워크플로에 들어가는 생성 이미지: 이것도 처리하십시오

​

추가 이미지 처리 모범 사례

• EXIF 방향 정보를 픽셀에 반영합니다: 휴대폰 사진은 회전 정보를 픽셀 자체가 아니라 EXIF Orientation 태그에 저장하는 경우가 많습니다. 일부 처리 파이프라인은 이 태그를 무시하므로, 모델은 옆으로 눕거나 거꾸로 된 이미지를 보게 됩니다. 업로드 전에 회전을 픽셀에 적용하십시오(대부분의 압축 라이브러리는 다시 인코딩할 때 이를 자동으로 수행합니다).
• 업로드 전에 EXIF 개인정보 메타데이터를 제거합니다: 원본 사진에는 종종 EXIF에 GPS 좌표, 기기 모델, 촬영 시간이 포함됩니다. 사용자 사진을 서드파티 API로 전송하기 전에 메타데이터를 제거하십시오 — 다시 인코딩하면 보통 부수적으로 제거되지만, 순서에 유의해야 합니다: 먼저 방향을 적용하고, 그다음 제거합니다.
• 형식 호환성: iPhone의 기본 HEIC/HEIF 형식은 대부분의 이미지 API에서 지원되지 않습니다 — 먼저 JPEG/PNG로 변환하십시오; 투명도가 필요하면 PNG/WebP를 사용하십시오; 애니메이션 GIF는 보통 첫 프레임만 읽힙니다.
• 색공간을 sRGB로 변환합니다: Apple 기기 사진은 흔히 Display P3를 사용합니다. 색상 프로파일을 무시하는 파이프라인은 색상 변이를 일으킵니다 — 업로드 전에 sRGB로 변환하십시오.
• 상황에 맞는 전송 방법을 선택합니다: 입력 측에서는 Base64가 가장 안정적입니다; URL (fileUri) 업로드는 엄격한 CDN 요구사항이 있습니다 — 장단점은 Nano Banana Series Developer Guide를 참고하십시오. 출력 측에서는 Nano Banana OSS Group을 사용하여 Base64 대신 URL을 받으십시오.
• 실제로 필요한 출력 등급을 선택합니다: 결과물에 4K가 꼭 필요하지 않다면 요청하지 마십시오 — 생성 속도가 느려지고, 파일이 커지며, 후속 전송/처리 비용도 높아집니다. 1K/2K에서 반복하고, 최종 렌더링에만 4K로 전환하십시오.
• URL 출력은 즉시 저장합니다: API가 반환하는 이미지 URL은 만료됩니다. 받는 즉시 자체 저장소로 옮기십시오 — 임시 URL을 영구 자산으로 취급해서는 안 됩니다.

​

빠른 참조

• 출력 해상도 = 크기 파라미터 (imageSize / size / aspect_ratio)이며, prompt의 텍스트가 아닙니다. 4K가 필요하시면 파라미터를 설정하시고 prompt에 적지 마십시오.
• gemini-3-pro-image는 등급이 1K / 2K / 4K인 imageSize를 사용합니다(기본값 1K). GPT image 시리즈는 size 픽셀 문자열을 사용합니다.
• 입력 압축과 출력 해상도는 서로 관련이 없습니다 — 요청의 두 개의 독립된 필드입니다.
• 픽셀 크기와 파일 크기는 서로 다른 개념입니다: 압축은 먼저 크기 조정(긴 변 2048px) 후 재인코딩(품질 0.9)이며, 파일 크기를 기준으로 사용하십시오(1.5MB 초과 시에만).
• 적절한 입력 압축(긴 변 2048px, 품질 0.9)은 출력 선명도에 영향을 주지 않습니다. 극단적인 과도 압축만 세밀한 편집에서 디테일을 잃을 수 있습니다.
• 권장 입력 압축: 1.5MB 초과 시에만 압축, 긴 변 ≤2048px, 품질 0.9, 원본 형식 유지, 다중 이미지 총합 ≤6MB, 단일 파일 ≤20MB, 실패 시 원본으로 되돌림.
• 다운스트림 워크플로에 넣기 전에 생성된 이미지를 압축하십시오: Nano Banana Pro 4K 이미지는 이미지당 약 9~18MB가 소요됩니다(채널에 따라 다름) — 그대로 다시 보내면 쉽게 한도에 도달합니다.
• 업로드 전에 EXIF와 형식을 처리하십시오: 방향 정보를 픽셀에 반영하고, GPS 및 기타 개인정보 메타데이터를 제거하며, HEIC를 JPEG로 변환하고, Display P3를 sRGB로 변환하십시오.

​

관련 문서

• Nano Banana 시리즈 개발자 가이드
• 사용 필드 및 출력 설명
• Gemini Image API 오류 처리 가이드