Пять бабушек — уже рубль.
Вообще не интересно насколько оно важно для клиентов.
Если бы была позиция — «мы поддерживаем бесплатный клон (как центос) к которому идет бесплатная поддержка для наших клиентов» — вопросов бы не было.
Если бы было «мы хотим предоставить клиентам монобренд, так что продаем свой клон по цене оригинала» — вопросов бы не было.
Но поскольку мы имеем «у нас точно такой же продукт, только в два раза дешевле», то налицо мудачья позиция.
А сколько денег такое решение им принесло, или наоборот принесло лишь убытки — не интересно.

это к чему? к пошаговому ресайзу?

спорить не стану, потому как прошёл это сам — если не веришь (в отличии от лампового звука, где важен слух) можешь сделать «ресайз», но только именно ресайз разовым уменьшением в N раз.

Да

Я к тому, что разница может быть, но будет она только для некоторых старых алгоритмов, например, с тупейшим nearest neighbour внутри (потому что умножение в те времена стоило дорого).
Современные алгоритмы, которые под векторные инструкции (SSE) спроектированы и написаны, в большинстве своём таких проблем не имеют. Можете взять какую-нибудь картинку в png (да хоть скриншот хабра) и сравнить побайтово результат уменьшения, скажем, в 10 или 20 раз одним махом или в 2-3 стадии.

Это фигня из серии теплого лампового звука. Где-то когда-то что-то было, а теперь просто миф для «ценителей»

Не могли бы Вы рассказать как вы это делали и какой библиотекой?

библиотеки нет, есть простой алгоритм вычисления шагов, который определяет сколько требуется шагов для уменьшения в 2 раза и один шаг (1,x раз )для уменьшения до размера, чтоб следующие шаги уменьшали равно в 2 раза. далее уменьшение в 1, х раз и далее n шагов уменьшения в 2 раза. Это проверено при уменьшении картинки полученной с камеры (примерно 2к*2к) до превьюшки 60*70. библиотеки я не нашёл, поэтому пришлось делать самому. Весь процесс такой: есть рамка просмотрового размера 600*700, в неё загружается фото товара с помощью перемещения, поворота, изменения размера в эту рамку вписывается та часть фото, которая наиболее информативна. происходит «обрезка» — получается «просмотровая» картинка, дальше устанавливаются границы для превьюшки и так же кадрируется, «обрезка» и в результате 2 картинки. В процессе «обрезки» и происходит вся магия преобразования

Ещё раз ресайзить за один раз — не правильно. происходит потеря качества.
не только потеря информации, но и потеря качества. А у Вас нет ни слова о том как происходит ресайз, хотя в заголовке написано про ресайз. Может в конкретном случае при таком достаточно не большом изменении размера это не заметно, но это так. Мне пришлось этим заниматься когда автоматизировал загрузку фото товаров на сайт. Было необходимо иметь просмотровую картинку 600*700 и превью 60*70. Алгоритм был отработан. А увидев заголовок про ресайз, решил что могу подчерпнуть что-то новенькое… к сожалению не удалось.
и из Вашего описания не получается что маленькая картинка берётся из кэша.

Все запросы с @ в конце отправляются nginx'ом на ресайз бэкенд.

получается, что все превью всегда ресайзятся

Естественно, мы так и делаем. В моем коде это работает так:
Вместо "/test.png" в том месте страницы, где нужна маленькая версия мы пишем "/test.png@75". Все запросы с @ в конце отправляются nginx'ом на ресайз бэкенд. Он в свою очередь пасит url, скачивает оригинал ("/test.png"), ресайзит его до нужного разрешения и отдает nginx'у. Nginx кэширует результат и отдает его клиенту.

фишка в том что при простом уменьшении размера с 200*200 до 75*75 произойдёт ухудшение качества изображения.

Не очень понял, что вы имеете в виду под простым случаем. Часть информации мы при ресайзе естественно теряем, но это не должно ухудшать качество картинки «на глаз»(естественно если потом получившуюся картинку не растягивать до размера оригинала).
Если же это проявляется в заметных артефакт, то есть смысл смотреть на алгоритм ресайза и его настройки.
На всякий случай уточню предыдущий коммент: мы храним только оригиналы в максимальном используемом разрешении (200х200 в примере). Менее качественные версии генерируются динамически и только кешируются на некоторое время.
Второй момент: например про главную. 75х75 это размер, определяемый версткой страницы, то есть в верстке есть контейнер 75х75 пикселей и мы вставляем туда версию нужного размера. Мы естественно не вставляем 75 версию в 200 контейнер.

Libvips дает возможность конвертировать картинки между разными форматами, в том числе в webp, но мы пока ей не пользуемся. За наводку спасибо, возможно стоит конвертировать в webp.

В примере с jpeg разница между картинками действительно несущественна, хотя и можно заметить артефакты по границе башни, если присматриваться. А вот с png кошмар, картинка просто убита в хлам. И такая ситуация не «возможна», она стопроцентно будет, если ставить себе целью 7-кратный выигрыш веса.

Если вам критичен вес картинок на сайте, внедряйте webp. Насколько мне известно, дает выигрыш порядка 20-30% при сжатии с потерями относительно jpg и 10-15% без потерь относительно png. Это уже при условии что jpg/png хорошо оптимизированы.

>> Чем нам не понравилось решение на nginx- накрутить нашу логику в конфиге можно, но выглядеть это будет очень уж страшно.
Ну я не знаю что страшней. 20 строк в конфиг nginx (локейшен для ресайза и парсинг аргументов — размеров + настройки кеша и pagespeed) или отдельный демон для ресайза.
Я конечно уверен что демон гибче и потому производительней. Но его ж нужно самим поддерживать, развивать и править баги.

Мы естественно тоже кешируем результаты nginx'ом, но бывают например, что приходит какой то трафик на старые страницы, для которых кэша нет или сбросился кэш. Отсюда интерес к производительности без кеша.
Чем нам не понравилось решение на nginx- накрутить нашу логику в конфиге можно, но выглядеть это будет очень уж страшно. Новых проектов это конечно не касается, там больше свободы и можно и на nginx сделать красиво.

У нас в принципе картинки ходят через отдельный инстанс. В настройках включена только оптимизация изображений. Без кеширования его включить нельзя. У него асинхронная модель оптимизации. На первый просмотр он всегда отдает оригинал.
Удобно тем что разным клиентам отдает разные оптимизации. Кому-то webP, а кому-то оптимизированный jpeg. Ну и конечно все рекомендованные оптимизации от гугла из коробки.

Сейчас пробывал очистить кеш pagespeed. На секунд 30 nginx скушал 4 ядра процессора и создал 1 гигабайт кеша за это время. После этого нагрузка сразу упала до привычных 20-30% У нас примерно по 200rps показы картинок. Но это веб сайт — кеширование результатов ресайза очень эффективно(больше 99% из кеша берется).

А у вас он проксирует весь трафик или отдельный инстанс, который занимается только ресайзом? Какую примерно нагрузку он держит с кэшированием и без?

Пробывали модуль для nginx — google pagespeed?
В нем есть отличный оптимизатор картинок вплоть до конвертации в WebP для современных браузеров.
Мы используем ngx_http_image_filter_module для ресайза и pagespeed для оптимизации. Нагрузка минимальна. Полученные картинки конечно кешируются в pagespeed

в примерах картинки только с жатием, размер оставлен без изменения. И о проблемах при ресайзе ни слова — а это отдельная тема для большого разговора. Не надо путать людей заголовками.