На самом деле правильнее было бы назвать «машинное зрение», но так я думаю понятнее будет, если кто не знает то это не охранное видеонаблюдение, а распознавание или измерение чего либо c помощью камер. Существует много задач и областей, где компьютерное зрение было бы очень востребовано и могло бы использоваться повсеместно, но на практике оно используется очень редко.
Я реализовал несколько проектов в этой области для решения разных задач, конкретно это вычисление и подсчет площадей, контроль качества продукции, причем разной и в разных отраслях таких как: фигурная порезка и раскрой листов ДСП, ДВП, МДФ, измерение площадей шкурок животных на производства изделий из кожи и др.
Задача вычисления площади может показаться довольно сложной. Если подходить строго математически, то да, например, посчитать площадь квадрата или прямоугольника очень просто умножаем длину на ширину и готово, если треугольника чуть сложнее, а вот других криволинейных фигур может быть очень сложно.
Мой алгоритм подсчета площади настолько прост, что его можно реализовать без всяких библиотек и т.п. буквально в десять строк кода, по сути это простейший детектор движения только с калибровкой камеры. Камера жестко фиксируется над местом, куда подается продукция, делается снимок фона (без продукции), например, белый стол, цвета пикселей загоняются в массив. Далее на стол подается или кладется образец, например какая-то коробка. Далее делается второй снимок с коробкой, цвета второго кадра пишутся в другой массив и затем сравниваются значения цветов, количество отличающихся пикселей суммируется. Затем этот образец измеряется рулеткой, вводится в программу его площадь и вычисляется площадь одного пикселя, т.е. площадь делится на число пикселей. Вот и вся калибровка. Далее достаточно подавать любую продукцию, любого размера и формы, определятся число изменившихся пикселей, и умножается на площадь одного пикселя, найденного при калибровке, надеюсь все понятно. Причем продукция может двигаться, например, на конвейере, площадь будет измеряться правильно, нужно только захват кадров откалибровать на движение, т.е. пропускать несколько кадров в которых есть изменения пикселей по краям камеры по направлению движения, чтобы не захватывалась продукция при входе и выходе из кадра.
Этот алгоритм 100% работает и проверен на практике. Конечно, есть несколько моментов типа фильтрации оптического шума, освещения и др. сильно влияющие на погрешность измерений, но все это успешно решается, как программно (авто-коррекция коэффициентов цветов и др), так и аппаратно — камеры которые сразу могут фильтровать шумы, физически в условиях производства легко реализуется стабильное освещение в закрытой части где устанавливается камера.
На практике погрешность получается меньше 1% для неподвижной продукции и до 3% для подвижной.
Есть множество разработок, например Open CV (Open Computer Vision) кстати на Хабре есть пост про историю этой библиотеки, существует много систем распознавания образов, номеров, лиц и др., все это есть готовое и можно использовать.
А на практике очень мало используются решения с компьютерным зрением. Но что больше всего интересно так это то, что все эти задачи все равно решаются разными, но совсем другими, способами, с помощью другого оборудования, причем гораздо более дорогостоящего. Большая часть таких внедренных мной систем была установлена на предприятиях по причине выхода из строя этого оборудования для подсчета, дороговизны ремонта или приобретения нового. Я не видел это оборудования в действии, видел только количество датчиков, механики, электроники и т.д. По отзывам заказчиков, старые системы работали хуже, медленнее а некоторые даже с бОльшей погрешностью. Причем стоимость такого оборудования как минимум с 4-мя нулями в USD, при том, что система с «компьютерным зрением» на порядок дешевле, и стоит все полностью с компьютером, камерой и софтом меньше $1000 можно вложиться даже в $500 т.к. есть готовое решение. Большая мощность компьютера не нужна, будет работать без тормозов даже на самом дешевом нетбуке. Кроме площади можно определять цвета продукции, дефекты поверхности, брак/бой и многое другое.
Недавно прочитал на Хабре «Костыльный программист» о подходах программирования и особенно проектирования программных решений и хочу на этом примере рассказать о Костылях при реализации подобного проекта другой командой. Мне довелось пообщаться с программистами этой команды и я был сильно удивлен чего они там наворотили. Алгоритмы используются строго математические, куча сторонних библиотек, высшая математика, не говоря уже про ООП с сотнями классов и т.д. Для определения типов фигур, координат, положений и т.д. используют OpenCV (о которой я писал выше), а площадь вычисляется по сложным формулам, по сторонам, углам, кривизне и т.д. В результате продукт получился очень кривой, требует большой мощности компьютера и на практике очень плохо работает, нужны длительные и сложные настройки под конкретный тип продукции и много другое не говоря уже о погрешности, которая доходит до 10%. Про саму OpenCV я не хочу особо говорить, т.к. это отдельная тема, скажу только что многие вещи там очень плохо работали, во всяком случае раньше работали плохо или не работали вовсе, это было лет 5 назад, когда она еще была Интеловской, я думаю именно поэтому Intel от нее отказались и сбросили ее в Open Source. Но что меня больше всего поразило так это то, что некоторые программисты даже не допускают мысли, что решение может быть намного проще и надежнее. Это была небольшая фирма, но грешат этим и многие именитые компании, которые нанимают таких программистов.
В итоге многие проекты разваливаются, затягиваются сроки и самое худшее это то, что получаются кривые и глючные продукты. И очень часто, не потому что плохой код или программисты, а потому что плохие алгоритмы и плохой подход в проектировании изначально.
Я этот пример привел к тому что сейчас все больше программистов вместо того чтобы все упрощать – все усложняют, используют ООП, шаблоны проектирования и т.п. там где оно вообще никаким боком не нужно и тогда когда оно еще или вообще не нужно. Светлые головы настолько забиты категориями, объектами и классами, что многие просто уже не могут по другому думать. Абстракция нужна не для усложнения а для упрощения системы, в первую очередь чтобы упростить понимание и посмотреть с другой стороны. Другая проблема в том, что многие выбирают не те библиотеки и не те технологии. Особенно меня пугают программисты, которые начитавшись новомодных книжек, и посетив несколько семинаров по ООП считают себя профессионалами и начинают рассказывать, как нужно «правильно» делать и т.п., они могут строить огромные UML диаграммы, что-то моделировать, писать какие-то абстрактные(пустые) классы, без какого-либо функционала и т.д. при этом что-то реально работающее придумать и сделать не могут. Чаще всего такие люди как раз и есть самые настоящие «Костыльные программисты» которые порождают Костыльные проекты с Костыльной архитектурой, это примерно как «Астронавты Архитектуры» (Д. Спольски). Конечно, новичкам может показаться что это очень круто, и т.п. но это как правило не так, потому что большая часть таких проектов проваливается, в других случаях сильно расстягиваются, до тех пор пока заказчик готов платить за неработающий продукт, но в итоге все равно разваливается либо переписывается уже другой командой. Бывают конечно исключения и получаются хорошие продукты, бывает что виноват и плохой код, при хорошем алгоритме и инструментарии, но это бывает намного реже, по крайней мере в моей, не маленькой, практике, таких случаев было очень мало.
ООП не хотел бы затрагивать конечно, т.к. боюсь, что будет очень длинная и никому не нужная дискуссия, это отдельная тема, я во многом согласен с авторами этой знаменитой дискуссии: Почему объектно-ориентированное программирование провалилось. ООП и в частности ОО Проектирование сверху вниз, применимо только в очень больших и очень сложных проектах, но далеко не во всех, таких проектов реально очень мало. А проектирование в подавляющем большинстве случаев, нужно начинать снизу вверх, с базового функционала и базовых прототипов, т.к. после получения первых результатов все может в корне изменится, станет более понятна предметная область и суть задачи, не говоря уже про «баго-фичи» (многие хорошие технологии появились благодаря багам, которые впоследствии становились отличными «фичами»). И конечно самое главное выбрать правильный алгоритм решения поставленной задачи. Если проект очень сложный, и не укладывается в голове то в большинстве случаев ООП, UML и системы проектирования, моделирования и т.п. все равно скорее всего не решат проблему и не упростят ничего, а скорее даже усложнят. Поэтому для создания очень сложной, но реально работающей системы лучше разделять на несколько проектов, направлений или библиотек и минимизировать потоки обмена данными между всем этим хозяйством. Помните что все гениальное просто.
Я думаю что «Компьютерное зрение» мало используется на практике, потому что нет хороших отраслевых решений и хороших реализаций, которые можно было бы легко установить и настроить без помощи специалистов в этой области. А те, что есть – либо слишком дороги, либо не раскручены и о них мало кто знает.
Я реализовал несколько проектов в этой области для решения разных задач, конкретно это вычисление и подсчет площадей, контроль качества продукции, причем разной и в разных отраслях таких как: фигурная порезка и раскрой листов ДСП, ДВП, МДФ, измерение площадей шкурок животных на производства изделий из кожи и др.
Задача вычисления площади может показаться довольно сложной. Если подходить строго математически, то да, например, посчитать площадь квадрата или прямоугольника очень просто умножаем длину на ширину и готово, если треугольника чуть сложнее, а вот других криволинейных фигур может быть очень сложно.
Мой алгоритм подсчета площади настолько прост, что его можно реализовать без всяких библиотек и т.п. буквально в десять строк кода, по сути это простейший детектор движения только с калибровкой камеры. Камера жестко фиксируется над местом, куда подается продукция, делается снимок фона (без продукции), например, белый стол, цвета пикселей загоняются в массив. Далее на стол подается или кладется образец, например какая-то коробка. Далее делается второй снимок с коробкой, цвета второго кадра пишутся в другой массив и затем сравниваются значения цветов, количество отличающихся пикселей суммируется. Затем этот образец измеряется рулеткой, вводится в программу его площадь и вычисляется площадь одного пикселя, т.е. площадь делится на число пикселей. Вот и вся калибровка. Далее достаточно подавать любую продукцию, любого размера и формы, определятся число изменившихся пикселей, и умножается на площадь одного пикселя, найденного при калибровке, надеюсь все понятно. Причем продукция может двигаться, например, на конвейере, площадь будет измеряться правильно, нужно только захват кадров откалибровать на движение, т.е. пропускать несколько кадров в которых есть изменения пикселей по краям камеры по направлению движения, чтобы не захватывалась продукция при входе и выходе из кадра.
Этот алгоритм 100% работает и проверен на практике. Конечно, есть несколько моментов типа фильтрации оптического шума, освещения и др. сильно влияющие на погрешность измерений, но все это успешно решается, как программно (авто-коррекция коэффициентов цветов и др), так и аппаратно — камеры которые сразу могут фильтровать шумы, физически в условиях производства легко реализуется стабильное освещение в закрытой части где устанавливается камера.
На практике погрешность получается меньше 1% для неподвижной продукции и до 3% для подвижной.
Есть множество разработок, например Open CV (Open Computer Vision) кстати на Хабре есть пост про историю этой библиотеки, существует много систем распознавания образов, номеров, лиц и др., все это есть готовое и можно использовать.
А на практике очень мало используются решения с компьютерным зрением. Но что больше всего интересно так это то, что все эти задачи все равно решаются разными, но совсем другими, способами, с помощью другого оборудования, причем гораздо более дорогостоящего. Большая часть таких внедренных мной систем была установлена на предприятиях по причине выхода из строя этого оборудования для подсчета, дороговизны ремонта или приобретения нового. Я не видел это оборудования в действии, видел только количество датчиков, механики, электроники и т.д. По отзывам заказчиков, старые системы работали хуже, медленнее а некоторые даже с бОльшей погрешностью. Причем стоимость такого оборудования как минимум с 4-мя нулями в USD, при том, что система с «компьютерным зрением» на порядок дешевле, и стоит все полностью с компьютером, камерой и софтом меньше $1000 можно вложиться даже в $500 т.к. есть готовое решение. Большая мощность компьютера не нужна, будет работать без тормозов даже на самом дешевом нетбуке. Кроме площади можно определять цвета продукции, дефекты поверхности, брак/бой и многое другое.
Недавно прочитал на Хабре «Костыльный программист» о подходах программирования и особенно проектирования программных решений и хочу на этом примере рассказать о Костылях при реализации подобного проекта другой командой. Мне довелось пообщаться с программистами этой команды и я был сильно удивлен чего они там наворотили. Алгоритмы используются строго математические, куча сторонних библиотек, высшая математика, не говоря уже про ООП с сотнями классов и т.д. Для определения типов фигур, координат, положений и т.д. используют OpenCV (о которой я писал выше), а площадь вычисляется по сложным формулам, по сторонам, углам, кривизне и т.д. В результате продукт получился очень кривой, требует большой мощности компьютера и на практике очень плохо работает, нужны длительные и сложные настройки под конкретный тип продукции и много другое не говоря уже о погрешности, которая доходит до 10%. Про саму OpenCV я не хочу особо говорить, т.к. это отдельная тема, скажу только что многие вещи там очень плохо работали, во всяком случае раньше работали плохо или не работали вовсе, это было лет 5 назад, когда она еще была Интеловской, я думаю именно поэтому Intel от нее отказались и сбросили ее в Open Source. Но что меня больше всего поразило так это то, что некоторые программисты даже не допускают мысли, что решение может быть намного проще и надежнее. Это была небольшая фирма, но грешат этим и многие именитые компании, которые нанимают таких программистов.
В итоге многие проекты разваливаются, затягиваются сроки и самое худшее это то, что получаются кривые и глючные продукты. И очень часто, не потому что плохой код или программисты, а потому что плохие алгоритмы и плохой подход в проектировании изначально.
Я этот пример привел к тому что сейчас все больше программистов вместо того чтобы все упрощать – все усложняют, используют ООП, шаблоны проектирования и т.п. там где оно вообще никаким боком не нужно и тогда когда оно еще или вообще не нужно. Светлые головы настолько забиты категориями, объектами и классами, что многие просто уже не могут по другому думать. Абстракция нужна не для усложнения а для упрощения системы, в первую очередь чтобы упростить понимание и посмотреть с другой стороны. Другая проблема в том, что многие выбирают не те библиотеки и не те технологии. Особенно меня пугают программисты, которые начитавшись новомодных книжек, и посетив несколько семинаров по ООП считают себя профессионалами и начинают рассказывать, как нужно «правильно» делать и т.п., они могут строить огромные UML диаграммы, что-то моделировать, писать какие-то абстрактные(пустые) классы, без какого-либо функционала и т.д. при этом что-то реально работающее придумать и сделать не могут. Чаще всего такие люди как раз и есть самые настоящие «Костыльные программисты» которые порождают Костыльные проекты с Костыльной архитектурой, это примерно как «Астронавты Архитектуры» (Д. Спольски). Конечно, новичкам может показаться что это очень круто, и т.п. но это как правило не так, потому что большая часть таких проектов проваливается, в других случаях сильно расстягиваются, до тех пор пока заказчик готов платить за неработающий продукт, но в итоге все равно разваливается либо переписывается уже другой командой. Бывают конечно исключения и получаются хорошие продукты, бывает что виноват и плохой код, при хорошем алгоритме и инструментарии, но это бывает намного реже, по крайней мере в моей, не маленькой, практике, таких случаев было очень мало.
ООП не хотел бы затрагивать конечно, т.к. боюсь, что будет очень длинная и никому не нужная дискуссия, это отдельная тема, я во многом согласен с авторами этой знаменитой дискуссии: Почему объектно-ориентированное программирование провалилось. ООП и в частности ОО Проектирование сверху вниз, применимо только в очень больших и очень сложных проектах, но далеко не во всех, таких проектов реально очень мало. А проектирование в подавляющем большинстве случаев, нужно начинать снизу вверх, с базового функционала и базовых прототипов, т.к. после получения первых результатов все может в корне изменится, станет более понятна предметная область и суть задачи, не говоря уже про «баго-фичи» (многие хорошие технологии появились благодаря багам, которые впоследствии становились отличными «фичами»). И конечно самое главное выбрать правильный алгоритм решения поставленной задачи. Если проект очень сложный, и не укладывается в голове то в большинстве случаев ООП, UML и системы проектирования, моделирования и т.п. все равно скорее всего не решат проблему и не упростят ничего, а скорее даже усложнят. Поэтому для создания очень сложной, но реально работающей системы лучше разделять на несколько проектов, направлений или библиотек и минимизировать потоки обмена данными между всем этим хозяйством. Помните что все гениальное просто.
Я думаю что «Компьютерное зрение» мало используется на практике, потому что нет хороших отраслевых решений и хороших реализаций, которые можно было бы легко установить и настроить без помощи специалистов в этой области. А те, что есть – либо слишком дороги, либо не раскручены и о них мало кто знает.
