Comments 55
Формат WebP поддерживается во многих браузерах и всё чаще применяется для публикации изображений в интернете.
А точнее только в хром-like и штатном андроид браузерах
Или firefox не официально поддерживает?
Mozilla, Apple и Microsoft крайне маловероятно когда-нибудь задумаются о поддержке этого формата, и по большому счету это только политическое решение.
Никаких технических ограничений нет, в багтрекере мозиллы поддержка webp висит уже давно.
Но даже в такой ситуации "только" 70% поддержки.
Хотя нет, Safari "по слухам" "going to support WebP in iOS 10 and macOS Sierra", так что скоро ситуация может измениться.
«WebP is now supported on Safari 10 both on macOS sierra and iOS 10»
https://groups.google.com/a/webmproject.org/forum/#!topic/webp-discuss/J8HLhTaklYE
В то же время WebM уже поддерживается. Так что есть все шансы, что и это сделают. Но вот когда?
It compresses JPEG files at a rate of 5 megabytes per second and decodes them back to the original bits at 15 megabytes per second, securely, deterministically, and in under 24 megabytes of memory
>>Стандарт JPEG допускает также использование значительно более эффективного арифметического кодирования, однако из-за патентных ограничений (патент на описанный в стандарте JPEG арифметический QM-кодер принадлежит IBM) на практике оно использовалось редко.
Все патенты давным давно закончились, сколько можно нести эту чепуху годами? https://en.wikipedia.org/wiki/Arithmetic_coding#US_patents
И в итоге всё равно кодируют арифметическим кодером из VP8, к чему тогда был этот ненужный пассаж про патенты?
Вообщем как я понял это абсолютно то же самое что и PackArc, WinZip, StuffIt и arithmetic jpeg, только вместо того чтобы добавить поддержку arithmetic jpeg во все брузеры и libjpeg придумываются очередные «временные упаковщики».
Абзац про FLIF вообще абсолютно лишний, FLIF это аналог gif/png а не jpeg, там даже в табличке не сранивают его с jpeg. Что курил автор чтобы впихнуть это абзац? А, ну да, это же Ализар, он не умеет думать.
И вообще, уже была статья про это https://geektimes.ru/post/261058/, ничего с тех пор не изменилось.
Может быть процессорной нагрузкой? Я не утверждаю, это предположение.
>>однако из-за патентных ограничений (патент на описанный в стандарте JPEG арифметический QM-кодер принадлежит IBM) на практике оно использовалось редко
>Все патенты давным давно закончились, сколько можно нести эту чепуху годами?
Патенты закончились, но на практике арифметическое кодирование всё равно до сих пор используется редко (потом что раньше оно было под патентами). Что не так?
>только вместо того чтобы добавить поддержку arithmetic jpeg во все брузеры и libjpeg придумываются очередные «временные упаковщики».
э-э-э, как вы себе это представляете? Пришёл такой дропбокс и встроил поддержку арифметического кодирования во все браузеры? Дропбокс просто решил свои конкретные проблемы. Решить «вместо этого» проблемы браузеров он просто не в состоянии.
В браузерах уже лет 5 открыты тикеты на поддержку arithmetic jpeg, но воз и ныне там. В libjpeg поддержка arithmetic jpeg давно есть, с 2009 года.
Браузеры можно понять. Введение нового обратно не совместимого формата означает, что половину бразуеров перестанут открывать некоторые картинки. Это ничем не отличается от поддержки нового формата. А зачем нам еще один новый формат без альфаканала? Лучше уже бросить силы на поддержку действительно нового формата врде webp.
Проблема в том, что отказаться от устаревшего JPEG в пользу WebP или FLIF очень трудно: этот формат получил слишком большое распространение.
Проблема не в том, чтобы отказаться, а в том, чтобы перейти на новый. Мы же до сих пор не можем использовать даже WebP нормально. Была бы возможность, давно бы уже использовали.
Например, формат WebP тоже использует кодер VP8 и на голову превосходит JPEG по показателям.
Есть одно но.
WebP кодек адаптивный, а jpg равномерный. Когда начал экспериментировать по сжатию паспортов, был удивлен насколько нагло webp себя ведет с тем что считает лишним т.е бледные лица на фотографии загранника он замылил мама не горюй. И тут jpg мне прекрасно равномерно все пожал без всех этих умных алгоритмов.
Другими словами, если ваш документ прыгает по яркости. Например, печати бледные, а где контрастные, то webp будет выдавать вам непредсказуемый результат в отличие от jpg. Кстати, не понимаю, почему декодеры jpg еще не умеют убирать квадраты, то есть jpg вполне себе имеет капельку качества через восстановление артефактов.
Постобработка с устранением артефактов блочности — пожалуйста, но декодеру этим заниматься нельзя, он должен обеспечивать результат «бит в бит».
Я может что-то не так понял, но кажется только декодеры lossless должны декодировать"бит в бит". Декодеры изображений, сжатых с потерями, по определению не смогут добиться результата "бит в бит". Так почему бы не убирать квадраты?
Улучшайзеры декодированной картинки, безусловно, имеют право на жизнь — но отдельно от кодеков.
Но в комментариях народ довольно позитивно воспринял мысль, что почему-то все, кроме JPG форматы «мылят» картинку. Да, JPG создаёт неприятные блоки, но «резкость» краёв этих блоков воспринимается приятнее, чем «мыльные» варианты, которые формально ближе к оригиналу.
А новые форматы слишком интеллектуальные, были примеры, когда на скане паспорта алгоритм решал что черно белая фотография с низкой контрастностью второстепенный элемент и замыливал фотографию до состояния фона. Старинный Jpeg более честен в этом плане, дефекты видны сразу, все части изображения равноправны, сюрпризов не возникает.
Там либа под разные операционные системы есть, я на Linux'е конвертирую.
Но, как выше сказали, результат не всегда предсказуем — надо смотреть каждую картинку, по крайней мере, пока статистику для себя не наработаете. Иной раз, картинка в jpg и качественнее, и меньше.
Что у вас на втором графики изображено? Почему PNG/PNG не равно 1? PNG разве вообще позволяет задавать степень сжатия?
Само собой при высокой поддержке может оказаться что кодер и декодер станут быстрее, но сомневаюсь что настолько.
Потом каждый раз по 5 мин с кэшированием и надеждой переложить на пользователей и их браузеры.
Если не ошибаюсь, тут пропорционально увеличиваются риски, так как возрастает ценность битов…
Не тоже самое, конечно, что реплику отключить на несколько петабайт, но все равно))
Dropbox использовала формат Lepton для кодирования 16 миллиардов изображений на хостинге Dropbox, освободив несколько петабайтЗа приемлимое кол-во времени и ресурсов. Точка.
Таким образом, ключевые преимущества FLIF — лучшая степень сжатия и универсальность, работа с любыми видами изображений. FLIF побеждает всех конкурентов на всех типах изображений. Проблема в том, что отказаться от устаревшего JPEG в пользу WebP или FLIF очень трудно: этот формат получил слишком большое распространение.
Господи, alizar, каким боком вы вообще сюда FLIF приплели? Про FLIF в оригинальной статье Дропбокса ни слова не было. FLIF не побеждает всех конкурентов на всех типах изображений, потому что он предназначен только для сжатия без потерь. Никто никогда не откажется от JPEG в пользу FLIF, это полный бред.
Свободный формат Lepton сжимает файлы JPEG на 22% без потерь