Архивирование, сжатие, упаковка.

[GriV]

как я описал скрещённый метод Хаффмана и RLE и к тому же привёл полное доказательство теоремы Хаффмана, если получается что я метод Хаффмана не знаю?
Каждый из методов имеет ДОСТОИНСТВА и НЕДОСТАТКИ.
т.о. суммарно (полностью итоговые данные) каждый из методов может как давать компрессию (сжатие), так и увеличение в конечном файле.
Чем сложней метод сжатия, тем меньше вероятность возникновения такого случая, но он всегда есть:
- Для самого простого RLE это просто очевидно
- Для Хаффмана это не так видно, но оно обязательно есть
- Для других методов на простейших примерах можно показать что так оно и будет, потому что ВСЕГДА можно найти последовательность, когда упаковищку придётся сохранить всю эту последовательность плюс ещё служебные данные.

[Proteus]

В спектруме одна тока неприятность. Данные по размеру слишком малы чтобы давать эеффект. А так у хафмана сжатие есть почти всегда и таблица картины не портит. Можно ещё динамическую таблицу применять, тогда её хранить не придётся, но там уже теория от потерь не защищает и они иногда появляются.
Ещё хафмана хорошо вместе с LZ методом применять. LZ это же по сути повторения областей, т.е. смещения и размеры памяти вот их хорошо кодировать по хафману... Работает эффектно и не нужно ломать голову над сложными методами.......

[GriV]

данных достаточно, чтобы сжимать.
К тому же все существующие методы сжатия (на всех машинах) рассчитаны на обработку кратнобайтовых последовательностей, а как показал Иван Рощин, зачастую просто преобразовав бит в байт можно сжатие значительно улучшить.
Стоит отметить, что ни один из существующих методов не постулирует размер последовательностей и их кратность (все методы можно применять как для байтового сжатия, так и для битового)
Всерьёз этим вопросом никто не занимался, так как получается значительное замедление процесса сжатия.
Интереса ради можно попробовать написать (де-)скрамблер, которые будет указанное бит->байт преобразование делать, тогда и увидеть можно будет насколько вырастает эффективность сжатия.

[Proteus]

Сжимать последовательность битов. Модет быть такие наивные методы как RLE дадут какой-то результат. Сомневаюсь что ARI даст какой-нибудь положительный результат, и Хафман не даст тем более. На 2-символьный алфавит они никак не расчитаны. (это можно на бумаге проверить). Да упаковке программ тоже никого толка не выдет никаким способом. Можно только на картинках через LZ методы какой-то толк извлечь (и то если с умом применять).

[Vitamin]

недавно, перечитавшись статей alco и ковыряясь с переводом спековского депакера LC на пц, проникся духом сжимательства %) и написал упаковщик (пока картинок). упрощенное дерево, окно поиска в 256 байт. и тем не менее, на некоторых картинках (с большими повторяющимися площадями) настолько рвал LC, что я по три раза перепроверял результаты. что бы это могло быть? :?

[lvd]

недавно, перечитавшись статей alco и ковыряясь с переводом спековского депакера LC на пц, проникся духом сжимательства %) и написал упаковщик (пока картинок). упрощенное дерево, окно поиска в 256 байт. и тем не менее, на некоторых картинках (с большими повторяющимися площадями) настолько рвал LC, что я по три раза перепроверял результаты. что бы это могло быть? :?

А если картинку в памяти вертикально разместить - улучшается ещё?

[GriV]

Сжимать последовательность битов. Модет быть такие наивные методы как RLE дадут какой-то результат. Сомневаюсь что ARI даст какой-нибудь положительный результат, и Хафман не даст тем более. На 2-символьный алфавит они никак не расчитаны. (это можно на бумаге проверить). Да упаковке программ тоже никого толка не выдет никаким способом. Можно только на картинках через LZ методы какой-то толк извлечь (и то если с умом применять).

как раз RLE здесь мало чего решит. Имеется в виду не однобитные последовательности, а длинные последовательности из нескольких бит.
Специально в целях исследования этой темы написал скрамблер и дескрамблер, который делает конверт бит->байт и наоборот. Так вот для разных файлов наблюдалась разная картина - был как прирост (на одних файлах) так и наоборот ухудшение результата (относительно конечно же того, что получалось без скремблирования) в других случаях.
Так что получается, что говорить о том, что такой подход даёт вообще говоря значительный прирост нельзя.

2Vitamin> чтото тебя не видно, я тебе могу исходник своего паковщика дать (на паскале только), посмотри как твой пакер работать будет на том, что остаётся несжатым.
2lvd> сжатие картинок невертикальным линейным методом не осуществляется

[elf/2]

недавно, перечитавшись статей alco и ковыряясь с переводом спековского депакера LC на пц, проникся духом сжимательства %) и написал упаковщик (пока картинок). упрощенное дерево, окно поиска в 256 байт. и тем не менее, на некоторых картинках (с большими повторяющимися площадями) настолько рвал LC, что я по три раза перепроверял результаты. что бы это могло быть? :?

в LC алгоритм тривиальный как оказалось, delc5.2 переписанный на си должен появиться в одной из следующих публикаций AlCo. если кому интересно увидеть его раньше - напишите хрумер'у, у него есть

[Vitamin]

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

[Cheburashka]

Доброго здоровья всем! Решился наконец протестировать, прокомментировать и выложить здесь доработанный мной распаковщик знаменитого формата apack (или aplib) Йоргена Ибсена. (текст, импортирован из ALASM).

UNAPACK.txt

По моим замерам, скорость распаковки превосходит скорость распаковщика Hrust1 (209 байт) на 8-11 процентов.

Теперь насчет степени сжатия: недавно появился на свет оптимизированный упаковщик по методу apack, который близко подобрался по степени сжатия к оптимизированному упаковщику oh1c (hrust1).

Вот ссылка: http://www.amstrad.es/forum/download...73bc4fdc8ca836

Думаю, в некоторых случаях, применение этой "пары" может иметь смысел.
На форум захожу редко, так что извиняйте за молчание!