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

[LionHunter]

10 часов назад, yura1yura сказал:

Будет ли дружить Ваш модуль с этим:

Да, будет. У меня оба стоят, всё отлично работает

[sitecreator]

Для тех, кто до сих пор не знает, что гугл запустил новый алгоритм оценки сайтов.

 

Убедительная просьба не жаловаться сейчас, что гугл ругается на ваши PNG, которые уже сжаты и на которые гугл до недавнего времени не ругался.

Я уже писал, что по новому алгоритму гугл теперь сравнивает каждый сжатый файл PNG со своим форматом WebP.

И WebP всегда будет выигрывать у PNG.

 

 

 

слева размер сжатого PNG, справа - WebP.

 

Никаким образом сам PNG сжать еще больше нельзя. Он и так уже сжат. И раньше гугл это устраивало.

Выход сейчас только один - использовать для PNG формат WebP.

Полная поддержка WebP будет в 1.10 версии Компрессора.

 

Вы же видите, что гугл не ругается на сжатые JPEG? Они сжаты за счет mozjpeg.  Потому, что алгоритм mozjpeg по степени сжатия сопоставим с WebP и не уступает ему.

 

Пожалуйста, перестаньте меня дергать на предмет, что у вас "случилась проблема" и "гугл снова жалуется на картинки".

Я прекрасно знаю, что гугл изменил подход к оценке изображений, в частности оценка PNG-картинок никогда не будет отличной теперь, даже в случае их сжатия.

У меня нет возможности постоянно персонально каждому это объяснять.

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

Спасибо за понимание.

[sitecreator]

Ночная сборка FF от октября 2018-го уже поддерживает WebP.

Так что в скором времени (через пару месяцев) позиции WEbP укрепятся еще сильнее.

Напомню, что сейчас уже поддержка WEbP по статистике использования составляет 72-75%.

Можно предположить, что с FF она достигнет 90%.

 

 

[prochet]

Когда примерно быть готовым к обновлению? =)

[sitecreator]

Новый FireFox отлично дружит с WebP.

А Компрессор 1.10 выводит его в любом поддерживающем браузере (jpeg отдается не поддерживающим).   У любого хостера.

Не нужно настраивать nginx (  к которому на общем хостинге и так нет доступа) или апачи.

Картинки по прямым ссылкам (не в кеше) также будут нужного формата.  Все автоматически.

 

 

 

 

Если обратите внимание, то картинка в webp вставлена прямой ссылкой, т. е. из папки исходников.

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

[sitecreator]

3 минуты назад, prochet сказал:

Когда примерно быть готовым к обновлению? =)

 

на днях, думаю.

Если бы еще не приходилось раз 15 или 20 на дню отвечать в письмах на одно и тоже...

 

[sitecreator]

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

 

Миф 1.

 

Цитата

Установите jpegoptim и у вас будет функция сжатия на сервере

 

jpegoptim не умеет сжимать!

Это программное решение создано для выкидывания мусора из файлов. За счет этого получается уменьшить вес файла.

На маленьких (порядка 1К) файлах вы можете увидеть результат существенный, т. к. мусор в виде дополнительной информации (какой фотокамерой снято, когда, каким редактором обработано и т.д. и т. п.) занимает объем, сопоставимый с полезной информацией.

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

 

Компрессор умеет выкидывать мусор (также как jpegoptim) без стороннего софта и без включения сжатия (mozjpeg). Это в нем по умолчанию включено.

 

Миф № 2

 

Цитата

формат WebP опасен тем, что есть риск не увидеть картинку в браузере, который не понимает WebP

 

А вот это уже целиком и полностью зависит о того каким способом реализована отдача формата WebP в браузер.

Тут вся ответственность на программисте и все зависит от степени его понимания сути данной задачи.

 

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

При наличии пары web+jpeg картинка будет доставлена совершенно в любой браузер.

 

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

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

 

Более того, я пошел несколько дальше. И предположил, что для Хрома у вас в коде (который получил уже браузер) прописан путь до картинки webp, которую Хром должен понять. А что если случится  самое страшное: путь то прописан, а самой картинки нет? Да ничего страшного! Хром покажет существующий jpeg.  При этом никаких лишних (двойных) загрузок!  Если есть webp в наличии, то Хром его отобразит. Если же такого файла нет, то он отобразит jpeg.  Но он никогда не станет качать напрасно jpeg если есть webp.

 

Я не могу себе представить такую ситуацию когда бы мой алгоритм выдачи webp мог бы дать сбой.

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

 

Итак, я специально удаляю на сервере файл картинки в формате webp,  но код (ссылка на картинку webp) будет отдаваться браузеру.  Конечно, программист может написать так свой код, что бедный браузер покажет нам пустое место вместо картинки. Но зачем нам писать дурной код?

 

Красным выделил картинку, у которой нет пары в webp.

 

 

 

 

 

Видно, что "бедный" браузер попытался загрузить сперва картинку в webp (она же прописана в HTML!),  но получил 404, т. е. картинки нет. Тогда он загружает резервный вариант PNG.

Во всех остальных случаях он загружает картинку только один раз, и именно в webp.

Специально обращаю на это внимание чтобы не возникло фантазий насчет "увеличения времени загрузки" из-за двойной загрузки изображений, т. е. пары png+webp.

Такого нет. 

 

Я специально удалил несколько файлов webp чтобы смоделировать критическую ситуацию. Максимум, что неприятного происходит - это некоторая затрата времени на ожидание ответа 404 в случае отсутствующего файла webp . Но это что-то неладное должно произойти на сервере чтобы он исчез.  С таким же успехом у вас может и jpeg испариться.

 

Как можете увидеть, то в случае отсутствия webp загружается jpeg/png.

 

 

=======================================

 

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

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

Кеш изображений очищать не нужно. За исключением случаев когда нужно наложить водяной знак или сделать обрезку фона.  В этих случаях у вас уже создается совсем другое  изображение.

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

Пусть сперва создастся кеш с водяным знаком, а сжатие (webp) можно включить позже. Таким образом можно равномерно распределить нагрузку.

 

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

 

[spectre]

Я заинтересован модулем но вы столько пишете что хватило бы на 3 блога, а можно для тупых в виде было - стало? 

 

А то вроде такой классный модуль который даёт пейджспид 100 а гугл изменил алгоритм и модуль стал ненужным но мы над этим работаем 

 

Я глубоко уважаю ваше творение но не могу понять зачем оно среднестатистическому магазину теперь для гугл пейджспид достаточно двух маленьких хаков без затрагивания картинок вообще

 

Либо на сервере жать 

 

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

 

 

Спасибо 

 

[markimax]

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

Ночная сборка FF от октября 2018-го уже поддерживает WebP.

Так что в скором времени (через пару месяцев) позиции WEbP укрепятся еще сильнее.

Напомню, что сейчас уже поддержка WEbP по статистике использования составляет 72-75%.

Можно предположить, что с FF она достигнет 90%.

 

 

 

 

Коллега пока Сафари не будет поддерживать WEBP - это минус 50%
Потому что трафик с сафари почти 40% конверсии корзины (iOS и эти "товарищи" как раз и делают конверсию, потому как у них есть деньги на iPhone)
Пока Сафари не поддержит webp - грош цена ему

Просто не используйте png и ваши попугаи будут выше
Mozjpeg - " forever "  :))))
И Компрессор очень хорошо с ним работает
Ничего не имею против модуля
Мало того - компрессор моудль /must have к покупке
Но.. коллега
WebP пока сафари его не поддержит -  в мусорку
Конечно у пользователей есть выбор
Но определение браузера - это костыль (чтобы отдать webp), потому как под ним могут маскироваться кто угодно, какой угодно браузер или пс бот
Зашел ПС бот проиндексировал webp - а у пользователей сафари в поисковике он не будет показан - 3.14 (вы думали об этом)?
В мусорку webp
Просто не используйте PNG формат

[Yoda]

Цитата

 

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

 

Миф 1.

 

  Цитата

Установите jpegoptim и у вас будет функция сжатия на сервере

 

jpegoptim не умеет сжимать!

Это программное решение создано для выкидывания мусора из файлов. За счет этого получается уменьшить вес файла.

На маленьких (порядка 1К) файлах вы можете увидеть результат существенный, т. к. мусор в виде дополнительной информации (какой фотокамерой снято, когда, каким редактором обработано и т.д. и т. п.) занимает объем, сопоставимый с полезной информацией.

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

 

Компрессор умеет выкидывать мусор (также как jpegoptim) без стороннего софта и без включения сжатия (mozjpeg). Это в нем по умолчанию включено.

 

 

Я не знаю с какой целью вы вводите людей в заблуждение, сознательно или нет!
Надеюсь что вы это делаете по неграмотности, а не от неуемной жажды наживы на несведущих пользователях, но, если вы обратитесь к документации Jpegoptim, там можно обнаружить вот такой текст:

 

Цитата

 

-m<quality>, --max=<quality>

Sets the maximum image quality factor (disables lossless optimization mode, which is by default enabled). This option will reduce quality of those source files that were saved using higher quality setting. While files that already have lower quality setting will be compressed using the lossless optimization method.

Valid values for quality parameter are: 0 - 100

 

 

Подскажите, в каком месте здесь нет сжатия?

 

По поводу WEBP.

К сожалению, у вас нет своего магазина, вы не знаете что такое цена клика, бюджет на рекламы, зарплаты сотрудников, зато вы знаете как удачно порождать мифы и продавать воздух. Так вот....

 

Не миф, а 

 

ФАКТ 1. Использование эскпериментальной необкатанной и не поддерживаемой большинством бразуеров и дополнений технологий и попытка навязать оную, является моральным преступлением по отношению к владельцам магазинов, да и всем тем кто ведется на ваше СУПЕР пупер рекламное сжатие.

ФАКТ 2. Вы верно сказали, что mozilla - добавит поддержку в течении двух месяцев, а что там Safari? А сколько у людей трафика с apple устройств может быть?
Опять я надеюсь это вы по незнанию, а не ради наживы а там и трава не расти.

 

 

[sitecreator]

3 минуты назад, spectre сказал:

А то вроде такой классный модуль который даёт пейджспид 100 а гугл изменил алгоритм и модуль стал ненужным но мы над этим работаем 

 

Mozjpeg, который сжимает jpeg в Компрессоре как работал эффективно, так и работает, и не уступает WebP.

Гугл вполне устраивают изображения сжатые с помощью Mozjpeg.

 

Но чтобы  угодить гуглу в плане PNG  можно прямо сейчас использовать в Компрессоре WebP для PNG.

 

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

зачем оно среднестатистическому магазину теперь

 

шибко разные у всех магазины.

Если вам достаточно пары хаков, то можно порадоваться за вас.

Но это далеко не везде прокатит.

[sitecreator]

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

Коллега пока Сафари не будет поддерживать WEBP - это минус 50%

 

Так смысл в том, что Гугл на это не обращает внимания. Он ранжирует исходя из сравнения изображений, которые отдаются в его виртуальный Chrome. И он их сравнивает с форматом WEbP.

 

Я ни в одном магазине не видел такой статистики чтобы сафари занимал 50% рынка.

Есть специализированные компании, которые занимаются сбором статистики.  Им можно верить?

 

Чисто практически, конечно, не здорово, что сафари остается за бортом.

Но как это влияет на отношение гугла?  Ведь задача у всех № 1 - это угодить гуглу.

Разве владелец магазина или разработчик (верстальщик, программист) по своей воле будет как-то учитывать насколько быстро что-то загружается в мобильник в сети 3G?

 

 

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

Но определение браузера - это костыль (чтобы отдать webp), потому как под ним могут маскироваться кто угодно, какой угодно браузер или пс бот

 

тут я полностью согласен.

а потому в принципе не использую такой подход.

[markimax]

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

 

 

 

Я ни в одном магазине не видел такой статистики чтобы сафари занимал 50% рынка.

 

У меня другая статистика по клиентам
Там продажи с мобильных более 50%
А конверсия у сафари из них 70%
Без обид - но пока webp не будет поддерживаться сафари - к моНАХам его
Вы думали  вообще ... что зайдет бот google, прикинется chrome - сьест изображения как webp в индекс и потом что он будет отдавать пользователям сафари (по умолчанию google поиск в iOS) !? Я скажу что - х

[sitecreator]

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

Но я это как-то даже и не рассматривал, т.к. при нужной настройке тот же imagick, к примеру, также выдает прогрессивный JPEG.  Т. е. это вроде как само-собой разумеющееся действие при правильном изначальном сохранении JPEG.  Также как и выкидывание мусора. Да, это все оптимизация, которая не требует особых ухищрений. Но это не сжатие. При сжатии также используются эти приемы как дополняющие.  Т.е. прогрессивный формат и очистку от мусора Компрессор может делать на уровне php.

[sitecreator]

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

Вы думали  вообще ... что зайдет бот google, прикинется chrome - сьест изображения как webp в индекс и потом что он будет отдавать пользователям сафари (по умолчанию google поиск в iOS) !? Я скажу что - х

 

Думал.

И решил, что гугл не настолько недальновидный чтобы так поступать.

Предполагаю, что гугл будет это делать как-то изящно.  По крайней мере, мне так думается.

Но некая топорность в подходе и у него случается.

 

Я исхожу из того, что webp предполагает пока наличие неразрывной пары.  И, наверняка, гугл это будет учитывать везде.

 

Также исхожу из той логики, что основная картинка прописана в теге <img>,  и там будет всегда только jpeg/png.

И любой браузер будет видеть именно эту картинку как основную или единственную (в случае старых браузеров).

А WebP поставляется опционально .  Поэтому думаю, что и ранжироваться будут по прежнему именно jpeg/png как основные.

[sitecreator]

Яндекс, замечено , еще примерно год назад перешел на WebP.

Не думаю, что на сайтах все эти картинки были в WebP.

 

К размышлению о ранжировании.

 

 

 

 

 

 

[Nameless]

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

Яндекс, замечено , еще примерно год назад перешел на WebP.

Не думаю, что на сайтах все эти картинки были в WebP.

 

К размышлению о ранжировании.

 

 

 

 

 

 

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

[sitecreator]

16 часов назад, Nameless сказал:

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

 

И какую мысль вы хотите донести?

В Сафари тоже не будет.

Только как это к ранжированию относится?

 

Подозреваю, что вы заходили не с нового, а с 17-го edgeHTML.  Впрочем, это не важно, т. к. ни один браузер без картинки не остается.  Да и равняться на пользователей IE, которых практически не осталось, тоже несколько странно.  Производители приложений для смартфонов  в подавляющем большинстве даже не рассматривают мобильный вариант windows как платформу, для которой нужно выпускать софт. Она вроде как существует в природе, но как экзотический вымирающий вид, также как и сами смартфоны на базе windows (мобильной) .

 

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

 

Давайте рассуждать логично.

Сам по себе JPEG или WebP - это всего навсего архив, но не сама матрица изображения в отличие, например, формата bmp и подобных.

Т.е. чтобы получить изображение, грубо говоря, матрицу пикселей RGB нужно распаковать архив.  И именно после распаковки можно оценивать изображение.

Только так и никак иначе.  Вот эти данные и оценивают поисковики на оригинальность изображения и прочее.

Фотошоп также как и поисковики сначала распаковывает JPEG, но не может работать с ним напрямую. Для работы напрямую есть низкоуровневые форматы, в которых вы буквально можете менять пиксели прямо в файле, например, через HEX-редактор потому, что в данном случае файл будет снимком самой матрицы изображений.

 

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

 

 

Вот яндекс показывает в webp.

 

 

Вот прямая ссылка на это изображение (заметьте, что оно отображается в вашем браузере, который даже не поддерживает webp):

 

вот оно в виде ссылки:

http://im0-tub-ru.yandex.net/i?id=1af57bab2547f7041f4894ab62bb1307&amp;n=13&amp;exp=1

 

при попытке сохранить вы увидите реальное название файла и его расширение. Это будет webp в браузерах, поддерживающих его.

 

 

 

 

а теперь посмотрите в каком формате этот файл на сайте, с которого яндекс взял эту картинку:

 

 

вот эта картинка -исходник 1200*1200 с сайта-донора:

 

 

https://opt-1087534.ssl.1c-bitrix-cdn.ru/images/dt-fwex175020-110mm-white.jpg?1488462357177892

 

Специально показываю в виде ссылки чтобы было видно, что это JPEG.

 

Т. е. уже из этого видно, что прямой связи между форматом исходника и отображаемым поисковиком форматом связи нет.

Поэтому волноваться, что могут быть проблемы с ранжированием WebP, не стоит.

Неужели можно предположить, что Гугл, рекомендуя свой любимый формат WebP,  будет дискредитировать его как то при ранжировании? Это же нелогично получается?

 

Все сказанное - лишь мои логические предположения, т. е. "имхо".  В сети не встречал никакого упоминания о проблемах с ранжированием webp.

 

[100napb]

On 11/28/2018 at 4:27 AM, sitecreator said:

 

On 11/28/2018 at 4:11 AM, markimax said:

Но определение браузера - это костыль (чтобы отдать webp), потому как под ним могут маскироваться кто угодно, какой угодно браузер или пс бот

 

тут я полностью согласен.

а потому в принципе не использую такой подход. 

 

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

 

Я у себя ради интереса использовал вот такую конструкцию в конфигах nginx. Работает исправно: проверяется заголовок $http_accept на поддержку webp браузером (без разницы, какой браузер; главное то, что он явно сообщает веб-серверу о своих возможностях). А затем сам веб-сервер решает, какой файл отдавать. Единственное, при таком решении в исходном html-коде никакой подмены jpg на webp не происходит:

Spoiler

#location ~* (^.+)\.(png|jpg|jpeg)$ {
# 	if ( $http_accept ~* webp ) {
#		set $webp "A";
#	}
#	if ( $request_filename ~ (.+)\.(png|jpg|jpeg)$ ) {
#		set $file_without_ext $1;
#	}
#	if ( -f $file_without_ext.webp ) {
#		set $webp "${webp}E";
#	}
# 
#	if ( $webp = AE ) {
#		add_header Vary Accept;
#		rewrite (.+)\.(png|jpg|jpeg)$ $1.webp break;
#	}
#}

 

[sitecreator]

12 минут назад, 100napb сказал:

использовал вот такую конструкцию в конфигах nginx

 

Это правильная идея. По идее самое простое без всякого изменения кода движка - это правильный конфиг веб-сервера.  Но на общем хостинге это довольно часто невозможно.  Или возможно, но тогда нужно отключать обработку статики сервером nginx, что снижает производительность. На VDS нет проблем никаких.

 

Поэтому для общего хостинга приходится использовать приемы посложнее.

[sitecreator]

22 минуты назад, 100napb сказал:

при таком решении в исходном html-коде никакой подмены jpg на webp не происходит

 

и не должно. Это не является ни недостатком, ни достоинством.  Просто особенность.

Такая же особенность как использование, например, <picture>, там тоже никакой подмены jpg на webp в <img> не происходит.

фактическую загрузку (файл и его расширение) можно увидеть в панели инструментов браузера.

 

Предполагаю, что полного понимания насчет webp нет у большинства разработчиков. Все их опасения связаны с подменой или неправильной подменой в коде HTML.  Т. е. строятся неверные выводы на основе неверного представления о механизме передачи/отображения webp.  Хотя практики подмены существуют, но это, действительно, костыли.  Смысл обсуждать дурные практики (костыли) и смысл их использовать когда есть нормальные методы?

[dexion]

33 минуты назад, 100napb сказал:

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

 

https://ruhighload.com/Оптимизация+изображений+с+webp вот тут вроде поаккуратней правило указано для nginx

Змінено 29 листопада 2018 користувачем dexion

[sitecreator]

25 минут назад, dexion сказал:

вроде поаккуратней правило указано для nginx

 

сам код для конфига пока не смотрел.

Но подход верный - прописывать правила либо в конфиг nginx, либо в конфиг апачи в зависимости от того, кто из них обрабатывает статику.

 

Желательно предусмотреть случай, что файл webp может физически отсутствовать на сервере по недоразумению, то тогда отдавать файл jpeg даже если браузер подтверждает поддержку webp.  Чтобы исключить вероятность отображения пустоты вместо картинки.  К браузерам это не относится напрямую, это уже заморочки и бардак на сервере получаются. Мало ли по какой причине нет webp на сервере...

[dexion]

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

файл webp может физически отсутствовать на сервере по недоразумению, то тогда отдавать файл jpeg даже если браузер подтверждает поддержку webp

А лучше генерировать отсутствующую картинку на лету и отдавать ее

[sitecreator]

12 минут назад, dexion сказал:

А лучше генерировать отсутствующую картинку на лету и отдавать ее

 

именно так сделано в 1.10 версии Компрессора.

Но если по какой-то причине невозможно создать webp, то тоже не проблема, будет показан jpeg.

 

По какой причине может быть невозможно сделать webp?

Например, неправильный JPEG,  это когда внутри него PNG находится.  Или сам JPEG является битым.

 

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

И заметьте, что в силу имеющегося опыта я даже учитываю "фантастические" варианты вроде PNG внутри JPEG.  А это, увы, случается нередко из-за использования всяких парсеров картинок и импорта товаров с картинками.  Просто эпидемия какая-то.  И многие клиенты даже и не не догадываются от такой проблеме.

 

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

Ну да... Но если у файл только расширение JPEG, то это еще не значит, что внутри JPEG.

 

Кстати, Компрессор и эту проблему исправляет.  делает из неправильного JPEG (когда тот PNG, а оттого раздут многократно) правильный.

Это к вопросу, что же Компрессор умеет полезного.

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

 

Просто все рассматривают какие-то идеальные случаи, но статистика говорит, что если у вас парсер или импорт товаров с картинками, то с вероятностью, как минимум, 50%+ у вас масса изображений PNG, которые замаскированы под JPEG.  Бывает и наоборот.