flif

[thedeemon]

Интернеты забурлили в связи с публикацией Free Lossless Image Format; там компрессор, декларирующий чудеса беспотерьного сжатия, да еще с хорошим свойством прогрессивной загрузки - если качать не всю картинку, а только начало файла, то все равно можно ей любоваться, просто в худшем качестве.

Сразу зачесались руки сравнить со своей поделкой. У меня ж есть видеокодек ScreenPressor, часть которого для intra-frame'ов может использоваться для отдельных картинок. Взял картинку из своего прошлогоднего примера, на которой гонял браузерные реализации (скриншот 960х540, 24 бита цвет, там текст, немного графики и мужик). Получилось:

BMP - 1555254 bytes (uncompressed)

PNG - 176469 bytes (compression ratio 8.8 to 1)

FLIF - 157515 bytes (9.9 to 1)

SPI - 149321 bytes (10.4 to 1) // ScreenPressor I-frame
Здеся оно разжимается в браузере.
По крайней мере эту картинку мой жмет сильнее. Уфф. :)

Upd: рано обрадовался, с опцией -n (non-interlaced) FLIF сжал до 134326.

Comments

[sleepy-drago.livejournal.com]

злые языки пишут что оно сильно недалеко от методов из h264, что ставит под большое сомнение free. ну и для полноты сравнения еще можно webp указать.

[nivanych.livejournal.com]

От PNG, поди, твой отличается только использованием PPMx-сжатия? ;-)

[thedeemon.livejournal.com]

Отнюдь. У меня соседние точки могут по-разному предсказываться, и подряд одинаково предсказываемые через RLE проходят, а потом уже арифметик с контекстным моделированием, вестимо.

[nivanych.livejournal.com]

Прикольно.

[thedeemon.livejournal.com]

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