alizar March 7, 2016 at 08:50 PM

FLIF — свободный формат сжатия изображений

FLIF (Free Lossless Image Format) — это новый свободный формат сжатия без потери качества, который превосходит PNG, lossless WebP, lossless BPG, lossless JPEG2000 и lossless JPEG XR по степени сжатия.

Как показало сравнительное тестирование (результаты), файлы FLIF в среднем:

на 14% меньше, чем lossless WebP,
на 22% меньше, чем lossless BPG,
на 33% меньше, чем PNG с брутфорсом через ZopfliPNG,
на 43% меньше типичного PNG,
на 46% меньше PNG, оптимизированного алгоритмом образования чересстрочного изображения Adam7,
на 53% меньше lossless JPEG2000,
на 74% меньше lossless JPEG XR.

Даже если для каждого отдельного изображения выбирать наилучший формат сжатия среди конкурентов, в зависимости от типа картинки — фотография, графика, 8 бит или больше — FLIF всё равно имеет преимущество примерно 12% по медиане (или 19% в среднем). Таким образом, ключевые преимущества FLIF — лучшая степень сжатия и универсальность, работа с любыми видами изображений.

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

Как и некоторые другие форматы, файлы FLIF обладают свойством «отзывчивой загрузки», когда показ предварительной версии начинается до полной загрузки файла (см. видео).

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

FLIF использует арифметическое кодирование, один из алгоритмов энтропийного сжатия, как видеокодек FFV1. Именно последний вдохновил разработчиков на создание нового формата сжатия, и благодаря арифметическому кодированию получены столь впечатляющие результаты. Арифметическое кодирование изобрели в компании IBM в конце 70-х — начале 80-х. По имеющейся информации, все патенты на арифметическое кодирование уже истекли, так что со стороны IBM не должно быть претензий.

Tags:

Comments 62

Shannon March 7, 2016 at 09:42 PM
+2
Demo можно глянуть тут — http://uprootlabs.github.io/poly-flif/, только Truncation надо в 0% поставить
Как и в случае с bpg, демо будет тормозить, так как нет нативной поддержки, и отрисовка идет на canvas
- UnickSoft March 7, 2016 at 10:23 PM
  0
  Немного потестировал это демо и в формате FLIF мне всегда выводит размер больше, чем в PNG. Странно, т.к. в статье говорится об обратном.
  - Shannon March 7, 2016 at 10:39 PM
    
    +1
    Вообще там во всех примерах у png больше вес, например:
    - UnickSoft March 9, 2016 at 01:02 PM
      
      0
      
      Верно, может быть тогда был какой-то глюк. Сейчас перепроверил и правда.
- Denai March 9, 2016 at 02:43 AM
  0
  Демо можно всегда подобрать выигрышное для формата. Например первая картинка из этой демки позиционируется как оригинал весом 151,8КБ, но простое открытие и пересохранение без потерь уменьшило размер файла до 126 КБ (129 789 байт). Одну и ту же картинку в PNG можно сохранить с разницей в весе 400%+
  - mwizard March 9, 2016 at 02:56 AM
    
    +1
    "пересохранение без потерь" — а вы точно альфа-канал не выбросили? Я открыл в PsCC, пересохранил и результат со сжатием меньше только на один процент от исходного. ЧЯДНТ?
    - Denai March 9, 2016 at 05:15 AM
      
      0
      
      Альфа на месте. Погуглите как работают PNGGauntlet и аналоги, фотошоп сохраняет не лучшим способом
      - VEG March 9, 2016 at 09:06 AM
        
        +1
        
        Ну так это уже не простое открытие и пересохранение. Это уже оптимизация изображения, которой, увы, сегодня мало кто занимается. А сравнивают, очевидно, со средним случаем, когда картинку просто взяли и сохранили в графическом редакторе. Маркетинг :)
        
        Хотя, конечно же, лучше бы сразу писали объём «среднего» PNG, и «оптимизированного по максимуму» рядом, чтобы пользователю самому не приходилось проводить тесты. Но в любом случае, по моим тестам FLIF показал себя гораздо лучше оптимизированного PNG.
        
        Denai March 9, 2016 at 05:12 PM
        
        0
        
        Предположу что проблема алгоритма во времени сжатия/разжатия, раз это не освещено в графиках. Про это есть где-то? В статье не замечаю
        
        Denai March 9, 2016 at 07:35 PM
        
        0
        
        Скачал бинарник и проверил на ~500КБ картинке из примера. ~8 секунд на сжатие во flif ~300КБ. Для сравнения в PNG ~447КБ сжалось за 2 секунды, в PNG ~420КБ сжалось за ~7 минут, в PNG 550КБ+ сжимается практически моментально. Во всех вариантах loseless, обратно flif не разжимал. Для массового сжатия графики долговато выходит.
        
        grossws March 9, 2016 at 08:33 PM
        
        0
        
        Если не сложно, сделайте замер скорости распаковки. Для client side оно куда интереснее.
        
        Denai March 9, 2016 at 08:39 PM
        
        0
        
        На той же картинке ~4 секунды на конвертацию обратно в PNG, сама же итоговая PNG получается весом 1,07 МБ т.е. явно на её создание время сильно не расходуется
        
        VEG March 9, 2016 at 10:26 PM
        
        0
        
        Ну формат ещё в разработке. Там об этом явно написано — то что будет запаковано сейчас, вероятно не сможет быть распакованным более новыми версиями flif.exe, потому что формат ещё не заморожен и может не раз измениться. Явно никто ещё особо не занимался оптимизацией алгоритмов.
        
        Denai March 10, 2016 at 07:40 PM
        
        0
        
        Ну я и не говорю что лучше не будет. Однако такие моменты стоит указывать.
Methos March 7, 2016 at 11:09 PM
+14
Когда браузеры это будут поддерживать то?
k12th March 7, 2016 at 11:33 PM
+6
Проблема не в новых замечательных фоматах, которые жмут лучше чем format[n-1] — их и так хватает. Проблема в том, что производители бразуеров не спешат внедрять инновации.
- PavelMSTU March 8, 2016 at 10:33 AM
  0
  Не спец по браузерам и Web'у.
  Подскажите, можно ли решить это примерно так:
  
  Запрос к пользователю: "поддерживаешь ли format_A"?
  Ответ от пользователя
  Если поддерживает — выдаем картинку в format_A (в нашем случае FLIF), если не поддерживает — выдаем в PNG
  
  Например можно придумать "глобальную куку", указывающую, что пользователь с данной кукой поддерживает формат FLIF...
  - bolk March 8, 2016 at 10:46 AM
    
    +9
    Для этого в протоколе HTTP есть специальный заголовок «Accept».
- drew March 8, 2016 at 01:05 PM
  0
  Встретил прекрасное на сайте опенсорс движка Prince of Persia:
dom1n1k March 7, 2016 at 11:35 PM
–6
Если в демке выбрать сжатие с потерями более 50%, то same size JPG на голову качественнее.
То есть этот режим реализован чисто формально, и выделенная аж жирным фраза "FLIF побеждает всех конкурентов на всех типах изображений" несколько преувеличена.
- ef_end_y March 8, 2016 at 12:56 AM
  +4
  ответ на ваше высказывание в первом предложении текущей статьи
  - dom1n1k March 8, 2016 at 01:07 AM
    
    –6
    До меня дошло — это у него не сжатие с потерями, а превью, эквивалент прогрессивного jpeg.
    Но все равно выходит, что эта функция реализована несколько слабовато.
Rathil March 7, 2016 at 11:42 PM
+2
Очень жалко, что производители браузеров не хотят/не могут вводить такие вещи, на сколько улучшился бы веб со всем этим.
Надеюсь на светлое будущее.
RolexStrider March 7, 2016 at 11:54 PM
+9
Патент на арифметик истек?! Одна из лучших новостей! Так давайте тогда с JPEG начнем и поддержим, там как раз арифметическое кодирование сразу даст ощутимый профит, на 5-22% ЕМНИП.
- DjOnline March 8, 2016 at 12:25 AM
  +4
  Я об это уже много лет говорю, стандарту арифметического кодирования в JPEG двадцать лет в обед, а его кроме пары опенсоурсных программ типа imagemagic никто не поддерживает.
  Webp тоже основан на арифметическом кодировании, но почему-то чуть позади.
  Вообще FFV1 лучший кодек по размеру видео для сжатия без потерь. По секрету скажи, его даже youtube поддерживает при заливке (через ffmpeg конечно же). Жаль никак не сделают FFV1v3 (которая умеет многопоточность,) в виде VfW и DShow,
  
  p.s. странно что новость так долго доходила до хабра, на реддите это ещё полгода назад обсуждали https://www.reddit.com/r/programming/comments/3n7yvx/flif_free_lossless_image_format/
  - EvilFox March 8, 2016 at 08:22 PM
    
    0
    На опеннете узнал как про FLIF так и про BPG уже очень давно. Хабр такие новинки почему-то не собирает своевременно уже.
theurs March 8, 2016 at 03:37 AM
–2
Почему арифметическое кодирование а не какой-нибудь lzma2?
- qw1 March 8, 2016 at 11:31 AM
  +1
  Некорректно поставлен вопрос.
  
  LZMA2 является контейнером, который хранит данные, сжатые компрессором LZMA.
  
  Любой компрессор состоит из модели данных и кодировщика. Модель в LZMA собственная, она и отличает LZMA от других алгоритмов, а кодировщик — rangecoder — вариант арифметического кодирования с контролируемой потерей точности (на какие-то доли отстаёт в сжатии от честного арифметического кодирования, зато работает заметно быстрее)
  
  Почему через LZMA не сжимать картинки? Модель данных, расчитанная на generic-использование, проиграет модели, заточенной под картинки.
  - theurs March 8, 2016 at 11:34 AM
    
    +2
    Точно проигрывает? Сделал скриншот, сохранил в формате bmp без сжатия и png с максимальным сжатием, потом сжал bmp 7зипом. Получилось 170кб у 7зипа и 290 у png, как так?
    - qw1 March 8, 2016 at 11:44 AM
      
      0
      
      В каком году был создан 7z и в каком PNG?
      - theurs March 8, 2016 at 11:50 AM
        
        +2
        
        В каком году был создан FLIF? Он точно так же сливает 7зипу.
        lzma — 2001
        png — 1996
        Не такая уж большая разница.
        
        зы попробовал так же с фотографией, получилось 7зип 1.8мб png(-9) 2.1мб то есть 7зип жмет заметно лучше и рисунки и фото
        
        qw1 March 8, 2016 at 03:31 PM
        
        0
        
        ну так
        
        png использует zlib (gzip, pkzip) в качестве кодера, ставший стандартом в то время, но уже имеющий приличный возраст;
        
        с 2001 у 7z появились новые кодеки, несовместимые с версией 2001-го года;
        
        в конце 90-х произошло многое в сжатии данных, наиболее важными я считаю работы Charles Bloom, очевидно имевшие влияние на 7z.
        
        Я считаю, если сейчас разрабатывать стандарт сжатия изображений, можно превзойти LZMA
        
        VEG March 8, 2016 at 03:39 PM
        
        +3
        
        В каком году был создан FLIF? Он точно так же сливает 7зипу.
        
        Только что проверил. Ваше утверждение не подтвердилось и близко. Взял вот это изображение: tic_tac_toe_large.png и вот что получилось:
        
        7z последней версии, LZMA на максимальной степени сжатия, результат — 1.69 мегабайта
        
        FLIF со стандартными настройками — 1.15 мегабайт.
        
        FLIF без interlaced — 1.07 мегабайт.
        
        Оптимизированный PNG (lossless) — 2.35 мегабайт.
        
        Как видно, FLIF оказался гораздо лучше LZMA.
        
        theurs March 8, 2016 at 05:19 PM
        
        0
        
        Проверил ваше изображение получил сходные результаты, вот только изображение изменилось после преобразования в flif и обратно, как будто было сжатие с потерями. А еще в выхлопе консольной утилиты присутствует подозрительная надпись
        
        -p, --palette=P max palette size=P (default: P=512)
        
        Если "Модель данных, расчитанная на generic-использование, проиграет модели, заточенной под картинки" тогда почему png проигрывает 7зипу?
        
        VEG March 8, 2016 at 06:28 PM
        
        0
        
        -p, --palette=P max palette size=P (default: P=512)
        Судя по всему, имеется в виду, что если указать просто -p, без конкретного числа, то будет считаться, что P=512.
        
        Проверил ваше изображение получил сходные результаты, вот только изображение изменилось после преобразования в flif и обратно, как будто было сжатие с потерями.
        Как именно вы сравнивали исходное изображение с полученным после распаковки FLIF?
        
        Если «Модель данных, расчитанная на generic-использование, проиграет модели, заточенной под картинки» тогда почему png проигрывает 7зипу?
        Потому что PNG упаковывает свои данные при помощи gzip, который появлися где-то в 1992-1993 годах.
        
        theurs March 8, 2016 at 06:33 PM
        
        0
        
        Если запустить консольный flif компрессор с ключом -v то он пишет что отбрасывает ненужный альфа канал у png файла. Похоже что тут не сжатие с потерями а просто небольшая не влияющая на сжатие модификация из-за которой и меняется контрольная сумма.
        
        qw1 March 8, 2016 at 06:31 PM
        
        0
        
        у png слабее кодер, там Хаффман.
    - wataru March 8, 2016 at 01:35 PM
      
      0
      
      Возможно тут дело в том, что 7zip рассчитан на одноразовую распаковку до работы с файлами, а png для распаковки каждый раз при просмотре. Мне кажется, что просмотр картинки в 7zip займет на порядки больше времени чем в специальных форматах. Кроме того из архива есть другие недостатки, скажем гораздо сложнее выдрать конкретную часть картинки или ее эскиз.
      - sim31r March 8, 2016 at 03:38 PM
        
        0
        
        А как вы из png выдерите эскиз без полной распаковки картинки? Никаких отличий. И вычислительные мощности выросли с 1990 года.
        
        Lain_13 March 8, 2016 at 05:19 PM
        
        +1
        
        Удивительно и как же этоделается-то?! Режит interlaced для того ведь и придумали, блин, чтоб показать эскиз задолго до того, как полная версия картиннки прогрузится. http://graphicdesign.stackexchange.com/questions/6677/what-does-the-interlaced-option-in-photoshop-do
maaGames March 8, 2016 at 08:24 AM
+2
1. Выставил truncation 0%.
2. Сделал скриншоты для FLIF и PNG.
3. Вычел одно из другого.
4. покрутил кривые.
Отчётливо видно, что изображения различаются. Так что либо это не совсем lossless, либо демонстрационная программа что-то не то демонстрирует (тогда это не имеющая практической пользы фальшивка).

Картинку вставить мне не разрешено.

https://habrastorage.org/files/498/fc3/1ee/498fc31eebe245d3ab5c7a1c8ab0584a.png
- AndreyDmitriev March 8, 2016 at 09:36 AM
  +1
  Я так полагаю, что это проблемы криво написанной веб-демки. Если сильно уменьшить размер (в хроме Ctrl±), то там и на глаз отличия видны — даже вычитать не надо. А при увеличении "артефакты" уходят. Единственно правильный тест — сжать/разжать библиотекой и сравнить с оригиналом. Я верю, такой тест проводился — формат-то без потери качества по по определению. Я на досуге посмотрю как этот формат управляется с 16-ти битными картинками, и, возможно, отпишусь — мне интересно, как он будет справляться с рентгеновскими снимками.
  - maaGames March 8, 2016 at 09:55 AM
    
    0
    Арифметическое кодирование без потерь, по определению. А вот предобработка может что-то удалять, но при 0% не должно по идее.
    
    Посмотрел на других примерах. Вроде бы расхождение только в полупрозрачных пикселах. Не нашёл кнопки загрузки своих изображений, так что толком не проверить ничего.
- VEG March 8, 2016 at 03:55 PM
  +2
  Проверил консольный кодер — он кодирует и декодирует без потерь. В вебе возможны различия из-за немного кривоватого декодера даже PNG, не обязательно FLIF. Лично сталкивался с тем, когда декодер GDI+ декодировал PNG с незначительными отличиями в младших битах цветов некоторых пикселей, а другие декодеры давали идентичный исходному результат.
beduin01 March 8, 2016 at 09:44 AM
–8
Я не совсем понял почему он называется «без потерь качества» если жмет с потерями т.е. качество сжатых изображений падает.
- beduin01 March 8, 2016 at 03:44 PM
  –1
  И что минусуете то? Объяснить слабо?
- VEG March 8, 2016 at 03:51 PM
  +3
  На основании чего вы решили, что качество сжатых изображений падает при использовании FLIF?
  - theurs March 8, 2016 at 05:08 PM
    
    0
    А как понимать выхлоп консольной утилиты?
    …
    -p, --palette=P max palette size=P (default: P=512)
    ...
    - VEG March 8, 2016 at 06:37 PM
      
      +3
      
      Очевидно, имеется в виду, что если указать просто -p, без конкретного числа, то будет считаться, что P=512. Я даже не поленился проверить это. Кодировал при помощи FLIF фотографию, потом декодировал обратно и сравнил с оригиналом. Получил идентичный результат. Графические данные ни в одном бите не отличаются.
      
      На всякий случай подскажу, что PNG файлы сравнивать между собой утилитами для двоичного сравнения файлов нельзя. Можно оба PNG файла декодировать в BMP файлы одной и той же утилитой, и тогда уже сравнивать полученные BMP файлы. BMP тоже позволяет по-разному представить одно и то же изображение, но после одной утилиты представление скорее всего будет одинаковым :)
    - qw1 March 8, 2016 at 06:40 PM
      
      +1
      
      Легко проверить, уменьшается ли количество цветов.
      Я взял большую картинку с градиентом, https://aleeodom.files.wordpress.com/2010/10/gradient.png
      Сжал-разжал — разницы нет. Уменьшение палитры до 512 цветов было бы слишком очевидным.
crwin March 8, 2016 at 01:06 PM
+5
Да мы тут анимированный PNG (APNG) уже лет 10 ждём — вот уже где намного большая необходимость. А вы хотите еще и поддержку нового формата с туманными перспективами. JPEG2000 не взлетел, об WebP как-то совсем не слышно, хоть и задумка суперская…
- k12th March 8, 2016 at 01:19 PM
  0
  Вот-вот, прекрасных форматов дофига, и еще один, насколько угодно процентов лучший, ничего не изменит.
  - sim31r March 8, 2016 at 03:31 PM
    
    0
    Не "насколько угодно" процентов. Отличия не так велики. Если один формат сжимает картинку в 20 раз, другой в 21 разница в размере конечного изображения 5%, но для пользователя в общем-то это не так важно, данные сжаты в десятки раз, что и требовалось, на фоне вспомогательной информации (на web страничках например), эта разница исчезающе мала.
    Для сжатия видеопотоков вопрос более актуален, но там и новые форматы чаще появляются.
    - k12th March 8, 2016 at 03:33 PM
      
      0
      
      Вот и я о чем.
- MrShoor March 15, 2016 at 04:50 AM
  +1
  И хорошо что APNG нету, потому что это не самый удачный формат для внедрения.
  - VEG March 15, 2016 at 01:43 PM
    
    0
    Почему? Обратно совместим с популярным PNG, жмёт анимацию лучше GIF, поддерживает альфа-канал, справляется со своей задачей. Поддерживается в Firefox и Safari. Microsoft в размышлениях. Если и она поддержит, то останется уговорить Google. Тем более, что ему уже давно предложили работающий патч для кода Chromium. Там буквально 500 строк кода. То есть нет необходимости тянуть какую-то ещё одну тяжёлую библиотеку.
    - MrShoor March 15, 2016 at 10:06 PM
      
      +1
      
      Обратная совместимость — единственный плюс. С GIF сравнивать вообще не имеет смысла, любой современный формат с анимацией — будет лучше GIF. Лучше сравнить APNG например с WebP, BPG или же вот этим FLIF. Чем он лучше?
      - VEG March 15, 2016 at 10:13 PM
        
        0
        
        Обратная совместимость, уже поддерживается половиной производителей браузеров, реализация требует меньше 1000 строк кода поверх уже поддерживаемого PNG, не испорчен патентами, в некоторых ситуациях жмёт даже лучше того же WebP. Когда FLIF будет закончен, оптимизирован, со всеми его заявленными качествами — было бы хорошо, чтобы все его поддержали. А сейчас — самое время для APNG. Тем более, что те несколько сотен строк кода для его поддержки — капля в море.
forgotten March 8, 2016 at 03:17 PM
0
Признаться, меня терзают некоторые сомнения. Я почему-то не верю, что в 2016 году может ВДРУГ появиться свободный формат сжатия, на десятки процентов уделывающий признанных лидеров. Да ещё и на основе патентов 80-х годов. Где-то нас на#бывают.
sim31r March 8, 2016 at 03:17 PM
+1
В самой статье противоречие. Создан новый формат, и цитирую из статьи лучше чем:
- на 14% меньше, чем lossless WebP,
- на 22% меньше, чем lossless BPG,
- на 33% меньше, чем PNG с брутфорсом через ZopfliPNG,
- на 43% меньше типичного PNG,
- на 46% меньше PNG, оптимизированного алгоритмом образования чересстрочного изображения Adam7,
- на 53% меньше lossless JPEG2000,
- на 74% меньше lossless JPEG XR.
А когда-то, точно так-же хвалили JPEG2000, 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 где исправят разные недостатки, и так далее.
- Lain_13 March 8, 2016 at 05:34 PM
  +1
  Спешить не спешить — не нам решать. Тут важен совершенно иной вопрос: решит ли Google взять его на замену WebP, так-как они WebP специально создавали для оптимизации загрузок и трубили, что он всем нужен, или не решит. Всё одно мёртворожденный — никто кроме Google его поддерживать не спешит ведь (ну кроме Оперы по очевидной причине). Ну и вопрос номер 2: как на это отреагирует Microsoft со своим Edge и Mozilla с поддержкой в Фоксе. Если эта тройка отработает как надо — формату быть, если опять всё застрянет на ком-то — будет разброд и шатание, как обычно. Причём если Mozilla и Google не сделают вместе, то MS даже видимости деятельности по поддержке проявлять не будет.
- Artima July 15, 2016 at 02:25 PM
  0
  Через 100 лет может и еще что-то появится. Но что мешает сделать поддержку всех этих форматов? Актуальны-то они именно сейчас.