Новый формат данных LGA (Linear Graphical Archive)

[Alex Cones]

Увы, программа выкинула файл в 55 Кб и зависла при загрузке ЦП в 99%

Вот-вот. А по теоретическим расчетам должно быть не больше 10-ти кб. Где-то ошибка, только не могу понять где.
JTG, а что это за прожка такая? И что она показывает?

Вот блок схема работы моей проги:

[evg_m]

зависла при загрузке ЦП в 99%

n=134
while ColM[N] <>n
length(colM)=128
подробнее смотри прилагаемый файл

[mutabor]

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

В подтверждение моих слов прилагаю скриншот, свойства этой картинки в моей проге к-рая жмет RLE алгоритмом, реализация его там у меня не самая оптимальная (последовательности немного не так кодируются), но общую тенденцию отражает плюс минус пару процентов. Не смотри на максимальную длину, в основном там наверняка по 2-3 пикселя максимум. Всего точек 87,500 а последовательностей из них 45-47 тыс. Делай выводы, по два пиксела в среднем.

Кстати пробовал в PNG сохранять, по сравнению с GIF она даже больше стала, с такой палитрой у GIF лучше сжатие (кстати RLE используется), чем у PNG, так что ты ее не сожмешь никак. Разве что заточить свой алгоритм именно под эту картинку, и получишь размер около 70% от размера GIF, т.е. около 25 кб.

[JTG]

JTG, а что это за прожка такая

Анализатор из winhex. Подсчитывает частоту появления каждого байта в файле

[Alex Cones]

Разве что заточить свой алгоритм именно под эту картинку

Кажется это единственный выход... Подскажите, пожалуйста, какие алгоритмы тогда здесь можно приспособить. Может тогда усовершенствовать RLE не только по просто одинаковым, а еще и некоторым последовательностям...

Вывод - она практически несжимаема.

Не бывает здоровых людей, есть недообследованные. Должен быть метод, который позволит это сделать...

Анализатор из winhex.

Убунтовский BlessHex удобней.

[JTG]

какие алгоритмы тогда здесь можно приспособить

Подключи zlib, маленький (+40 Кб) и шустрый.
(В статье, кстати, программирование опять победило здравый смысл и началось изобретение велосипеда, забыли про ивент onProgress)

[Alex Cones]

Сообщение от JTG

Подключи zlib, маленький (+40 Кб) и шустрый

Раз RAR мало дает, то не думаю, что ZIP даст больше. Тут надо выращивать свою велосипеду, подстраивая под файл.
Я вот, что заметил, заглянув в хексовы кишки (BMP):


Тут можно комбинировать RLE и замены последовательностей.

[mutabor]

Сообщение от Alex Cones

Кажется это единственный выход... Подскажите, пожалуйста, какие алгоритмы тогда здесь можно приспособить. Может тогда усовершенствовать RLE не только по просто одинаковым, а еще и некоторым последовательностям...
Не бывает здоровых людей, есть недообследованные. Должен быть метод, который позволит это сделать...
Убунтовский BlessHex удобней.

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

Подключи zlib, маленький (+40 Кб) и шустрый.

Ну а толку, если они не хотят 35 кб картинку в ресурсы запихать, так они будут 40 кб библиотеку пихать? Да плюс еще картинку к-рая в сжатом виде будет все те же 35 кб занимать (проверил 7-zip и zip им же, не сжимает вообще).

p.s. Совет: хочешь меньше размер? Подумай о замене картинки на другую. Красоту наводи градиентами (желательно не круговыми).

[Alex Cones]

p.s. Совет: хочешь меньше размер? Подумай о замене картинки на другую. Красоту наводи градиентами

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

Значит все-таки придется остаться в рамках возможных алгоритмов... А жаль... Так хочется выйти за рамки возможного...

[mutabor]

Сообщение от Alex Cones

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

Я бы поспорил насчет бездушности градиентов. Можно и небо, и облачка градиентными сделать, а травка так и быть будет самым тяжелым грузом в картинке, но и ее упростить нужно тоже. Конечно это будет скорее картинка наподобии мультяшной, нежели фото, но бездушной я бы не сказал, ее тоже можно красиво нарисовать.

А вообще, что такое в наше время 35 кб? Сущий пустяк (особенно в сравнении с весом VCL приложения). Не об чём говорить ) На красоте экономить нельзя )

p.s. Да, и самое главное, я перепутал выше, 70% это в сравнении с битмапом 8-битным (87 кб), а до размера GIF еще очень далеко, он действительно весьма компактный для таких картинок, возможно даже лучший из существующих. Но у меня там не правильный RLE, а если сделать как положено, то наверное и получится GIF.

GIF использует LZW-компрессию, что позволяет неплохо сжимать файлы, в которых много однородных заливок (логотипы, надписи, схемы).

Метод LZW, так же, как и RLE, лучше действует на участках однородных, свободных от шума цветов, он действует гораздо лучше, чем RLE, при сжатии произвольных графических данных, но процесс кодирования и распаковки происходит медленнее.