Как размер чересстрочного.png файла может быть меньше исходного файла?

Question

Итак, я попытался использовать команду imagemagick:

"convert picA.png -interlace line picB.png" 

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

Так что мне просто интересно, почему это происходит? Я действительно не хочу, чтобы мое новое изображение теряло качество из-за команды.

Кроме того, есть ли проблема совместимости с чересстрочным изображением.png?

РЕДАКТИРОВАТЬ: я думаю, моя проблема в том, что исходное изображение не было сжато так хорошо, как могло бы быть.

Answer 1

Следующее применимо только к случаям, когда размер пикселя составляет>= 8 бит. Я не расследовал другие случаи, но ожидаю аналогичных результатов.

Файл изображения в формате PNG с чересстрочной разверткой почти всегда будет больше из-за дополнительных данных для описаний типов фильтров, необходимых для обработки проходных строк сканирования. Это то, что я подробно объяснил на этой веб-странице на основе PNG RFC RFC2083. Короче говоря, это происходит потому, что сумма приведенного ниже количества байтов для описания типов чересстрочных фильтров за один проход чередования почти всегда превышает высоту изображения (которая является числом типов фильтров для не чересстрочных изображений):

nb_pass1_lines = CEIL(height/8)

nb_pass2_lines = (width>4?CEIL(height/8):0)

nb_pass3_lines = CEIL((height-4)/8)

nb_pass4_lines = (width>2?CEIL(height/4):0)

nb_pass5_lines = CEIL((height-2)/4)

nb_pass6_lines = (width>1?CEIL(height/2):0)

nb_pass7_lines = FLOOR(height/2)

Хотя теоретически может случиться так, что энтропия / сложность данных случайно будет достаточно снижена при чередовании Adam7, так что с помощью фильтрации обычно дополнительное пространство, необходимое для типов фильтров с чередованием, может быть компенсировано с помощью сжатия по дефляту, используемого для Формат PNG. Это было бы частным случаем, который нужно доказать, поскольку энтропия / сложность более вероятно возрастут с чередованием, потому что данные изображения становятся менее согласованными благодаря деконструкции чередования.

Я использовал слово "случайно", потому что уменьшение энтропии / сложности данных не является целью чересстрочной развертки Adam7. Его цель - обеспечить прогрессивную загрузку и отображение изображения через механизм пропусков. Хотя снижение энтропии / сложности является целью фильтрации для PNG.

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

Когда дело доходит до размера файла PNG, меньший размер для чересстрочной развертки может быть из-за:

1. Различный контент, не связанный с пиксельным кодированием, встроенный в файл, такой как палитра (в случае типа цвета =! 3) и некритические фрагменты, такие как цветность, гамма, количество значащих битов, цвет фона по умолчанию, гистограмма, прозрачность, физический размеры в пикселях, время, текст, сжатый текст. Обратите внимание, что некоторые из содержимого, не связанного с пиксельным кодированием, могут приводить к различному отображению изображения в зависимости от используемого программного обеспечения и ситуации.
2. Различный контент, связанный с кодированием пикселей (который может изменить качество изображения), такой как глубина в битах, тип цвета (и, следовательно, использование палитры или нет с типом цвета = 3), размер изображения,... .
3. Различный контент, связанный со сжатием, такой как лучший выбор фильтрации, случайная меньшая энтропия / сложность данных из-за чередования, как описано выше (частный теоретический случай), более высокий уровень сжатия (как вы упомянули)

Если бы мне нужно было проверить, эквивалентны ли 2 файла изображений PNG пикселям, я бы использовал следующую команду в приглашении bash:

diff <( convert non-interlaced.png rgba:- ) <( convert interlaced.png rgba:- )

Это должно вернуть без разницы.

Что касается вопроса совместимости, если кодер PNG и декодер PNG реализуют обязательные аспекты PNG RFC, я не вижу причин для чередования, которое могло бы привести к проблеме совместимости.

Изменить 2018 11 13:

Некоторые эксперименты, основанные на автоматически эволюционирующих распределенных генетических алгоритмах с нишевым механизмом (размещен на https://en.oga.jod.li/), объясняются здесь: https://jod.li/2018/11/13/can-an-interlaced -png-изображение-быть меньше, чем заместитель эквивалентной нечересстрочное-изображение /

Эти эксперименты показывают, что эквивалентные изображения PNG могут иметь меньший размер чересстрочного, чем не чересстрочного. Лучшие изображения для этого являются высокими, они имеют ширину в один пиксель и имеют пиксельное содержимое, которое выглядит случайным. Хотя форма не является единственным важным аспектом для чересстрочного изображения, которое должно быть меньше не чересстрочного изображения, поскольку случайные случаи с одинаковой формой приводят к разным размерам размеров.

Итак, да, некоторые PNG-изображения могут быть идентичными по пикселям и для непиксельного контента, но иметь меньший размер чересстрочного, чем не чересстрочного.

Answer 2

Так что мне просто интересно, почему это происходит?

Из раздела Чересстрочная развертка и проходное извлечение спецификаций PNG.

Сканирующие строки, которые не полностью заполняют целое число байтов, дополняются, как определено в 7.2: Сканирующие строки.

ПРИМЕЧАНИЕ. Если эталонное изображение содержит менее пяти столбцов или менее пяти строк, некоторые проходы будут пустыми.

Я предполагаю, что поведение, которое вы испытываете, является результатом метода Adam7, требующего дополнительного заполнения.