-
Пригляделся к shrinklerу, вернее к его распаковщику для z80.
Самая шокирующая вещь - это время распаковки. Тест устройств (исходный 25600 байт, упакованный - 14280 байт) на 3 МГц z80 (без тормозов) распаковывается 68.5 секунд! Это на два десятичных порядка медленнее lzsa1 и lz4. Если переделать умножение на развернутый цикл, то распаковка ускоряется почти в полтора раза, но и размер распаковщика увеличивается на 3/4. И это еще для z80, версия для 8080 будет медленнее и больше по размеру. Вот так выглядит LZMA-подобная штука для восьмибиток без быстрого аппаратного умножения и большого количества регистров.
-
Похвастаюсь про shrinkler. После некоторых раздумий стало ясно, что цикл умножения можно разворачивать экономно, аккуратно и сильно выиграть в скорости при минимальном увеличении размера. Да и умножение не единственное место для приложения сил. Но над версией z80 есть кому думать, а я примерился к 8080. Поставил такую цель - получить скорость официальной версии для z80 при размере не больше разогнанной версии для z80. И это получилось выполнить и перевыполнить. В итоге при размере разогнанной версии для z80 версия для 8080 опережает по скорости официальную для z80 на 25%. Это позволило при векторовских тормозах получить быстродействие как у официальной для z80 без тормозов на той же частоте. Аналогично будет для компов на ВМ80 с частотой 2.4-2.5 МГц и прозрачным озу (корвет, океан, орион).
Можно поставить галочку - распаковщик shrinkler для 8080 есть. Но хочется еще доработать, потом собираюсь выложить на gitlab или github.
-
Подскажите, есть ли аналог Laser Compact v5.2 для PC? На текущий момент из всего, что я перепробовал, он сжимает изображения лучше всего, особенно в связке с Screen Optimizer v4.2. Пробовал ZX7, ZLF, Hrust 1.3 / Hrum 3.5. Все они вроде как общего назначения и от этого хуже справляются.
-
Лучше в спековской теме спросить, для вектора таких утилит не было, да и экран у вектора совсем другой.
-
morozov, непонятно, упаковщик на пц для спектрума нужен штоле? ну, есть мои поделия https://zx-pk.ru/blogs/680-lethargeek.html
должны жать типичные скрины лучше лазера (правда, декомпрессор для z80 сложнее и распаковка медленней раза в три))
лазер на пц с исходником тоже есть, где-то в спековских разделах тема была; и конечно, всё лежит на vtrd
- - - Добавлено - - -
адаптировать спековские методы к векторовским плоскостям в принципе несложно, и даже код скорей всего упростился бы
(точней, проще стал бы код для z80, а вот с убогим 8080 результат может оказаться куда печальней)
-
Если подумать, утилит типа laser compacta для вектора не было, зато самые популярные графические редакторы сохраняли картинку в сжатом виде (scr, spr). Соответственно для писи "утилитой для компрессии векторовского экрана" можно назвать sprview или утилиту yura (хотя я не помню точно, у него только смотрит или еще и сжимает). SPRview точно сжимает. А если говорить о современности, то shrinkler победит любого векторовского конкурента, даже если его не дополнять разными вариантами сканирования/обхода картинки и перекодирования цветового пространства. Правда для него желательны не убогие процы типа 8080 или z80, а что-нибудь покруче. Для 8080 (и z80) есть exomizer (если нужно только распаковывать, а упаковывать на писи) - по сравнению со shrinklerом он просто мгновенный и я серьезно оптимизировал его распаковщики, ближе к новому году появятся исходники.
-
Краткий поверхностный тест сжатия графики на примере картинок сконверченных Романом Пантелеевым (9 файлов).
До общественности они дошли в виде spr файлов, поэтому в качестве базы для сравнения беру цифру 9*(32768+16)=295056 байт, т.е. полностью 256x256, хотя некоторые картинки не на полную ширину. Фактически lzsa, exomizer и shrinkler сжимали .o32 файлы, которые представляют собой копию видеопамяти вектора с перевернутыми столбцами и 128 байтным заголовком и реальная степень сжатия для этих форматов даже чуть-чуть больше, но эта крошечная фора не спасет spr.
Код:
Оригинал 295056 байт - 100%
SPR 134656 байт - 45.64%
LZSA1 115128 байт - 39.02%
LZSA2 109294 байт - 37.04%
Exomizer 105206 байт - 35.66%
Shrinkler 102128 байт - 34.61% (-2)
Shrinkler 101004 байт - 34.12% (-9)
7z (формат zip)102916 байт - 34.88%
7z (формат 7z) 99119 байт - 33.59%
Использовал LZSA 1.1.0, exomizer 3.0.2 и shrinkler 4.4. 7z "старый" - 15.14
Стоит отметить, что в очередной версии LZSA 1.1.0 опять чуть улучшено сжатие в LZSA2, но счет LZSA2:MegaLZ по сравнению с 1.0.9 на моем наборе файлов не изменился.
-
Я в 90-ых изучал алгоритм сжатия картинок в SСR-формат, для использования в своей программе. Обнаружил, что графический редактор (сохранявший картинку) не использует все возможности алгоритма. Внёс не большие изменения в алгоритм компрессора, сжиматься картинки стали лучше, а декомпрессор подходил стандартный.
Правда выигрыш был не большой (но было приятно), о времени сжатия я не задумывался.
-
Улучшение сжатия в рамках старого формата хранения это хорошая тема и есть немало подобных примеров (например 7z лучше сжимает в zip, чем классический zip; в LZSA формат не меняется а сжатие улучшается, в exomizere аналогично и т.д.).
Время сжатия сейчас в эпоху писи с неубогими процами не так важно как время распаковки. Ну а степень сжатия всегда будет очень важна.
Возможно стоит потестировать в сравнении с современными и лучшие классические упаковщики: Press Бобкова и LZ77 Луппова. Они 100% проиграют лучшим современным, зато могут сжимать на векторе.
Еще лучше бы сделать большое сводное тестирование пригодных для распаковки на 8080 компрессоров, типа того, что делал introspec/spke, но это надо сильно захотеть и потратить много времени.
- - - Добавлено - - -
Добавил в сравнение 7z в качестве ориентира.
-
Уточнил данные для 7z. Т.к. предыдущие форматы сжимали в raw то и для zip/7z привел цифры без заголовка (поэтому цифра zip стала меньше). Кроме того для 7z/LZMA2 пережал без непрерывного сжатия (поэтому для 7z цифра стала больше), т.к. все остальные сжимали файлы по отдельности.
