В случае текстов на естественных языках наилучший результат даёт сжатие по словарю. Всякие побитовые упаковки после него -- это так, остатки подбирать.Сообщение от drbars
В случае текстов на естественных языках наилучший результат даёт сжатие по словарю. Всякие побитовые упаковки после него -- это так, остатки подбирать.
Oleg N. Cher(30.03.2022)
Я наилучшие результаты с текстами получал на ppm методах. Но спек такое распаковать не сможет.
PPM -- это по сути алгоритм с неявным словарём; точнее, в нём словарь конструируется по мере обработки потока. В теории, при этом происходит экономия на передаче отдельного словаря. На практике, во всех алгоритмах с неявным словарём, а это не только PPM, но и всё семейство LZ*, например, происходит замусоривание словаря записями, которые никогда не будут использованы. Что уменьшает степень сжатия.
На самом деле, PPM с небольшой глубиной контекста (предыстории) на спеке сделать можно. Но смысл этого неясен.
AК априори лучше Хаффмана, оба метода энтропийные, но у Хаффмана разрядность побитовая, а в АК дробная. Поэтому АК не может быть хуже Хаффмана.
Сейчас интересен rANS, но мало материалов и даже читая материалы от разработчика не могу с ним разобраться совсем (впрочем я и с АК плохо разбираюсь, только понимаю теорию).
Сейчас на ПК для себя пользуюсь zpaq64 если есть время для сжатия, если нет, то 7zip PPMd FAST.
Хаффманом обычно дожимают, так как у него задача такая - снижение энтропии. Например если взять файл 1024 байт заполненный нулями, то Хаффман сожмёт его максимум в 8 раз + служебка всякая, а банальный LZ сделает байт 30, что даст сжатие в 33 раза. как то так.
Вопрос, кто-то изучал момент сжатия битовых изображений - спрайтов, с быстрым доступом "на лету". Пока ничего лучшего чем фиксированная таблица для Хаффмана посчитанная по факту с разбиением данных по блокам - ничего не придумывается., но там 256 байт на таблицу сразу отдаём и в среднем по 4 бита на "хвост" спрайта для выравнивания по блокам. Зато при распаковке буфер всего в пару-тройку байт нужен и довольно быстрые операции со сдвигами.
что конкретно значит "на лету"? прямо на экран из потока сжатого? выйдет либо слишком медленно, либо незначительно по размеру
Прихожу без разрешения, сею смерть и разрушение...
да, на этапе vsync например
почему медленно? чем, по операциям, отличается от например смешения спрайтов или наложения маски? хаффман на распаковку очень быстрый же.
по размеру - ну тут от контента зависит, хаффман же энтропийный кодер, если много будет повторяющихся данных то и сожмёт хорошо, даже 1:2 это много.
Вспомнился ещё один интересный упаковщик из прошлого — ACB (associative coding algorithm). Помню давал очень приличное сжатие.
эх, этот алгоритм везде как мем уже. в любом случае он безумно медленный даже на пентиумах, что уж говорить про 6502/z80
по сравнению даже с примитивной процедурой вывода неупакованного спрайта дольше в разы
+ лишних несколько сдвигов и условных переходов на каждый распакованный байт
еще и регистры выделить надо, а их в оптимальных процедурах и так впритык
а вот однократная распаковка графики для нового уровня (и даже каждого нового экрана) вполне оправданна и на практике применяется
Прихожу без разрешения, сею смерть и разрушение...
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием