Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 58
Может Mozilla хочет «спонсорской помощи» чтобы внедрять решения Google/Microsoft (например NaCl, WebP, Dart, итд). Пока какие-то решения только в одном браузере разработчики не спешат ими пользоваться.
И где же ссылка для «поиграться»?
blog.mozilla.org/research/2014/03/05/introducing-the-mozjpeg-project/
Версия 1.0 — это форк libjpeg-turbo, в которую прикрутили функциональность perl-скрипта jpgcrush
Патчи от Mozilla не будут приняты обратно в libjpeg-turbo (www.libjpeg-turbo.org/About/Mozjpeg), сжатие mozjpeg в несколько раз медленнее (например, issue 13); также немного замедляется распаковка большинства изображений, пересжатых с помощью mozjpeg
Версия 1.0 — это форк libjpeg-turbo, в которую прикрутили функциональность perl-скрипта jpgcrush
… version 1.0, is a fork of libjpeg-turbo with ‘jpgcrush’ functionality added. We noticed that people have been reducing JPEG file sizes using a perl script written by Loren Merritt called ‘jpgcrush’, references to which can be found on various forums around the Web. It losslessly reduces file sizes, typically by 2-6% for PNGs encoded to JPEG by IJG libjpeg, and 10% on average for a sample of 1500 JPEG files from Wikimedia. It does this by figuring out which progressive coding configuration uses the fewest bits.
Патчи от Mozilla не будут приняты обратно в libjpeg-turbo (www.libjpeg-turbo.org/About/Mozjpeg), сжатие mozjpeg в несколько раз медленнее (например, issue 13); также немного замедляется распаковка большинства изображений, пересжатых с помощью mozjpeg
А где оптимизация?
Оригинал из статьи: 22,9 КБ
Совсем чуть-чуть оптимизированный png: 3,2 КБ
Совсем чуть-чуть оптимизированный png: 3,2 КБ
такие форматы, как WebP, предлагают ряд возможностей, которые не доступны в JPEG (например, анимации), но для Mozilla этого недостаточно, чтобы поддержать ихНе то что drm — наиболее важный функционал, полностью соответствуют своим слоганам на главной:
Стремление делать добро заложено в нашем кодеТёмную силу
Преданный вам, вашей приватности и открытому Интернету
Давайте исследовать, пробовать и творить вместе, чтобы построить открытый и общий Интернет.
Хабр чудит — ваша картинка весит аж 9 килобайт.
Фейсбуковцы уже на стену лезут от этой моды на фоточки и селфи.
Я сначала не понял, в чём суть — существует (и довольно давно) jpegtran, который весьма неплохо оптимизирует жпеги. А выяснилось, что оно внутри и есть jpegtran, но с улучшенной степенью сжатия:)
Фейсбуковцы уже на стену лезут от этой моды на фоточки и селфи.
Я сначала не понял, в чём суть — существует (и довольно давно) jpegtran, который весьма неплохо оптимизирует жпеги. А выяснилось, что оно внутри и есть jpegtran, но с улучшенной степенью сжатия:)
Низачёт за оптимизацию — ваша картинка весит 8,90 КБ (9 121 байт)
Однако да, оригинальный текст в JPEG'е (равно как и любой текст в этом формате) я не могу рассматривать иначе, чем
а вот эта всего 4,91 КБ (5 034 байт)
Однако да, оригинальный текст в JPEG'е (равно как и любой текст в этом формате) я не могу рассматривать иначе, чем
вот так
На самом деле Google не поддержал формат APNG, разработанный в Mozilla. Вот в они, похоже, в ответ также не хотят поддерживать WebP :)
Верхние буквы темнее
На нижней картинке некоторые детали слегка «замылились». Например, левый край буквы «o».
Но вообще, если не выискивать специально отличия, то разница не видна.
Но вообще, если не выискивать специально отличия, то разница не видна.
Мне кажется что все идут не в ту сторону. Я хочу чтобы изображение было такое, которое мне достаточно не только по скорости соединения но и по устройству вывода. Я хочу чтобы оно подгружалось и не мешало чтению. Я не хочу чтобы подгружались те, которых я никогда не увижу.
Подготавливать каждому персонально сжатую картинку будет стоить чудовищных мощностей (и, соответственно, электричества).
Opera Turbo справляется же как-то.
Большинство людей смотрят одни и те же сайты.
Но на разных устройствах. Изначальный комментатор хотел, чтобы ему доставлялась картинка минимально его удовлетворяющая, проблема в том, что во-первых, зоопарк устройств большой, во-вторых, критерии минимального удовлетвортельного качества у всех разные. И по-моему, имея практически неограниченные вычислительные ресурсы на стороне пользователя, логично было бы спихнуть работу по изменению размера картинки на клиент (тут, конечно, зависит от размера оригинала: не стоит пользователю на смартфон отдавать 20-мегапиксельные фотографии в PNG).
Да нет. 5% это никакой не прорыв. И даже 15% — не прорыв. Это даже не стоит никакой новости.
При сохранении совместимости с форматом даже 5% — это успех.
Ну вот у нас только в одной инсталляции нашего продукта 8 терабайт джпегов. Если их обработать этой штукой, получит 400 гигабайт свободного места в плюс. Нелохо, как мне кажется.
Это те самые ребята, что уже 5 лет не могут сделать нормальной работу img style='scale:0.5' в своем супер-браузере? :)
Про любой браузер можно составить подобную фразу, у всех есть нереализованные фичи, которые уже поддерживает кто-то другой.
Mozilla занимается много чем кроме собственно своего браузера. Например, они принимали участие в разработке кодека Opus. Были и другие интересные проекты. Я вот сожалею, что они свернули развитие Mozilla Persona — очень интересный проект, но без поддержки компаний типа Google им одним сложно такое продвинуть, к сожалению.
Mozilla занимается много чем кроме собственно своего браузера. Например, они принимали участие в разработке кодека Opus. Были и другие интересные проекты. Я вот сожалею, что они свернули развитие Mozilla Persona — очень интересный проект, но без поддержки компаний типа Google им одним сложно такое продвинуть, к сожалению.
scale? zoom, может? zoom там не работает, а scale — да: -moz-transform: scale(число);
Scale не работает: уменьшение картинки происходит, а контент все равно считается по исходным размерам. Т.е. он сначала все верстает, а потом уменьшает картинку. Бессмысленное действие, потому что вокруг нее просто очень много полей пустых образуется. Я когда искал как это обойти, нашел баги датированные 2009 годом.
По словам технического директора Mozilla Андреаса Гала, организация обнаружила, что WebP, майкрософтовский JPEG XR и подобные royalty-free-форматы не предлагают достаточно улучшений по сравнению с JPEG, чтобы оправдать затраты и усилия на раскрутку нового формата в интернете.
Расстрелять. В Интернете вовсю используются палитровые привет-из-восьмидесятых GIFки. Полноцветные изображения для устранения потерь качества или необходимости альфа-канала хранятся в PNGшках, которые превращаются практически в BMP. Но да — у всех нормальных форматов «недостаточно улучшений».
И уж 5% — это просто умопомрачительное улучшение по сравнению с 20-60% от перехода на WebP.
Вместо этого, форматом, у которого наибольший потенциал для включения в Firefox, по мнению Гала, является Daala — новая технология сжатия видео, над которой Mozilla работает в партнёрстве с фондом Xiph.Org.
ЕЩЁ один формат?! Чуваки, Гугл же вас пошлёт, как с мертворождённым APNG.
20-60% у wepb нет абсолютно.
habrahabr.ru/post/214813/#comment_7381755
20% поверю и то спорно, потому что главные артфакты webp — мыло в низкочастотных областях. А это мыло сейчас выглядит не лучше чем квадраты.
Да, низкочастотные области мылятся, а у jpg независимо по всем частотам идут квадраты. Что в некоторых случаях очень нужно.
К примеру, смысл вашей фотографии сводится к плохо различимому фону (белый медведь в снежную буру) на фоне чего то яркого, а благодаря умным кодерам он будет благополучно замылен ибо не распознан как значимая область.
JPG жмет равномерно, webp выбирает что важно, а что нет.
Если учесть что jpg довольно хорошо восстанавливается со своими артефактами — проверьте не поленитесь www.vicman.net/jpegenhancer/
Это можно было добавить в декодер. В случае webp я даж не знаю чем можно восстановить артефакты. Оно правда нафиг нужно…
habrahabr.ru/post/214813/#comment_7381755
20% поверю и то спорно, потому что главные артфакты webp — мыло в низкочастотных областях. А это мыло сейчас выглядит не лучше чем квадраты.
Скрытый текст
Да, низкочастотные области мылятся, а у jpg независимо по всем частотам идут квадраты. Что в некоторых случаях очень нужно.
К примеру, смысл вашей фотографии сводится к плохо различимому фону (белый медведь в снежную буру) на фоне чего то яркого, а благодаря умным кодерам он будет благополучно замылен ибо не распознан как значимая область.
JPG жмет равномерно, webp выбирает что важно, а что нет.
Если учесть что jpg довольно хорошо восстанавливается со своими артефактами — проверьте не поленитесь www.vicman.net/jpegenhancer/
Это можно было добавить в декодер. В случае webp я даж не знаю чем можно восстановить артефакты. Оно правда нафиг нужно…
Я не понимаю, откуда у всех такая любовь к издевательству над кодеками. Я забыл, когда в последний раз видел жутко пережатый JPEG. Кто-нибудь сохраняет JPEG с качеством ниже 90%?
20–60% — для разных форматов. Анимированные гифки можно пережимать очень эффективно, выигрыш может быть огромным. С JPEG и PNG выигрыш заметно меньше, но он тоже гораздо более ощутимый, чем смехотворные мозилловские 5%.
Да даже чёрт с ней, с разницей в 20%. Где в вебе сжатие с потерей качества, но 8-битным альфа-каналом? Где полноцветные анимированные картинки? Где анимации с альфа-каналом? Меня отсутствие функционала у используемых форматов больше раздражает, чем время скачивания.
20–60% — для разных форматов. Анимированные гифки можно пережимать очень эффективно, выигрыш может быть огромным. С JPEG и PNG выигрыш заметно меньше, но он тоже гораздо более ощутимый, чем смехотворные мозилловские 5%.
Да даже чёрт с ней, с разницей в 20%. Где в вебе сжатие с потерей качества, но 8-битным альфа-каналом? Где полноцветные анимированные картинки? Где анимации с альфа-каналом? Меня отсутствие функционала у используемых форматов больше раздражает, чем время скачивания.
Меня отсутствие функционала у используемых форматов больше раздражает, чем время скачивания.
это пока с GPRS'ом в роуминге не столкнулся.
если в Нерезиновой интернетом пользоваться, то всё равно, а за её пределами даже сотовый иногда только с внешней антенной ловит.
Ну так они же все объясняли что бесполезно воевать с новыми форматами. Куча сил и средств и нуль эффектов. Взялись за оптимизацию текущего, что сказать довольно грамотно, но это при условии что будет доступны готовые любы для всех gd2, image magic и тп.
Нету в вебе сжатия с потерей и 8 битной альфой, во флеше есть. PNG панда жмет изображение png24 в png8 при наличии 8 битного альфа канала и усе.
Если этого нет, видимо силы компании не способны к этому, либо на патент нарываемся либо не выстреливает. Вот wma — был встроен в аппаратные декодеры дешевых плееров и толку… никому не нужен, за непонятные плюшки (DRM, и что то там чуть лучше mp3) универсальность важнее новизны как показывает практика внедрения технологий. Машина слишком не поворотлива.
Нету в вебе сжатия с потерей и 8 битной альфой, во флеше есть. PNG панда жмет изображение png24 в png8 при наличии 8 битного альфа канала и усе.
Если этого нет, видимо силы компании не способны к этому, либо на патент нарываемся либо не выстреливает. Вот wma — был встроен в аппаратные декодеры дешевых плееров и толку… никому не нужен, за непонятные плюшки (DRM, и что то там чуть лучше mp3) универсальность важнее новизны как показывает практика внедрения технологий. Машина слишком не поворотлива.
Нету в вебе
А в WebP есть это всё и много чего ещё. Лицензия BSD, патентами не захвачен (вопли «А вдруг патент всё-таки есть?» всерьёз не воспринимаю, потому что проблема совершенно динакова для любого нового формата), портировано на все оси. Преимущества огромные и очевидные. Используй — не хочу. Но нет, Мозилле чего-то не хватает.
Мозилловский APNG («конкурент») — костыль на костыле, совершенно не оптимизированный под анимацию формат. Обратная совместимость с PNG к чертям не нужна, потому что отображаемый результат всё равно тербуется везде одинаковый. И этот формат официально послан в попу хозяевами PNG, так что даже трепыхаться бесполезно.
смехотворные мозилловские 5%.«Смехотворные мозилловские 5%» работают во всех браузерах, даже самых старых. А что касается WebP — думаете, Microsoft и Apple в принципе могут поддержать что-то подобное? С трудом представляю себе такую ситуацию. Разве что издание закона об обязательной поддержке свободных стандартов и соответствующее решение суда.
APNG в этом плане имел куда больше шансов, если бы поддерживался всеми Open Source браузерами — ведь он как минимум отображал бы первый кадр во всех остальных браузерах, из-за чего им в принципе можно было бы пользоваться в случаях, когда анимацией можно было бы пожертвовать. Как пример, иконка «горячей» темы в форумах, графические смайлики. Пускай бы эти изображения отображались во всех браузерах, но в свободных — с анимацией. Глядишь, среди пользователей прошла бы молва, что IE глючит и часто не отображает анимацию, из-за чего кто-то бы мигрировал бы на свободные браузера, а MS и Apple со временем были бы вынуждена реализовать поддержку APNG. С WebP такого не выйдет, потому что в случае использования только этого формата пользователи других браузеров не увидят вообще никакой картинки (что выглядит как типичная ошибка сайта, а не браузера), а если делать fallback в JPEG/PNG, то вообще непонятно в чём выигрыш — на сервере места занято больше, а пользователи IE или Safari даже подозревать не будут, что у них что-то не так, как у других.
А что касается WebP — думаете, Microsoft и Apple в принципе могут поддержать что-то подобное?
SVG же поддержали.
Глядишь, среди пользователей прошла бы молва, что IE глючит и часто не отображает анимацию, из-за чего кто-то бы мигрировал бы на свободные браузера
Так не бывает. Виноват всегда веб-разработчик. «Почему у меня смайлики не двигаются? — Потому что IE. — На остальных форумах работает же! — Там другой формат. — Ну и сделай так же, не выпендривайся!»
SVG же поддержали.Наверное, они просто не были заинтересованы в продвижении какого-то своего формата. Зато они очень заинтересованы в продвижении H.264/H.265/AAC. Поэтому поддержки VP8/VP9/Ogg Vorbis/Opus ожидать от них уже не приходится. На всякий случай напомню, что поддержку Ogg Vorbis компании Microsoft и Apple не добавляют уже больше 5 лет. Изначально этот формат был описан в стандарте HTML5 как обязательный для поддержки, но заинтересованные игроки добились исключения этого пункта. Apple вообще не стесняясь выпиливает поддержку свободных форматов даже там, где она изначально была. Например, первые iPod Shuffle производились на чипах Sigmatel STMP35xx, которые по умолчанию поддерживали Ogg Vorbis, но в продукции Apple эту поддержку старательно выпилили. У меня тогда был Samsung YP-U2 на Sigmatel STMP3550 — он без проблем справлялся с этим форматом и даже поддерживал UTF-8 Vorbis Comment (теги).
Apple и Microsoft уже лет 10 воротят нос от свободных форматов, и я не вижу даже намёка на то, что они изменились. Хотя тот же свободный Opus на сегодняшний день объективно лучший кодек с потерями, который подходит как для VoIP, так и для музыки. Но на браузерах Mozilla и Google его поддержка заканчивается. Зато запатентованный и неуниверсальный AAC теперь поддерживается почти везде. Google старательно сидел на двух стульях, поддерживая как свободные форматы, так и несвободные, хотя долгое время обещал отказаться от последних. В такой ситуации Mozilla была вынуждена поддержать несвободные форматы, а это был один из последних весомых игроков, который не поддерживал несвободные технологии.
Есть ли шансы, что свободный WebP (который часть WebM) поддержат MS и Apple, когда нужные им форматы поддерживаются уже почти везде (кроме Opera)? Если бы когда-то они договорились бы, мол вы поддерживаете наши свободные форматы, мы поддержим ваши несвободные, и будем жить дружно — может быть. Но чуда не случилось, и более широкую поддержку имеют те форматы, в продвижение которых вложено больше денег, а не те, поддержку которых было проще всего и дешевле реализовать.
Есть ещё небольшая надежда на WebRTC, где поддержка свободного кодека Opus — обязательна. Но MS и Apple не хотят реализовывать поддержку этого формата и прилагают усилия, чтобы упоминание формата Opus было убрано из стандарта, что когда-то они уже провернули с HTML5. Правда, пока что не вышло, поэтому поддержки WebRTC нет в браузерах этих компаний. Зато MS изобрела вообще что-то своё, похожее на WebRTC, но с возможностью использовать «правильные» с их точки зрения форматы.
«Почему у меня смайлики не двигаются? — Потому что IE. — На остальных форумах работает же! — Там другой формат. — Ну и сделай так же, не выпендривайся!»Частично такая же проблема была когда-то с IE6. Однако, слава «в нём всё глючит и криво отображается» со временем к нему в итоге всё же пришла, хотя пользователи долго не хотели с его слазить, ведь «всё и так вроде как работает», что стоило огромных усилий со стороны веб-разработчиков.
Хотя тот же свободный Opus на сегодняшний день объективно лучший кодек с потерями, который подходит как для VoIP, так и для музыки.
Опус вживую я не особо видел. Если говорить про аудио, то патенты MP3 не протухли только в Штатах. К их идиотской патентной системе я любви не питаю, так что пусть выкручиваются как хотят (или ждут ещё 3 года, чтоб наверняка). Лично я никаких стеснений не ощущаю.
Качество низких битрейтов меня тоже мало волнует, потому что музыку я держу в высоких битрейтах, а в универсальный стандарт VoIP я не верю. Это сказки. Вон, есть Jabber. Банальная вещь: сообщения передавать, файлы пересылать, всё такое. Сколько проблем было? Несколько конфликтующих реализаций стандартного функционала, вялое перетекание юзеров, прикрытие жаббер-сервисов корпорациями… Всё уныло.
Какой к чертям VoIP… Утопия.
Есть ли шансы, что свободный WebP (который часть WebM) поддержат MS и Apple, когда нужные им форматы поддерживаются уже почти везде (кроме Opera)?
Мелкомягкие и обгрызанные свои форматы картинок не пропихивают же? Или WebP без WebM немыслим?
И что вообще мелкообгрызанные имеют с несводобных кодеков? Это их же имеют патентами, а не они остальных.
Однако, слава «в нём всё глючит и криво отображается» со временем к нему в итоге всё же пришла
С опозданием лет эдак на 5…
Opus — действительно хороший кандидат на стандарт. Максимальное качество, минимальная задержка (очень актуально для VoIP). Он немножко проигрывает по качеству HE-AAC v2 при кодировании музыки на битрейте около 30kbps, но уже при 64kbps он вырывается вперёд, и это при том, что формат ограничен маленьким размером фрейма.
Мелкомягкие и обгрызанные свои форматы картинок не пропихивают же? Или WebP без WebM немыслим?Про Windows Media Photo, который переименовали в JPEG XR не слышали?
И что вообще мелкообгрызанные имеют с несводобных кодеков? Это их же имеют патентами, а не они остальных.MS и Apple являются держателями многих патентов, касающихся H.264 и AAC, так что они заинтересованы в продвижении этих форматов.
Впервые слышу про JPEG XR. Русская версия статьи заметно устарела, там даже лицензия неверно указана. С одной стороны, теперь это под BSD и чессловом, с другой стороны, киллер-фич по сравнению с WebP не замечаю (больше цветовых пространств (вроде), какая-то магия lossy-lossless — вот и всё). По SSIM сливает всем подряд…
Если WebP я вживую в вебе пару раз встречал, то JPEG XR даже не пахнет. Что-то не заметно, что его продвигают.
Если WebP я вживую в вебе пару раз встречал, то JPEG XR даже не пахнет. Что-то не заметно, что его продвигают.
Я с WebP столкнулся однажды, когда загружал версию своего расширения Pure URL в Chrome Webstore. Я заметил, что все изображения на этом сайте в Firefox выглядели ощутимо лучше, чем в Chrome. Оказалось, что Google пережимал все изображения в WebP и отдавал именно их в своём браузере. Он и сейчас пережимает, но видимо разработчики поубавили степень сжатия, потому что теперь такие противные артефакты, как ранее, не бросаются в глаза.
Я сохраняю. Не вижу смысла сохранять с качеством выше 50. Разве что какие-что совсем очевидные артефакты вылезут. Тогда можно 60.90 — это пустая трата места.
Ну так вот чего жаловаться. Google послал их с APNG, который решал одну из существующих проблем, требовал минимальный патч в пару сотен строк в существующем декодере PNG, при этом предлагая отличный fallback, в отличие от WebP. Годами позднее Mozilla в ответ послала Google с их WebP. А с этого формата толку мало, пока его не поддерживают все браузера. Так и живём. Когда Open Source проекты воротят нос от разработок друг друга, чего уж тут говорить о Microsoft и Apple, у которых есть интерес в продвижении форматов, на которые у них есть пакеты патентов.
Ну а почему бы не послать если аппаратно webp тяжел, и не такие у него и прорывные технологии. Исключая универсальность и прорывность возникла спорность. Стоит ли плодить еще один стандарт, внося еще больше неразберихи и поддержки.
Google послал их с APNG, который решал одну из существующих проблем, требовал минимальный патч в пару сотен строк в существующем декодере PNG
В первую очередь этот формат был послан в попу PNG Group, а не гуглом.
Фоллбэк — это клёво, но по остальным параметрам формат ужасен, он откровенно не предназначен для анимации. Представьте, что «смешные картинки» (зачастую нарезанные с тытрубки) сегодня начали постить в APNG. Они же в пять раз толще будут. И я не верю в фоллбэки, потому что в 95% случаев нужно, чтобы отображалось всё и правильно во всех актуальных браузерах (а часто и неактуальных).
Да, в новости забыли указать, какое влияние на процессор изменение сжатия окажет.
Вообще же, им бы не пару процентов выжимать, а хотя бы с цетовыми профилями договориться одинаково во всех браузерах работать. А то заходишь на сайт IE, FF и GC — а цветах некоторых фото — разные. Если любопытно разобраться, то вскоре оказывается, что у «уехавших» фото просто внедрен цветовой профиль.
Сегодня, когда IPS монитор купить не особо и сложно, и уж точно не так чтобы дорого, выбор, имеющийся у вебмастеров (а именно тупо сохранение без профилей, в самом узком цветовом пространстве) выглядит издевательством. И речь даже не идет о новом хитром кодеке или формате — просто о том, чтобы дать ОС использовать цункции управления цветопередачей в отношении фото, которые профиль имеют. Оно, конечно, явно потребует на каждой платформе отдельной реализации, но тут уж что поделаешь?
Вообще же, им бы не пару процентов выжимать, а хотя бы с цетовыми профилями договориться одинаково во всех браузерах работать. А то заходишь на сайт IE, FF и GC — а цветах некоторых фото — разные. Если любопытно разобраться, то вскоре оказывается, что у «уехавших» фото просто внедрен цветовой профиль.
Сегодня, когда IPS монитор купить не особо и сложно, и уж точно не так чтобы дорого, выбор, имеющийся у вебмастеров (а именно тупо сохранение без профилей, в самом узком цветовом пространстве) выглядит издевательством. И речь даже не идет о новом хитром кодеке или формате — просто о том, чтобы дать ОС использовать цункции управления цветопередачей в отношении фото, которые профиль имеют. Оно, конечно, явно потребует на каждой платформе отдельной реализации, но тут уж что поделаешь?
Да, забыл отметить. Тут както наткнулся на то, что wordpress не убирает мету из фотографий даже в превьюшках. Итого, если вы постите в блог фотографии сразу с фотика, ваша превьюшка может 30kb отдать на мету при 5kb физических графических данных. И эти 30kb не сжимаются gzip, насколько я знаю, вебсервера игнорируют jpg, нафига их сжимать? Так что при выводе галлереи из 15 штук вы 450kb потратите только на мету!!!
core.trac.wordpress.org/ticket/28634
Будет в релизе, надо будет сделать плагинчик. Категорически отказались в целях обратной совместимости включать возможность вырезания меты по дефолту в превьюшках в следующем релизе. То есть по массе своей ничего не поменяется в трафике на столь популярной cms системе. Якобы мета кому то нужна в превьюшках. Это допускаю исключительно при наличии icc профилей. Распространение которых ясчитаю крайне малым в силу сложности вообще понимания что это такое и нафига если в вебе sRGB вроде бы как все устраивает.
Итого, у нас есть два стандарта jpg. Exif и jfif. Последний съедает меньше места по дефолтным параметрам. Exif же больше сжирает по своей структуре. Килобайта на два три четыре. То есть всяческие оптимизаторы jpg не обращают внимания на этот вопрос, что если перепилить заголовки jpg файла это тоже даст выигрышь в процентном соотношении, особенно для превьюшек.
core.trac.wordpress.org/ticket/28634
Будет в релизе, надо будет сделать плагинчик. Категорически отказались в целях обратной совместимости включать возможность вырезания меты по дефолту в превьюшках в следующем релизе. То есть по массе своей ничего не поменяется в трафике на столь популярной cms системе. Якобы мета кому то нужна в превьюшках. Это допускаю исключительно при наличии icc профилей. Распространение которых ясчитаю крайне малым в силу сложности вообще понимания что это такое и нафига если в вебе sRGB вроде бы как все устраивает.
Итого, у нас есть два стандарта jpg. Exif и jfif. Последний съедает меньше места по дефолтным параметрам. Exif же больше сжирает по своей структуре. Килобайта на два три четыре. То есть всяческие оптимизаторы jpg не обращают внимания на этот вопрос, что если перепилить заголовки jpg файла это тоже даст выигрышь в процентном соотношении, особенно для превьюшек.
>> не предлагают достаточно улучшений по сравнению с JPEG
В сотый раз повторю — банально включение арифметического сжатия у jpeg даёт выигрыш на 25-30%. Патенты давно закончились, но браузеры до сих пор не поддерживают такой jpeg. Слоупоки и ССЗБ.
А также напомню про habrahabr.ru/post/214813/#comment_7381955 h265 still image, который на 60% лучше jpeg и который не надо изобретать.
В сотый раз повторю — банально включение арифметического сжатия у jpeg даёт выигрыш на 25-30%. Патенты давно закончились, но браузеры до сих пор не поддерживают такой jpeg. Слоупоки и ССЗБ.
А также напомню про habrahabr.ru/post/214813/#comment_7381955 h265 still image, который на 60% лучше jpeg и который не надо изобретать.
В сотый раз повторю — банально включение арифметического сжатия у jpeg даёт выигрыш на 25-30%.
Объясните в сто первый раз, чем jpg c арифметическим сжатием, которое никто пока не поддерживает отличается от любого другого формата, который никто пока не поддерживает?
Смысл в обратной совместимости, о чем тут и толкуют.
1) Мы включаем в мозилле новый jpg.
2) Кто-то не включает ( IE пользователи досвиданья точно, мобильные браузеры тоже)
3) все путаются — вроде jpg а не работает.
что то стало лучше и понятнее?)
А не проще ли перейти на другой формат тем кому это нужно. Тот же JPEG2000 например.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Mozilla выпустила улучшенный JPEG-кодировщик