Так, соберу все мысли про бэкенд картинок, которые у меня были. Итак, мы будем делать единый картиночный CDN/процессор для всех картинок с единой обработкой. Сейчас у нас а) аттачи к постам б) аватарки в) архивные картинки г) картинки к вики-текстам. Сейчас у нас есть paperclip + delayed_paperclip + imagemagick, от всего этого надо избавляться. Во-первых, надо хранить оригиналы в оригинальном виде. Из оригиналов на лету (почти) делаются вторичные картинки по прямому запросу клиента (с кэшированием на файловой системе), то есть все же мы делаем самописный imgix. Я не уверен, что это правильное решение, но imgix все равно решит только часть проблем, поэтому все равно переделывать надо. Главная вторичная картинка — это "каноническая версия", которая почти всегда совпадает с исходной картинкой, кроме а) EXIF-ротированные JPEG'и повернуты в правильном направлении б) левые форматы (webp, tiff, bmp) перекодированы в уместный нормальный формат (jpeg или png) в) JPEG'и стрипнуты mozjpeg'ом (если это дает улучшение больше 10 процентов). #mokum-dev
Главную вторичную картинку мы генерим сразу при загрузке. Остальные вторичные картинки создаются по запросам от клиентов на основании размеров их viewport + ретиновости + "интента" + формата. (так как ведется статистика, то популярные варианты предгенерируются). "Интент" — это то, насколько можно/нужно жать картинку. Теория такая, что "превьюшку" можно жать жестче, чем "полноэкранную версию". Кроме того, надо обрабатывать новый андроид-хромовский заголовок, который реквестирует "сбережение bandwidth", забыл как называется — такое можно еще пожать. ‎- псы в рапиде
Урл картинки формируется на клиенте и содержит размеры и интент. Соответственно, либо оно отдается с файловой системы, либо проваливается до рельсов. Рельсы инициируют конвертацию (в оффлайне), после чего начинают ждать контролируемое время. Если мы укладываемся, то готовый файл пишется на диск и отдается клиенту, если нет, то рельса отдает какой-нибудь другой файл который уже есть (потому что мы знаем все вторичные файлы, которые у нас сгенерены) — например, в самом худшем случае, канонический вторичный (видимо, параллельно с ним надо генерить некий фоллбэк в виде "файла половинного размера"). ‎- псы в рапиде
Да, еще есть отдельная история про вторичные файлы-превьюшки: панорамы, longcats и анимогифы. Для них превьюшка должна выглядет как-то по-другому. Явно надо иметь опцию отдавать анимогифы по отдельному клику на превьюшку (для мобил). Также анимогифы явно не надо пытаться перекодировать, потому что 30 процентов их содержат сломанное говно. Длиннокотов надо показывать по методу, подсказанному @mudak: брать верхний кусочек, процентов 10, и рисовать поверх какую-то стрелочку вниз. Для панорам аналогично — после чего включить и для тех и для других какой-нибудь panorama-viewer с прокручиванием пальцами. ‎- псы в рапиде
Анимогифы хочется настоятельно рекомендовать загружать на gfycat.com, благо его эмбед поддерживается. Что еще? Update: еще есть массированный техно-онанизм на отдаваемые форматы (типа webp или JPEG XR, прости господи) — но я очень скептически к этому отношусь, в том числе из-за проблемы даунлоада). Про проблему с даунлоадом — побочным эффектом будет появление кнопки "скочать кортинке", которая позволит скочать кортинке во вторичном каноническом формате (то есть не в webp каком-нибудь!) ‎- псы в рапиде
Можно закину пару центов? 1) я бы очень хотел progressive loading с блюром. этот эффект гораздо приятнее чем просто скачивание, и прямо скажем сильно улучшит жизнь для больших картинок https://jmperezperez.com/medium-image-progressive-loading-pla... 2) Imagemagick неплохо бы заменить чем то побыстрее и без дыр, simd based? 3) сам лайтбокс тоже неплохо было бы поменять на просмотрщик как у медиума, главный бонус это правильная реакция на навигацию и скролл плюс офигенный эффект. (я кажется присылал похожий) 3) мне кажется вторичные картинки проще генерировать не на лету а post-upload, лёт очень дорогая хрень. АПД, пока написал ты сам отметил про пост аплоад. ‎- туктуктук наноробот
Кстати, как собираешься обрабатывать EXIF-rotation? я для себя понял что это ад бездны ‎- туктуктук наноробот
@ayoshi: а) mozjpeg по умолчанию делает progressive load, вопрос в том, каков его профиль б) да, от IM надо отказываться в пользу GM или более специализированных решений. Идея в том, чтобы сделать pipeline контролируемым, то есть частые случаи обрабатывать сверхбыстрыми заточенными решениями, остальное свалить на gm. про все твои ссылки, я, конечно, помню в) лайтбоксы немного ортогональны, но тоже, конечно, тут — в частности, я хочу перейти на родной react.js-лайтбокс, без игр с DOM; г) я не знаю "проще" ли это, но нужно контролировать и находить баланс между bandwidth и latency. д) обработка EXIF-rotation тривиальна, там просто не о чем говорить — http://linux.die.net/man/1/exiftran ‎- псы в рапиде
Мы не можем генерировать картинки на post-upload, потому что мы не знаем, клиенты с какими размерами окон к нам придут! причем многие эти клиенты будут первыми в своей категории для этой картинки, поэтому возможно, кэширование не будет так эффективно. Но так как у нас все картинки сохраняют aspect ratio, то мы можем отдавать картинку чуть побольше, но зато чуть побыстрее. ‎- псы в рапиде
http://thumbor.org использовался в андеве для динамичного ресайза ‎- stepashka

2015-2016 Mokum.place