Модуль Image COMPRESSOR & Watermark & WebP & Lazy Load etc. by Sitecreator [Поддержка]

[sitecreator]

30 минут назад, markimax сказал:

Т  е  реальными изображениями. Поймете тогда

 

тут бы реальный магазин увидеть с реальными изображениями.

 

Некоторый анализ я уже сделал, залез под капот SEO CMS и т. д.  Часть вопросов отпала.

 

11 минут назад, AWARO сказал:

если компрессор исходник тоже обработает

 

если и его сожмет?

исходники компрессор не трогает, иначе это слишком большие накладные расходы по времени. Да и смысла пока не видел.

исходники то нередко больших размеров вроде 1200 Х 1200 пикс. 

 

Да и исходник - это все же исходник и его нежелательно трогать.

Поскольку пользователь может баловаться с уровнем качества (при сжатии) и нежелательно чтобы это качество потерялось.

 

 

[markimax]

Только что, sitecreator сказал:

 

...

Не надо пользоваться никакими библиотеками
http://php.net/manual/ru/imagick.adaptiveresizeimage.php

Вы же везде его используете

Если в названии картинки есть _adaptive - то адаптивный ресайз ей делать
 

[HyperLabTeam]

Только что, sitecreator сказал:

если и его сожмет?

исходники компрессор не трогает, иначе это слишком большие накладные расходы по времени. Да и смысла пока не видел.

исходники то нередко больших размеров вроде 1200 Х 1200 пикс. 

 

Да и исходник - это все же исходник и его нежелательно трогать.

Поскольку пользователь может баловаться с уровнем качества (при сжатии) и нежелательно чтобы это качество потерялось.

Да почему нет, качество не потеряет если не борщануть зато в весе выиграет. (сделать отдельной настройкой для исходника и для блондинок указать осторожно - невозвратно)
Вот резкость бы ещё туда для фот в кеше))
 

[sitecreator]

5 минут назад, AWARO сказал:

чтоб одинаково ровно в виджетах , списке статей

 

да я понял насчет "чтобы ровно".

 

Я же вижу уже готовый результат.

А мне хотелось взглянуть на набор картинок ДО обрезки и после.

Просто чтобы сравнить.

 

Ну раз это нужный и единственно правильный алгоритм, то его включу в модуль.

 

8 минут назад, markimax сказал:

Толку от него никакого
Это тогда надо каждое изображение обрабатывать (а если их 100500k ?

 

Толк может быть если изначально исходники с большими полями. Но вот только нужно ли кому-то их обрезать - это вопрос.

тут кол-во не имеет значения. картинки то создаются на лету при первом просмотре страницы.

И лишняя операция погоды не сделает.

[sitecreator]

5 минут назад, markimax сказал:

Не надо пользоваться никакими библиотеками
http://php.net/manual/ru/imagick.adaptiveresizeimage.php

Вы же везде его используете

Если в названии картинки есть _adaptive - то адаптивный ресайз ей делать

 

все правильно, я пользуюсь imagick. на этой платформе и сделаю.

библиотеку я нашел в SEO CMS и сделал предположение, что она и ресайзит адаптивно.

 

 

[sitecreator]

7 минут назад, AWARO сказал:

Да почему нет, качество не потеряет если не борщануть зато в весе выиграет. (сделать отдельной настройкой для исходника и для блондинок указать осторожно - невозвратно)

 

В принципе можно подумать.

Также можно назначить определенную папку, которую ни при каких условиях пережимать не нужно.

[markimax]

5 минут назад, sitecreator сказал:

 

все правильно, я пользуюсь imagick. на этой платформе и сделаю.

библиотеку я нашел в SEO CMS и сделал предположение, что она и ресайзит адаптивно.

 

 

А в GD нету функции адаптивного ресайза, поэтому приходится использовать библиотеку
Imagick - ну это продвинутое расширение  и понимает "предпочтения моды" сезона

[sitecreator]

6 минут назад, markimax сказал:

А в GD нету функции адаптивного ресайза, поэтому приходится использовать библиотеку

 

там много чего нету.

просто я всю функциональность строил из предположения, что найдется хостинг, где только одна лишь GD.

 

7 минут назад, markimax сказал:

Imagick - ну это продвинутое расширение  и понимает "предпочтения моды" сезона

 

тут спору нет.

 

А есть ли вообще виртуальный хостинг сегодня, который не поддерживает imagick?

Все, что я смотрел, имеет imagick.

 

В общем, заморачиваться не буду. Весь последующий доп. функционал сделаю на imagick.

[sitecreator]

Для любителей Windows и тех, кто просто желает протестировать возможности КОМПРЕССОРА добавил возможность работы на машине разработчика (например, используя Openserver).

 

Все возможности суперсжатия теперь доступны для локальных доменов localhost и *.local  (ключ не нужен).

 

Необходимо всего лишь скачать OptiPNG отсюда http://optipng.sourceforge.net/

и mozjpeg отсюда: https://mozjpeg.codelove.de/binaries.html

 

для OptiPNG на сайте разработчика доступна актуальная версия (бинарник), а для mozjpeg немного устаревшая 3.1 (актуальная версия 3.3)

Но для тестов под windows, думаю, что этого выше крыши.

 

на всякий случай приложу файлы здесь.
 

Цитата

 

Создайте в windows папку "C:\optipng"  и положите в нее файл optipng.exe из архива.

Создайте в windows папку "C:\mozjpeg" и распакуйте в нее архив mozjpeg_3.1_x86.zip.

 

 

 

mozjpeg_3.1_x86.zip

optipng.zip

[sitecreator]

В 27.08.2017 в 02:45, markimax сказал:

Другого алгоритма как это сделать  - нету. Или поля или без полей и с ЧАСТИЧНОЙ обрезкой изображения.

 

В 27.08.2017 в 02:45, markimax сказал:

http://php.net/manual/ru/imagick.adaptiveresizeimage.php

 

я вижу некое противоречие в этих двух предложениях.

функцию adaptiveResizeImage я рассматривал давно и экспериментировал с ее возможностями.

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

 

вот два варианта в зависимости от параметра bestfit (false, true).

 

 

 

Водяной знак специально не убрал.  Чтобы было видно, что он без искажений накладывается. 

 

 

А вот это:

 

 

Это НЕ есть адаптивный ресайз.

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

 

Вот кусок кода, который за это отвечает в библиотеке GD:

 

 

А вот в модели данный параметр не используется.

 

Лишь в шаблоне journal2 код модели изменили:

 

public function resize($filename, $width, $height, $type = '')

 

Чтобы можно было резать лишнее либо по высоте, либо по ширине.

@markimax , я не могу понять как без этого третьего параметра алгоритм может решить по какой стороне следует резать изображение?

 

 

Жаль, что никто не смог показать сайт с реальными товарами, где бы использовался "адаптивный" алгоритм.  Я бы мог элементарно сравнить исходники и "адаптивные" картинки на выходе.  Взял в кавычки потому, что adaptiveResizeImage не имеет отношения к той адаптивности, которая отрезает часть изображения.

Это должно как-то по другому называться, но не адаптивность.

 

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

 

 

 

Т. е. слишком высокие картинки обрезаются по вертикали, а слишком широкие - по горизонтали.

 

[sitecreator]

https://www.imagemagick.org/api/resize.php

 

 

Цитата

 

AdaptiveResizeImage

AdaptiveResizeImage() adaptively resize image with pixel resampling.

This is shortcut function for a fast interpolative resize using mesh interpolation. It works well for small resizes of less than +/- 50 of the original image size. For larger resizing on images a full filtered and slower resize function should be used instead.

The format of the AdaptiveResizeImage method is:

Image *AdaptiveResizeImage(const Image *image,const size_t columns, const size_t rows,ExceptionInfo *exception)

 

A description of each parameter follows:

 

Цитата

 

image

the image.

 

columns

the number of columns in the resized image.

 

rows

the number of rows in the resized image.

 

exception

return any errors or warnings in this structure.

 

 

It works well for small resizes of less than +/- 50 of the original image size.

Данный метод рекомендуется применять при небольших изменениях размеров изображения (+/- 50 %) от оригинального.

 

http://www.imagemagick.org/Usage/resize/

 

Вот тут в картинках показаны самые разные виды ресайзинга.

 

[sitecreator]

В 26.08.2017 в 15:49, klaos27 сказал:

У Марка в SEO CMS есть такая штука как "Адаптивный resize изображений".

"Адаптивный ресайзинг" сделал.  Добавил в версию 1.0.2

Но я бы назвал это все же "адаптивная обрезка".

Смысл именно в обрезке.

 

Сделал варианты:

 

• автоматически (как у @markimax )
• расположить по ширине (обрезать по высоте)
• расположить по высоте (обрезать по ширине)

Последние два в неполноценном виде присутствуют в движке изначально, только воспользоваться нельзя. Шаблон  journal2, например, использует (и расширяет) эти возможности. Возможно, где-то они тоже используются.

Поэтому решил сделать полную совместимость с journal2,  да и всем желающим даю возможность выбирать вариант "адаптивной обрезки".

 

В SEO CMS не нужно включать " Адаптивный resize ".  Настраивайте все средствами КОМПРЕССОРА. Тогда watermark будет вместе с адаптивным ресайзингом  (обрезкой).

 

правда, в админке тоже изображения становятся "адаптивными".

 

Не знаю хорошо это или плохо. Обойти это просто нельзя, да и нужно ли?

Картинки складываются в обычный кеш, а не в папку adaptive (как в SEO CMS ).

 

Например, тот же elFinder точно также обрезает картинки.

 

 

[t04ka]

В чем именно кастрирована версия для виртуального хостинга?

На нем будет работать какая нибудь компрессия?

[sitecreator]

В 29.08.2017 в 23:45, t04ka сказал:

В чем именно кастрирована версия для виртуального хостинга?

 

Информация уже неактульная.

На обычном хостинге все работает с максимальными возможностями.

 

Все, что касается watermark будет работать.

На виртуальном хостинге вы получите максимум, что может предложить imagick.

по сравнению с GD файлы будут несколько меньше. И это вполне устраивало Гугл еще год назад. Он не ругался на файлы, сжатые при помощи imagick.

Сейчас Гугл пошел дальше в рекомендациях по оптимизации и примерно лишь половину файлов считает приемлемыми (сжатыми при помощи imagick) .

 

mozjpeg в плане уменьшения размеров файлов значительно превосходит алгоритм imagick.  Но mozjpeg нет на обычном хостинге и вряд ли будет.

Теперь есть и работает у большинства хостеров, в РФ не было исключения ни для одного хостера.

 

На обычном хостинге можно использовать формат WebP (формат Гугла).  Его я добавлю в будущих версиях.

Но тут нужно понимать, что еще и в движок нужно вносить изменения чтобы WebP поддерживался.

 

В 29.08.2017 в 23:45, t04ka сказал:

На нем будет работать какая нибудь компрессия?

 

Максимальная будет.

только за счет imagick.  это максимум на виртуальном хостинге. Лучше, конечно, чем GD.

Но до уровня mozjpeg  или WebP  не дотягивает.  

 

mozjpeg  и WebP  по степени максимального сжатия сопоставимы. mozjpeg  иногда обгоняет WebP.

 

[t04ka]

Купил потестить функционал сжатия, так как гуглотест ругается на 5 оставшихся изображений из кэша.

Было 88, стало 88.

До этого!!!!

Файлы выгружались с сервера и обрабатывались файлоптимайзером.

Вероятно в этом дело.

 

[sitecreator]

@t04ka , вы тестируете на виртуальном хостинге?

[sitecreator]

На одном из серверов под Centis 7.3 обнаружил некую странность в работе с версией mozjpeg 3.3.1 (последняя).

Эффективность сжатия была невысокой. Т. е. файлы были меньшего размера чем их производил imagick, но разница была а районе  5%.

 

Сделал откат на версию 3.2 и проблема исчезла. Эффективность снова стала на хорошем уровне.

 

вы всегда можете установить именно эту версию. с ней никаких проблем не наблюдалось.

https://github.com/mozilla/mozjpeg/releases/tag/v3.2

 

[t04ka]

8 часов назад, sitecreator сказал:

@t04ka , вы тестируете на виртуальном хостинге?

Конечно =)

[sitecreator]

 

 

 

Этому сайту как раз не хватало суперсжатия чтобы набрать 100/100 попугаев.

 

Специально сделал выборку на 500 товаров.

 

 

[sitecreator]

9 часов назад, sitecreator сказал:

@t04ka , вы тестируете на виртуальном хостинге?

 

18 минут назад, t04ka сказал:

Конечно =)

 

На VDS возможностей больше, на виртуальном вы получаете максимум, который может дать imagick.

 

9 часов назад, t04ka сказал:

так как гуглотест ругается на 5 оставшихся изображений из кэша

 

3 из них - это png. С этим форматом на виртуальном хостинге сложно что-то лучше сделать. 

основной все же формат - это JPEG. 

две оставшиеся картинки в JPEG - это большие баннеры.

 

Могу предположить, что этот баннер равен по размерам (геометрическим) исходной картинке.

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

 

Я в новой версии изменил этот алгоритм, вместо простого копирование идет сжатие в любом случае (либо за счет imagick, либо за счет mozjpeg).

[t04ka]

5 часов назад, sitecreator сказал:

 

 

 

Этому сайту как раз не хватало суперсжатия чтобы набрать 100/100 попугаев.

 

Специально сделал выборку на 500 товаров.

 

 

Что сделали с теми же внешними скриптами? Метрика, Аналитика?

[sitecreator]

3 часа назад, t04ka сказал:

Что сделали с теми же внешними скриптами? Метрика, Аналитика?

 

загружаются через JS немного иначе чем изначально так, чтобы pagespeed не догадался.

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

по сути это чистая формальность.

[t04ka]

6 часов назад, sitecreator сказал:

 

загружаются через JS немного иначе чем изначально так, чтобы pagespeed не догадался.

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

по сути это чистая формальность.

В ручную делали? Модуль есть? купить можно? =)

[sitecreator]

3 часа назад, t04ka сказал:

В ручную делали? Модуль есть? купить можно? =)

 

насчет модуля можно подумать.

делал для яндекса, гугла, "вконтакте" и т. д. руками

причем, без всякого намека на потерю функциональности.

[sitecreator]

В новой версии добавил новые возможности:

 

 

Есть адаптивный ресайз (resize) теперь.

И, главное,  теперь есть поддержка очень хорошего уровня сжатия (максимального) для всех форматов (JPEG, PNG) на виртуальном (обычном) хостинге.

Гугл pageSpeed ругаться не будет на картинки.

 

В 29.08.2017 в 23:45, t04ka сказал:

В чем именно кастрирована версия для виртуального хостинга?

На нем будет работать какая нибудь компрессия?

 

Теперь будет очень хорошее сжатие благодаря включению WebP.

Не хуже чем на VDS/VPS.

С одной оговоркой, данное максимальное сжатие доступно для браузеров Хром и других на подобном движке.

Гугл при оценке скорости не берет в расчет браузеры, не знающие про WebP.

Доля рынка браузера Хром (Сафари, Опера и т. д.) весьма внушительна.

А также FireFox заявил поддержку (реализовал или в процессе) для браузеров на Андроид формата WebP.

 

На VDS получаете одновременно максимальное сжатие для любых браузеров.

Это с версии 1.1.0 моего модуля.