В спецификациях методов сжатия PNG, JBIG2, JB2 и даже в JPEG-LS, WebP-lossless, PCIF/BCIF и прочих столько идей, аж глаза разбегаются...Сообщение от Lethargeek
Только проблема может быть в том, что распаковщик будет размером в пару десятков килобайт и отрабатывать одну картинку будет за пару минут.
troosh, да понятно, что депакер попроще нужен
и совсем неочевидна ценность упомянутых алгоритмов
так, png и tiff хуже жмут нецветные контрольные скрины
у zx-картинок своя специфика
Прихожу без разрешения, сею смерть и разрушение...
Речь про то, что для лучшего сжатия применяют различные обратимые фильтры. Да, для монохромных картинок переход в частотную область за счет DCT мало что даст, но повышение локальности в обработываемых данных вполне себе работает: на некоторых SCR файлов будет заметный прирост, если сжимать не в линейном порядке исходные данные, а вертикальными столбцами 8x64 пикселя или другими тайлами.
В этом плане в PNG понапридумывали много способов порядка обхода исходного изображения, плюс простейшие предсказатели, тот же XOR с предыдущим байтом.
Ну а в таких методах как JBIG2 там вообще доходит до того, что распознавание образов используют для раздельного кодирования объектов и различных заливок по патернам (шашечками).
я так понял, jbig-и больше для текстов и достаточно больших разрешений
столбцы это очевидно и примитивно, ну, и png я делал из bmp, жми как хочешь
а вот поди ж ты... архиваторы обычные по столбцам получше, но недостаточно
хотя, может, это примитивный paint в png так хреново жмёт? вопрос залу:
подскажите простенький portable lossless конвертер с лучшей компрессией
сложный софт ставить и осваивать влом, да и места нет
Прихожу без разрешения, сею смерть и разрушение...
Прикалываешься? Эта пакость в 32 бита сохраняет, вот и кажется что плохо жмёт, впрочем, вполне возможно что и сжатие не на полную катушку.
Да обычный XnView запусти и выбери в нём максимальную степень сжатия для сохранения в PNG.
P.S. PNG лучший!
В правильно заданном вопросе содержится половина ответа
с какой стати в 32 бита, раз на входе монохромная бмпшка?
ну, давай...
SCR 6144 для LC
BMP 6206 для paint/xnview
и моей считалочки (Lgk)
6144 (по столбцам) для RAR
мотоциклы (еще мною обработанная слегка)
http://zx-pk.ru/showpost.php?p=748482&postcount=36
Paint PNG: 4328
XnView PNG: 4261
LC5.2.1: 3809
RAR: 3503
Lgk: 3269
сильно текстурированная картинка (необработанная)
http://zxart.ee/eng/graphics/authors/v/vassa/town/
Paint PNG: 4701
XnView PNG: 4625
LC5.2.1: 4517
RAR: 4140
Lgk: 3919
для ZX, выходит, не лучший
Прихожу без разрешения, сею смерть и разрушение...
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Ещё можно прогнать PNG-шки через http://optipng.sourceforge.net (с -o7)
Тут: http://optipng.sourceforge.net/pngtech/optipng.html как он работает и ссылки на аналоги.
optipng (из bmp, из уже готового png результат почему-то хуже)
мотоциклы: 3877
город: 4577
всё еще слабей чем LC
Прихожу без разрешения, сею смерть и разрушение...
Я тупо открыл 16-цветную финальную картинку Barbarian.png и сохранил. Она 32 бита оказалась.Затем пересохранил её в XnView — она стала 24 бита (цветность специально не уменьшал). Итого:
4 бита — 4661
32 бита — 9893
24 бита — 7079
Сейчас открыл в Paint ч/б Clive.png и сохранил. Она снова 32 бита стала. Если ручками в свойствах Paint выбрать ч/б, то ч/б и сохранит со вполне неплохим результатом:
1 бит оригинал — 3122
1 бит Paint — 3183
32 бита — 8700
24 бита — 6059
Согласен.для ZX, выходит, не лучший
В правильно заданном вопросе содержится половина ответа
у меня если такое проделать, то размер увеличится по сравнению с цветным png
причём созданные раньше именно моим пайнтом - увеличиваются ровно на 21 байт))
2636 = Clive LC5.2.1
2425 ~ Clive Lgk
Прихожу без разрешения, сею смерть и разрушение...
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием
