Сжатие и упаковка - обсуждение и сравнения

[ivagor]

как банальный RLE может быть эффективнее методов сжатия по Хаффману?

У него не "банальный RLE", а еще и ДИКМ и пусть не Хаффман, но экономное кодирование. И "эффективнее" в случае QOI значит в основном "быстрее", сжимает PNG в среднем лучше.

[Advertiser]

[Sandro]

Любопытная статья 'Программист, не имеющий представления о сжатии данных, создал суперзамену формату PNG'.
Вопрос а как банальный RLE может быть эффективнее методов сжатия по Хаффману?

А так, что уровень журналистики упал ниже плинтуса. Вместо того, чтобы обратиться за комментарием к специалисту, сразу тиснули, не глядя.

Во-первых, алгоритмы подобного рода изобретает каждый второй. Сам грешен. На естественных изображениях подойти близко к PNG действительно легко -- по той простой причине, что они вообще плохо сжимаются алгоритмами без потерь.

Во-вторых, автор алгоритма ошибочно считает, что поскольку PNG -- без потерь, то он всегда одинаковый. И взял для сравнения мини-упаковщик из коллекции алгоритмов STB. Он фиговый. Сравнивать надо с монстрами типа PNGCrush или OptiPNG. Вот им-то он и сольёт.

В-третьих, PNG таки реально дендрофекальная конструкция сляпанная на коленке для замены внезапно запатентованному gif. Отыграть 10%-15% на естественных изображениях у PNG можно. Особенно, если они большие. Но не настолько простым способом.

[lexarr]

Исходник распаковщика для i8080:

nrv2d-i80.7z

Это алгоритм NRV2d из библиотеки UCL (такие упаковщики уже были). Размер - около 200 байт. Только оригинальный поток, запакованный с помощью утилиты uclpack, не подходит. Но написано как переделать: в функции ucl_nrv_99_compress поменять одно значение. Правильный упаковщик n2dpack прилагается. Пример использования (для ПК «Специалист»): исходный размер – 17 кБ, сжатый – 5 кБ.
Может кому пригодится.

[Eugene85]

Появились компрессоры RIP и mRIP на PC. Будет что пообсуждать и посравнивать

https://gitlab.com/eugene77/rip
https://gitlab.com/eugene77/mrip

UPD: Добавил краткое описание формата.

[Eugene85]

а нету готовых упаковщиков с алгоритмами
которые не лезут в уже распакованные данные?

Случайно вспомнил про упаковщик dict от Булата Зиганшина, автора архиватора FreeArc.
Декомпрессор не имеет состояния и простой донельзя, будет очень быстрым даже на спектруме.
Реализация есть только на PC, правда. Отыскать в сети его уже нереально, поэтому прилагаю прям здесь; в архиве и исходник, и описание формата, и бинарник.

dict.zip

[drbars]

Случайно вспомнил про упаковщик dict от Булата Зиганшина, автора архиватора FreeArc.
Декомпрессор не имеет состояния и простой донельзя, будет очень быстрым даже на спектруме.
Реализация есть только на PC, правда. Отыскать в сети его уже нереально, поэтому прилагаю прям здесь; в архиве и исходник, и описание формата, и бинарник.

Есть некоторые сомнения что z80 потянет ppmd. У меня есть несколько таких компрессоров, результаты очень хорошие.

[Eugene85]

drbars, вы что-то попутали, ppmd тут совершенно ни при чём.

[drbars]

drbars, вы что-то попутали, ppmd тут совершенно ни при чём.

Точно, там оптимизация для улучшения сжатия ppm алгоритмом.

[Eugene85]

Да, он позиционируется как препроцессор для текстовых данных. Однако объём всё же уменьшает, поэтому может рассматриваться и как компрессор, обладающий специфическими свойствами, которые могут быть полезны в каких-то ситуациях.

[drbars]

Для z80 по идее ещё можно использовать kzip. Он даёт очень хорошие результаты, чуть лучше rip/mrip даже.
Распаковать можно утилитой unzip для trdos. Автономного депакера не встречал.