Google ругается на картинки в /image/cache

[eleo]

 

Цитата

Самый простой - это использование в коде php (движка) exec для запуска cjpeg (енкодер).

 

Вот так? В system/library/image.php

exec('cjpeg "' . $file . '"', $output, $result);

А энкодер cjpeg он уже есть или тоже устанавливать нужно?

[sitecreator]

В 11.04.2017 в 09:39, eleo сказал:

Вот так?

 

echo exec('/opt/mozjpeg/bin/cjpeg'.' -quality '.$quality.' '.$inputimg.' > '.$outputimg);

 

справка по параметрам cjpeg:  (как тут под спойлер убрать?)

 

usage: /opt/mozjpeg/bin/cjpeg [switches] [inputfile]
Switches (names may be abbreviated):
  -quality N[,...]   Compression quality (0..100; 5-95 is most useful range,
                     default is 75)
  -grayscale     Create monochrome JPEG file
  -rgb           Create RGB JPEG file
  -optimize      Optimize Huffman table (smaller file, but slow compression, enabled by default)
  -progressive   Create progressive JPEG file (enabled by default)
  -baseline      Create baseline JPEG file (disable progressive coding)
  -targa         Input file is Targa format (usually not needed)
  -revert        Revert to standard defaults (instead of mozjpeg defaults)
  -fastcrush     Disable progressive scan optimization
  -dc-scan-opt   DC scan optimization mode
                 - 0 One scan for all components
                 - 1 One scan per component (default)
                 - 2 Optimize between one scan for all components and one scan for 1st component
                     plus one scan for remaining components
  -notrellis     Disable trellis optimization
  -trellis-dc    Enable trellis optimization of DC coefficients (default)
  -notrellis-dc  Disable trellis optimization of DC coefficients
  -tune-psnr     Tune trellis optimization for PSNR
  -tune-hvs-psnr Tune trellis optimization for PSNR-HVS (default)
  -tune-ssim     Tune trellis optimization for SSIM
  -tune-ms-ssim  Tune trellis optimization for MS-SSIM
Switches for advanced users:
  -noovershoot   Disable black-on-white deringing via overshoot
  -arithmetic    Use arithmetic coding
  -dct int       Use integer DCT method (default)
  -dct fast      Use fast integer DCT (less accurate)
  -dct float     Use floating-point DCT method
  -quant-baseline Use 8-bit quantization table entries for baseline JPEG compatibility
  -quant-table N Use predefined quantization table N:
                 - 0 JPEG Annex K
                 - 1 Flat
                 - 2 Custom, tuned for MS-SSIM
                 - 3 ImageMagick table by N. Robidoux
                 - 4 Custom, tuned for PSNR-HVS
                 - 5 Table from paper by Klein, Silverstein and Carney
  -restart N     Set restart interval in rows, or in blocks with B
  -smooth N      Smooth dithered input (N=1..100 is strength)
  -maxmemory N   Maximum memory to use (in kbytes)
  -outfile name  Specify name for output file
  -memdst        Compress to memory instead of file (useful for benchmarking)
  -verbose  or  -debug   Emit debug output
  -version       Print version information and exit
Switches for wizards:
  -qtables file  Use quantization tables given in file
  -qslots N[,...]    Set component quantization tables
  -sample HxV[,...]  Set component sampling factors
  -scans file    Create multi-scan JPEG per script file

 

В 11.04.2017 в 09:39, eleo сказал:

А энкодер cjpeg он уже есть или тоже устанавливать нужно?

 

нужно установить.

есть классчический cjpeg из libjpeg (их несколько версий от 6b до 9-й), есть из libjpeg-turbo.  Они нам не нужны, ибо сжимают на классическом уровне.

а нужен cjpeg именно из mozjpeg.  Т. е. они все одинаково называются, совместимы на бинарном уровне,  но сжимают по различным алгоритмам.

mozjpeg - это форк libjpeg-turbo,  взявший из нее хорошую скорость работы + лучшее сжатие + выкидывание мусора (метаданные).

 

Нужно учесть один момент, что cjpeg в качестве входного файла не предполагает формат jpeg. Поэтому можно скормить файл в формате bmp.

А bmp можно создать используя imagick, т. е. отказаться от использования gd в image.php.  Я именно так поступил.  bmp создается быстро, т. к. не использует сжатие.  Поэтому лишние процедуры в виде сжатия (кодирования) и декодирования не происходят и не отнимают особо время и мощность.

 

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

 

вообще с imagick  файл image.php становится гораздо меньше, т. к. использование imagick  проще чем gd, ведь в imagick, например,  независимо от формата графики используются одинаковые конструкции (формат автоматически определяется по расширению файла).

 

[sitecreator]

Странно, конечно, что и нескольких часов на редактирование не дают для своих же сообщений. И 7 часов не прошло, а отредактировать не могу.

Уважаемые администраторы, ну что за паранойя?  С чем это связано?

 

Вижу, что случайно оператор 'echo' затесался в код при копипасте.  Только сейчас заметил.  Кто надо, конечно, тот поймет. но все же...

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

Это форум программистов или?

 

[sitecreator]

Сравнил алгоритмы mozjpeg и webp.

Гугл довольно лояльно относится к собственному формату независимо от его размеров.

 

По умолчанию тот же imagemagick сжимает с качеством завышенным для webp.  Файлы получаются излишне большими, Гугл не реагирует на это. Похоже, что даже не пытается подобрать лучший параметр качества сжатия для конкретного изображения.  Что-то вроде: увидел "webp", ну его можно и не проверять, он сам по себе хорош.  Странный, конечно, подход.

 

До jpeg докапывается если на 100 байт можно картинку уменьшить, а тут и десятки Кб в упор не видит.  Такие вот попугаи выходят...

 

Это результаты mozjpeg (q=78) и webp (q=default). Видно, что файлы webp больше по весу. Но это же webp,  на этом оптимизация закончена!  Чисто формальный подход.

 

 

 

Для оценки качества картинка дана в png без потерь.

 

 

 

Вообще параметры качества для mozjpeg и webp сильно отличаются в абсолютных единицах.

Для достижения одинакового веса файлов для webp  нужно задавать качество примерно на 10 (минимум) единиц меньше.  Вес получается одинаковый, визуально различий также незаметно.

 

[chukcha]

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

Такие вот попугаи выходят...

ВОТ! ВОТ!!!

[sitecreator]

при одинаковом q=78  MOZJPEG  выигрывает в весе.

 

 

 

 

[sitecreator]

соответственно q=78 (mozjpeg)  q=68 (webp) 

webp  несколько больше.

 

 

 

[sitecreator]

При попытке достичь уменьшения файла на 12% по сравнению с mozjpeg формат webp повел себя не очень хорошо - контур стал смазываться.

Получается, что в реальности webp не может сжать лучше чем mozjpeg при сопоставимом качестве.

 

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

Я предполагал, что за счет webp можно было бы добиться более впечатляющих результатов.  На деле webp не превзошел по сжатию mozjpeg.

Возможно, что в каких то специфических случаях (что же это за картинки такие?) webp обгонит mozjpeg  на пару процентов,  но мои эксперименты пока этого не подтвердили.

 

Делаем вывод, что mozjpeg позволяет сжимать картинки по максимуму без потери качества. При этом  скорость обработки не вызывает никаких нареканий.

Возможно, что webp работает (кодирует) быстрее?

Впрочем, какая от этого польза если все равно придется делать (генерировать) две картинки вместо двух: одну в JPEG (для всех непонимающих webp), а другую в WEBP (исключительно для Хрома и Оперы)?

 

 

 

 

 

[sitecreator]

mozjpeg дает реальный выигрыш в 20% по сравнению с классическим jpeg при качестве Q=78

 

 

[sitecreator]

Нашел сегодня еще один забавный косяк гугла в подсчете попугаев.

 

 

В шапке сайта есть картинка-лого "logo4.png"

И в подвале этого сайта есть тоже эта же самая картинка, но масштабированная за счет свойства CSS background-size.

 

Так вот именно на эту самую картинку Гугл ругается, мол, на 98% процентов больше чем надо!  И предлагает ее сжать.  В качестве оптимизированного изображения Гугл дает скачать малюсенькую картиночку 37 * 6 пикселей.  гугл решил, что она подойдет и для шапки и для футера?

Я мог еще ожидать картинку размером 150*26  (как у меня в футере),  тут хоть и ошибочная, но логика прослеживается, но предложение гугла меня поставило в тупик.

 

А у меня в подвале картинка размером 150*26  (за счет масштабирования).  И она же в шапке :  300 * 49

 

 

И, конечно же,  нескольких попугаев гугл из-за собственного глюка убил наповал!  Скольких покажу чуть позже.

Охота за попугаями - это некий квест, иногда не подчиняющийся никакой логике (как в моем случае).

 

Ну как можно верить после этого в попугаев?

 

[sitecreator]

Подстроился под этот косяк Гугла. (Гугл посчитал, что в лого шапки размером 300 * 49 достаточно запихнуть картинку 37 * 6 пикселей )

И 5 убитых попугаев ожили!

Не хило!  Ох уж эти попугаи...

 

[florapraktik]

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

Охота за попугаями - это некий квест,

Это хорошее определение процесса!

[zlatoff]

Цитата

А у меня в подвале картинка размером 150*26  (за счет масштабирования).  И она же в шапке :  300 * 49

 

Так именно таким макаром и делается дизайн под ретина-дисплеи: делается двойной ресайз (в сторону уменьшения) растровых изображений. Хотя элементы шаблона грамотней будет увести в  css, в @media запросы, и для ретины подавать файлы двойного размера, а всем прочим оригинал. 

 

Но вот думаю что гугловский тестер незаморачивается этой темой.

[sitecreator]

Если кто-то желает посмотреть эффект вживую, то данный сайт (ocstore 1.5) доступен вам для тестов. Доступ по IP, указанному на картинке.

Гугл принимает все изображения и не ругается.  Элементы дизайна (корзина), разумеется, в расчет не берем.

 

Сейчас подготавливаю решение (дополнение) для разных версий Опенкарт.  В нем будет использован imagick, интегрирован водяной знак (с тонкими настройками) и, конечно, суперсжатие. В данный момент тестирую на разных платформах. Будет доступен для Centos (в первую очередь), Ubuntu и прочими linux.  Поддержка php любых версий.  на PHP Version 7.0.17 уже работает (тестовый сайт именно на нем).  Ищите в разделе дополнений, надеюсь, в скором времени  (насколько быстро модерируется, правда, не знаю).

 

 

 

 

[Dotrox]

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

В нем будет использован imagick

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

Кстати, вроде, GraphicsMagick (php расширение Gmagick) существенно быстрее в большинстве задач.

[sitecreator]

35 минут назад, Dotrox сказал:

Он есть далеко не на каждом сервере

 

Это так. На большинстве нормальных (не за три копейки) общих хостингах он есть. Но есть N-е количество общих хостингов, где его нет. Правда, последнее время мне такие не встречаются. Все как-то больше работаю с большими магазинами, а для них хостинг за 99 руб (сегодня смотрел в отзывах) не подходит.  Владельцам все же нужны не только попугаи, но и реальная скорость работы магазина.

 

В принципе решение больше предназначено тем, у кого VDS.  Там можно не ограничиваться полумерами и сделать практически 99,5% картинок, которые одобрит Гугл. Если использовать только imagick (общий хостинг), то тут эффективность на уровне 50%, т. е. примерно на половину картинок Гугл будет ругаться.

 

А так согласен, что нужно писать большими буквами.  Я предложу файл-тест, скачав который пользователь поймет может ли он использовать imagick, т. е. есть ли для него смысл в таком дополнении.

[Kindzaza]

В 21.04.2017 в 06:31, sitecreator сказал:

Сейчас подготавливаю решение (дополнение) для разных версий Опенкарт.  В нем будет использован imagick, интегрирован водяной знак (с тонкими настройками) и, конечно, суперсжатие. В данный момент тестирую на разных платформах. Будет доступен для Centos (в первую очередь), Ubuntu и прочими linux.  Поддержка php любых версий.  на PHP Version 7.0.17 уже работает (тестовый сайт именно на нем).  Ищите в разделе дополнений, надеюсь, в скором времени  (насколько быстро модерируется, правда, не знаю).

Доброго! Как скоро это решение случится? Или не стоит ждать?

[sitecreator]

@Kindzaza , вы можете написать мне в личку. Для определенных версий решение уже готово, для остальных доделываю.

Вероятно, что для вашей версии движка и операционной системы уже сделано.

[sitecreator]

Вопрос по суперсжатию решен для всех форматов (JPEG, PNG) как на VDS, так и практически на любом обычном хостинге, который позволяет cgi-скрипты.

Также вы можете использовать формат WebP.

 

Можно забыть про то, что Гугл ругается.

 

решение в виде модуля здесь:

 

 

 

[sitecreator]

Вопрос по суперсжатию решен для всех форматов (JPEG, PNG) как на VDS, так и практически на любом обычном хостинге, который позволяет cgi-скрипты.

Также вы можете использовать формат WebP.

 

Можно забыть про то, что Гугл ругается.

 

решение в виде модуля здесь:

 

 

 

[Gambull]

В 21.02.2017 в 09:57, halfhope сказал:

Так уж вышло, что серверные библиотеки imagick и GD, которые обрабатывают изображения, не могут сделать их такими, какие они нужны PageSpeed (оптимизированными). Для оптимизации изображений без потери качества нужен сторонний пакет, а точнее пакеты для оптимизации png и jpeg изображений. Ими могут быть:

JPEG

• jpegoptim
• JPEGmini
• Jpegtran

PNG

• optipng
• pngcrush
• pptiPng
• tinyPng
• pngout

Рекомендую ставить optipng и jpegoptim, потому что они проверены и другие я не пробовал) Для установки на сервер необходимы права на установку пакетов, которых нет на обычном shared хостинге, но обычно есть на VPS/VDS. Если у вас shared хостинг, то спросите у тех. поддержки о наличии одного из этих пакетов и возможности их установить, при их отсутствии.
 

Либо установите сами, через терминал:

apt-get install jpegoptim optipng

или 

yum install jpegoptim optipng

Затем нужно найти все jpg и png изображения и оптимизировать их. Ищем jpg изображения и оптимизируем их (не забывайте про аналогичное расширение jpeg):

Будьте внимательны, при использовании --strip-all удаляются метаданные изображений, такие как название фотоаппарата, геоданные и т.д. Если это критично, то уберите --strip-all из команды. 

 

Для PNG:

find /путь/к/сайту -name "*.png" -exec optipng {} \;

Если у вас все получилось и вы все еще читаете, значит можно добавить автоматическую обработку изображений в класс обработки изображений OpenCart, который находится по адресу system/library/image.php. Для этого необходимы права на вызов функции exec. В файл нужно добавить закомментированные строки. 

    public function save($file, $quality = 90) {
		$info = pathinfo($file);
       
		$extension = strtolower($info['extension']);
   		
		if (is_resource($this->image)) {
			if ($extension == 'jpeg' || $extension == 'jpg') {
				imagejpeg($this->image, $file, $quality);
				// exec('jpegoptim "' . $file . '"', $output, $result);
			} elseif($extension == 'png') {
				imagepng($this->image, $file);
				// exec('optipng "' . $file . '"', $output, $result);
			} elseif($extension == 'gif') {
				imagegif($this->image, $file);
			}
			   
			imagedestroy($this->image);
		}
    }

 

Доброй ночи подскажите как в этой команде указать 80 % чтоб он сжал 

find /путь/к/сайту -name "*.jpg" -exec jpegoptim {} --strip-all \;