> Оно не лучше, оно сильно хуже! снэппи хорошо работает на сильно разреженных данных.Да на самом деле и на остальных работает.
> все типы лемпел-зива - на данных, в которых есть многобайтовые
> повторяющиеся последовательности.
Ну спасибо, Кэп. Вообще, рассказывать о том как работает LZ тому кто разок написал анпакер одного их таких "простых LZ" - довольно интересное начинание :).
> И на каком нибудь 10-12-битном шумноватом изображении не дадут такого результата
Насчет скорости - у сабжевых LZ поиск совпадений минимальный. Скорость сжатия LZ компрессора зависит от того насколько быстро он забивает на поиск совпадений, в ущерб сжатию, разумеется. Чем быстрее забивает, тем хуже сжатие и выше скорость. Можно задетектировав плохо сжимающиеся данные вообще перейти к просто копированию, чтобы скорость не снижать. В целом упомянутые "быстрые LZ" достаточно универсальны. В хучем случае они просто не сожмут, но отработают все-равно достаточно быстро.
> который выдаст примитивнейший бит-пакер, ни по сжатию, ни тем более по скорости.
Ну если заморачиваться классификацией данных, на что надо отдельное время и усилия, тогда и LZ можно костыли подставить в виде препроцессора, который сделает данные удобнее для сжатия. Таких трюков придумано немеряно, в том числе и для битмапов различной природы. Но это дополнительное время на классификацию и препроцессинг. Для скоростного универсального алгоритма сжатия который не знает что дадут на вход (например, компрессия в ФС или БД) это неприемлимо.
Кстати у LZ4 есть и режим генерации pre-compressed данных на случай если скорость сжатия не интересует а вот размер данных и скорость распаковки - важны.
Раз уж вы хотели с шумом и прочая - вот, получите:
$ ./lz4c -b0 photo2011_1.dng test.1
*** LZ4 Compression CLI , by Yann Collet (Jul 12 2013) ***
photo2011_1.dng : 11127342 -> 9333542 (83.88%), 205.5 MB/s , 1025.2 MB/s
То что доктор прописал - равка с матрицы. Шум и прочие прелести - в комплекте. Даже сжалось. Не сильно, зато на скорости 205Мб/сек. А распаковка так вообще гиг в секунду. Поди плохо, да?
Если хочется сжать получше - оно и так умеет:
$ ./lz4c -b1 photo2011_1.dng test.1
*** LZ4 Compression CLI , by Yann Collet (Jul 12 2013) ***
photo2011_1.dng : 11127342 -> 7152148 (64.28%), 11.9 MB/s , 931.4 MB/s
Это если что в 1 поток было. При желании и распараллелить ведь можно - паковать разные субблоки на нескольких ядрах, например.
> то есть повторяя то что кто-то уже написал выше - все зависит от структуры данных!
Ясен перец. А LZO, LZ4 и прочие - это скоростные и не ресурсоемкие алгоритмы сжатия, которые не требуют предварительных знаний о структуре и типе данных и используются там где скорость роялит (запись на диск, отсылка по сети, ...). Это универсальные быстрые алгоритмы без претензий на максимальное сжатие и оптимальность во всех возможных случаях. Это "какое-то" сжатие. Зато быстро. Очень быстро. Как видите оно даже трудно жмущуюся равку прожевало на довольно убедительных 200 Мб/сек и даже уменьшило при этом размер на 1/5. К слову, скорость записи на винч где делался опыт - 120Мб/сек на внешних треках, так что такая компрессия может поднять скорость записи, даже на относительно неудачных данных. А на более удачных и подавно :)
> все алгоритмы сжатия работают на специфической структурированности в данных.
Конкретно эти LZ* задуманы быть generic скоростной давилкой данных без какого либо предварительного знания. Не чемпионские параметры, зато быстро.
