Простейший способ подсчитать кол-во пикселей разных цветов

[updates-bot]

Обсуждение статьи "Простейший способ подсчитать количество пикселей определенного цвета в изображении"

http://gis-lab.info/qa/im-countpixels.html

[Александр Мурый]

Дополню: в ImageMagick отличная документация с примерами. А вот страница с полезными bash-скриптами на основе IM (правда, только для Unix-систем).

[udav]

Для таких картинок, наверно, еще можно в Photoshop'е выбрать Image \ Histogram, для индексированной картинки каждый пиксел должен иметь свою яркость, отражаться отдельным столбиком в гистограмме, а по нему там показывается отдельная статистика.

[Denis Rykov]

Процент черного 69.35218% или все-таки белого?

[Максим Дубинин]

_DR_, ой

udav, да, в фотошопе можно тоже, но я не знал есть ли у автора вопроса фотошоп.

[Александр Мурый]

IMHO, "простейший способ" не предполагает наличие очень небесплатного (на самом деле) фотошопа. Подобное можно выполнить и в любом другом нормальном растровом редакторе типа GIMP, а при более или менее частой работе с растрами ImageMagick -- это выход, особенно при массовой обработке.

[Boris]

На счет того, что пакет решил задачу, как описано, сомнений нет. Но тот, кто назвал его документацию отличной, сильно погорячился. Наверное она отлична от GDAL, где описаний вообще не богато, а все желающие приглашаются сразу же в описание API функций.
Такого путанного документа, равно как и пакета, явно созданного для чего-то другого, чем такие мелочи как растры из ГИС, я давно не видел. Параметры разбросаны по нескольким страницам, описание параметров создано по принципу "очевидно, что ...". Примеры к параметрам имеют очень косвенное отношение, а идут в порядке осознания или решения проблем, которые автору удалось победить.
Растровые операции богато задуманы, плохо описаны и отвратительно реализованы. Что бы простейшая операция сложения двух монохромных растров выполнялась в компилированной программе в 10 раз дольше, чем точно такая же в интерпретаторе с вызовом GDAL? А на 6 вообще не смогла закончиться? При том, что GDAL складывал расты в 256 цветов, попутно вычисляя на них логическую функцию, а этот складывал растры уже приведенные к двум цветам.
И это единственная программа, на моей современной памяти, которая стабильно, т.е без вариантов, в процессе вычислений забирала 100% у всех 4-х ядер процессоров.

[Александр Мурый]

Такого путанного документа, равно как и пакета, явно созданного для чего-то другого, чем такие мелочи как растры из ГИС, я давно не видел.

IM не создавался для работы с "тяжёлыми" растрами (те самые "мелочи" размером в тыщи на тыщи пикселей, к-е характерны для ГИС/данных ДЗЗ). Главная его задача --- массовая обработка относительно небольших изображений.

Растровые операции богато задуманы, плохо описаны и отвратительно реализованы. Что бы простейшая операция сложения двух монохромных растров выполнялась в компилированной программе в 10 раз дольше, чем точно такая же в интерпретаторе с вызовом GDAL? А на 6 вообще не смогла закончиться?

Да, у IM есть определённые проблемы с производительностью, это не секрет. В частности, из-за этого когда-то был создан форк IM --- GraphicsMagick, можете попробовать,а заодно и сравнить их. В основном они совместимы, в GM нет самых новых функций IM.

Как вариант: это open source, так что если хотите мощную и одновременно быструю программу и знаете чем помочь -- помогите себе и автору, допишите/перепишите/скомпилируйте "под себя".

P.S. вон в Scanex (насколько я знаю) как-то используют IM и не жалуются (по крайней мере здесь )