Как организовать скачивание, обработку и сохранение больших изображений в Python

Что проверяют

Понимаете ли вы, где при работе с большими файлами кончается память и где процесс упирается в сеть или в процессор. Следом обычно спрашивают, как обработать тысячу таких картинок, а не одну.

Как отвечать

Разложите задачу на три этапа, у каждого своё узкое место.

• скачивание потоком: requests.get(url, stream=True, timeout=(5, 60)) и запись на диск через iter_content(chunk_size=1024 * 1024), а не response.content, который держит весь файл в памяти. Размер проверяют заранее по Content-Length и по факту при чтении. Пишут во временный файл и затем переименовывают через os.replace, так на диске не останется половинок;
• обработка: Image.open в Pillow ленивый и сначала читает только заголовок, так что размеры и формат видны до декодирования. Для превью подходит thumbnail(), он сохраняет пропорции, а у JPEG draft() позволяет декодировать сразу в уменьшенном масштабе. ImageOps.exif_transpose поворачивает фото по EXIF. Для по-настоящему огромных изображений лучше pyvips: libvips обрабатывает картинку по частям и почти не ест память;
• сохранение: формат и параметры под задачу, например JPEG с quality=85 и optimize=True или WebP. Картинку с альфа-каналом перед JPEG переводят в RGB. В объектное хранилище большой файл уходит multipart-загрузкой, в boto3 её делает upload_file.

Для множества файлов: скачивание упирается в сеть, его параллелят через asyncio с httpx или aiohttp, либо потоками. Обработка упирается в процессор, её отдают в ProcessPoolExecutor или отдельным воркерам очереди.

Где спотыкаются

Вызывают requests.get без timeout. По умолчанию таймаута нет, и зависшее соединение держит воркер бесконечно.

Делают resize((800, 800)) для любой картинки. Пропорции ломаются, фото сплющивается.

Отключают защиту Image.MAX_IMAGE_PIXELS, увидев DecompressionBombError. Лимит защищает от маленького файла, который при декодировании займёт гигабайты памяти, и снимать его без своей проверки размера нельзя.