Upscaling guest photos with a local model instead of an API

개요

Knipsmig은 자체 서버에서 로컬 모델을 사용하여 게스트 사진의 해상도를 API 호출 없이 개선하는 기능을 구현했습니다.

주요 내용

* API 대신 로컬 모델 사용 결정:
* 생성 모델(Gemini, OpenAI)은 이미지를 재구성하여 원본과 달라질 수 있는 위험이 있음 (얼굴 왜곡 등).
* 슈퍼 해상도 네트워크는 원본 픽셀을 기반으로 픽셀을 추가하여 충실도를 유지함.
* 타사 API 사용 시 데이터 처리 계약(DPA) 변경 및 개인정보 보호 관련 추가 서류 작업 필요.
* API는 이미지당 비용이 발생하지만, 자체 서버의 CPU 시간은 추가 비용이 거의 없음.
* Real-ESRGAN 모델 도입:
* Real-ESRGAN 프로젝트의 realesr-general-x4v3 (SRVGGNet variant) 모델을 선택함.
* 이 모델은 약 1.2M 파라미터, 5MB 크기의 ONNX 파일로, CPU에서 약 10배 빠름.
* PyTorch 모델을 pytorch2onnx.py 스크립트를 사용하여 ONNX 형식으로 내보냄.
* Rails 애플리케이션 내 통합:
* 내보낸 .onnx 파일을 vendor/models/에 저장하고 onnxruntime gem을 통해 실행.
* ImageUpscaler.call(vips_image) 메서드로 기존 Vips 이미지 처리 파이프라인에 통합.
* 크롭, 회전, 톤 보정 등 기존 편집 후 마지막 단계에서 해상도 업스케일링 수행.
* 성능 최적화 및 구현 세부 사항:
* 타일링: 큰 이미지는 512px 타일로 분할하고 16px 오버랩을 적용하여 테두리에서 발생하는 문제를 최소화.
* Ruby 배열 사용 최소화: 텐서를 Ruby 배열로 마샬링하는 대신, float로 캐스트하고 raw byte를 OrtValue로 직접 전달하여 성능 저하 방지.
* 색 공간 태깅: copy(interpretation: :srgb)를 사용하여 단일 밴드 이미지가 흑백으로 처리되는 문제 해결.
* 스레드 제한: 웹 컨테이너에서 실행되는 이미지 편집 작업이 전체 시스템 성능에 영향을 미치지 않도록 4개의 스레드로 제한.
* 비용 및 성능 분석:
* M1 Mac에서 1080x810 사진 업스케일링에 약 18초 소요 (모델 실행 시간은 1MP당 10-15초).
* 프로덕션 환경에서는 더 느리지만, 합리적인 성능을 보임.
* 기능 제한 및 사용자 경험:
* 최대 긴 변이 2048px 이하인 사진만 업스케일링 가능 (더 큰 사진은 이미 충분히 해상도가 높음).
* 결과 미리 보기 기능 제공 및 최대 4096px로 출력 제한.
* 한 번에 최대 50개의 사진만 일괄 선택 가능.

시사점

좁고 명확하게 정의된 이미지 처리 작업의 경우, 자체 서버의 CPU와 경량화된 로컬 모델을 사용하는 것이 개인 정보 보호, 비용 및 예측 가능성 측면에서 API 호출보다 우수할 수 있습니다.