Какие еще параметры я могу попытаться сжать это изображение PNG?

-2

Я написал программу для без потерь перекомпоновки файлов PNG. Поскольку, к сожалению, нет единственного параметра, который гарантирует это оптимально, я просто проверяю все (время вычисления не является объектом, и в любом случае не является необоснованным).Какие еще параметры я могу попытаться сжать это изображение PNG?

Конкретно, есть:

10 уровней сжатия ZLib переходить в png_set_compression_level (от 0 до 9)
5 стратегий ZLib перейти в png_set_compression_strategy (системы, фильтруют Хаффмана только, RLE , и статический huffman)
Чередование (2 значения)
Букет из различных префильтров для передачи в png_set_filter. Я использую PNG_ALL_FILTERS, чтобы проверить их все.

Так что мой код в основном сжимает все возможные комбинации (10 * 5 * 2 = 100) и выбирает тот, который имеет самый низкий размер.

Это прекрасно работает для широкого круга типичных изображений. Для некоторых изображений сокращение может составлять до 20% (хотя более типично 5%). Напр. изображения-тяжелые веб-сайты, это заметно.

Вот PNG изображения (link to original):

Вот тестовое изображение. Он занимает точно 144,391 байт. Моя стратегия best effort составляет 145,501 байт.

Я обеспокоен не столько тем, что это на 0,77% больше. Меня беспокоит, что Я проверил все параметры, и один из них должен был быть оптимальным. Итак, это Can't Happen.

Так что мой вопрос: что происходит? Какие параметры мне не хватает? Я не видел ничего в документации.

источник

2016-01-11 imallett

Почему это не может случиться? Вы не знаете, сжалось ли ваше исходное изображение с помощью того же программного обеспечения, которое вы используете. – pvg

@pvg На самом деле, я знаю, что версии zlib и libpng, которые использует программа сохранения, такие же, как те, которые я использую. – imallett

Я полагаю, вы можете попробовать один из доступных бесплатных оптимизаторов png и посмотреть, что они придумали. Если он меньше, то кажется разумным предположить, что вы упустили что-то в этой дикой гусиной погоне. – pvg

Рассматривая источник OptiPNG, я обнаружил, что:

Zlib параметр использование памяти (передается косвенно от png_set_compression_mem_level) также влияет на степень сжатия. Это, несмотря на то, что говорит documentation. У меня нет объяснений, и думаю, что это плохая вещь.

Когда я установил это на 8 (по умолчанию) вместо 9, я использовал, я смог воспроизвести исходное изображение.
Параметр фильтра (до png_set_filter) имеет значение. Этот сорт имеет смысл; выбор оптимального фильтра для определенной строки не обязательно означает глобально оптимальное сжатие (поскольку эта строка может сжиматься с соседними строками). Это полная догадка, поскольку ничто из этого не появляется в документации.

Когда я оптимизирую эти значения, я получаю изображение размером 140 541 байт, что представляется оптимальным.

источник

2016-01-11 19:40:25 imallett

Качество? Это должно быть ошибкой. Сжатие PNG без потерь. –

@MarkAdler В контексте (особенно без потерь) сжатия _quality_ ссылается на способность алгоритма получить высокий коэффициент сжатия. _lossiness_ означает потерю информации. Но это было определенно неясно; Я редактировал. – imallett

А, ок. Связанная документация не говорит о том, что уровень памяти _won't_ влияет на уровень сжатия. Я не знаю, что вы подразумеваете под «это плохая вещь». –

Вы можете попробовать recompressing with zopfli, чтобы получить лучший выигрыш над лучшим сжатием zlib.

источник

2016-01-11 21:25:12

Какие еще параметры я могу попытаться сжать это изображение PNG?

ответ

Смежные вопросы