Сравнил с apc12spke на 20 файлах - oapack нигде не проиграл, иногда выиграл по несколько байт, один раз - 115 байт. Но удивительно медленный.
Вид для печати
Сравнил с apc12spke на 20 файлах - oapack нигде не проиграл, иногда выиграл по несколько байт, один раз - 115 байт. Но удивительно медленный.
Пропустил, оказывается уже есть следующий быстрый компрессор для этого формата - apultra. У него нет проигрыша в 100 байт, максимум 8 байт на моем наборе тестовых файлов и сжимает быстро. Но если для какого-то применения несколько байт критичны, то подойдет oapack.
а где выкопать последний zx7 с собранымм пакером?
Последний это какой? Этот? https://github.com/antoniovillena/zx7b Если не этот, то оригинальный тут вот есть https://vtrd.in/pcutilz.php
этот оказался переделанный для работы задом напередЦитата:
Сообщение от Shadow Maker
от этого и название ZX7 Backwards
в моем случае он даже сожрал на 33 байта больше чем старый zx7 со второй ссылки
на других данных подсунутых для теста разница 1 байт в пользу старого zx7
Ну упакованные назад можно в то же место распаковывать, это часто важно. Упакованные вперед часто себя перетирают.Цитата:
Сообщение от NEO SPECTRUMAN
с таки же успехом можно распаковывать и вперед незатирая
и упаковщик назад может перетереть если его криво поставить
но мне для многократных распаковок :v2_dizzy_roll:
и с людскими "началами" проще работать чем с концами :)
В репозитории zx7b много чего, и если говорить про околоzx7, то самый интересный там saukav.exe. Это обобщенный вариант zx7 (и zx7mini) с опциями позволяющими сжимать вперед и назад, с разными ограничениями для смещения и двумя вариантами гамма-функции. При правильном подборе опций он сжимает лучше zx7
негодится по причинеЦитата:
Сообщение от ivagor
Цитата:
the decompression routine is generated by the compressor.
Это не обязательно, можно использовать свои распаковщики, например я делал для 8080, для которого автор конечно распаковщиков не предусмотрел.Цитата:
Сообщение от NEO SPECTRUMAN
а нету готовых упаковщиков с алгоритмами
которые не лезут в уже распакованные данные?
Все lzподобные лезут в уже распакованные данные, но как раз saukav при использовании минимальной битности смещения (или zx7mini, но лучше saukav) позволяет ограничиться кольцевым буфером в 256 (для скорости и удобства) байт. Для примера можно сделать распаковщик картинок, который будет выводить в произвольном (нелинейном) порядке на экран, главное чтобы в кольцевом буфере была копия последних распакованных данных.
RLE. но жмут они так себе.Цитата:
Сообщение от NEO SPECTRUMAN
есть жо еще хафманыЦитата:
Сообщение от jerri
но я спрашиваю за готовое решение
а так смотря что жать
когда данные типа 1,1,1,1,1,2,2,2,2,2.3,3,3,3,3
rle подобное пакует на ура
я вообще описываю\сжимаю как количество повторений до инкримента :)
а что хаффманы? ты хочешь еще доп буфер под данные использовать?Цитата:
Сообщение от NEO SPECTRUMAN
кокой буфер?Цитата:
Сообщение от jerri
иму нужно дополнительное место под дерево
но оно есть часть упакованных данных (ну а в некоторых случаях это часть депакера и через это дерево всегда прогоняются все данные : )
в итоге запакованное можно последовательно читать не распаковывая никуда вообще
в принципе вариант с кольцевым буфером тоже подходит
А дерево оно в воздухе растет да? :)Цитата:
Сообщение от NEO SPECTRUMAN
оно как раз и занимает вот тот самый буфер.
но тут успешно не указывают на сколько можно делать этот overlapЦитата:
Сообщение от Shadow Maker
в zx0 аффтар даже наглядно показывает "дельту" какой зазор должен оставаться и пишет оно при упаковке
ну и умя там выходит 2 байта
https://github.com/einar-saukas/ZX0Код:compressed data |------------------|
decompressed data |---------------------------------|
<---> << start
delta
среди всего хлама есть пакеры гарантировано с дельтой = 0 ?
тк варианты с !=0 и переменного размера только способствуют дополнительной головной боли в моем случае...
NEO SPECTRUMAN,
Прямо чтоб гарантировано - боюсь, это невозможно математически. При любом алгоритме сжатия общего назначения либо нужен (хотя бы мизерный) буфер под словарь/модель, либо будет дельта > 0.
Hrust 1 & 2 обеспечивают дельта=0 для подавляющего большинства файлов, но декомпрессор использует буфер 6 байт на стеке.
Любопытная статья 'Программист, не имеющий представления о сжатии данных, создал суперзамену формату PNG'.
Вопрос а как банальный RLE может быть эффективнее методов сжатия по Хаффману?
У него не "банальный RLE", а еще и ДИКМ и пусть не Хаффман, но экономное кодирование. И "эффективнее" в случае QOI значит в основном "быстрее", сжимает PNG в среднем лучше.Цитата:
Сообщение от polikarpov76
А так, что уровень журналистики упал ниже плинтуса. Вместо того, чтобы обратиться за комментарием к специалисту, сразу тиснули, не глядя.Цитата:
Сообщение от polikarpov76
Во-первых, алгоритмы подобного рода изобретает каждый второй. Сам грешен. На естественных изображениях подойти близко к PNG действительно легко -- по той простой причине, что они вообще плохо сжимаются алгоритмами без потерь.
Во-вторых, автор алгоритма ошибочно считает, что поскольку PNG -- без потерь, то он всегда одинаковый. И взял для сравнения мини-упаковщик из коллекции алгоритмов STB. Он фиговый. Сравнивать надо с монстрами типа PNGCrush или OptiPNG. Вот им-то он и сольёт.
В-третьих, PNG таки реально дендрофекальная конструкция сляпанная на коленке для замены внезапно запатентованному gif. Отыграть 10%-15% на естественных изображениях у PNG можно. Особенно, если они большие. Но не настолько простым способом.
Исходник распаковщика для i8080:
nrv2d-i80.7z
Это алгоритм NRV2d из библиотеки UCL (такие упаковщики уже были). Размер - около 200 байт. Только оригинальный поток, запакованный с помощью утилиты uclpack, не подходит. Но написано как переделать: в функции ucl_nrv_99_compress поменять одно значение. Правильный упаковщик n2dpack прилагается. Пример использования (для ПК «Специалист»): исходный размер – 17 кБ, сжатый – 5 кБ.
Может кому пригодится.
Появились компрессоры RIP и mRIP на PC. Будет что пообсуждать и посравнивать :)
https://gitlab.com/eugene77/rip
https://gitlab.com/eugene77/mrip
UPD: Добавил краткое описание формата.
Случайно вспомнил про упаковщик dict от Булата Зиганшина, автора архиватора FreeArc.Цитата:
Сообщение от NEO SPECTRUMAN
Декомпрессор не имеет состояния и простой донельзя, будет очень быстрым даже на спектруме.
Реализация есть только на PC, правда. Отыскать в сети его уже нереально, поэтому прилагаю прям здесь; в архиве и исходник, и описание формата, и бинарник.
Вложение 77179
Есть некоторые сомнения что z80 потянет ppmd. У меня есть несколько таких компрессоров, результаты очень хорошие.Цитата:
Сообщение от Eugene85
drbars, вы что-то попутали, ppmd тут совершенно ни при чём.
Точно, там оптимизация для улучшения сжатия ppm алгоритмом.Цитата:
Сообщение от Eugene85
Да, он позиционируется как препроцессор для текстовых данных. Однако объём всё же уменьшает, поэтому может рассматриваться и как компрессор, обладающий специфическими свойствами, которые могут быть полезны в каких-то ситуациях.
Для z80 по идее ещё можно использовать kzip. Он даёт очень хорошие результаты, чуть лучше rip/mrip даже.
Распаковать можно утилитой unzip для trdos. Автономного депакера не встречал.
Если сравнивать с упаковщиком Eugene85, то нет, по крайней мере пока мне не удалось найти файлов, на которых kzip лучше.Цитата:
Сообщение от drbars
ivagor, подозреваю, что ты не учёл структуры архива zip, это примерно 110..120 байт.
drbars, действительно, выжимает все соки из формата deflate. И всё же rip'у чаще проигрывает, чем выигрывает; сравнивал на своём корпусе, причём за вычетом структур zip. И главное: распаковщик, говорят, занимает под 2 КБ :\
ZIP/Deflate -- это боль. Я несколько раз порывался написать его распаковщик для БК, но каждый раз, как перечитывал документацию -- всё желание пропадало. Он безобразно тяжёлый. И алгоритмически, и по размеру кода, и по необходимой памяти.
А сжатие так себе.
Заголовок я учитывал, но тогда попробовал слишком мало файлов. Сейчас попробовал 21 файл, kzip выиграл в 4 из 21, но очень незначительно, в целом rip уверенно победил (и это даже без учета сложности распаковщика zip).Цитата:
Сообщение от Eugene85
Любопытно а есть упаковщики/распаковщики позволяющие извлекать выборочную последовательность из общего упакованного кода ?
Если в упаковщиках с LZ смещение для копирования из распакованных данных более-менее ограниченное (до единиц килобайт тому назад), то можно сделать распаковщик с кольцевым буфером, позволяющий распаковывать хоть побайтно. Сам делал такой вариант для saukav.exe (там как раз можно выбирать размер буфера при упаковке). Можно сделать такой распаковщик для MegaLZ и вроде даже делали.Цитата:
Сообщение от Dart Alver
Huffman, Arithmetic coding подойдёт думаю.Цитата:
Сообщение от Dart Alver
- - - Добавлено - - -
Кстати, есть ли реализация Arithmetic coding для z80 ? На текстах этот метод даёт результат лучше Huffman'а.
Насчет кодирования не знаю, а распаковщик с LZMA есть - shrinklerЦитата:
Сообщение от drbars
Это другое. Арифметическое кодирование - это метод сжатия. Вопрос был если ли для этого метода реализация для z80.Цитата:
Сообщение от ivagor
Спасибо, а то я не знал.Цитата:
Сообщение от drbars