Это связано с тем, какой модуль PHP используется - Imagick или GD? Как посмотреть, с помощью какого модуля PHP происходит пережатие картинки и как можно сменить модуль, если причина в этом?
Смотрите в config.local.php
'image_resize_lib' => 'auto', // library to resize images - "auto", "gd" or "imagick"
1 лайк
Жаль, что нет документации по этому модулю. Обращение к техподдержке и эмпирические изыскания привели к следующим выводам:
-
Модулем “Поддержка HiDPI” можно пользоваться.
-
Чтобы не было увеличения размера файлов, необходимо установить Настройка > Иконки > Формат иконки > “такой же, как у источника”. Модуль при активации почему-то ставит это значение в PNG, это приводит к увеличению размеров загруженных JPG файлов, так как они сохраняются в другом формате - PNG, который сжимает изображение по другому алгоритму.
-
Все изображения для загрузки на сайт нужно сразу готовит для отображения на экранах высокой четкости. Самое простое - увеличивать размеры всех изображений в два раза. Посложнее - осознано готовить нужные размеры изображений для разных разделов сайта в зависимости от размеров исходного изображения и размеров, которые оно будет занимать на экране. К примеру, у товарных позиций основное изображение имеет высоту 350 пикселей для обычных экранов и 700 пикселей для высокой четкости. Соответственно вы должны загружать изображение для данной страницы высотой не менее 700 пикселей. Если у вас есть изображение товара высотой 500 пикселей, то надо предварительно увеличить его высоту до 700, и тогда оно целиком впишется в отведенные 350 пикселей на обычных экранах, в противном случае уменьшится до 250 и дополнится сверху и снизу белыми полями до 350.
-
В документации написано, что лучше использовать библиотеку Imagick. Но у меня с этой библиотекой PNG файлы получаются большего размера, чем с библиотекой GD. Так что я в файле config.local.php оставил ‘image_resize_lib’ => ‘gd’. Это имеет отношение к PNG файлам с простой графикой в несколько цветов (логотипы, схемы, элементы дизайна). Фотографии в PNG лучше сжимает Imagick, но вряд ли кто хранит фотографии в PNG, так как весят они в таком формате существенно больше, чем в JPG.
-
Можно данный модуль сделать чуть умнее в отношении загрузки небольших по ширине/высоте изображений. Нужно, чтобы изображения не уменьшались просто в два раза по ширине и высоте, а уменьшались до необходимых размеров в зависимости от ситуации. Если вернуться к примеру выше, то изображение высотой 500 пикселей не нужно под обычный экран уменьшать до 250 пикселей, а потом добавлять белые поля до 350 пикселей - надо уменьшить до 350 пикселей. И тогда это изображение нормально отобразится на обычных экранах. Для экранов высокой четкости изображение не нужно сверху и снизу дополнять белыми полями до 700 пикселей. Нужно или увеличить по высоте до 700 пикселей, или загрузить исходное без изменений, но потом на странице растягивать до 700 пикселей. Владелец сайта должен помнить, что на экранах высокой четкости такое изображение будет выглядеть замылено в данном месте.
-
Хорошо будет, когда разработчики тем будут в своей документации указывать, где используются изображения каких размеров помимо стандартных изображений, перечисленных в Настройки > Иконки. Сейчас это приходится высматривать самому в каждом случае.
-
Есть места на сайте, где на экранах высокой четкости отображается изображение для обычных экранов и соответственно выглядит размыто. Наверное, по каждому такому выявленному случаю нужно писать в техподдержку.
2 лайка
Нужно было чуть глубже капнуть, и разобраться с форматами. О чем ниже.
Да, пожалуйста, ради менее 2%, где 60% в кредит, тратить ресурсы, чтобы отвалились минимум 10% от 98%. Тут хозяин барин.
Теперь немного о форматах. В движке есть поддержка 3х форматов - JPG, PNG, GIF.
- GIF - старый формат, который поддерживает только палитру 8 бит или 256 цветов, но есть прозрачность и может содержать последовательность изображений, что позволяет делать анимацию.
Но формат старый, неудобный, и практически себя изжил. - JPG - самый популярный формат растровых изображений, но это формат со сжатием с потерей данных, соответственно, чем выше сжатие тем больше потеря данных и качества. Имеет высокую совместимость с любыми средствами просмотра. Используется для любого вида фотографий, где необходима передача цвета больше 16 бит.
Из минусов, при пережатии или апскейл идет существенное ухудшение изображения, а также нет прозрачности.
Есть отдельный формат JPEG2000, но распространения не получил. - PNG - Формат, который изначально предполагался на замену GIF, также обладает прозрачностью, имеет два формата PNG-8 - аналог GIF, но без анимации и формат PNG-24, уже аналог JPG, но с прозрачностью. Очень удобен для графики, текста в картинках, там где нет большого количества цветов + нужна прозрачность. Это логотипы, рекламные баннера, диаграммы, рисованные картинки без большого количества переходов и градиентов.
Т.к. принцип формата - сжатие без потерь + альфа канал (прозрачность), то всегда будет больше весить, чем JPG для применения фотографий. И чем больше размер фото (разрешение), тем больше разница в размере файла. - Есть еще два формата WebP (от Google) и BPG, они мало используются, и пока не получили должного распространения, хотя обладают лучшими показателями качество / размер, чем JPG.
Теперь об изображениях в CS-Cart.
- По большому счету будем использовать 2 формата - JPG и PNG, т.к. GIF почти устарел, а SVG не поддерживается системой.
- Если опираться на на два типа нужных изображений - Фото товара и полноцветные фото к статьям с одной стороны и графика с другой. Для первого у нас есть JPG, для второго PNG. Чтобы не было непонятности с картинками/фото, обязательно нужно настроить, чтобы CS-Cart сам не менял формат “Формат иконки = Такой же, как у источника”, но для этого нужно готовить фото для него отдельно. О чем чуть ниже.
- Если Вы готовите, или поставщик дает сжатые фото товара, то в настройках CS-Cart лучше вообще выключить повторное сжатие, настройка в иконках - “Качество формата JPEG (0—100) = 100” или 90, т.к. повторное сжатие сжатого, только дополнительно ухудшит фото.
Но есть нюанс, по идее (не проверял), если у Вас изначальное фото подготовлено, то изменение размера самого фото, без изменения качества никак не должно сказываться на пропорциональном размере файла. Если же стоит сжатие (качество формата), то сначала фото изменяет размер, потом переживается, с еще большей потерей качества, в этом случае будет минимальная разница в размере файла, но значительная в качестве. Надо проверить! - Теперь к Retina дисплеям. Опять же, что частично описал @sinobook.ru не верно, а именно.
Сначала мы радеем за качество фото, а потом сильно заблуждаемся, что нужно увеличивать фото. Любое увеличение размера фото, больше, чем на 5% ведет к ухудшению фото, если увеличивать фото в 1,5 - 2 раза, то на выходе будет тоже мыло, что без модуля. Да, растягивание фото дает большее мыло, т.к. мы просто увеличиваем размер, а информация о количестве цвета остается таже, если же программно делать, то происходит интерполяция, и качество зависит от способа и программы, но на выходе все равно мыло.
Так как же правильно подготовить фото?
- Все просто, сначала - получить от поставщика хорошие фотографии. Что значит хорошие?
Физический размер в пикселях минимум 2000 по наименьшей стороне, чем значение больше, тем лучше. И без сжатия, т.к. фактически оригиналы, которые не могут по определению весить меньше 1Мб на каждое фото. - Определиться, какого размера будут фото для увеличенного отображения (во весь экран). Для 80% пользователей, это будет фото размером 1280х960 (формат 4:3). Размер файла такого фото товара при 70% заполнении будет в среднем 160кб (по факту от 120кб до 300кб), при оптимальном сжатии. Если готовить и тут к Retina, то уже нужно в два раза больше, и размер файла в 2 раза больше. Но насколько игра стоит свеч, каждый сам решает.
- Дальше, уже программно (модулем) должна идти подготовка иконок для каждого типа дисплея. Например размеры для разных типов.
3.1 Список товаров - обычные 240х180, ретина - 480х360.
3.2 Быстрый просмотр товара - обычные 320х240, ретина - 640х480
3.3 Детальная страница товара - обычные 600х450, ретина - 1200х900.
Как видно из п.2, то для всех 3х типов достаточно размера 1280х960, единственное, что фото на детальной странице на ретина не будет увеличиваться, и займет на экране малую площадь, 1280х960 против 1200х900.
P.S. для последних iMac вообще нужно 3х кратный размер фото 
4. Что такое оптимальное сжатие фото - это параметр равный 60-75% от исходного, в любом случае, можно самому эксперементировать и определить для себя лучше по соотношению размер/качество. Некоторые товары будут нормально выглядеть и при 50%, а другие только при 70%+.
Как должен работать модуль HDPI. Нужны настройки для нескольких типов иконок, в зависимости от первоначального изображения. Т.е. если ему скармливаем фото меньшего разрешения, чем у нас иконка для ретины данного типа, то он ничего не делает с ним, а оставляет то, что есть для обычного разрешения. Также нужно управление сжатием для каждого типа иконок, т.к. для миниатюр 300х300 можно сжать и на 50-55%, а для детальных фото, уже 65-70%. Принудительная работа с форматом, т.к. для 99% случаев, это JPG.
По факту, все это актуально, если поставщик дает фото хорошего качества. Сколько мне известно, очень малое количество поставщиков дают нормальные фото, в основном это картинки размером 600х600 или чуть больше. Поэтому все эти танцы с бубнами для таких фото вообще бессмысленны.
P.S.S. Я не знаю, на сколько будет интересно, но я могу подготовить гайд, как пакетно готовить фото для сайта в Photoshop. Правда не быстро.
1 лайк
Интересно; будет хорошо, если напишете.
А почему они отвалятся?
В текущей реализации - увеличение трафика. Покупателей больше бесит, и они уходят, долгая загрузка сайта, не же ли фото товара. Я говорю про сейчас, а не как могло бы быть.
Не понимаю. Почему увеличение трафика? Пользователи с обычным экраном - они же будут загружать только изображения для обычного экрана. Изображения с суффиксом @2x у них грузиться не будут.
Если есть в этом полная уверенность, то увеличения не будет. Тут вопрос, какой способ используется, их много. У меня нет ретины, протестировать не могу.
Нашел такую штуку, как JPEGmini. Уже оптимизированные изображения без потери на глаз качества ужимает в 2-3 раза. Перегоню все картинки через него, и, думаю, для меня в ближайшее время вопрос с модулем hdpi не актуален.
Мы предлагаем модуль для оптимизации изображения через бесплатный сервис resmush.it
https://www.ecom-labs.ru/cs-cart-multi-vendor-moduli/cs-cart-modul-optimizaciya-izobrazheniy.html
Нее, это банальщина)))
Вкатывают без спроса недетский коэффициент компрессии, и вся наука)
JPEGmini свой патент не зря получили. Не знаю, как они умудряются подобное проворачивать.
Видел у вас этот модуль. Но онлайн у них на сайте результат для проверки не получить; не знаю, как сравнивать.
Сегодня у клиента смотрел. Какие-то изображения остались в текущем размере, у каких-то уменьшился размер в 4 раза
У меня ваш модуль уже вторые сутки колбасит миниатюры)
Отпишусь потом.
Затестил модуль от EcomLabs.
Вот итог в цифрах по одной странице товара:
В общем и целом неплохо.
Но сравнил с JPEGmini - он по размеру процентов 15-20% сверху еще может убрать после resmush.it
@ecomlabs, можете рассмотреть подключение в модуле еще одного сервиса?
Доработать не по полной стоимости с перспективой улучшения продукта. У JPEGmini есть платная (аренда времени) сервер-версия на Amazon AWS.
Не думаю. что вложения себя окупят при наличии бесплатной альтернативы. Обсудим с разработчиками
