Программирование

[ivagor]

Если для главной заставки, то наверно лучше так не стоит, а для картинок по ходу игры вполне приемлемо.

Хочу реабилитировать квадраты. C zx0 они для данной картинки ничего хорошего не дают, но с upkr или rip квадраты размером 32x32 (обход по столбцам) сжимаются лучше:
upkr - 8647 байт
rip - 9057 байт
Это без палитры (+16 байт).
Если картинка одна, то надо учитывать и размер распаковщика и перестановщика и тогда более простой вариант с чуть большей по размеру картинкой может оказаться более выгодным.

[Advertiser]

[parallelno]

Согласен. Нужно учитывать все.
Пока результат меня радует. Напоминает кадр из СD фильма на паузе

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

Обновил статистику
5175 байт с ZX0 и 4534 bytes (13.83667%) с помощью UPKR.




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

Картинка с дизером
5740 байт с ZX0 и 4953 bytes (15.115356%) с помощью UPKR.



original photo download

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

Имхо вполне не плохо при таком коэфициенте сжатия

[ivagor]

Посмотрел tmp-rgb-compressed.png (256x256). По этой картинке еще нельзя судить о том, что будет на векторе. Надо привести к 16 цветам и в рамках векторовской палитры. К сожалению качество неминуемо ухудшится, но скорее всего улучшится сжатие.

[parallelno]

Посмотрел tmp-rgb-compressed.png (256x256). По этой картинке еще нельзя судить о том, что будет на векторе. Надо привести к 16 цветам и в рамках векторовской палитры. К сожалению качество неминуемо ухудшится, но скорее всего улучшится сжатие.

Наверное я в торопях выложил не приведенную к палитре вектора картинку. Но упаковка адаптирует палитру перед сжатием, поэтому коэффициент сжатия не измениться.
Я сжимал всю картинку, где по сути продублированы тайлы. если сжимать только уникальные тайлы, то UPKR выдает что-то примерно 4600. И ещё будет 1024 индексный массив из байтов. Нужно будет пожать все это безобразие и сравнить.

[ivagor]

У меня возникло много вопросов, но думаю они все прояснятся когда увижу результат сжатия под вектор.

[parallelno]

Буду сюда выкладывать сравнения.
Для сравнения я взял картинку, адаптировал под размер и палитру Вектора, затем индексы цвета двух соседних вертикальных пикселей объеденил в один байт. Добавил палитру, все упаковал UPKR упаковщиком.
Вторая картинка это та же картинка только прогоненая через vector quantization, затем декодированная обратно, востановлена палитра (местами неточно). Потом индексы цвета двух соседних вертикальных пикселей объеденил в один байт, упаковано UPKR упаковщиком.

То есть подход по сути не упаковщик, а упрошатель картинок.
Я сделал свой формат на тайлах, но он начинает сильно жирнеть когда тайлов больше 256, поэтому отказался в пользу просто востановленной картинки после квантизации и упакованой как та с которой идет сравнение.

и так lossless vs lossy:

contrast_dither_adaptive
original image to upkr: 8886 // lossless, 8886 байт
vector quantization to upkr:
3608, rate: 0.41, tile_size: 4, n_clusters: 256 // lossy, 3608 байт. rate это во сколько он меньше чем lossless
4473, rate: 0.50, tile_size: 4, n_clusters: 1536
6605, rate: 0.74, tile_size: 2, n_clusters: 1536



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

original image to upkr: 8886
vector quantization to upkr:
3554, rate: 0.40, tile_size: 4, n_clusters: 256
4428, rate: 0.50, tile_size: 8, n_clusters: 256
5531, rate: 0.62, tile_size: 2, n_clusters: 1536




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

image_intro2
original image to upkr: 8049
vector quantization to upkr:
3651, rate: 0.45, tile_size: 8, n_clusters: 256
4386, rate: 0.54, tile_size: 4, n_clusters: 1024
5273, rate: 0.66, tile_size: 2, n_clusters: 1536



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

img06
original image to upkr: 10230
vector quantization to upkr:
4333, rate: 0.42, tile_size: 8, n_clusters: 256
4873, rate: 0.48, tile_size: 8, n_clusters: 512
5322, rate: 0.52, tile_size: 2, n_clusters: 1536




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

img14
original image to upkr: 3818
vector quantization to upkr:
2828, rate: 0.74, tile_size: 4, n_clusters: 512
3295, rate: 0.86, tile_size: 2, n_clusters: 512
3604, rate: 0.94, tile_size: 2, n_clusters: 1536



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

img17
original image to upkr: 3008
vector quantization to upkr:
2751, rate: 0.91, tile_size: 2, n_clusters: 96
2877, rate: 0.96, tile_size: 2, n_clusters: 1536



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

svofski, а какие размеры получились у писателей? у тебя сохранились оригиналы, хочется прогнать через VQ алгоритм.

[svofski]

svofski, а какие размеры получились у писателей? у тебя сохранились оригиналы, хочется прогнать через VQ алгоритм.

Пушкин был 1394 байта + 373 байта рисовалка, спасибо ivagor-у. Но это нельзя сравнивать. В моем алгоритме псевдослучайно блуждающая кисточка малюет картинку и фактически он пригоден только для очень крупных планов и высоко узнавабельных оригиналов. Скорость отображения очень низкая, это годится только как демо-эффект, но для этого надо сначала все разогнать раз в 10. Наверняка можно улучшить, но все равно на алгоритм для общего применения он никогда не потянет.

Оригинала картинок у меня не сохранилось, но если просто сравнить, тут ничего сложного. Берешь первый попавшийся портрет (не обязательно Пушкина на самом деле), обрезаешь его примерно вот так как у меня, и запускаешь.

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

Картинку типа img06 по-моему можно векторизовать и рисовать полигонами. Но это тоже вряд ли получится сделать очень быстро.

[parallelno]

Хочется услышать ваши мысли по поводу результатов. Все ли понятно из статистики? Какие вы видите плюсы и минусы. Может быть у вас есть идеи для улучшения?

[ivagor]

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

Если несколько больших (полноэкранных?) картинок, то использование upkr мне кажется жестоким по отношению к пользователю. Понимаю в деме предельных параметров распаковать 1-2 картинки, человек посмотрит ее один раз и успокоится. А если запускать игру несколько раз и там каждый раз upkr распаковывает картинки по 32 Кб, то терпение быстро иссякнет. Еще момент с местом под распаковку - при использовании "безбуферных" (выдающих полный результат) распаковщиков в сочетании с пикселями нужно дополнительно 32 Кб. Вместо этого можно использовать менее эффективные упаковщики, но с буферными (удобно на 256 байт) распаковщиками и потратить те 32 Кб на компенсацию меньшей степени сжатия. На мой взгляд приемлемыми компромиссами по скорости и степени сжатия являются rip и exomizer, плюс они умеют ограничивать длину и дальность ссылок, т.е. можно распаковывать в кольцевой буфер ограниченного размера.

Никогда всерьез не занимался сжатием палитровых картинок, но насколько я понял из прочитанного, сейчас самый модный вариант - предсказатели+оптимизация палитры для согласования+сжимаем арифметическим кодером. Но тут еще надо найти эти экспериментальные упаковщики, сделать для них распаковщик для вектора и получить скорость скорее всего хуже upkr.
Для полутоновых или нечто jpeg-подобное (с ДКП) или вейвлеты. Но тут сразу много вопросов - насколько приемлемы полутоновые картинки, устроит ли 8 оттенков желтого/зеленого/красного, распаковщик сложный и медленный. 16 отенков серого на ЧБ мониторе более интересны, но это специфическое решение. Кстати, для полутоновых векторное кодирование должно давать более приемлемые результаты, чем для палитровых. Еще можно вспомнить экзотику типа фрактальных, но это опять надо искать упаковщики и делать распаковщик.

Возвращаясь на землю, я бы скорее всего ориентировался на rip. Если сжимать байты, то распаковываем на экран. Если сжимаем пиксели, то распаковываем в кольцевой буфер. Пиксели сжимаются лучше, но ограничение длины и дальности ссылок ухудшает сжатие, поэтому надо смотреть конкретные примеры. Также использование буфера позволяет распаковывать картинки произвольного размера, а не на полный экран.

[parallelno]

ivagor, напиши пожалуйста что ты думаешь про упрощатель картинок. Напиши если можешь свои мысли по поводу соотношения качества изображения и размера. Вместо upkr может быть любой упаковщик.