Это то , к чему мы в итоге и пришли :)

На счёт 1-2% — тут же ещё зависит степень сжатия. Можно уменьшить картинку на 10%, а можно и в 2 раза. Тут будет ситуативно от оригинального размера

Ольга, я частично ответил на ваш вопрос в соседнем комментарии.

Принятия решений оптимизации production performance, там где есть pandas — это уже вне моей компетенции, но теперь это будет актуальной тема для инженерного блог-поста :)

Одна из проблем pandas, что его очень легко неправильно использовать, если не знать всех принципов работы. И этим регулярно злоупотребляют data scientist`ы. (Мое личное наблюдение). В таком случае performance резко падает. И да, один из вариантов — оптимизация кода и типов данных. На некоторых проектах — это чисто инженерное решение. К сожалению, детального сравнения оптимизированного кода c pandas и кода без него у меня нет.

А в случае, когда данных уже много и их надо параллелизировать — то тут точно надо искать альтернативы. (Spark/dask, etc)

Взять несколько картинок. Уменьшить их bicubic обеими библиотеками, сравнить результат по MSE

Выпиливается. Надобность pandas — его удобство для рисерча.
Но когда перформанс в продакшн важен, выпиливание pandas — первое место для оптимизации

Как раз-таки облегчить. Например, пока все не перешли на нейронные сети, в computer vision только и занимались что придумывали kernel’ы. Что в каком-то роде и есть feature engineering.

Антон, спасибо, хороший поинт. Я неявно подразумевал, что этот пункт входит как раз 80% времени работы с данными.
Feature engineering достаточно уникален для каждого проекта, поэтому и не уделил ему достаточно внимания в статье. Но да, вы правы, без фичей далеко не уедешь :)