Вопрос к обладателям плагина "Правильные изображения"
Как известно, штатные средства генерации эскизов изображений для товара имеют один неприятный баг: при генерации эскизов размер файлов почему-то сильно увеличивается. Затем можно производить оптимизацию, например, через TinyPNG плагином от Игоря Гапонова. Но предварительное раздутие размеров файлов снижает эффективность оптимизации.
Есть такой плагин "Правильные изображения" ( https://www.webasyst.ru/store/plugin/shop/goodimage/ ). Который, якобы, сам генерирует эскизы и затем оптимизирует их средствами сервера. Так вот вопрос: страдает ли он той же болезнью увеличения размеров файлов эскизов при их генерировании? В поддержке плагина ответить не могут, они сами не знают как их плагин работает. Только дают ссылку на описание. Может кто-то из обладателей плагина может ответить?
10 ответов
Три дня боролись с этим плагином, все настроили, но реально успеха добиться не смогли. Много фоток просто запорол, то фон не распознает, то само изображение сломает. Оптимизация так де не дала результатов, т.е в проверке загружали фото,оптимизировали,тот же самый объем, только фото на 20-30px стало меньше. В общем удалили, занимаемся возвратом средств.
Полагаю это проблема не плагина, а модуля обработки на сервере. А там кто из знает. Итог разочарование.
Лучше изначально фотки нормально подготавливать, фон,отступы изображения от краев, и сжимать при необходимости. Далее при запросе штатные средства отлично генерируют нужного размера фото.
Благодарю за развернутый ответ. Но меня плагин не интересует в части его способности обрезать фото, фото у нас уже готовятся правильные. Меня больше интересует генерация эскизов и дальнейшая их оптимизация. Повторюсь: штатная генерация эскизов имеет баг с необъяснимым увеличением размера файла при одинаковых размерах изображения. Поэкспериментируйте сами: залейте изображение размером, скажем, 970х970. А затем сравните два файла - свой оригинальный и эскиз того же размера, созданный фреймворком. Разница размеров составит порядка пары-тройки десятков килобайт в сторону увеличения. А вот есть ли здесь такой баг?
Напишите мне на почту qwertygifts@yandex.ru
Много лет прошло с тех пор как последний раз расчехлял jpegoptim. В моем серванте завалялась версия 1.2.3, а актуальная вроде 1.4.6. Ну да не важно. Хотя почему не важно? Важно. Версия 1.2.3 не умеет
А это для больших изображений может ещё дать некоторую экономию в размерах, но просто впадлу было ./configure make make install.
Чтобы не покупать сразу плагин, но протестировать интересующий аспект его работы, зайдите на сервер по ssh и поднимите утилиту jpegoptim --help, а далее
Если вам плагин не нужен по части кадрирования и правки холста и вас интересует JPG, то зачем вам искать что-то большее, чем командная строка для тестов? Про рекурсивное использование и другие сценарии работы легко нагуглите сами.
Погоняете утилиту. Посравниваете работу.
При сопоставимых настройках качества = 85 на выходе из исходной картинки движком был создан эскиз размерами 1048х1048 точек в 294 кб, а утилита jpegoptim выдала его же 216 кб (см. выше). За счет чего?
Разница в наличии режима цветовой субдискретизации (Википедия объяснит). Дело тут вот в чем. В полученных эскизах число используемых цветов оказалось разным. Мои инструменты показали 151122 против 180123. Где меньше цветов, там и меньше размер файла. Как это отразится на качестве? Иногда никак, а иногда бывает и крадет яркие краски (на скриншоте ниже в режиме просмотра ДО и ПОСЛЕ на ёлке погасли красные точки). Упс! Бывает. Этой ёлке не повезло.
Поскольку jpegoptim лежит в основе оптимизации jpg в этом плагине, то вот вам и результат. Экономия почти 80 кб на одной фотке размерами 1048х1048 весьма неплохо, если не произойдет "кражи" цветов.
Мой совет будет такой. Загрузите на сервер тестовую пачку изображений. Прогоните их через jpegoptim и сравните глазами с оригиналом. Если качество вас устроит, то вперёд.
Огрлмное спасибо за столь разжеваный ответ. Есть только одно "но". Меня, в первую очередь, интересует создание эскизов. Оптимизация - это вторичное действие. Дело в том, что движок при создании эскизов добавляет очень много килобайт. Соответственно, дальнейшая оптимизация, по сути, убирает этот, добавленный движком размер.
Если на пальцах, то выглядет примерно так:
1. Имеем оригинал разрешением 1024х1024 размером 200кб.
2. Создаем движком эскиз с тем же разрешением 1024х1024, но получаем уже 250кб.
3. Оптимизируем и возвращаемся к 200кб.
Так вот меня интересует существует ли в упомянутом плагине особенность из второго пункта. Разработчик не может дать ответ.
Могу конечно ошибаться, но что-то мне подсказывает, что оптимизация касается массовой обработки уже созданных ранее эскизов.
Поскольку сна ни в одном глазу, то позволю себе порассуждать на вольную тему.
Опять же пост ранее про экономию 80 кб на одном эскизе в "схватке движка vs. jpegoptim" писал на примере так называемого условно оптимизированного оригинального изображения, которые обычно использует большинство людей, думая, что они сделали всё правильно. Возможно они используют не те инструменты или неправильно ими пользуются. Либо же там такие оригиналы, что по сравнению с ними любой эскиз - это уже хорошо.
А теперь начинается самое интересное. Есть у меня оригинал размером 825х825 73.8 кб. Загружаю его на две разные витрины на двух разных серверах, на которых у меня развернуты WA+SS, чтобы убедиться в точности результата, если вдруг будут расхождения.
На выходе получаю два эскиза, которые сравню потом с оригиналом. Наложение водяного знака я отключил для чистоты эксперимента, но он добавит прогнозируемую величину и всё четко просчитывается. Сравним итоги.
Теперь надо разобраться как достигнут такой эффект и даст ли нам хотя бы что-то оптимизация jpegoptim в этом случае.
Если вспомнить, что jpegoptim у меня без -all-progressive, то постараемся понять что даст прогрессивный вариант. На вышеупомянутых эскизах -6%.
А для случая малых эскизов типа 100-300 точек прогрессивный формат может даже увеличить размер файла. В случае с разными эскизами 200х0 значения в тесте были от -1% до +3%.
Стоит ли овчинка выделки с малыми эскизами? Думаю что нет.
Дело в том, что правильно созданный оригинал при создании из него эскиза не ведет себя как сорвавшийся с диеты и внезапно разжиревший кот. Увеличение, при грамотно подобранных параметрах исходного изображения и настройках сервера, практически минимально или отсутствует вовсе.
Ключевой момент, на который стоит обратить внимание выглядит вот так.
Напоследок взял большой красивый wallpaper с 571 тыс цветов в оригинале, прогнал его через сценарий фотоподготовки, который обычно провожу для фотографий товаров в своих магазинах и попытался добиться увеличения эскиза.
Ничего у меня не получилось. Как был оригинал 288 кб так и эскиз получился 288 кб.
Прогрессивный формат позволил бы выиграть -7%.
Экономия на прогрессивности наводит на мысль, что возможно стоит применять jpegoptim рекурсивно к некоторым видам эскизов сугубо по вкусу примерно так
sudo -u www-data find -type f -iname "*.970.jpg" -exec jpegoptim --strip-all --all-progressive -pm85 {} \; -exec chmod 644 {} \; взято из какого-то совета на первом же результате в выдаче поисковика, но команду точно надо дорабатывать под себяОднозначно к малым эскизам применять такое не обязательно и даже нежелательно.
Когда ваши оригиналы порождают слишком толстые эскизы, тогда нужно видеть весь процесс от оригинала фото до настроек движка и знать чем и как вы готовите оригиналы, чтобы выявить причину возникающего перевеса. В идеале никакой разницы быть не должно и этого можно добиться.
Если мыслить дальше и на перспективу, то захочется webp, но это требует ещё более пристального рассмотрения. Там тоже не все так однозначно и это тема для другого обсуждения. В сценариях, которые сейчас тестирую и обдумываю, webp дает выигрыш всего 3-5%.
Еще раз огромнейшее спасибо Вам за потраченное на меня время и толковые разъяснения.
Вы ввели меня в сомнения. Допускаю, что все дело в неверной подготовке оригиналов. Вот, что делаю я:
1. Готовлю, обрезаю и сохраняю изображение в фотошоп:
2. Получаю на выходе в разрешении 410х1620 с размером 119 885 байт:
3. Заливаю движком в настройках товара. Получаю эскиз с тем же разрешением, но размер уже 131 951 байт:
Настройки создания эскизов в движке:
Т.е. движок при создании эскиза в том же разрешении добавляет порядка 10% к размеру файла при том, что в настройках установлено даже не максимальное качество эскизов. Проблема во мне, движке, фотошопе? Всегда полагал, что в движке, т.к. неоднократно встречал здесь темы с описанием подобной проблемы.
Просто покажу кое-что, а вы после этого стучите мне в telegram. Расскажу как это работает и что нужно делать.
Взял ваш оригинал из поста выше. Он оказался ещё довольно сырым по моим меркам. Прогнал через свой софт. На выходе получил нормальную картинку на 87.5 кб. Загрузил его в качестве фото тестового товара. Создался эскиз 410х1620 точек размерами 86.8 кб.
Всё четко. Никакой магии.
Темы такие возникают неоднократно, но это и нормально. Всё движется своим путем.
В Телеге удобнее рассказать будет, а на форуме нормального быстрого диалога в реальном времени не выстроить да и писать долго.
Я б с удовольствием, но сообщения блокируются. У вас стоит запрет на сообщения от сторонних контактов? Мой телеграм