Комментарии 62
Demo можно глянуть тут — http://uprootlabs.github.io/poly-flif/, только Truncation надо в 0% поставить
Как и в случае с bpg, демо будет тормозить, так как нет нативной поддержки, и отрисовка идет на canvas
Как и в случае с bpg, демо будет тормозить, так как нет нативной поддержки, и отрисовка идет на canvas
Немного потестировал это демо и в формате FLIF мне всегда выводит размер больше, чем в PNG. Странно, т.к. в статье говорится об обратном.
Демо можно всегда подобрать выигрышное для формата. Например первая картинка из этой демки позиционируется как оригинал весом 151,8КБ, но простое открытие и пересохранение без потерь уменьшило размер файла до 126 КБ (129 789 байт). Одну и ту же картинку в PNG можно сохранить с разницей в весе 400%+
"пересохранение без потерь" — а вы точно альфа-канал не выбросили? Я открыл в PsCC, пересохранил и результат со сжатием меньше только на один процент от исходного. ЧЯДНТ?
Альфа на месте. Погуглите как работают PNGGauntlet и аналоги, фотошоп сохраняет не лучшим способом
Ну так это уже не простое открытие и пересохранение. Это уже оптимизация изображения, которой, увы, сегодня мало кто занимается. А сравнивают, очевидно, со средним случаем, когда картинку просто взяли и сохранили в графическом редакторе. Маркетинг :)
Хотя, конечно же, лучше бы сразу писали объём «среднего» PNG, и «оптимизированного по максимуму» рядом, чтобы пользователю самому не приходилось проводить тесты. Но в любом случае, по моим тестам FLIF показал себя гораздо лучше оптимизированного PNG.
Хотя, конечно же, лучше бы сразу писали объём «среднего» PNG, и «оптимизированного по максимуму» рядом, чтобы пользователю самому не приходилось проводить тесты. Но в любом случае, по моим тестам FLIF показал себя гораздо лучше оптимизированного PNG.
Предположу что проблема алгоритма во времени сжатия/разжатия, раз это не освещено в графиках. Про это есть где-то? В статье не замечаю
Скачал бинарник и проверил на ~500КБ картинке из примера. ~8 секунд на сжатие во flif ~300КБ. Для сравнения в PNG ~447КБ сжалось за 2 секунды, в PNG ~420КБ сжалось за ~7 минут, в PNG 550КБ+ сжимается практически моментально. Во всех вариантах loseless, обратно flif не разжимал. Для массового сжатия графики долговато выходит.
Если не сложно, сделайте замер скорости распаковки. Для client side оно куда интереснее.
На той же картинке ~4 секунды на конвертацию обратно в PNG, сама же итоговая PNG получается весом 1,07 МБ т.е. явно на её создание время сильно не расходуется
Когда браузеры это будут поддерживать то?
Проблема не в новых замечательных фоматах, которые жмут лучше чем format[n-1] — их и так хватает. Проблема в том, что производители бразуеров не спешат внедрять инновации.
Не спец по браузерам и Web'у.
Подскажите, можно ли решить это примерно так:
Запрос к пользователю: "поддерживаешь ли format_A"?
Ответ от пользователя
Если поддерживает — выдаем картинку в format_A (в нашем случае FLIF), если не поддерживает — выдаем в PNG
Например можно придумать "глобальную куку", указывающую, что пользователь с данной кукой поддерживает формат FLIF...
Подскажите, можно ли решить это примерно так:
Запрос к пользователю: "поддерживаешь ли format_A"?
Ответ от пользователя
Если поддерживает — выдаем картинку в format_A (в нашем случае FLIF), если не поддерживает — выдаем в PNG
Например можно придумать "глобальную куку", указывающую, что пользователь с данной кукой поддерживает формат FLIF...
Встретил прекрасное на сайте опенсорс движка Prince of Persia:
Если в демке выбрать сжатие с потерями более 50%, то same size JPG на голову качественнее.
То есть этот режим реализован чисто формально, и выделенная аж жирным фраза "FLIF побеждает всех конкурентов на всех типах изображений" несколько преувеличена.
То есть этот режим реализован чисто формально, и выделенная аж жирным фраза "FLIF побеждает всех конкурентов на всех типах изображений" несколько преувеличена.
Очень жалко, что производители браузеров не хотят/не могут вводить такие вещи, на сколько улучшился бы веб со всем этим.
Надеюсь на светлое будущее.
Надеюсь на светлое будущее.
Патент на арифметик истек?! Одна из лучших новостей! Так давайте тогда с JPEG начнем и поддержим, там как раз арифметическое кодирование сразу даст ощутимый профит, на 5-22% ЕМНИП.
Я об это уже много лет говорю, стандарту арифметического кодирования в JPEG двадцать лет в обед, а его кроме пары опенсоурсных программ типа imagemagic никто не поддерживает.
Webp тоже основан на арифметическом кодировании, но почему-то чуть позади.
Вообще FFV1 лучший кодек по размеру видео для сжатия без потерь. По секрету скажи, его даже youtube поддерживает при заливке (через ffmpeg конечно же). Жаль никак не сделают FFV1v3 (которая умеет многопоточность,) в виде VfW и DShow,
p.s. странно что новость так долго доходила до хабра, на реддите это ещё полгода назад обсуждали https://www.reddit.com/r/programming/comments/3n7yvx/flif_free_lossless_image_format/
Webp тоже основан на арифметическом кодировании, но почему-то чуть позади.
Вообще FFV1 лучший кодек по размеру видео для сжатия без потерь. По секрету скажи, его даже youtube поддерживает при заливке (через ffmpeg конечно же). Жаль никак не сделают FFV1v3 (которая умеет многопоточность,) в виде VfW и DShow,
p.s. странно что новость так долго доходила до хабра, на реддите это ещё полгода назад обсуждали https://www.reddit.com/r/programming/comments/3n7yvx/flif_free_lossless_image_format/
На опеннете узнал как про FLIF так и про BPG уже очень давно. Хабр такие новинки почему-то не собирает своевременно уже.
Почему арифметическое кодирование а не какой-нибудь lzma2?
Некорректно поставлен вопрос.
LZMA2 является контейнером, который хранит данные, сжатые компрессором LZMA.
Любой компрессор состоит из модели данных и кодировщика. Модель в LZMA собственная, она и отличает LZMA от других алгоритмов, а кодировщик — rangecoder — вариант арифметического кодирования с контролируемой потерей точности (на какие-то доли отстаёт в сжатии от честного арифметического кодирования, зато работает заметно быстрее)
Почему через LZMA не сжимать картинки? Модель данных, расчитанная на generic-использование, проиграет модели, заточенной под картинки.
LZMA2 является контейнером, который хранит данные, сжатые компрессором LZMA.
Любой компрессор состоит из модели данных и кодировщика. Модель в LZMA собственная, она и отличает LZMA от других алгоритмов, а кодировщик — rangecoder — вариант арифметического кодирования с контролируемой потерей точности (на какие-то доли отстаёт в сжатии от честного арифметического кодирования, зато работает заметно быстрее)
Почему через LZMA не сжимать картинки? Модель данных, расчитанная на generic-использование, проиграет модели, заточенной под картинки.
Точно проигрывает? Сделал скриншот, сохранил в формате bmp без сжатия и png с максимальным сжатием, потом сжал bmp 7зипом. Получилось 170кб у 7зипа и 290 у png, как так?
В каком году был создан 7z и в каком PNG?
В каком году был создан FLIF? Он точно так же сливает 7зипу.
lzma — 2001
png — 1996
Не такая уж большая разница.
зы попробовал так же с фотографией, получилось 7зип 1.8мб png(-9) 2.1мб то есть 7зип жмет заметно лучше и рисунки и фото
lzma — 2001
png — 1996
Не такая уж большая разница.
зы попробовал так же с фотографией, получилось 7зип 1.8мб png(-9) 2.1мб то есть 7зип жмет заметно лучше и рисунки и фото
ну так
Я считаю, если сейчас разрабатывать стандарт сжатия изображений, можно превзойти LZMA
- png использует zlib (gzip, pkzip) в качестве кодера, ставший стандартом в то время, но уже имеющий приличный возраст;
- с 2001 у 7z появились новые кодеки, несовместимые с версией 2001-го года;
- в конце 90-х произошло многое в сжатии данных, наиболее важными я считаю работы Charles Bloom, очевидно имевшие влияние на 7z.
Я считаю, если сейчас разрабатывать стандарт сжатия изображений, можно превзойти LZMA
В каком году был создан FLIF? Он точно так же сливает 7зипу.
Только что проверил. Ваше утверждение не подтвердилось и близко. Взял вот это изображение: tic_tac_toe_large.png и вот что получилось:
- 7z последней версии, LZMA на максимальной степени сжатия, результат — 1.69 мегабайта
- FLIF со стандартными настройками — 1.15 мегабайт.
- FLIF без interlaced — 1.07 мегабайт.
- Оптимизированный PNG (lossless) — 2.35 мегабайт.
Как видно, FLIF оказался гораздо лучше LZMA.
Проверил ваше изображение получил сходные результаты, вот только изображение изменилось после преобразования в flif и обратно, как будто было сжатие с потерями. А еще в выхлопе консольной утилиты присутствует подозрительная надпись
-p, --palette=P max palette size=P (default: P=512)
Если "Модель данных, расчитанная на generic-использование, проиграет модели, заточенной под картинки" тогда почему png проигрывает 7зипу?
-p, --palette=P max palette size=P (default: P=512)
Если "Модель данных, расчитанная на generic-использование, проиграет модели, заточенной под картинки" тогда почему png проигрывает 7зипу?
-p, --palette=P max palette size=P (default: P=512)Судя по всему, имеется в виду, что если указать просто -p, без конкретного числа, то будет считаться, что P=512.
Проверил ваше изображение получил сходные результаты, вот только изображение изменилось после преобразования в flif и обратно, как будто было сжатие с потерями.Как именно вы сравнивали исходное изображение с полученным после распаковки FLIF?
Если «Модель данных, расчитанная на generic-использование, проиграет модели, заточенной под картинки» тогда почему png проигрывает 7зипу?Потому что PNG упаковывает свои данные при помощи gzip, который появлися где-то в 1992-1993 годах.
у png слабее кодер, там Хаффман.
Возможно тут дело в том, что 7zip рассчитан на одноразовую распаковку до работы с файлами, а png для распаковки каждый раз при просмотре. Мне кажется, что просмотр картинки в 7zip займет на порядки больше времени чем в специальных форматах. Кроме того из архива есть другие недостатки, скажем гораздо сложнее выдрать конкретную часть картинки или ее эскиз.
А как вы из png выдерите эскиз без полной распаковки картинки? Никаких отличий. И вычислительные мощности выросли с 1990 года.
Удивительно и как же этоделается-то?! Режит interlaced для того ведь и придумали, блин, чтоб показать эскиз задолго до того, как полная версия картиннки прогрузится. http://graphicdesign.stackexchange.com/questions/6677/what-does-the-interlaced-option-in-photoshop-do
1. Выставил truncation 0%.
2. Сделал скриншоты для FLIF и PNG.
3. Вычел одно из другого.
4. покрутил кривые.
Отчётливо видно, что изображения различаются. Так что либо это не совсем lossless, либо демонстрационная программа что-то не то демонстрирует (тогда это не имеющая практической пользы фальшивка).
Картинку вставить мне не разрешено.
https://habrastorage.org/files/498/fc3/1ee/498fc31eebe245d3ab5c7a1c8ab0584a.png
2. Сделал скриншоты для FLIF и PNG.
3. Вычел одно из другого.
4. покрутил кривые.
Отчётливо видно, что изображения различаются. Так что либо это не совсем lossless, либо демонстрационная программа что-то не то демонстрирует (тогда это не имеющая практической пользы фальшивка).
Картинку вставить мне не разрешено.
https://habrastorage.org/files/498/fc3/1ee/498fc31eebe245d3ab5c7a1c8ab0584a.png
Я так полагаю, что это проблемы криво написанной веб-демки. Если сильно уменьшить размер (в хроме Ctrl±), то там и на глаз отличия видны — даже вычитать не надо. А при увеличении "артефакты" уходят. Единственно правильный тест — сжать/разжать библиотекой и сравнить с оригиналом. Я верю, такой тест проводился — формат-то без потери качества по по определению. Я на досуге посмотрю как этот формат управляется с 16-ти битными картинками, и, возможно, отпишусь — мне интересно, как он будет справляться с рентгеновскими снимками.
Проверил консольный кодер — он кодирует и декодирует без потерь. В вебе возможны различия из-за немного кривоватого декодера даже PNG, не обязательно FLIF. Лично сталкивался с тем, когда декодер GDI+ декодировал PNG с незначительными отличиями в младших битах цветов некоторых пикселей, а другие декодеры давали идентичный исходному результат.
Я не совсем понял почему он называется «без потерь качества» если жмет с потерями т.е. качество сжатых изображений падает.
И что минусуете то? Объяснить слабо?
На основании чего вы решили, что качество сжатых изображений падает при использовании FLIF?
А как понимать выхлоп консольной утилиты?
…
-p, --palette=P max palette size=P (default: P=512)
...
…
-p, --palette=P max palette size=P (default: P=512)
...
Очевидно, имеется в виду, что если указать просто -p, без конкретного числа, то будет считаться, что P=512. Я даже не поленился проверить это. Кодировал при помощи FLIF фотографию, потом декодировал обратно и сравнил с оригиналом. Получил идентичный результат. Графические данные ни в одном бите не отличаются.
На всякий случай подскажу, что PNG файлы сравнивать между собой утилитами для двоичного сравнения файлов нельзя. Можно оба PNG файла декодировать в BMP файлы одной и той же утилитой, и тогда уже сравнивать полученные BMP файлы. BMP тоже позволяет по-разному представить одно и то же изображение, но после одной утилиты представление скорее всего будет одинаковым :)
На всякий случай подскажу, что PNG файлы сравнивать между собой утилитами для двоичного сравнения файлов нельзя. Можно оба PNG файла декодировать в BMP файлы одной и той же утилитой, и тогда уже сравнивать полученные BMP файлы. BMP тоже позволяет по-разному представить одно и то же изображение, но после одной утилиты представление скорее всего будет одинаковым :)
Легко проверить, уменьшается ли количество цветов.
Я взял большую картинку с градиентом, https://aleeodom.files.wordpress.com/2010/10/gradient.png
Сжал-разжал — разницы нет. Уменьшение палитры до 512 цветов было бы слишком очевидным.
Я взял большую картинку с градиентом, https://aleeodom.files.wordpress.com/2010/10/gradient.png
Сжал-разжал — разницы нет. Уменьшение палитры до 512 цветов было бы слишком очевидным.
Да мы тут анимированный PNG (APNG) уже лет 10 ждём — вот уже где намного большая необходимость. А вы хотите еще и поддержку нового формата с туманными перспективами. JPEG2000 не взлетел, об WebP как-то совсем не слышно, хоть и задумка суперская…
Вот-вот, прекрасных форматов дофига, и еще один, насколько угодно процентов лучший, ничего не изменит.
Не "насколько угодно" процентов. Отличия не так велики. Если один формат сжимает картинку в 20 раз, другой в 21 разница в размере конечного изображения 5%, но для пользователя в общем-то это не так важно, данные сжаты в десятки раз, что и требовалось, на фоне вспомогательной информации (на web страничках например), эта разница исчезающе мала.
Для сжатия видеопотоков вопрос более актуален, но там и новые форматы чаще появляются.
Для сжатия видеопотоков вопрос более актуален, но там и новые форматы чаще появляются.
И хорошо что APNG нету, потому что это не самый удачный формат для внедрения.
Почему? Обратно совместим с популярным PNG, жмёт анимацию лучше GIF, поддерживает альфа-канал, справляется со своей задачей. Поддерживается в Firefox и Safari. Microsoft в размышлениях. Если и она поддержит, то останется уговорить Google. Тем более, что ему уже давно предложили работающий патч для кода Chromium. Там буквально 500 строк кода. То есть нет необходимости тянуть какую-то ещё одну тяжёлую библиотеку.
Обратная совместимость — единственный плюс. С GIF сравнивать вообще не имеет смысла, любой современный формат с анимацией — будет лучше GIF. Лучше сравнить APNG например с WebP, BPG или же вот этим FLIF. Чем он лучше?
Обратная совместимость, уже поддерживается половиной производителей браузеров, реализация требует меньше 1000 строк кода поверх уже поддерживаемого PNG, не испорчен патентами, в некоторых ситуациях жмёт даже лучше того же WebP. Когда FLIF будет закончен, оптимизирован, со всеми его заявленными качествами — было бы хорошо, чтобы все его поддержали. А сейчас — самое время для APNG. Тем более, что те несколько сотен строк кода для его поддержки — капля в море.
Признаться, меня терзают некоторые сомнения. Я почему-то не верю, что в 2016 году может ВДРУГ появиться свободный формат сжатия, на десятки процентов уделывающий признанных лидеров. Да ещё и на основе патентов 80-х годов. Где-то нас на#бывают.
В самой статье противоречие. Создан новый формат, и цитирую из статьи лучше чем:
А сегодня, совершенно очевидно, очень хорошо, что те форматы не стали стандартом, так как появились новые алгоритмы сжатия изображений. Может и с FLIF не надо спешить? На Хабре сколько статей по WebP
habrahabr.ru/company/io/blog/261971
habrahabr.ru/post/275735
habrahabr.ru/company/io/blog/261651
habrahabr.ru/company/io/blog/261083
geektimes.ru/post/105335
habrahabr.ru/post/264491
Может через несколько лет появится новый формат сжатия изображений, который точно так же поставит FLIF в разряд сравниваемых устаревших форматов? Уверен, что разработчики чуть позже, предоставят FLIF 2.0 где исправят разные недостатки, и так далее.
А когда-то, точно так-же хвалили JPEG2000, JPEG XR
- на 14% меньше, чем lossless WebP,
- на 22% меньше, чем lossless BPG,
- на 33% меньше, чем PNG с брутфорсом через ZopfliPNG,
- на 43% меньше типичного PNG,
- на 46% меньше PNG, оптимизированного алгоритмом образования чересстрочного изображения Adam7,
- на 53% меньше lossless JPEG2000,
- на 74% меньше lossless JPEG XR.
JPEG 2000. Отличный формат сжатия, поддерживает компрессию как с потерями качества, так и без, а также прозрачность и прогрессивное сжатие. Заявлено сжатие на 20% лучше, чем в обычном JPEG
А сегодня, совершенно очевидно, очень хорошо, что те форматы не стали стандартом, так как появились новые алгоритмы сжатия изображений. Может и с FLIF не надо спешить? На Хабре сколько статей по WebP
habrahabr.ru/company/io/blog/261971
habrahabr.ru/post/275735
habrahabr.ru/company/io/blog/261651
habrahabr.ru/company/io/blog/261083
geektimes.ru/post/105335
habrahabr.ru/post/264491
Может через несколько лет появится новый формат сжатия изображений, который точно так же поставит FLIF в разряд сравниваемых устаревших форматов? Уверен, что разработчики чуть позже, предоставят FLIF 2.0 где исправят разные недостатки, и так далее.
Спешить не спешить — не нам решать. Тут важен совершенно иной вопрос: решит ли Google взять его на замену WebP, так-как они WebP специально создавали для оптимизации загрузок и трубили, что он всем нужен, или не решит. Всё одно мёртворожденный — никто кроме Google его поддерживать не спешит ведь (ну кроме Оперы по очевидной причине). Ну и вопрос номер 2: как на это отреагирует Microsoft со своим Edge и Mozilla с поддержкой в Фоксе. Если эта тройка отработает как надо — формату быть, если опять всё застрянет на ком-то — будет разброд и шатание, как обычно. Причём если Mozilla и Google не сделают вместе, то MS даже видимости деятельности по поддержке проявлять не будет.
Через 100 лет может и еще что-то появится. Но что мешает сделать поддержку всех этих форматов? Актуальны-то они именно сейчас.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
FLIF — свободный формат сжатия изображений