Форумы GIS-Lab.info

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

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

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

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

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

_DR_, ой

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

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

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

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

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

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

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

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

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