а нету готовых упаковщиков с алгоритмами
которые не лезут в уже распакованные данные?
а нету готовых упаковщиков с алгоритмами
которые не лезут в уже распакованные данные?
Все lzподобные лезут в уже распакованные данные, но как раз saukav при использовании минимальной битности смещения (или zx7mini, но лучше saukav) позволяет ограничиться кольцевым буфером в 256 (для скорости и удобства) байт. Для примера можно сделать распаковщик картинок, который будет выводить в произвольном (нелинейном) порядке на экран, главное чтобы в кольцевом буфере была копия последних распакованных данных.
RLE. но жмут они так себе.Сообщение от NEO SPECTRUMAN
С уважением,
Jerri / Red Triangle.
есть жо еще хафманы
но я спрашиваю за готовое решение
а так смотря что жать
когда данные типа 1,1,1,1,1,2,2,2,2,2.3,3,3,3,3
rle подобное пакует на ура
я вообще описываю\сжимаю как количество повторений до инкримента
Последний раз редактировалось NEO SPECTRUMAN; 29.12.2020 в 14:47.
а что хаффманы? ты хочешь еще доп буфер под данные использовать?есть жо еще хафманы
но я спрашиваю за готовое решение
а так смотря что жать
когда данные типа 1,1,1,1,1,2,2,2,2,2.3,3,3,3,3
rle подобное пакует на ура
я вообще описываю\сжимаю как количество повторений до инкримента
С уважением,
Jerri / Red Triangle.
кокой буфер?
иму нужно дополнительное место под дерево
но оно есть часть упакованных данных (ну а в некоторых случаях это часть депакера и через это дерево всегда прогоняются все данные : )
в итоге запакованное можно последовательно читать не распаковывая никуда вообще
в принципе вариант с кольцевым буфером тоже подходит
Последний раз редактировалось NEO SPECTRUMAN; 29.12.2020 в 16:34.
А дерево оно в воздухе растет да?
оно как раз и занимает вот тот самый буфер.
С уважением,
Jerri / Red Triangle.
но тут успешно не указывают на сколько можно делать этот overlap
в zx0 аффтар даже наглядно показывает "дельту" какой зазор должен оставаться и пишет оно при упаковке
ну и умя там выходит 2 байта
https://github.com/einar-saukas/ZX0Код:compressed data |------------------| decompressed data |---------------------------------| <---> << start delta
среди всего хлама есть пакеры гарантировано с дельтой = 0 ?
тк варианты с !=0 и переменного размера только способствуют дополнительной головной боли в моем случае...
Последний раз редактировалось NEO SPECTRUMAN; 27.01.2021 в 21:09.
NEO SPECTRUMAN,
Прямо чтоб гарантировано - боюсь, это невозможно математически. При любом алгоритме сжатия общего назначения либо нужен (хотя бы мизерный) буфер под словарь/модель, либо будет дельта > 0.
Hrust 1 & 2 обеспечивают дельта=0 для подавляющего большинства файлов, но декомпрессор использует буфер 6 байт на стеке.
NEO SPECTRUMAN(28.01.2021)
Любопытная статья 'Программист, не имеющий представления о сжатии данных, создал суперзамену формату PNG'.
Вопрос а как банальный RLE может быть эффективнее методов сжатия по Хаффману?
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием