Как называется проект, мотив которого звучит так: «Сохраним трафик загружая картинки нужного размера»?

Question

[aleksandrvin]

С месяц назад видел в сети проект, где ребята ставили себе целью изменить подход к организации загрузки картинок в HTML. То ли концепцию разрабатывали, то ли библиотеку по изменению размера картинок на лету… хочу почитать-применить, а найти проект не могу.


У самого вырисовывается такая архитектура:

1. В img элементах в HTML указывать явно размер картинки, т.е. src="/image/XXX/320x200" например

2. Контроллер ресурса /image/ находит по ключу (XXX) нужную картинку в БД и пережимает её в требуемый размер (320x200), в HTTP ответе помечает, что объект можно закэшировать

3. Перед Web-сервером ставим кэш, который сохраняет сгенерированные картинки


В итоге: реальую работу по пережатию картинки из БД «ждёт» только первый пользователь, остальные получают её «на халяву» (обычно первый пользователь — это тот, кто картинку добавил на сервер).


Хочу проверить — какие идеи в том проекте, напомните пожалуйста, кто узнал проект.

Answer 1

[Вячеслав Слинько]

Так этож везде так, нет?

Answer 2

[Максим]

Вот, например:
wiki.nginx.org/HttpImageFilterModule

Comments

[aleksandrvin]

Не понял: он кэширует результат изменения размера картинки, или вычисляет каждый раз заново?

[Ilya Evseev]

Сам по себе данный модуль ничего нигде не кэширует.
Его вызвали — он читает картинку, преобразовывает, отдаёт.

Про кэширование читайте здесь:
webcrunch.ru/library/development/highload-basics/ngx-http-image-filter-module-local/

Про то, что resize лучше поручать отдельному экземпляру nginx'a:
mailman.nginx.org/pipermail/nginx-ru/2009-November/030006.html

Answer 3

[xmoonlight]

По сабжу: phpThumb это отлично делает «налету».
А по пережатию при upload-e на сервер: canvas HTML5 на стороне клиента.
Абсолютно реально: делай раз, делай два

Answer 4

[Артем Спиридонов]

Мы от тотального пережатия отказались. Достаточно сделать один или два масштаба — «большая» и «маленькая». По месту размер определяется CSS-ом.

С нынешним потреблением трафика результат ни в какое сравнение не идет.

Кстати, это создает запас «ретинности».

Comments

[Артем Спиридонов]

И еще момент — это сопровождение. В процессе развития проекта дизайн может меняться, и это нормально.

В случае, когда задан фиксированный ряд размеров, получение неискаженных изображений в новом размере может стать головной болью.

В случае, когда ряд размеров меньше, и они применяются с некоторым запасом, проблем при смене дизайна не возникает.

И конечно, ретина… :)

[aleksandrvin]

Почему отказались?

Моя идея в том, что оригинал картинки не трогается, — как загрузил пользователь, такой оригинал и будет. Затем, наперёд неизвестно: какой размер потребуется в каком месте сайта, поэтому делать пред-пережатие нельзя. И соответственно третье: пережимать каждый раз одно и то же неправильно.

[nukex]

Так же считаю, что размеры нужно сразу предопределять, например как делает это Last.fm или Beatport:
image_original, image_small, image_thumb и т.д, т.е /image/XXX/original/photo

Answer 5

[Сергей Протько]

Думаю это просто один из пунктов какого-то чеклиста. Хотя проектов, реализующих подобное вагон.

скажем есть фронт сервер или просто web сервер, который, если мы не находим изображение, вызывает приложение и оно генерит вам картинку нужного размера и сохраняет на диске. Далее эту картинку напрямую будет раздавать WEB сервер.

А уже конкретная реализация зависит от используемых технологий.

Answer 6

[Wott]

Такое было в рамках развития концепции адаптивной верстки — в зависимости от размеров экрана показывать разный layout и, соответственно, разный размер картинок

Но перекидывать на лету умеет большинство сайтов и в этом нет ничего для нового проекта :)

Answer 7

[aleksandrvin]

Вопрос не в том, как это сделать, какими php или прочими библиотеками делается, или как отобразить на клиенте. Вопрос в том: как называется проект, у которого мотив, что в сабже. Уточню, те ребята не просто библиотеку по пережатию картинок на сервере пишут — в том то и вся соль. :)