Сжатие и упаковка. hrum3.5, hrust1, hrust2, laser compact x.x.

[troosh]

Выложу, пожалуй, результаты сжатия в JBIG2. Готовые бинарники под linux взял тут: http://bfo.com/products/pdf/jbig2/ (это не самая последняя версия упаковщика). Привожу два варианта по jbig2: без опций и с опциями "-s -t 0.9", - в первом случае размер меньше, т.к. упаковщик допускает больше потерь при сжатии.

Хоть стандарт и допускает использование кодов Хаффмана вместо арифметического кодирования (распаковщики это поддерживают, как, например, этот на Javascript: https://github.com/igstan/jbig2.js), но заставить используемый кодировщик использовать кодирование Хаффмана я не могу.

Картинки для тестов брал в этой теме (пришлось некоторые масштабировать до оригинального размера), и ещё некоторые взял из инета (192x256, без атрибутов). Цветную картинку 6339760_.png сжало в черный квадрат, поэтому размеров не привожу.

jbig2 jbig2/s optipng
3350  3485    4002  6124201_.png (мотоциклы оригинал?)
 596   623     689  6315259_.png (скриншот текстового меню)
3177  3320    3957  6317232_.png (мотоциклы оптимизированные?)
   -     -    6019  6339760_.png (мотоциклы в цвете)
2005  2384    4659  Barbarian.png (хоть и в цвете, но не малевич)
2283  2505    3116  Clive.png
1667  1754    2510  Moran-Kinder_Tripman.png
4645  4948    4977  Moran-Throughme.png
1392  1488    2041  RoboNIX-Dangerous_Temptation.png
2056  2372    2904  Surfin'Bird-New_Old_Frontier.png

P.S. PNG хорош тем, что он универсальный, быстрый и относительно простой, пиксель там может быть от 1 бита до 3*16, поддерживается альфа канал. Используемый метод сжатия zlib(deflate) стандартный, без заморочек на то, что файлы будут малого размера ~6k. Отсюда и проигрывает сильно заточенным под специфику SCR изображений.

[Lethargeek]

Привожу два варианта по jbig2: без опций и с опциями "-s -t 0.9", - в первом случае размер меньше, т.к. упаковщик допускает больше потерь при сжатии.

я не понял, так потери для всех случаев возможны, без опций тоже?
вижу разницу 6317232_.png.s.pbm и 6317232_.png.s_t09.pbm (тройка сдвинута)
но у 6317232_.png._.pbm с оригиналом видимых расхождений нет

Barbarian.png (хоть и в цвете, но не малевич)

не, так обесцвечивать не годится
нужно из эмуля выгрузить бинарь без атрибутов
потом после резета в 48k бейсик загрузить обратно
потом сохранить текущий экран в картинку
и потом уже в редакторе инвертировать

[troosh]

По стандарту можно как lossless, так и lossy (это от кодека зависит, а не особенность математики). Как я понимаю, это открытый референсный кодек через параметр -t позволяет регулировать степень потерь. Если бы можно было задать "-t 1.0", то наверное это бы означало без потерь, но вот он таки ругается, если попытать задать более 0.9. Кроме того, может это просто ошибка в программе.

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

Живой спектрум не включал лет 20, да и до эмулятора пока не созрел. Мне проще обрезать последние 768 байт атрибутов у SCR и конвертировать сырые данные в какой-то подходящий формат. А ещё проще, что я и сделал, сразу же поискать готовые файлы в нужном размере и глубине цвета для этого, в общем-то, пока чисто теоретического сравнения форматов (и понимания, где пределы дозволенного энтропией).

[Lethargeek]

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

[Titus]

Выложу, пожалуй, результаты сжатия в JBIG2.

Картинки предварительно преобразовывал по столбцам?

[troosh]

Нет, просто подсунул .png файлы компресору jbig2, он там уже сам как-то - я не вникал. В zip архиве доступны оригинальные файлы, что я использовал.

[Lethargeek]

прогнал новые картинки через считалку

2239 ~ испорченный Barbarian
1883 ~ Moran-Kinder_Tripman
4513 ~ Moran-Throughme
1445 ~ RoboNIX-Dangerous_Temptation
2253 ~ Surfin'Bird-New_Old_Frontier
750 -- менюшка))

видно, что все резервы для простых картинок еще не выбраны
нету групп больше одного знакоместа (запланировано вплоть до 8x8)
не "пакуется" служебная информация (лишних байт несколько десятков)
что опять-таки относительно заметней на картинках попроще
текст вообще ссылками на ксорки должен кодироваться

[Lethargeek]

опыты потихоньку продолжаются, а тем временем хочу задать вопрос нашим игроделам,
демомейкерам и езинщикам: чем (или как) вы жали графику в играх/демах/дискмагах?
и не только задники или заставки, но и динамику (например, шрифты бегущих строк);
пакеры универсальные (мб с подгонкой под них картинок) или самодельные под задачу?
думаю, будет интересно не только мне

[Titus]

опыты потихоньку продолжаются, а тем временем хочу задать вопрос нашим игроделам,
демомейкерам и езинщикам: чем (или как) вы жали графику в играх/демах/дискмагах?

Я жал своим собственным пакером, а до 95 года ASCLZSS и ZYX.

[jerri]

опыты потихоньку продолжаются, а тем временем хочу задать вопрос нашим игроделам,
демомейкерам и езинщикам: чем (или как) вы жали графику в играх/демах/дискмагах?
и не только задники или заставки, но и динамику (например, шрифты бегущих строк);
пакеры универсальные (мб с подгонкой под них картинок) или самодельные под задачу?
думаю, будет интересно не только мне

Переписанный Hrum3.51, Hrust