RLE упаковщик Спектрум-экранов

[Jukov]

Простой упаковщик спектрум картинок по методу RLE, используется 5-ть методов упаковки данных. На выходе получается упакованная картинка со встроенным релоцируемым декомпрессором. Интересно было бы сравнить с другими аналогичными

[SoftLight]

Простой упаковщик спектрум картинок по методу RLE, используется 5-ть методов упаковки данных. На выходе получается упакованная картинка со встроенным релоцируемым декомпрессором. Интересно было бы сравнить с другими аналогичными
Симпатичная программа, приятный интерфейс. Сравнивать имеет смысл только с другими реализациями RLE. Потому, что против LZSS/LZB всегда будет разница 10-20% в пользу последних. На стандартных экранах 6912 это будет лишние 600-800 байт.

[Vitamin]

Ну можно с моей древней поделкой сравнить:)
https://zxart.ee/rus/soft/tool/packer/upakovschiki-ekranov/tornado-screen-packer/

[Lethargeek]

Симпатичная программа, приятный интерфейс. Сравнивать имеет смысл только с другими реализациями RLE. Потому, что против LZSS/LZB всегда будет разница 10-20% в пользу последних. На стандартных экранах 6912 это будет лишние 600-800 байт.
даже для сравнительно разреженного grandprix разница с лазеркомпактом ~40%
на заполненных картинках должно будет получаться и того больше
и это только для побайтовой (а не чанковой) упаковки

крч на типичных спектрумовских картинках RLE разве что для атрибутов имеет смысл

- - - Добавлено - - -


используется 5-ть методов упаковки данных
а чем "по гор. байтам" отличается от "по гор. линиям"?

[Jukov]

Ну можно с моей древней поделкой сравнить:)
https://zxart.ee/rus/soft/tool/packer/upakovschiki-ekranov/tornado-screen-packer/

Спасибо, сравнил. Прогресс определенно есть

- - - Добавлено - - -


а чем "по гор. байтам" отличается от "по гор. линиям"?
В методе по горизонтальным линиям берутся 32 байта первой (самой верхней) линии, затем под ней и т.д.
В методе по гор. байтам берутся 7-е биты расположенных сверху вниз 8-ми байт и получается первый байт данных, затем 6-е, 5-е и т.д. до нулевого, после чего происходит переход к следующему в строке знакоместу

- - - Добавлено - - -


даже для сравнительно разреженного grandprix разница с лазеркомпактом ~40%
на заполненных картинках должно будет получаться и того больше
и это только для побайтовой (а не чанковой) упаковки

крч на типичных спектрумовских картинках RLE разве что для атрибутов имеет смысл
Можете подсказать конкретную программу для ZX по данному методу для сжатия спектрум-картинок?

[Xela]

Стало интересно, решил проверить на нескольких пакерах, что были под рукой. Понимаю, что не все они, RLE, но тем не менее:

https://i.postimg.cc/d3TQx5HW/RLE-SCREEN-ARCHIVER-v1-0-000000.png (https://postimages.org/) https://i.postimg.cc/RZmfwtqr/RLE-SCREEN-ARCHIVER-v1-0-000001.png (https://postimages.org/) https://i.postimg.cc/3xZG1wDk/RLE-SCREEN-ARCHIVER-v1-0-000002.png (https://postimages.org/)
https://i.postimg.cc/Fzt1NtLt/RLE-SCREEN-ARCHIVER-v1-0-000003.png (https://postimages.org/) https://i.postimg.cc/hv9vGCLX/RLE-SCREEN-ARCHIVER-v1-0-000004.png (https://postimages.org/) https://i.postimg.cc/YqzjKs2V/RLE-SCREEN-ARCHIVER-v1-0-000005.png (https://postimages.org/)
https://i.postimg.cc/zGdB3HgF/RLE-SCREEN-ARCHIVER-v1-0-000006.png (https://postimages.org/) https://i.postimg.cc/nrYVxXx7/RLE-SCREEN-ARCHIVER-v1-0-000007.png (https://postimages.org/) https://i.postimg.cc/g2SRssg6/RLE-SCREEN-ARCHIVER-v1-0-000000.png (https://postimages.org/)
https://i.postimg.cc/25gWR6Rk/RLE-SCREEN-ARCHIVER-v1-0-000001.png (https://postimages.org/) https://i.postimg.cc/J0LB02zS/RLE-SCREEN-ARCHIVER-v1-0-000003.png (https://postimages.org/) https://i.postimg.cc/LhdRNWL3/RLE-SCREEN-ARCHIVER-v1-0-000000.png (https://postimages.org/)

[Vitamin]

Спасибо, сравнил. Прогресс определенно есть
Да, можно еще попробовать VideoStudio в виде "сделать видео из одного кадра" - он станет ключевым и сожмется as is. Там не RLE в чистом виде, но какая-то его быстрая вариация в связке с BitPack. Главное включить поддержку этого режима и цвета (если надо).

[Lethargeek]

В методе по горизонтальным линиям берутся 32 байта первой (самой верхней) линии, затем под ней и т.д.
В методе по гор. байтам берутся 7-е биты расположенных сверху вниз 8-ми байт и получается первый байт данных, затем 6-е, 5-е и т.д. до нулевого, после чего происходит переход к следующему в строке знакоместу
но это же не горизонтальные байты, да и вообще не байты, а вертикально-битовые штрихи)
вообще правильнее было бы обозначать методы наподобие v8v, v8h, h256, v192 итд


Можете подсказать конкретную программу для ZX по данному методу для сжатия спектрум-картинок?
в смысле "данному" - чтобы только именно RLE и запускалось именно на zx?
специально не интересовался, да и в чистом виде вряд ли где применяется, кроме разве самых древних поделок
а так на втрд лежит кучка упаковщиков экрана как для zx, так и утилит для пц

[Jukov]

но это же не горизонтальные байты, да и вообще не байты, а вертикально-битовые штрихи)
вообще правильнее было бы обозначать методы наподобие v8v, v8h, h256, v192 итд

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


в смысле "данному" - чтобы только именно RLE и запускалось именно на zx?
специально не интересовался, да и в чистом виде вряд ли где применяется, кроме разве самых древних поделок
а так на втрд лежит кучка упаковщиков экрана как для zx, так и утилит для пц Только сейчас заметил, что на vtrd кроме архиваторов есть отдельно упаковщики экранов.