Комментарии 76
Полностью поддерживаю! Слишком часто многие, не осознав самой задачи, не поняв что конкретно она должна решать, не уложив в голове ее понимание, начинают оперировать шаблонными схемами, паттернами, которые часто только усложняют всю конструкцию… В общем, зачот.
Наверное у вас не получается понять ООП… Для маленьких проектов да, можно и без него. Но вот в больших — гемор еще тот. Нет, не при разработке — а при поддержке и доработке функционала.
Почему не получается? Только его и использую больше десяти лет. Функциональщина как-то плохо укладывается в голове, хотя я и стараюсь. Я согласен с автором в целом, когда проблему можно решить нестандартным и одновременно простым образом. А вместо этого начинают привлекать тяжелую артиллерию. Я это хорошо понимаю, потому как сам этим частенько грешу.
А проектирование в подавляющем большинстве случаев, нужно начинать снизу вверх, с базового функционала и базовых прототипов,
Как это противоречит ООП? По-моему, наоборот ООП в таких случаях помогает. В том числе спрятать алгоритмы, и если выбраны неправильно, то поменять его не трогая больше в системе ничего. Например в вашей системе я сделал бы сходу три класса: ПредставлениеОбъекта, УстройствоПолученияПредставленияОбъекта и ВычислительПлощадиОбъекта. Сделал бы два метода-заглушки УстройствоПолученияПредставленияОбъекта:: ПолучитьПредставлениеОбъекта и ВычислительПлощадиОбъекта:: ВычислитьПлощадьОбъекта. Всё, можно рисовать GUI и показывать заказчику :) А пока он думает, где шрифт сделать побольше, а фон посинее, можно начинать думать о конкретных реализациях. Причём они будут максимально отделены друг от друга.
Как это противоречит ООП? По-моему, наоборот ООП в таких случаях помогает. В том числе спрятать алгоритмы, и если выбраны неправильно, то поменять его не трогая больше в системе ничего. Например в вашей системе я сделал бы сходу три класса: ПредставлениеОбъекта, УстройствоПолученияПредставленияОбъекта и ВычислительПлощадиОбъекта. Сделал бы два метода-заглушки УстройствоПолученияПредставленияОбъекта:: ПолучитьПредставлениеОбъекта и ВычислительПлощадиОбъекта:: ВычислитьПлощадьОбъекта. Всё, можно рисовать GUI и показывать заказчику :) А пока он думает, где шрифт сделать побольше, а фон посинее, можно начинать думать о конкретных реализациях. Причём они будут максимально отделены друг от друга.
Понял, кажется, ваши претензии к ООП. Вы о тех архитекторах которые бы уже к этой простейшей модели начали накручивать фабрики устройств, репозитории объектов, стратегии вычисления, да ещё бы заранее озаботились о том, что может потребоваться вычислять не только площадь, но и периметр, вес и период полураспада, потом связали бы это всё трехсторонним мостом. Да?
да, и это тоже. Если делать эту систему с использованием ООП то все равно нужно сначала реализовать алгоритм без ООП, посмотреть какие параметры функции можно сгруппировать, обычно это сразу видно и они аж сами просятся, и потом только их вынести в класс, обычно это делается когда все уже четко работает, для упрощения понимания, дальнейшей работы и сопровождения.
Абстрагирую вот так сначала что-то сотвори, а потом уже «разделяй и властвуй». А когда еще ничего нет лучше этого не делать.
Да можно конечно сделать сразу классы и т.д. и сразу угадать что все будет именно так, что мало вероятно но бывает, только в простеньких проектах, и когда делают это очень и очень опытные программисты, имеющие очень большой опыт при работе с конкретной задачей, в этом случае как раз и применяют шаблоны проектирования сверху вниз.
А вот когда это не так и функциональный код пытаются подогнать под структуру проекта(классов) и т.п. вот это уже скорее и есть то зло о котором я писал.
Абстрагирую вот так сначала что-то сотвори, а потом уже «разделяй и властвуй». А когда еще ничего нет лучше этого не делать.
Да можно конечно сделать сразу классы и т.д. и сразу угадать что все будет именно так, что мало вероятно но бывает, только в простеньких проектах, и когда делают это очень и очень опытные программисты, имеющие очень большой опыт при работе с конкретной задачей, в этом случае как раз и применяют шаблоны проектирования сверху вниз.
А вот когда это не так и функциональный код пытаются подогнать под структуру проекта(классов) и т.п. вот это уже скорее и есть то зло о котором я писал.
Прямо сейчас моей основной обзанностью является «разделять и властвовать» над тем, что до меня «сотворили» — есть параметры, а есть глобальные переменные, в основном используются функции, но встречаются и объекты, причём с минимум тремя областями ответственности самый простой из них, причём часть из них глобальные, а часть передаются функциями. Сложновато разделять такую путаницу, чтоб потом властвовать.
Это напоминает подход «Стрельба трассирующими», описанный в книге Программист-прагматик.
Смысл в том, чтобы как можно раньше создать работающий скелет (или прототип) программы и посмотреть как оно будет работать, то есть получить обратную связь и узнать ньюансы еще на ранних стадиях проекта.
И еще есть понятие преждевременного обобщения, которое нарушает принципы KISS и YAGNI.
Смысл в том, чтобы как можно раньше создать работающий скелет (или прототип) программы и посмотреть как оно будет работать, то есть получить обратную связь и узнать ньюансы еще на ранних стадиях проекта.
И еще есть понятие преждевременного обобщения, которое нарушает принципы KISS и YAGNI.
В принципе это не противоречит ООП, просто чаще всего его используют сверху вниз, вот как примерно Вы «сходу» 3 класса, в том числе ключевой алгоритм и т.д. при этом не имея еще никакого понятия, как будет работать алгоритм, какие параметры, коэфициенты цветов, когда их нужно корректировать и т.п. В том то и дело что в этой системе, как и в большинстве других подобных ООП в принципе не нужно, да можно коненчо и с ним, но все лучше сделать без единого класса и на чистом Си, даже код будет понятней и быстрее работать, т.к. эта система критична к скорости, потом можно даже вынести в отдельный модуль/библиотеку. Если вы не можете представить себе такое и сразу беретесь за классы — то я думаю это плохо, это то что я пытался донести в этом посте.
Раньше я тоже очень увлекался ООП и сходу клепал классы и т.д. но позже я с этим стал очень осторожен, а часто не использую вовсе, в зависимости от проекта.
Раньше я тоже очень увлекался ООП и сходу клепал классы и т.д. но позже я с этим стал очень осторожен, а часто не использую вовсе, в зависимости от проекта.
Я бы не назвал то, что я сделал проектированием сверху вниз. Минимальная декомпозиция задачи «вычислить площадь представленного объекта». Поставь мне такую задачу и требование «сверху вниз» я бы начала с основного окна приложения, основного цикла, возможные входные сигналы, процедуры их обработки и т. п. Подойдя непосредственно к алгоритмам хорошо если через неделю. А так я готов начинать думать об алгоритмах через 5 минут после начала «проектирования». Понятнее — субъективно, требование к скорости вы не озвучивали, да и не думаю, что объектная обвязка С++ окажется узким местом, если алгоритмы у нас будут +- одинаковы. А так, по сути, я последовал вашему совету «лучше разделять на несколько проектов, направлений или библиотек и минимизировать потоки обмена данными между всем этим хозяйством.» — три «глобальных» указателя в памяти на структуры и две функции, которые получают их попарно. Ну и пара функции (инициализации устройства и калибровки вычислителя) получают по одному. У вас сильно проще?
Если чисто по алгоритму у меня немного проще, если по системе то намного сложнее. Больше всего кода на обработку картинки, фильтрацию шума, и корректировки цветов, в зависимости от освещения и и т.д.
Если не работали с обработкой изображений, особенно с видео (25 кадров в секунду) то сразу так может быть трудно понять, много тонкостей, а описывать подробно все очень долго тут. Если коротко то очень много параметров нужно учитывать и даже определить изменения пикселя не так просто как кажется, многое зависит от самой камеры, от разрешения, от платы захвата видео и типа и кодирования сигнала, а в статье я все упрощенно написал конечно.
Если не работали с обработкой изображений, особенно с видео (25 кадров в секунду) то сразу так может быть трудно понять, много тонкостей, а описывать подробно все очень долго тут. Если коротко то очень много параметров нужно учитывать и даже определить изменения пикселя не так просто как кажется, многое зависит от самой камеры, от разрешения, от платы захвата видео и типа и кодирования сигнала, а в статье я все упрощенно написал конечно.
Ну как, очень мало. Скорее — редко, но метко. Например, «Паркон» мне уже 9 штрафов выписал :D
Поддерживаю: машинное зрение действительно недостаточно широко используется. Недавно следил за баталиями на форуме фрилансеров в области электроники. Заказчик хотел оснастить выставочный стенд системой, которая при появлении людей перед стендом выдавала бы на презентационный комп координаты, стобы в презентации использовать эти движущиеся объекты как-то.
Начали с ультразвуковых датчиков как парктроники у автомобилей. Предлагали расставить их 5-10 штук в ряд и отслеживать… Массу еще чего интересного наворотили. Заказчики периодически выдавали перлы типы «с помощью креатива ваше решение на 30 тыс. долларов наверняка можно снизить до 500 долл.)
Затем на десятый день дискуссии какой-то чел предложил написать на OpenCV с распознаванием лиц такую прогу за 500 баксов. Начался дикий вой: „Заказчик требовал обнаруживать ЧЕЛОВЕКА, а вы предлагаете FACE DETECTOR! Так не честно!!! А-А-А!!!!!“
Естественно, вариант с распознаванием лиц самый экономичный, не требует никакого нестандартного железа кроме дешевой веб-камеры и USB-входа… Но реакция „профессионалов“ была поражающей.
Начали с ультразвуковых датчиков как парктроники у автомобилей. Предлагали расставить их 5-10 штук в ряд и отслеживать… Массу еще чего интересного наворотили. Заказчики периодически выдавали перлы типы «с помощью креатива ваше решение на 30 тыс. долларов наверняка можно снизить до 500 долл.)
Затем на десятый день дискуссии какой-то чел предложил написать на OpenCV с распознаванием лиц такую прогу за 500 баксов. Начался дикий вой: „Заказчик требовал обнаруживать ЧЕЛОВЕКА, а вы предлагаете FACE DETECTOR! Так не честно!!! А-А-А!!!!!“
Естественно, вариант с распознаванием лиц самый экономичный, не требует никакого нестандартного железа кроме дешевой веб-камеры и USB-входа… Но реакция „профессионалов“ была поражающей.
Строго говоря одним детектором лиц тут не обойтись, но он плюс чуть-чуть алгоритмов из области детекции движений действительно сделают свое дело. Так что может не 500, но в пару тысяч уж точно можно уложить. Возможности комп. зрения для презентаций сейчас очень сильно недооценены
<Кстати>В openCV есть не только детектор лиц, но и детектор фигур людей. Из коробки.</Кстати>
Сравнение двух подходов очень напоминает эту байку:
Нужно было провести анализ струкуры материала образец разрезали, протравили, сфотографировали. Как обработать результаты? Несколько тысяч снимков, на которых нужно вычислить % чужеродных вкраплений. Американцы написали софт, который на отсканированной фотографии идентифицирует включения, считает их прощадь и формирует результат. Отсканировали эти снимки, сняли ВЦ на неделю. И тут узнают, что у наших все уже готово. Но они досчитали и получили свои результаты через неделю, которые отличались на доли процента. Как удалось русским? Они взвесили фотографии, из них вырезали ножницами участки с вкраплениями. А потом взвесили и сами «вкрапления»
да, где-то так, а если серьезно то в моем алгоритме площадь точнее вычисляется, т.к. она вычисляется абсолютно, а не математически. Если кто не знает посмотрите мат. часть:
Из WiKi "интегральное исчисление возникло из потребности создания общего метода нахождения площадей"
Если просто, то на самом деле площадь примерно как на картинке и вычисляется с помощью интегралов в общем случае для разных фигур.
Из WiKi "интегральное исчисление возникло из потребности создания общего метода нахождения площадей"
Если просто, то на самом деле площадь примерно как на картинке и вычисляется с помощью интегралов в общем случае для разных фигур.
Если кто не знает почитайте обязательно, там погрешность в самом методе вычисления, картинка выше из WiKi наглядно это иллюстрирует. Я не стал писать мат. часть в посте т.к. подумал что это многих бы утомило, для меня это понятно все, почему решил что все понятно написал, нужно было хоть этот рисунок вставить и ссылку.
А как на счет перспективных искажений?
Что-то я не увидел погрешности в методе вычисления. Если вы про «бесконечно малые приближения» при интегрировании, то они дают «бесконечно малые погрешности», которые при любом раскладе ниже разрешения камеры.
мы говорим не о теории, любые приближения подразумевают погрешность, а в моем алгоритме единственная возможная погрешность в разрешении камеры, т.е. входящих данных, но они для вычисления берутся с камеры такого же разрешения для любого метода и алгоритма. Не говоря уже о том чтобы брать бесконечно малые пределы интеграции на практике(это очень ресурсоемкая задача учитывая что обрабатывать нужно 25 кадров в секунду), поэтому на практике будет погрешность.
Да, разумеется.
Меня, правда, немного удивило то, что нет никакого «ранжирования» для переоценки вклада центральных пикселов по сравнению с теми, что находятся у границы изображения. Даже без этого погрешность получилась меньше 1%, чего обычно хватает с головой.
Меня, правда, немного удивило то, что нет никакого «ранжирования» для переоценки вклада центральных пикселов по сравнению с теми, что находятся у границы изображения. Даже без этого погрешность получилась меньше 1%, чего обычно хватает с головой.
Для вычисления объемов/площадей разной сложной фигни хорошо использовать метод монте-карло: реализуется элементарно, результаты дает с любой наперед заданной точностью. В случае работы с изображениями конечно удобнее считать пиксели, но если был какой-то процессинг с выделением и обработкой контуров — то можно использовать монте-карло. А вот интегрировать контуры, полученные путем снятия изображения с камеры — это полный приезд…
>на стол подается или ложится образец
Ну кладется же, е мое!
Ну кладется же, е мое!
спасибо, исправил
Всё это, конечно, хорошо, но я как-то не уловил причинно-следственных связей между популярностью компьютерного зрения и проблемами проектировщиков. Чем CV в данном случае отличается от, скажем, разработки офисных программ? Вам не кажется, что здесь большую роль играет инфраструктура — та же необходимость закупать оборудование, малое количество готовых библиотек, всё ещё ранний этап развития области и т.д.?
А к кривизне рук конкретных разработчиков компьютерное зрение ортогонально. Тот же OpenCV 2 c C++ интерфейсом — это вполне неплохой пример красиво спроектированной архитектуры.
А к кривизне рук конкретных разработчиков компьютерное зрение ортогонально. Тот же OpenCV 2 c C++ интерфейсом — это вполне неплохой пример красиво спроектированной архитектуры.
да, скорее больше ранний этап развития области, хотя он наверно не такой уже и ранний, например биометрия используется намного больше, хотя появилась чуть позже.
Тут наверно не столько кривизна рук конкретных разработчиков, сколько кривизна мозгов и подходе в общем, во всяком случае в рамках этого примера, я думаю подобных примеров у многих есть, так что этот пример не редкость вообще, а в этой области в частности, учитывая что в этом направлении не так уж много разработчиков работает, на сколько я знаю их всего несколько десятков, и вполне возможно что просто нет удачных решений еще. Инфраструктура возможно тоже играет роль.
Тот же openCV, как я писал, была гораздо хуже, с последней версией я еще пока не работал, так что ничего не могу сказать пока, но я просматривал код, в общем конечно лучше намного, но на практике еще не пробовал.
Еще такой момент, что на этом заработать сложновато, даже просто убедить заказчика попробовать готовое решение не так просто и особого смысла развивать это направление я пока не вижу, поэтому больше занимаюсь биометрией и другими проектами.
В любом случае для меня это все еще вопрос без ответа. Я надеюсь больше на Google когда они свои автопилоты запустят в серийные авто и откроют код, вот это я думаю и будет рывок.
Тут наверно не столько кривизна рук конкретных разработчиков, сколько кривизна мозгов и подходе в общем, во всяком случае в рамках этого примера, я думаю подобных примеров у многих есть, так что этот пример не редкость вообще, а в этой области в частности, учитывая что в этом направлении не так уж много разработчиков работает, на сколько я знаю их всего несколько десятков, и вполне возможно что просто нет удачных решений еще. Инфраструктура возможно тоже играет роль.
Тот же openCV, как я писал, была гораздо хуже, с последней версией я еще пока не работал, так что ничего не могу сказать пока, но я просматривал код, в общем конечно лучше намного, но на практике еще не пробовал.
Еще такой момент, что на этом заработать сложновато, даже просто убедить заказчика попробовать готовое решение не так просто и особого смысла развивать это направление я пока не вижу, поэтому больше занимаюсь биометрией и другими проектами.
В любом случае для меня это все еще вопрос без ответа. Я надеюсь больше на Google когда они свои автопилоты запустят в серийные авто и откроют код, вот это я думаю и будет рывок.
Таки людей, занимающихся компьютерным зрением, достаточно много, не знаю, почему вы решили, что их всего несколько десятков. Область ещё молода — алгоритмы проработаны только для отдельных задач, а библиотеки существуют ещё для меньшего их количества. Однако я не вижу корреляции между самим по себе комптьютерным зрением и кривостью решений. Примеры, которые вы привели, встречаются во всех областях computer science. Я не устану цитировать анекдот про «любое практическое применение» (#3 отсюда), но в то же время, ваше решение описанной проблемы — это скорее хак, чем полноценный алгоритм. Да, вполне удачный хак, но область его применения ограничена конкретной задачей. Другая команда использовала более формальный подход. Да, этот подход для конкретной задачи дал более плохой результат, но в то же время он, возможно, в будущем позволит превзойти ваш результат. А заодно его можно будет обобщить для более широкого круга задач. Поэтому я бы не сказал, что здесь дело в криворукости подхода — в общем и целом подход очень даже правильный: именно он позволяет области CV развиваться и создавать новые алгоритмы и новые возможности. И уж тем более применение на практике не зависит от формальности или математичности подхода.
По поводу убеждения заказчика. Маркетологи часто используют для демонстрации идей кривую S. Эту кривая показывает закон привыкания пользователей к новым технологиям. График можно разделить на 3 равные части по оси времени. В первой части (период созревания) технология медленно набирает популярность, не выходя по оси количества пользователей за 10%. Во второй части наблюдается резкий скачёк — это период бурной популяризации технологии, в который график достигает примерно 90% пользователей. Последняя часть отражает процесс стагнации — последние, самые закостенелые пользователи наконец-то принимают преимущества новой технологии и тоже постепенно начинают использовать её. Так было с мобильными телефонами, интернетом, микроволновыми печами, ещё раньше — с автомобилями, разделением труда и т.д. Сейчас можно наблюдать скачёк популярности мобильных устройств и других, более специфичных областей, таких как обработка естественных языков. Computer Vision сейчас находится на стадии созревания, поэтому, конечно, большая часть потенциальных пользователей будет с опаской смотреть на него. Но дело тут не в CV, а просто в природе мышления пользователей.
По поводу убеждения заказчика. Маркетологи часто используют для демонстрации идей кривую S. Эту кривая показывает закон привыкания пользователей к новым технологиям. График можно разделить на 3 равные части по оси времени. В первой части (период созревания) технология медленно набирает популярность, не выходя по оси количества пользователей за 10%. Во второй части наблюдается резкий скачёк — это период бурной популяризации технологии, в который график достигает примерно 90% пользователей. Последняя часть отражает процесс стагнации — последние, самые закостенелые пользователи наконец-то принимают преимущества новой технологии и тоже постепенно начинают использовать её. Так было с мобильными телефонами, интернетом, микроволновыми печами, ещё раньше — с автомобилями, разделением труда и т.д. Сейчас можно наблюдать скачёк популярности мобильных устройств и других, более специфичных областей, таких как обработка естественных языков. Computer Vision сейчас находится на стадии созревания, поэтому, конечно, большая часть потенциальных пользователей будет с опаской смотреть на него. Но дело тут не в CV, а просто в природе мышления пользователей.
Я имел ввиду разработчики — компании, которые выпустили что-то реально работающее, а людей интересующихся конечно больше. Не думаю что это «хак». Это как раз полноценный и правильный алгоритм для решения конкретной задачи, и именно для этой задачи он предназначен изначально. Для других задач лучше делать другие хорошие алгоритмы. Сделать универсальный алгоритм для решения «широкого круга задач» — практически не реально. Думаю что и в будущем ни один другой алгоритм не сможет превзойти этот, потому что как я выше писал про мат.часть, — площадь вычисляется абсолютно, без каких либо искажений, приближений и погрешностей самого вычисления т.е. при идеальных условиях будет абсолютно точная площадь.
На счет убеждения заказчиков согласен, вот только стадия созревания слишком затянулась.
На счет убеждения заказчиков согласен, вот только стадия созревания слишком затянулась.
Почему же, это вполне себе хак — an inelegant but effective solution to a computing problem. И именно для конкретной задачи. Достаточно изменить одно условие (например, возможность снимать фон без предмета или стабильность этого фона), чтобы всё решение свалилось. В то же время более сложные модели могут оказаться устойчивыми к таким изменениям.
Насчёт универсальных алгоритмов тоже не соглашусь — вспомните хотя бы, сколько практических применений есть у алгоритмов распознавания образов.
Что же касается долгой стадии созревания, то мне кажется, что вот-вот должен начаться скачёк — крупные компании, такие как Google и Facebook уже активно используют алгоритмы компьютерного зрения, а бум стартапов содействует появлению большого количества новых идей, связанных с интеллектуальной обработкой видео.
Насчёт универсальных алгоритмов тоже не соглашусь — вспомните хотя бы, сколько практических применений есть у алгоритмов распознавания образов.
Что же касается долгой стадии созревания, то мне кажется, что вот-вот должен начаться скачёк — крупные компании, такие как Google и Facebook уже активно используют алгоритмы компьютерного зрения, а бум стартапов содействует появлению большого количества новых идей, связанных с интеллектуальной обработкой видео.
Ну это не тот случай, вы или не понимаете что такое «хак»или не понимаете как работает алгоритм или не знаете мат.часть. посмотрите внимательно ссылку выше там где картинка в моем комментарии.
Если снимать фон без предмета будет правильно показывать ноль, стабильность фона тоже, т.к. цвета корректируются по очень многим параметрам, и никакие «более сложные модели» не окажутся устойчивыми «к таким изменениям». И главное отличие от хака, в том что точность будет выше при любых раскладах т.к. это идеальный алгоритм для определения площади по изображению с камеры.
В этом алгоритме тоже очень много практических применений, в разных отраслях и типах объектов измерения, возможно отраслей даже больше чем в распознавании образов.
На счет Google я тоже надеюсь что ждать осталось недолго.
Если снимать фон без предмета будет правильно показывать ноль, стабильность фона тоже, т.к. цвета корректируются по очень многим параметрам, и никакие «более сложные модели» не окажутся устойчивыми «к таким изменениям». И главное отличие от хака, в том что точность будет выше при любых раскладах т.к. это идеальный алгоритм для определения площади по изображению с камеры.
В этом алгоритме тоже очень много практических применений, в разных отраслях и типах объектов измерения, возможно отраслей даже больше чем в распознавании образов.
На счет Google я тоже надеюсь что ждать осталось недолго.
И вот как раз под тем комментарием вам приводят пример с перспективными искажениями. Да, конкретно в случае, для которого писалась прогарамма, оно вносит небольшую пограшность. А как адаптировать ваш метод для более «объёмного» продукта и камеры, находящейся к нему под углом? А что, если сцена динамически меняется, например, если мы отслеживаем не товары на конвеере, а картеж хаммеров в ираке со спутниковых снимков? Рано или поздно вы поймёте ограничения своей модели и придёте либо к чему-то вроде eigenfaces, либо к моделям формы, либо вообще к 3D реконструкции. Возможно, ребята из другой компании как раз и пытались сделать что-то подобное?
это же совершенно разные задачи… если так подходить, «а если камеру пальцем зактнуть» — включается подстветка и камера превращается в биометрический сканер, сканирует отпечаток, проводит идентификацию и связывается с ФБР, ну сами подумайте… не нужно за уши притягивать то чего нет.
Перспективные искажения есть в любой камере в данном случае они очень малы поэтому и не учитываются, к тому же калибровка частично учитывает и эти искажения.
Если будут такие задачи то конечно же я не будут использовать этот алгоритм, т.к. он для этого не предназначен.
А ребята из другой компании делали абсолютно тоже самое и провалили заказ, клиент вынужден был отказаться от ихнего решения, они пытались клиента убедить что лучшего результата достичь невозможно и т.п. после этого мне с большим трудом удалось уговорить клиента хотя бы посмотреть мое решение.
Перспективные искажения есть в любой камере в данном случае они очень малы поэтому и не учитываются, к тому же калибровка частично учитывает и эти искажения.
Если будут такие задачи то конечно же я не будут использовать этот алгоритм, т.к. он для этого не предназначен.
А ребята из другой компании делали абсолютно тоже самое и провалили заказ, клиент вынужден был отказаться от ихнего решения, они пытались клиента убедить что лучшего результата достичь невозможно и т.п. после этого мне с большим трудом удалось уговорить клиента хотя бы посмотреть мое решение.
Есть подозрение, что ребята из другой команды пытались построить как раз более общую модель, чтобы не переписывать всё с нуля, когда заказчик чуть-чуть изменит требования. Я хочу сказать, что более сложные математические модели — это не есть абсолютное зло, они действительно имеют право на жизнь и на практике используются довольно часто. То есть проблема overengineering-а не является присущей именно компьютерному зрению, а больше зависит от людей. Всё это возвращает нас к изначальному вопросу: как применимость CV на практике зависит от излишней сложности конкретных решений?
>> сложные математические модели — это не есть абсолютное зло, они действительно имеют право на жизнь и на практике используются довольно часто
Я полностью согласен, но всегда есть исключения и в этом случае это именно оно.
Даже математических способов решения задач бывает очень много и далеко не всегда выбираются самые лучшие или хотя бы простые. Обычно чем сложнее решение, тем оно менее надежно, и вероятность поломки или неправильной работы растет пропорционально сложности, это не только в программировании и компьютерах но и практически в любой технике чем больше узлов и деталей тем более вероятна ошибка или просчет.
А в CV еще более вероятно, потому что нужно правильно выбрать мат. модели, правильно скомпоновать все последовательности, очень много испытаний проводить не в лабораторных условиях. Не говоря уже о инструментах и проектировании.
И конечно же ни в коем случае не пытаться делать универсальных решений, типа как вы писали выше… это ошибочный, если хотите, — тупиковый путь, за универсальность как правило расплачиваются качеством, надежностью или чем-то другим. Это тоже, не только в компьютерах а в общем. Когда будут уже готовые, отточенные и хорошо работающие решения для разных задач, вот тогда можно при необходимости попробовать скомбинировать некоторые.
Это наиболее правильный подход подход и конечно же применим в общем случае для всего, а не только CV.
Я полностью согласен, но всегда есть исключения и в этом случае это именно оно.
Даже математических способов решения задач бывает очень много и далеко не всегда выбираются самые лучшие или хотя бы простые. Обычно чем сложнее решение, тем оно менее надежно, и вероятность поломки или неправильной работы растет пропорционально сложности, это не только в программировании и компьютерах но и практически в любой технике чем больше узлов и деталей тем более вероятна ошибка или просчет.
А в CV еще более вероятно, потому что нужно правильно выбрать мат. модели, правильно скомпоновать все последовательности, очень много испытаний проводить не в лабораторных условиях. Не говоря уже о инструментах и проектировании.
И конечно же ни в коем случае не пытаться делать универсальных решений, типа как вы писали выше… это ошибочный, если хотите, — тупиковый путь, за универсальность как правило расплачиваются качеством, надежностью или чем-то другим. Это тоже, не только в компьютерах а в общем. Когда будут уже готовые, отточенные и хорошо работающие решения для разных задач, вот тогда можно при необходимости попробовать скомбинировать некоторые.
Это наиболее правильный подход подход и конечно же применим в общем случае для всего, а не только CV.
Вот вообще не согласен с последней мыслью. Возьмём банальный пример: определение объектов на фото/видео.
Ваш подход. Пришло задание научиться определять, когда в комнату входит человек. Ваше решение: сделать снимок закрытой двери, если входной снимок отличается от снимка закрытой двери больше чем на n% — дверь открыта и в неё кто-то вошёл. Пришло следующее задание — распознавать текст, написанный разными шрифтами. Ваше решение: составить таблицу всех возможных шрифтов, сравнивать каждую букву попискельно. Ещё одно задание — научиться отличать человеческое лицо от баклажана. Ваше решение: калибровать камеру так, чтобы она точно смотрела в центра лица/баклажана и сравнивать цвета пикселей. При изменении условий задачи дополнить или полностью переписать алгоритм.
Мой подход. Задание — определять момент входа человека в комнату. Решение: создать ИНС, обучить её для классификации закрытой двери и открытой двери со входищим человеком. Задание — распознавать символы. Решение: взять созданную для прошлой задачи ИНС и обучить её для распознавания символов. Задание — научиться отличать человека от баклажана. Решение: не поверите, но взять ИНС и обучить её для задачи классификации объектов на людей и баклажаны. Алгоритм один, а решает сразу много задач, при этом начиная со второй задачи затраты времени на разработку практически равны нулю. И только если обобщённый алгоритм не дал достаточно хороших результатов, приходится придумывать дополнительные ad hoc решения. Дополнительный бонус обобщённых алгоритмов: они получают гораздо большее развитие, чем специализированные. Для примера. Одним из первых алгоритмов распознавания лиц был eigenfaces. Он был простым и малоэффективным, но всё-таки использовался относительно интенсивно. Затем из фундаметнальной области хааровских вейвлетов пришёл хааровский классификатор, который умел находить на фото лица с достаточно большой точностью. Однако и у него были свои недостатки, например, он ничего не говорил о контурах лица. Тогда на сцену вышли модели активных форм, которые эти контуры прекрасно ловили. Но точность была не 100%, поэтому можно было улучшать. И их улучшили, добавив элементы eigenfaces и создав модели активного образа (active appearance models). Каждая новая модель строилась на стеке предыдущих решений. В случае со специализированными алгоритмами это невозможно — они просто решают слишком узкую задачу.
Ваш подход. Пришло задание научиться определять, когда в комнату входит человек. Ваше решение: сделать снимок закрытой двери, если входной снимок отличается от снимка закрытой двери больше чем на n% — дверь открыта и в неё кто-то вошёл. Пришло следующее задание — распознавать текст, написанный разными шрифтами. Ваше решение: составить таблицу всех возможных шрифтов, сравнивать каждую букву попискельно. Ещё одно задание — научиться отличать человеческое лицо от баклажана. Ваше решение: калибровать камеру так, чтобы она точно смотрела в центра лица/баклажана и сравнивать цвета пикселей. При изменении условий задачи дополнить или полностью переписать алгоритм.
Мой подход. Задание — определять момент входа человека в комнату. Решение: создать ИНС, обучить её для классификации закрытой двери и открытой двери со входищим человеком. Задание — распознавать символы. Решение: взять созданную для прошлой задачи ИНС и обучить её для распознавания символов. Задание — научиться отличать человека от баклажана. Решение: не поверите, но взять ИНС и обучить её для задачи классификации объектов на людей и баклажаны. Алгоритм один, а решает сразу много задач, при этом начиная со второй задачи затраты времени на разработку практически равны нулю. И только если обобщённый алгоритм не дал достаточно хороших результатов, приходится придумывать дополнительные ad hoc решения. Дополнительный бонус обобщённых алгоритмов: они получают гораздо большее развитие, чем специализированные. Для примера. Одним из первых алгоритмов распознавания лиц был eigenfaces. Он был простым и малоэффективным, но всё-таки использовался относительно интенсивно. Затем из фундаметнальной области хааровских вейвлетов пришёл хааровский классификатор, который умел находить на фото лица с достаточно большой точностью. Однако и у него были свои недостатки, например, он ничего не говорил о контурах лица. Тогда на сцену вышли модели активных форм, которые эти контуры прекрасно ловили. Но точность была не 100%, поэтому можно было улучшать. И их улучшили, добавив элементы eigenfaces и создав модели активного образа (active appearance models). Каждая новая модель строилась на стеке предыдущих решений. В случае со специализированными алгоритмами это невозможно — они просто решают слишком узкую задачу.
с чего вы решили что это мой подход? я же нигде не писал что этот подход применим для всех задач, а наоборот акцентировал на том, что именно для этой конкретной задачи он самый лучший. Вы все время пытаетесь перевести на другие задачи этот алгоритм, предназначенный и отработанный исключительно для площади, я уже устал писать что этого делать не нужно.
Относительно метода с ИНС (нейронная сеть) для таких задач может неплохо работать для одних задач, и плохо для других, об «обучении» и нечеткой логике тут затевать спор я думаю не стоит, но даже если идеально подобрать все параметры и смоделировать сложную, гибридную ИНС для этой задачи, все равно не будет 100% надежного определения, а простой метод детекции пикселей с указанием зоны на камере, может работать лучше и быстрее и кстати на практике в охранном видеонаблюдении вполне нормально работает в помещениях в большинстве случаев.
Но я согласен что ИНС метод может работать в определенных условиях намного лучше чем простой детектор движения, я занимался таким детектором для охранки, в результате получилась намного меньше ложных сработок при детекции движения во время дождей, снега и др. и в темное время суток, намного лучше работает в ночном режиме при плохом освещении, когда камера дает много шума.
Относительно метода с ИНС (нейронная сеть) для таких задач может неплохо работать для одних задач, и плохо для других, об «обучении» и нечеткой логике тут затевать спор я думаю не стоит, но даже если идеально подобрать все параметры и смоделировать сложную, гибридную ИНС для этой задачи, все равно не будет 100% надежного определения, а простой метод детекции пикселей с указанием зоны на камере, может работать лучше и быстрее и кстати на практике в охранном видеонаблюдении вполне нормально работает в помещениях в большинстве случаев.
Но я согласен что ИНС метод может работать в определенных условиях намного лучше чем простой детектор движения, я занимался таким детектором для охранки, в результате получилась намного меньше ложных сработок при детекции движения во время дождей, снега и др. и в темное время суток, намного лучше работает в ночном режиме при плохом освещении, когда камера дает много шума.
Так наоборот же! Я как раз говорю, что вы для каждой задачи придумаете своё, отдельное решение, в то время как общепринятый (по крайней мере в научных работах) подход — это создать наиболее общие алгоритмы (возможные без сильной потери эффективности на данной задаче), чтобы в дальнейшем иметь возможность применять их для других задач. Если видели матрицу компетентности программиста от Гугля, то там выражена довольно интересная идея — применение оценки сложности алгоритмов к эффективности работы разработчика. Так вот, если применить эти оценки к вашему и общепринятому подходу, то получится, что ваш подход даёт линейную эффективность — O(n) — т.е. на каждую новую задачу вам придётся потратить столько же времени, сколько и на предыдущую, потому что вы всё время ищете ad hoc алгоритмы. Общепринятый же подход даёт амортизированную O(log n), т.е. каждая новая задача будет обходиться для вас «дешевле», чем предыдущая. В моём примере достаточно было создать ИНС один раз и затем просто применить её ко всем трём задачам.
Ну так задачи же совершенно разные, и нельзя, нет скорее невозможно придумать один алгоритм для решения всех задач с использованием камеры. Давайте абстрагируем так: даже если бы удалось придумать супер алгоритм с ИНС и возможностями приближенными к человеческим, все равно он не позволит с такой же точностью и легкостью вычислить площадь любой фигуры, но зато будет прекрасно определять открытие двери, фильтровать погоду и шумы камер.
Я этот пост написал для того чтобы задумались, может быть в этом и проблема, что CV до сих пор никак не выйдет на должный уровень, потому что возможно одна из причин есть «наиболее общие алгоритмы», которые на практике сильно теряют эффективность. Если оно никак не выходит из начинающей стадии, может стоит пересмотреть «общепринятый (по крайней мере в научных работах) подход». Научные работы нужно адаптировать к реалиям.
Я считал что проблема больше связана с подходами в программировании в общем и реализациями в этой области в частности, но если вы так усиленно доказываете что это плохо, то похоже она еще глубже.
Вот давайте так, «общепринятый» подход — хорошо, я не против него, он состоит из одного алгоритма? одной формулы? Нет, он включает в себя множество других алгоритмов, формул и методик и т.д. так вот эти отдельные алгоритмы тоже могут применяться в рамках реализации одной конкретной задачи отдельно, и одни хороши для одной задачи и совершенно не пригодны для другой.
>вы всё время ищете ad hoc алгоритмы
Конечно же я этого не делаю, я честно говоря очень удивлен, тем что вы все время искажаете все, например что я ищу, я применяю, причем «все время» и хуже всего что совершенно разные задачи пытаетесь свести вместе
Я этот пост написал для того чтобы задумались, может быть в этом и проблема, что CV до сих пор никак не выйдет на должный уровень, потому что возможно одна из причин есть «наиболее общие алгоритмы», которые на практике сильно теряют эффективность. Если оно никак не выходит из начинающей стадии, может стоит пересмотреть «общепринятый (по крайней мере в научных работах) подход». Научные работы нужно адаптировать к реалиям.
Я считал что проблема больше связана с подходами в программировании в общем и реализациями в этой области в частности, но если вы так усиленно доказываете что это плохо, то похоже она еще глубже.
Вот давайте так, «общепринятый» подход — хорошо, я не против него, он состоит из одного алгоритма? одной формулы? Нет, он включает в себя множество других алгоритмов, формул и методик и т.д. так вот эти отдельные алгоритмы тоже могут применяться в рамках реализации одной конкретной задачи отдельно, и одни хороши для одной задачи и совершенно не пригодны для другой.
>вы всё время ищете ad hoc алгоритмы
Конечно же я этого не делаю, я честно говоря очень удивлен, тем что вы все время искажаете все, например что я ищу, я применяю, причем «все время» и хуже всего что совершенно разные задачи пытаетесь свести вместе
Так, давайте разбираться. Общепринятый подход — это общая идея того, как нужно решать задачи. Обобщённые методы/алгоритмы — это алгоритмы, не заточенные на строго определённую задачу, но умеющие решать целый ряд проблем. Общепринятый подход сводится к тому, чтобы использовать известные или создавать новые обобщённые алгоритмы. Любой алгоритм является до определённой степени обобщённым. Однако вы делаете упор на то, что задачи слишком разные и для них нужно придумывать достаточно узкоспециализированные решения. Решение с подсчётом пикселей перестанет работать при изменении любого условия, и уж тем более не справится с задачами вроде определения объёма грузовиков в пустыне по снимкам из космоса. Честно говоря, я вообще не знаю, для чего ещё может хорошо работать алгоритм с подсчётом символов, особенно в жизненных ситуациях, а не в строго нормированных производственных помещениях. Я же делаю упор на то, что от любой конкретной задачи можно абстрагироваться и увидеть в ней что-то большее, и, соответственно, создать алгоритмы для решения более общих задач. Возьмите задачу «измерение площади товара» и уберите из него «товар», заменив его на более общее «объект». Вот вам и более общая задача. И если вы её сможете решить достаточно эффективно, то в будущем сэкономите целую кучу времени, а не будете изобретать по одному новому алгоритму в неделю.
Это касается не только CV. Вообще алгоритмы в computer science не создаются с бухты барахты — вначале любой порядочный алгоритмист проверяет, нельзя ли решить проблему с помощью одного из распространённых алгоритмов. И в 8 случаях из 10 это сделать возможно (поищите вопросы по тегу algorithm на StackOverflow — подавляющее большинство принятых ответов описывает решение с помощью одного из стандартных алгоритмов, причём решает без какой либо потери эффективности).
Я не хочу сказать, что специализированные решения — это плохо, но искать их следует только когда стандартные, обобщённые алгоритмы не дают нужного эффекта. Просто потому что нет смысла изобретать для каждой задачи свой алгоритм (или даже держать 2 сотни специализированных алгоритмов в голове), если можно выделить общие черты, общие принципы и отталкиваться от них.
Ваши ответы также, насколько я понимаю, подразумевают, что более общие алгоритмы не способны дать достаточную для продакшена точность. Однако, для каких именно задач, по-вашему, обобщённым алгоритмам не хватает точности, а специализированным было бы достаточно? Единственный пример с другой командой, которая не смогла с достаточной точностью определить размер товара, не показателен — как вам уже сказали выше, сам метод предполагает бесконечную точность. Если команда не смогла добиться этой точности или достаточного уровня оптимизации, то это уже инженерная проблема, а не проблема метода — им просто не хватило времени/ресурсов/мозгов. А можете привести примеры более распространённых задач (читать как: задачи, над которыми работала больше, чем одна группа разработчиков) и для которых сработали только узкоспециализированные алгоритмы, но не более общие? Распознавание символов — проблема давно решена с точностью фиг знает сколько процентов. Отслеживание движущихся предметов — тоже не проблема для современных алгоритмов. Определение эмоций на лице человека — вот как раз в последние годы эта задача активно решается, успехи уже очень неплохие. При этом создать с нуля, не опираясь на обобщённые методы, специализированный алгоритм для этих задач практически невозможно. Сложность зашкаливает.
В итоге получается, что более общие алгоритмы:
1. Существенно экономят время.
2. Позволяют решать более сложные задачи.
2:0 в пользу более общих алгоритмов. Тогда спрашивается, почему эти алгоритмы, или почему подход, основанный на использовании таких алгоритмов, должен каким-то образом мешать развитию компьютерного зрения?
Попробуйте задать себе вопрос: «Что лично мне мешает внедрить какую-то технологию компьютерно зрения в общественную жизнь?». Я уверен, вы найдёте кучу других объяснений, кроме общности алгоритмов.
Это касается не только CV. Вообще алгоритмы в computer science не создаются с бухты барахты — вначале любой порядочный алгоритмист проверяет, нельзя ли решить проблему с помощью одного из распространённых алгоритмов. И в 8 случаях из 10 это сделать возможно (поищите вопросы по тегу algorithm на StackOverflow — подавляющее большинство принятых ответов описывает решение с помощью одного из стандартных алгоритмов, причём решает без какой либо потери эффективности).
Я не хочу сказать, что специализированные решения — это плохо, но искать их следует только когда стандартные, обобщённые алгоритмы не дают нужного эффекта. Просто потому что нет смысла изобретать для каждой задачи свой алгоритм (или даже держать 2 сотни специализированных алгоритмов в голове), если можно выделить общие черты, общие принципы и отталкиваться от них.
Ваши ответы также, насколько я понимаю, подразумевают, что более общие алгоритмы не способны дать достаточную для продакшена точность. Однако, для каких именно задач, по-вашему, обобщённым алгоритмам не хватает точности, а специализированным было бы достаточно? Единственный пример с другой командой, которая не смогла с достаточной точностью определить размер товара, не показателен — как вам уже сказали выше, сам метод предполагает бесконечную точность. Если команда не смогла добиться этой точности или достаточного уровня оптимизации, то это уже инженерная проблема, а не проблема метода — им просто не хватило времени/ресурсов/мозгов. А можете привести примеры более распространённых задач (читать как: задачи, над которыми работала больше, чем одна группа разработчиков) и для которых сработали только узкоспециализированные алгоритмы, но не более общие? Распознавание символов — проблема давно решена с точностью фиг знает сколько процентов. Отслеживание движущихся предметов — тоже не проблема для современных алгоритмов. Определение эмоций на лице человека — вот как раз в последние годы эта задача активно решается, успехи уже очень неплохие. При этом создать с нуля, не опираясь на обобщённые методы, специализированный алгоритм для этих задач практически невозможно. Сложность зашкаливает.
В итоге получается, что более общие алгоритмы:
1. Существенно экономят время.
2. Позволяют решать более сложные задачи.
2:0 в пользу более общих алгоритмов. Тогда спрашивается, почему эти алгоритмы, или почему подход, основанный на использовании таких алгоритмов, должен каким-то образом мешать развитию компьютерного зрения?
Попробуйте задать себе вопрос: «Что лично мне мешает внедрить какую-то технологию компьютерно зрения в общественную жизнь?». Я уверен, вы найдёте кучу других объяснений, кроме общности алгоритмов.
и опять вы туда же…
>Возьмите задачу «измерение площади товара» и уберите из него «товар», заменив его на более общее «объект»
«объект» очень растяжимое понятие… но все что касается площади — мой алгоритм ее решит точнее и быстрее любых других.
>более общие алгоритмы не способны дать достаточную для продакшена точность
Я этого не говорил, но я утверждаю что конкретно этот алгоритм даст наивысшую точность и скорость в задаче «определения площади по картинке камеры», и более того применим в любой отрасли и для любых «объектов», возможно с небольшими корректировками чисто по обработке изображений но без изменения метода вычисления площади.
Если вы пытаетесь доказать что общий метод в общем случае может быть лучше, то я с этим не спорю, честно говоря я уже даже не понимаю что вы имеете ввиду под «обобщеными методами» если чисто мат. метод итегрального исчисления то я согласен, в общем случае и многих частных тоже, но только не в этом, он сильно проигрывает в точности и скорости.
>можете привести примеры более распространённых задач (читать как: задачи, над которыми работала больше, чем одна группа разработчиков)
не могу, по крайней мере таких которые реально работают не видел, даже на выставках крайне редко что-то хорошо работает.
>2:0 в пользу более общих алгоритмов
Я не понимаю что такое «более общие» алгоритмы, я за то чтобы общие алгоритмы (их много) состояли из хороших и проверенных на практике а общих или нет, это уже вопрос, если их станут применять большинство то они станут общими, если нет то нет.
Вот конкретно в CV в общие алгоритмы можно спокойно добавить как составную часть определение плошади по моему алгоритму и от этого CV только выиграет и проиграет если будет считать площадь интегральными или другими методоми
>Возьмите задачу «измерение площади товара» и уберите из него «товар», заменив его на более общее «объект»
«объект» очень растяжимое понятие… но все что касается площади — мой алгоритм ее решит точнее и быстрее любых других.
>более общие алгоритмы не способны дать достаточную для продакшена точность
Я этого не говорил, но я утверждаю что конкретно этот алгоритм даст наивысшую точность и скорость в задаче «определения площади по картинке камеры», и более того применим в любой отрасли и для любых «объектов», возможно с небольшими корректировками чисто по обработке изображений но без изменения метода вычисления площади.
Если вы пытаетесь доказать что общий метод в общем случае может быть лучше, то я с этим не спорю, честно говоря я уже даже не понимаю что вы имеете ввиду под «обобщеными методами» если чисто мат. метод итегрального исчисления то я согласен, в общем случае и многих частных тоже, но только не в этом, он сильно проигрывает в точности и скорости.
>можете привести примеры более распространённых задач (читать как: задачи, над которыми работала больше, чем одна группа разработчиков)
не могу, по крайней мере таких которые реально работают не видел, даже на выставках крайне редко что-то хорошо работает.
>2:0 в пользу более общих алгоритмов
Я не понимаю что такое «более общие» алгоритмы, я за то чтобы общие алгоритмы (их много) состояли из хороших и проверенных на практике а общих или нет, это уже вопрос, если их станут применять большинство то они станут общими, если нет то нет.
Вот конкретно в CV в общие алгоритмы можно спокойно добавить как составную часть определение плошади по моему алгоритму и от этого CV только выиграет и проиграет если будет считать площадь интегральными или другими методоми
«объект» очень растяжимое понятие… но все что касается площади — мой алгоритм ее решит точнее и быстрее любых других.
Ещё раз: определение площади грузовиков в Ираке по снимкам со спутника, определение площади товаров при наклоне камеры, определение площади товара на произвольной поверхности (произвольного цвета и интенсивности). Ни на одной из этих задач ваш метод работать не будет, а его доработка обойдётся гораздо дороже, чем использование другой модели.
Если вы пытаетесь доказать что общий метод в общем случае может быть лучше, то я с этим не спорю
Тогда о чём статья и к чему комментарии вроде:
Я этот пост написал для того чтобы задумались, может быть в этом и проблема, что CV до сих пор никак не выйдет на должный уровень, потому что возможно одна из причин есть «наиболее общие алгоритмы», которые на практике сильно теряют эффективность.
Я так понял, что вас смущает тенденция решать задачи сложными математическими и т.п. моделями (aka общими методами), что вы считаете именно эту тенденцию причиной слабого развития CV. А здесь вы говорите, что такие методы действительно могут быть лучше. Так в чём тогда ваша позиция?
> определение площади грузовиков в Ираке по снимкам со спутника, определение площади товаров при наклоне камеры, определение площади товара на произвольной поверхности (произвольного цвета и интенсивности)
Хоть и нереальные задачи вы придумываете но еще раз говорю этот алгоритм вычислит площадь и в этих и любых других задачах лучше любого другого!!!
Моя позиция в том что что-то не так с CV и возможно, я не уотверждаю, что да, проблема в излишней сложности, иногда в самих подходах к решению задачи, в то время как их можно решить намного проще и эффективнее. Хотя бы исходя из того преимущества, что входные данные уже есть, что не нужно тратить ресурсы на лишние вычисления, а только правильно воспользоваться входящими данными, и мой пост тому пример.
Хоть и нереальные задачи вы придумываете но еще раз говорю этот алгоритм вычислит площадь и в этих и любых других задачах лучше любого другого!!!
Моя позиция в том что что-то не так с CV и возможно, я не уотверждаю, что да, проблема в излишней сложности, иногда в самих подходах к решению задачи, в то время как их можно решить намного проще и эффективнее. Хотя бы исходя из того преимущества, что входные данные уже есть, что не нужно тратить ресурсы на лишние вычисления, а только правильно воспользоваться входящими данными, и мой пост тому пример.
Да почему нереальные? Те же гугломобили отслеживают разметку на дороге. Если нужно определить, является ли очередная белая полоска частью разметки или просто дохлым животным, то подсчёт площади может оказаться очень полезным. Однако ваш алгоритм уже работать не будет: камера сильно наклонена, а статическое фото фона сделать впринципе невозможно, ибо самого статического фона нет. Плоские объекты? Есть. Вычислить плоскость по вашему методу? Невозможно.
Вот вам, кстати, хорошее определение более общих алгоритмов: алгоритм А1 является более общим, чем алгоритм А2, если А1 может решать в точности те же задачи, что и А2, но при этом обладает меньшим количеством условий (например, условие наличия статического фона).
Вот вам, кстати, хорошее определение более общих алгоритмов: алгоритм А1 является более общим, чем алгоритм А2, если А1 может решать в точности те же задачи, что и А2, но при этом обладает меньшим количеством условий (например, условие наличия статического фона).
ну опять за уши притягиваете… во первых площадь там не нужна, а животное или еще что-то определять не нужно, чтобы там не было разметка или препятствие, оно определяется совсем другими алгоритмами.
А разметку на дороге нужно отслеживать совсем по другому вот один из свежих и то достаточно большая погрешность, с этим неплохо справлялась даже OpenCV 5 лет назад. А посчитать площадь моим алгоритмом можно без проблем с любым фоном, и с любым углом камеры, только погрешность увеличится. В моем посте снимок фона делался для большей точности, но цвет фона можно легко определять например по бОльшему числу откорректированых значений цветов пикселей, определяются значимые и фоновые пиксели или др. способом.
В идеале детектится полоса разметки любым методом, а площадь считается по числу пикселей, а не интегральным методом, мы же говорили о мат. методе подсчета.
А разметку на дороге нужно отслеживать совсем по другому вот один из свежих и то достаточно большая погрешность, с этим неплохо справлялась даже OpenCV 5 лет назад. А посчитать площадь моим алгоритмом можно без проблем с любым фоном, и с любым углом камеры, только погрешность увеличится. В моем посте снимок фона делался для большей точности, но цвет фона можно легко определять например по бОльшему числу откорректированых значений цветов пикселей, определяются значимые и фоновые пиксели или др. способом.
В идеале детектится полоса разметки любым методом, а площадь считается по числу пикселей, а не интегральным методом, мы же говорили о мат. методе подсчета.
Ну так если камера под большим наклоном, скажем, 60° к вертикали, то перспективные искажения будут играть ключевую роль в погрешностях. Вам так или иначе придётся реконструировать форму объекта с учётом модели искажения, ибо в перспективе его площадь будет значительно отличаться от реальной. Скажете, опять придумал и под таким углом камеру никогда не придётся ставить? Первая компания, в которой я работал, снимала офис в здании полиграфии или чего-то такого. Своими глазами видел конвеер со стопками бумаги и человека (!), который стоит и проверяет размеры листов. Измерение площади с помощью CV было бы идеальной заменой этому бедняге, но вот проблема: под потолком шли трубы, так что устойчиво закрепить камеру было бы… ну не невозможно, но довольно геморно. А вот поставить камеру на приёмнике бумаги — было бы идеальным решением. Но ваш алгоритм уже будет дико «грешить» из-за наклона камеры.
Для бумаги ещё можно придумать какие-то трюки — она почти всегда прямоуголной формы и детектится просто. А что делать с цехом резки металлов? Опять же, пример из жизни знакомых: в цехе вырезаются плоские листы металла для варки то ли котлов, то ли бочек каких-то. Размер листов должен быть строго определённым, иначе весь производственный процесс валится. Поставить камеру под потолком тоже может быть весьма проблематично. Плюс к этому, металл может различаться по цвету и частично сливаться с фоном, что сразу ставит крест на вашем методе. Единственный правильный метод здесь — искать замкнутые контуры и считать площадь математически.
И это только примеры ооочень близкие к описанному вами. Шаг вправо, шаг влево, и просто подсчёт пикселей начинает давать дичайшие погрешности.
Для бумаги ещё можно придумать какие-то трюки — она почти всегда прямоуголной формы и детектится просто. А что делать с цехом резки металлов? Опять же, пример из жизни знакомых: в цехе вырезаются плоские листы металла для варки то ли котлов, то ли бочек каких-то. Размер листов должен быть строго определённым, иначе весь производственный процесс валится. Поставить камеру под потолком тоже может быть весьма проблематично. Плюс к этому, металл может различаться по цвету и частично сливаться с фоном, что сразу ставит крест на вашем методе. Единственный правильный метод здесь — искать замкнутые контуры и считать площадь математически.
И это только примеры ооочень близкие к описанному вами. Шаг вправо, шаг влево, и просто подсчёт пикселей начинает давать дичайшие погрешности.
Закрепить камеру правильно и создать условия освещения, все равно вышло бы дешевле чем платить все время зарплату.
Цвета металла или чего другого никак не повлияет, а вот если метал или что угодно будет сливаться с фоном, то это ставит крест на любом методе. Ни один алгоритм не сможет этого сделать.
И кстати найдя замкнутые контуры можно также посчитать площадь моим методом, а не математическим.
Цвета металла или чего другого никак не повлияет, а вот если метал или что угодно будет сливаться с фоном, то это ставит крест на любом методе. Ни один алгоритм не сможет этого сделать.
И кстати найдя замкнутые контуры можно также посчитать площадь моим методом, а не математическим.
На практике фон не сливается с объектами, а если и сливается то объект становится не видимым. Но не забывайте что камера может лучше человека различать цвета, в картинке можно увеличить контраст и уже будет разница достаточная для определения, которую человек не увидит. плюс камеры видят в ИК диапазоне и в темноте с ИК подсветкой может отлично работать.
Зарплату кому? Разработчику системы? Он один раз напишет программу и свободен.
Закрепить камеру может быть принципиально невозможно, например, из-за норм пожарной безопасности. Ну или придётся делать перепланировку цеха, а это, уж извините, совсем дорогое занятие. Так что не переводите проблему с технического уровня на организационный.
Контур может быть обозначен только светотенью на границах листа металла. Если положить белый лист бумаги на белый же ватман, то лист вы всё равно увидите, хотя цвет внутри контура листа будет идентичен цвету вне его. Просто подсчёт белых пикселей покажет, что площадь листа бумаги равна 0.1(мм2) * длину периметра листа.
Если вы начинаете работать с контуром, то это уже так или иначе интегральное исчисление: вы замеряете расстояние между двумя границами (для определённости — вертиальными) контура с заданным шагом по другой оси (горизонтали). При шаге в 1 пиксель интегрирование становится идентичным вашему методу. Хотя нет, не идентичным: ваш метод предполагает итерирование по всем пикселям внутри линии, интегрирование оставляет свободу выбора реализации.
Итого:
1. При некоторых условиях всё равно придётся выделять контур.
2. При наличии контура ваш метод становится эквивалентным интегрированию.
Закрепить камеру может быть принципиально невозможно, например, из-за норм пожарной безопасности. Ну или придётся делать перепланировку цеха, а это, уж извините, совсем дорогое занятие. Так что не переводите проблему с технического уровня на организационный.
Контур может быть обозначен только светотенью на границах листа металла. Если положить белый лист бумаги на белый же ватман, то лист вы всё равно увидите, хотя цвет внутри контура листа будет идентичен цвету вне его. Просто подсчёт белых пикселей покажет, что площадь листа бумаги равна 0.1(мм2) * длину периметра листа.
Если вы начинаете работать с контуром, то это уже так или иначе интегральное исчисление: вы замеряете расстояние между двумя границами (для определённости — вертиальными) контура с заданным шагом по другой оси (горизонтали). При шаге в 1 пиксель интегрирование становится идентичным вашему методу. Хотя нет, не идентичным: ваш метод предполагает итерирование по всем пикселям внутри линии, интегрирование оставляет свободу выбора реализации.
Итого:
1. При некоторых условиях всё равно придётся выделять контур.
2. При наличии контура ваш метод становится эквивалентным интегрированию.
Зарплату работнику, который считает вручную. Я как раз и говорю что организационно решить проблему и установить систему будет дешевле чем платить зарплату. Камеру установить вертикально или с минимальным углом наклона, в подавляющем большинстве случаев не представляет проблемы.
И опять таки с ватманом притянуто, и если даже так то на практике полного совпадения цветов не будет, если только ватманы эти из одного рулона. А если нет то цвета можно отличить, ну и конечно на практике никто не будет на белом фоне мерять белый ватман, а с контуром или любым другим общим методом при совпадении цветов — контур получить очень проблематично и моим методом тоже.
Самая простая интеграция требует разбивки полученного контура на составляющие фигуры и интеграцию в пределах числа этих фигур и их площадей, поэтому мой метод никак не становится эквивалентным интегрированию потому что нет никакой разбивки в принципе и площадь считается в чистом виде. Если притянуть за уши, и принять что есть попиксельная разбивка, то она максимально приближена к мельчайшей фигуре их число и их и площади известны поэтому только простейшее суммирование. А интегральным методом сначала нужно разбить на разные части, посчитать их площади, и потом только сложить. А алгоритмы разбивки на части еще сложнее и тоже масса нюансов.
Может конечно я плохо объяснил, но раз такое пишите то похоже что не до конца поняли.
И опять таки с ватманом притянуто, и если даже так то на практике полного совпадения цветов не будет, если только ватманы эти из одного рулона. А если нет то цвета можно отличить, ну и конечно на практике никто не будет на белом фоне мерять белый ватман, а с контуром или любым другим общим методом при совпадении цветов — контур получить очень проблематично и моим методом тоже.
Самая простая интеграция требует разбивки полученного контура на составляющие фигуры и интеграцию в пределах числа этих фигур и их площадей, поэтому мой метод никак не становится эквивалентным интегрированию потому что нет никакой разбивки в принципе и площадь считается в чистом виде. Если притянуть за уши, и принять что есть попиксельная разбивка, то она максимально приближена к мельчайшей фигуре их число и их и площади известны поэтому только простейшее суммирование. А интегральным методом сначала нужно разбить на разные части, посчитать их площади, и потом только сложить. А алгоритмы разбивки на части еще сложнее и тоже масса нюансов.
Может конечно я плохо объяснил, но раз такое пишите то похоже что не до конца поняли.
Ещё раз говорю: не переводите проблему с технического уровня на организационный. Если можно решить проблему технически и таким образом избавиться от ограничений типа «камера должна быть ровно сверху», то почему этого не сделать?
Ватман и лист бумаги я привёл как наглядный пример, когда объект отделён от фона только светотенью контура. Для металла может быть то же самое: лист или какая-то его часть может быть по цвету идентична фону, и в этом случае для правильного подсчёта площади так или иначе придётся выделять контур.
Разбивки на какие части? Вы представляете себе, что такое простейший интегральный метод? Как вообще замерять площадь на графике между двумя кривыми? Для этого тупо берётся интеграл разницы между значениями первой кривой и второй. Если графики заданы дискретно, а кривые на любом цифровом изображении заданы именно так, то интеграл заменяется на сумму. Т.е. мы просто для всех x считаем разницу между границами контура y1 и y2, а затем суммируем. Если задать шаг по x равным 1px, то получается максимально точный из возможных для дискретных изображений результат, идентичный результату вашего метода.
Ватман и лист бумаги я привёл как наглядный пример, когда объект отделён от фона только светотенью контура. Для металла может быть то же самое: лист или какая-то его часть может быть по цвету идентична фону, и в этом случае для правильного подсчёта площади так или иначе придётся выделять контур.
Разбивки на какие части? Вы представляете себе, что такое простейший интегральный метод? Как вообще замерять площадь на графике между двумя кривыми? Для этого тупо берётся интеграл разницы между значениями первой кривой и второй. Если графики заданы дискретно, а кривые на любом цифровом изображении заданы именно так, то интеграл заменяется на сумму. Т.е. мы просто для всех x считаем разницу между границами контура y1 и y2, а затем суммируем. Если задать шаг по x равным 1px, то получается максимально точный из возможных для дискретных изображений результат, идентичный результату вашего метода.
ну не сможете Вы решить эту проблему с приемлемым уровнем погрешности, если будет камера слишком далеко, высоко, под большим углом, если в кадре будет наложение других объектов и т.п. все что вы придумывали.
Конечно представляю, и простейший я написал выше, а тот где «тупо берётся интеграл разницы между значениями первой кривой и второй» еще сложнее с точки зрения реализации алгоритма разбивки и определения этих кривых, т.к. графики и кривые не заданы еще, их нужно разбить и определить для начала.
Конечно представляю, и простейший я написал выше, а тот где «тупо берётся интеграл разницы между значениями первой кривой и второй» еще сложнее с точки зрения реализации алгоритма разбивки и определения этих кривых, т.к. графики и кривые не заданы еще, их нужно разбить и определить для начала.
Если слишком далеко/высоко, и разрешение плохое, то нет. Вернее, скорее всего нет, хотя попробать восстановить изображение можно, как раз недавно пост на Хабре был на эту тему. Если угол позволяет увидеть все контуры объекта, а также известен наклон камеры и расстояние до объекта — не вижу никаких проблем.
Ещё раз: если у вас есть контуры, то «кривые» уже определены. Даже если вы их не сохранили во время выделения контуров, достаточно один раз пробежать по пикселям, чтобы определить их местоположение. И ваш алгоритм, если ничего лишнего не придумывать, сведётся к тому же: начать с «холостого» режима, идти по строкам пикселей, при нечётном пересечении контура перейти в режим суммирования, при чётном — снова в «холостой» режим. Повторить для каждой строки пикселей на изображении.
Ещё раз: если у вас есть контуры, то «кривые» уже определены. Даже если вы их не сохранили во время выделения контуров, достаточно один раз пробежать по пикселям, чтобы определить их местоположение. И ваш алгоритм, если ничего лишнего не придумывать, сведётся к тому же: начать с «холостого» режима, идти по строкам пикселей, при нечётном пересечении контура перейти в режим суммирования, при чётном — снова в «холостой» режим. Повторить для каждой строки пикселей на изображении.
конечно, можно даже сделать реконструкцию 3D и заодно посчитать объем, но это в теории, а на практике не получается пока нормально.
Я не понимаю что вы имеете ввиду «кривые» уже определены как они определены? каким методом? как разбивается фигура? есть же много методов.
И не надо пожалуйста менять мой алгоритм, он работает совсем не так, а то что вы написали не понято что делает и при чем тут четные/нечетные
Я не понимаю что вы имеете ввиду «кривые» уже определены как они определены? каким методом? как разбивается фигура? есть же много методов.
И не надо пожалуйста менять мой алгоритм, он работает совсем не так, а то что вы написали не понято что делает и при чем тут четные/нечетные
3D реконструкцию по проекции на одну плоскасть как раз в общем случае сделать невозможно. А то, что я привёл для примера, делается элементарно.
Приличную картинку куска металла на конвеере долго искать, вот вам iPhone — его картинок хватает. Оригинальная картинка:
После выделения контуров:
Если нам нужно измерить площадь айфона, и мы знаем, что это именно айфон и дырок в нём нет, то мы оставляем только внешний контур, а остальные затираем. Белые вертикальные полоски — это графики функций, площадь между ними — это площадь айфона. Если мы не сохранили координаты белых точек во время выделения контуров, то просто начинаем ходить по строкам пикселей, начиная с самой верхней. В первой полосе нет белых пикселей, значит ничего не суммируем. Вторая строка — одна белая полоса, обозначающая край устройства — она нам тоже ни к чему. На третьей строчке будут 2 белых пикселя, обозначающие вход внутрь фигуры и выход из неё. Всё, что находится между этими 2-мя точками, пойдёт в сумму общей площади. Фигура, которую вы так отчаянно ищите, в данном случае — это прямоугольник шириной в 1 пиксел и длиной в расстояние между левым и правым пикселями контура.
В случае с листом металла внутри контура могут быть бреши, прорези в изделии, которые считать не надо (или надо? я уж не знаю, какая была цель у вашего алгоритма). Тогда внутренние контуры не затираем, но алгоритм остаётся тем же: когда встречаем чётный по счёту белый пиксел в строке (пошла часть объекта), переключаемся в режим суммирования, когда встречаем чётный (закончилась часть объекта, либо брешь, либо конец объекта) — переходим в режим обычного сканирования.
Приличную картинку куска металла на конвеере долго искать, вот вам iPhone — его картинок хватает. Оригинальная картинка:
После выделения контуров:
Если нам нужно измерить площадь айфона, и мы знаем, что это именно айфон и дырок в нём нет, то мы оставляем только внешний контур, а остальные затираем. Белые вертикальные полоски — это графики функций, площадь между ними — это площадь айфона. Если мы не сохранили координаты белых точек во время выделения контуров, то просто начинаем ходить по строкам пикселей, начиная с самой верхней. В первой полосе нет белых пикселей, значит ничего не суммируем. Вторая строка — одна белая полоса, обозначающая край устройства — она нам тоже ни к чему. На третьей строчке будут 2 белых пикселя, обозначающие вход внутрь фигуры и выход из неё. Всё, что находится между этими 2-мя точками, пойдёт в сумму общей площади. Фигура, которую вы так отчаянно ищите, в данном случае — это прямоугольник шириной в 1 пиксел и длиной в расстояние между левым и правым пикселями контура.
В случае с листом металла внутри контура могут быть бреши, прорези в изделии, которые считать не надо (или надо? я уж не знаю, какая была цель у вашего алгоритма). Тогда внутренние контуры не затираем, но алгоритм остаётся тем же: когда встречаем чётный по счёту белый пиксел в строке (пошла часть объекта), переключаемся в режим суммирования, когда встречаем чётный (закончилась часть объекта, либо брешь, либо конец объекта) — переходим в режим обычного сканирования.
3D реконструкцию как раз можно сделать достаточно точно, собственно то что вы написали ранее т.е. просчет при известном наклоне камеры по сути и есть 3D реконструкция, т.к. картинку вы фактически должны перевести из одной плоскости в другую так или иначе. Более того есть готовые приставки которые конвертируют видео 2D в 3D на лету, в новых дорогих телевизорах есть встроенная такая система по крайней мере в samsung и вполне нормально работает.
Вот примерно как у вас на картинке контуры так и будет все работать, нужно было сделать еще под двойным углом и на таком же фоне, как вы предлагали… догадываетесь какой бы получился контур.
Кроме того мы говорим о произвольной фигуре и общем методе для всего, представьте например шкуру животного, график функции говорите..., ну посчитайте такой контур
Составьте хотя бы определенный интеграл, не говоря уже о разбивке (алгоритме построения этого интеграла) и я надеюсь поймете. Вы говорите о применении интеграла по графику функции а я говорил о самом принципе интегрирования, т.е. сама суть интегрального метода на практике неизбежно приводит к погрешности. Если бы вы прочитали внимательно хотя бы ту ссылку что я писал выше в самом начале про суть интегрального исчисления то может и не писали бы тут столько, но в любом случае это полезно, может быть и я чего-то не понимаю, или вы и это позволит нам хотябы посмотреть на это с другой стороны.
Вот примерно как у вас на картинке контуры так и будет все работать, нужно было сделать еще под двойным углом и на таком же фоне, как вы предлагали… догадываетесь какой бы получился контур.
Кроме того мы говорим о произвольной фигуре и общем методе для всего, представьте например шкуру животного, график функции говорите..., ну посчитайте такой контур
Составьте хотя бы определенный интеграл, не говоря уже о разбивке (алгоритме построения этого интеграла) и я надеюсь поймете. Вы говорите о применении интеграла по графику функции а я говорил о самом принципе интегрирования, т.е. сама суть интегрального метода на практике неизбежно приводит к погрешности. Если бы вы прочитали внимательно хотя бы ту ссылку что я писал выше в самом начале про суть интегрального исчисления то может и не писали бы тут столько, но в любом случае это полезно, может быть и я чего-то не понимаю, или вы и это позволит нам хотябы посмотреть на это с другой стороны.
Про 3D: давайте сразу с пруфом. В общем случае 2D не реконструируется в 3D никак, тупо потому что третью координату неоткуда брать. 3D точка (x, y, z) может соответствовать сколь угодно много 2D точек (x, y), соответсвенно одназначное обратное преобразование в общем случае по определению невозможно. Можно более или менее решить задачу для конкретных ситуаций, например, когда известна примерная 3D модель транслируемого объекта, но в общем случае это ну никак не получится сделать.
Для примера: на изображении вы видите равнобедренную трапецию. Возможно, это «лежачий» прямоугольник, превратившийся в трапецию из-за перспективных искажений, а возможно это действительно трапеция, стоящая вертикально. Ни информация о наклоне камеры, ни о расстоянии до объекта не позволяет однозначно определить, что изображено.
Перспективные искажения можно восстановить при условии, что мы точно знаем положение объекта. Если мы стопроцентно уверены, что наша фигура лежит, и у нас есть данные об уголе наклона и расстоянии до неё, то простейшая геометрия позволяет перевести изображение в нужную нам плоскость. Но это только если мы знаем положение объекта.
Вы, видимо, совсем не понимаете, как считается интеграл функции, заданной дискретно. Вот вам замечательное изображение из той же статьи:
Как видите, есть некая аналоговая функция, показанная на графике кривой линией. Для того, чтобы найти площадь под этой линией, ось X разбивается на на равные части — шаги. На каждом шаге берётся высота получившихся «столбиков» по оси Y (брать можно несколькими способами, на рисунке показаны 2 — по значениям y, соответствующим началу шага (x[n]) и концу шага (x[n+1])). В итоге график непрерывной функции заменяется дискретным графиком, набором столбиков, высоту которых легко измерить.
Когда мы работаем с цифровыми изображениями, мы изначально имеем дело с дискретными функциями. Т.е. область под графиком (или между графиками) уже имеет вид этих столбиков. Нам ничего больше делать не надо — мы просто замеряем высоту этих столбиков и суммируем результаты.
Со шкурой животного ничего не меняется. Возьмём горизонтальный срез чуть ниже области, где у животного должен был быть хвост. Т.е. возьмём просто горизонтальную полоску пикселей. Эту полоску можно разделить на 5 областей: фон, левая часть шкуры, фон, правая часть шкуры, фон. Разделены эти 5 областей 4 точками — начало левой части шкуры, конец левой части шкуры, начало правой части шкуры, конец правой части шкуры. Это 4 опорные точки, через которые проходит вертикальная линия. Мы можем начать сканировать полоску пикселей с самого левого и переключаться между 2-мя режимами: обычное сканирование и суммирование. В первой области мы будем просто итерировать по пикселям, проверяя, не являются ли они контрольными точками. На первой контрольной точке (начало шкуры) мы переключимся в режим суммирования и будем инкрементировать сумму до тех пор, пока не дойдём до 2-й точки (конец шкуры). На 2-й точке мы снова переключимся в режим простого сканирования и будем итерировать пока не дойдём до 3-й точки, обозначающей начало ещё одного куска шкуры. И снова мы переключаемся в режим суммирования и идём, пока не дойдём до 4-й точки. После 4-й точки мы снова переключимся в «холостой» режим и до конца полоски пикселей не будем ничего суммировать.
То же самое повторяется для каждой строчки пикселей, в результате получается максимально точно вычисленныя площадь. Это нормальный интегральный метод для дискретных функий, ничего сложного и никакой высшей математики с дифференцированием и т.д.
Для примера: на изображении вы видите равнобедренную трапецию. Возможно, это «лежачий» прямоугольник, превратившийся в трапецию из-за перспективных искажений, а возможно это действительно трапеция, стоящая вертикально. Ни информация о наклоне камеры, ни о расстоянии до объекта не позволяет однозначно определить, что изображено.
Перспективные искажения можно восстановить при условии, что мы точно знаем положение объекта. Если мы стопроцентно уверены, что наша фигура лежит, и у нас есть данные об уголе наклона и расстоянии до неё, то простейшая геометрия позволяет перевести изображение в нужную нам плоскость. Но это только если мы знаем положение объекта.
Вы, видимо, совсем не понимаете, как считается интеграл функции, заданной дискретно. Вот вам замечательное изображение из той же статьи:
Как видите, есть некая аналоговая функция, показанная на графике кривой линией. Для того, чтобы найти площадь под этой линией, ось X разбивается на на равные части — шаги. На каждом шаге берётся высота получившихся «столбиков» по оси Y (брать можно несколькими способами, на рисунке показаны 2 — по значениям y, соответствующим началу шага (x[n]) и концу шага (x[n+1])). В итоге график непрерывной функции заменяется дискретным графиком, набором столбиков, высоту которых легко измерить.
Когда мы работаем с цифровыми изображениями, мы изначально имеем дело с дискретными функциями. Т.е. область под графиком (или между графиками) уже имеет вид этих столбиков. Нам ничего больше делать не надо — мы просто замеряем высоту этих столбиков и суммируем результаты.
Со шкурой животного ничего не меняется. Возьмём горизонтальный срез чуть ниже области, где у животного должен был быть хвост. Т.е. возьмём просто горизонтальную полоску пикселей. Эту полоску можно разделить на 5 областей: фон, левая часть шкуры, фон, правая часть шкуры, фон. Разделены эти 5 областей 4 точками — начало левой части шкуры, конец левой части шкуры, начало правой части шкуры, конец правой части шкуры. Это 4 опорные точки, через которые проходит вертикальная линия. Мы можем начать сканировать полоску пикселей с самого левого и переключаться между 2-мя режимами: обычное сканирование и суммирование. В первой области мы будем просто итерировать по пикселям, проверяя, не являются ли они контрольными точками. На первой контрольной точке (начало шкуры) мы переключимся в режим суммирования и будем инкрементировать сумму до тех пор, пока не дойдём до 2-й точки (конец шкуры). На 2-й точке мы снова переключимся в режим простого сканирования и будем итерировать пока не дойдём до 3-й точки, обозначающей начало ещё одного куска шкуры. И снова мы переключаемся в режим суммирования и идём, пока не дойдём до 4-й точки. После 4-й точки мы снова переключимся в «холостой» режим и до конца полоски пикселей не будем ничего суммировать.
То же самое повторяется для каждой строчки пикселей, в результате получается максимально точно вычисленныя площадь. Это нормальный интегральный метод для дискретных функий, ничего сложного и никакой высшей математики с дифференцированием и т.д.
На счет 3D в нашем случае зная угол камеры, можно добвить ось Z и ее длину (дальность камеры) и реконструировать изображение до положения камеры сверху, это только один из способов. Но речь в общем не об этом шла 3D я как один из вариантов.
В том-то и дело что я хорошо понимаю и как считается и как это работает, поэтому и говорю что погрешность в самом методе, если только не интегрировать до бесконечных пределов, а на практике это не реально.
Это погрешность часто называется интегральная нелинейность, из этого же рисунка выше видно, что кривые аппроксимируется прямой линией по методу наименьших квадратов. Понимаете?
Причем эта погрешность есть даже на уровне АЦП в любых интегральных чипах на уровне сигналов, и вообще в любом АЦП и DSP процессорах, в том числе в CISC процессорах. Более того скажу что в современных процессорах используется RISC архитектура с некоторыми инструкциями в которых по этой же причине точность вычислений меньше. Есть байка, и многие считают что это правда, что в NASA было несколько провалов миссий из-за того что они делали все просчеты на новых RISC процессорах. На самом деле погрешность очень маленькая и связана она уже с самими вычислителями, но тем не менее, интегральная погрешность есть, и даже не спорьте.
И вот вы все же пришли наконец к тому что нужно делить на области. А как определить эти области(точки)? я имею ввиду алгоритм для любой произвольной фигуры типа шкуры только например еще сложнее, например с сотней различный по форме ответвлений, с заворотами и т.п.?
В том-то и дело что я хорошо понимаю и как считается и как это работает, поэтому и говорю что погрешность в самом методе, если только не интегрировать до бесконечных пределов, а на практике это не реально.
Это погрешность часто называется интегральная нелинейность, из этого же рисунка выше видно, что кривые аппроксимируется прямой линией по методу наименьших квадратов. Понимаете?
Причем эта погрешность есть даже на уровне АЦП в любых интегральных чипах на уровне сигналов, и вообще в любом АЦП и DSP процессорах, в том числе в CISC процессорах. Более того скажу что в современных процессорах используется RISC архитектура с некоторыми инструкциями в которых по этой же причине точность вычислений меньше. Есть байка, и многие считают что это правда, что в NASA было несколько провалов миссий из-за того что они делали все просчеты на новых RISC процессорах. На самом деле погрешность очень маленькая и связана она уже с самими вычислителями, но тем не менее, интегральная погрешность есть, и даже не спорьте.
И вот вы все же пришли наконец к тому что нужно делить на области. А как определить эти области(точки)? я имею ввиду алгоритм для любой произвольной фигуры типа шкуры только например еще сложнее, например с сотней различный по форме ответвлений, с заворотами и т.п.?
Я вам ещё раз говорю: цифровое изображение и любые линии на нём по определению заданы дискретно. Изображение — это тупо матрица. У элементов матрицы (пикселей) есть целочисленные индексы — 1, 2, 3 и т.д., но никак не 1.125, 2.44 и т.д. Между индексами элементов матрицы ничего нет. На изображении нет прямых линий. Все прямые линии остались на уровне АЦП, который уже отработал и выдал цифровое, дискретное изображение. Это изображение никогда не приводится обратно к аналоговому виду для обработки. Наоборот, аналоговое изображение переводится в цифровое, потому что компьютеры — процессоры, память — умеют работать с цифрами, а не с аналоговым сигналом.
Интегрирование можно провести 2-мя способами — математическими формулами в тетрадке или дискретно на компьютере. Рисунок выше показывает дискретное интегрирование аналоговой функции — то, что делает АЦП. Когда у вас есть цифровое изображение, у вас уже нет кривой линии, у вас есть только эти столбики — вертикальные векторы пикселей. Это столбики никогда не аппроксимируются никакой линией — нафига их аппроксимировать, если их можно вычислить точно? Если вы этого не понимаете, то любые мои объяснения будут бесполезны.
Я вам дал подробнейшее описание алгоритма вычисления поиска через дискретное интегрирование области внутри контуров. Это лучшее объяснение, которое я могу придумать. Если вы всё ещё не понимаете, как это работает, и что это будет работать для объектов с формой любой сложности, то я не знаю, как вам ещё об этом рассказать.
Интегрирование можно провести 2-мя способами — математическими формулами в тетрадке или дискретно на компьютере. Рисунок выше показывает дискретное интегрирование аналоговой функции — то, что делает АЦП. Когда у вас есть цифровое изображение, у вас уже нет кривой линии, у вас есть только эти столбики — вертикальные векторы пикселей. Это столбики никогда не аппроксимируются никакой линией — нафига их аппроксимировать, если их можно вычислить точно? Если вы этого не понимаете, то любые мои объяснения будут бесполезны.
Я вам дал подробнейшее описание алгоритма вычисления поиска через дискретное интегрирование области внутри контуров. Это лучшее объяснение, которое я могу придумать. Если вы всё ещё не понимаете, как это работает, и что это будет работать для объектов с формой любой сложности, то я не знаю, как вам ещё об этом рассказать.
Хотя есть одна последняя идея. Возьмите тетрадку в клеточку и нарисуйте там график какой-нибудь сложной формы, что-нибудь вроде:
А затем проинтегрируйте её вручную. Возьмите за шаг 1 клетку и просто нарисуйте столбики как на картинке из Википедии, а потом посчитайте, сколько клеток попало внутрь эти столбиков. Это и будет площадь. И именно так работает дискретное интегрирование. Если вы и после этого не поймёте, то я тут бесполезен.
А затем проинтегрируйте её вручную. Возьмите за шаг 1 клетку и просто нарисуйте столбики как на картинке из Википедии, а потом посчитайте, сколько клеток попало внутрь эти столбиков. Это и будет площадь. И именно так работает дискретное интегрирование. Если вы и после этого не поймёте, то я тут бесполезен.
я все прекрасно понимаю, и вижу что начали понимать, вы говорите о методе применения, а я говорю о сути (сущности) самого метода интегрирования. Когда вы только называете слово интегрирование это уже подразумевает разложение, преобразование, приведение и т.д. и кривые от этого не станут прямыми и погрешность никуда не уйдет.
Есть погрешность и в моем методе я же писал, но она обусловлена размером пикселя(клетки) и высотой от камеры, если вы поняли суть интегрирования то должны понять что мой метод в сущности это тоже самое только намного проще и быстрее с минимальной погрешностью и никак не зависит от сложности фигуры, не требует разбиения и т.д. ну и тем более что это не хак или что там еще вы писали, а очень простой и хороший алгоритм, кроме того проверенный на практике. И никакие «более общие методы» не дают никаких преимуществ.
Есть погрешность и в моем методе я же писал, но она обусловлена размером пикселя(клетки) и высотой от камеры, если вы поняли суть интегрирования то должны понять что мой метод в сущности это тоже самое только намного проще и быстрее с минимальной погрешностью и никак не зависит от сложности фигуры, не требует разбиения и т.д. ну и тем более что это не хак или что там еще вы писали, а очень простой и хороший алгоритм, кроме того проверенный на практике. И никакие «более общие методы» не дают никаких преимуществ.
Если вы всё ещё говорите про кривые и прямые, то нет, вы не поняли.
я и не говорил о них, это вы предлагали «более общие» алгоритмы, контуры, кривые и т.д. и только когда «разделали шкуру» наверно поняли. Если еще глубже разобраться то я думаю увидите четко и ясно что мой метод лучше и Ваш iPhone и моя шкура :) считается в один проход моментально без выделения контура, интегрирования и других общих методов. Если хотите продолжить давайте поговорим о получении контуров, чтобы понять что это тоже ничего не дает с точки зрения даже не знаю уже чего, наверно «более общих методов», но по-моему их лучше называть как-то конкретно?
А там я могу много рассказать о коррекции(нормализации) цветов, о том как определить фон без снимка фона и что на практике получается (почему лучше со снимком), как влияет цвет поверхности фона, блики, тени, освещение и т.д., правда наверно слишком много получится, лучше написать еще один пост на эту тему.
А там я могу много рассказать о коррекции(нормализации) цветов, о том как определить фон без снимка фона и что на практике получается (почему лучше со снимком), как влияет цвет поверхности фона, блики, тени, освещение и т.д., правда наверно слишком много получится, лучше написать еще один пост на эту тему.
Подсчёт пикселей внутри одной их строки — это частный случай дискретного интегрирования. Частный — потому что интегрирование можно осуществить и иначе, например, вычислив ключевые точки заранее и тупо вычисляя разницу между их индексами. Кроме того, при интегрировании вы можете увеличить шаг, сделав его не 1, а 2, 3 или 5 пикселей. Так вы потеряете точность, но увеличите скорость вычисления. Ваш алгоритм это не позволит. Это не значит, что ваш метод плох, это значит, что интегрирование является более общим методом, дающим больше возможностей для конфигурирования.
Всё это я говорил для того, чтобы показать, что математические методы не являются чем-то переусложнённым, а вполне подходят для решения задач компьютерного зрения. Отсюда следует вывод, что CV идёт по правильному пути, и этот путь не является причиной малого использования его в жизни и на производстве.
Что касается конкретно контуров, то ещё раз: положите чёрный iPhone на чёрную поверхность, и всё, что будет отделять его от фона — это белый контур по бокам устройства. Ваш алгоритм в чистом виде посчитает только этот контур и некоторые области внутри девайса, но пропустит (посчитает за фон) те области, которые по цвету идентичны фону. Вам так или иначе придётся определять, какая часть изображения находится внутри айфона, а какая снаружи — по одному отдельно взятому чёрному пикселю этого сказать невозможно.
Всё это я говорил для того, чтобы показать, что математические методы не являются чем-то переусложнённым, а вполне подходят для решения задач компьютерного зрения. Отсюда следует вывод, что CV идёт по правильному пути, и этот путь не является причиной малого использования его в жизни и на производстве.
Что касается конкретно контуров, то ещё раз: положите чёрный iPhone на чёрную поверхность, и всё, что будет отделять его от фона — это белый контур по бокам устройства. Ваш алгоритм в чистом виде посчитает только этот контур и некоторые области внутри девайса, но пропустит (посчитает за фон) те области, которые по цвету идентичны фону. Вам так или иначе придётся определять, какая часть изображения находится внутри айфона, а какая снаружи — по одному отдельно взятому чёрному пикселю этого сказать невозможно.
вот правильно сказали «частный случай», и на практике все будет частными случаями, а многие методы не будут работать совсем или с такой погрешностью что их реально использовать нельзя. Да еще в добавок придется написать алгоритм выбора методов по картинке, т.к. результаты будут прямо-пропорциональны правильности определения методов.
Я не говорил что мат. методы просты или сложны, они разные, я говорил что их неправильно выбирают и применяют, понимание приходит когда начинаешь делать на практике а не в теории, но иногда и не приходит, и тогда получаются плохие результаты.
На счет контуров, тоже еще раз говорю — цвета не идентичны и будут отличаться и достаточно четко даже в плохой ч/б камере, если только поверхность не сделана из того же материала при чем из той же партии и из того же сырья. На iPhone в частности можно даже достаточно точно выделить участки(пиксели) где есть отпечатки пальцев(они не бликуют). Глянцевые поверхности очень сильно бликуют, и ваша картинке iPhone c контуром наглядно показывает как сильно влияют тени, блики и освещение на выделение контура, да и на все остальное тоже, это все частные случаи и их можно обойти тоже используя другие частные случаи(методы).
Я напишу как нибудь пост на эту тему, думаю практика будет интересна многим, там можно продолжить, а тут уже вроде все и так разобрали больше чем нужно.
p.s.
я написал вам личное сообщение
Я не говорил что мат. методы просты или сложны, они разные, я говорил что их неправильно выбирают и применяют, понимание приходит когда начинаешь делать на практике а не в теории, но иногда и не приходит, и тогда получаются плохие результаты.
На счет контуров, тоже еще раз говорю — цвета не идентичны и будут отличаться и достаточно четко даже в плохой ч/б камере, если только поверхность не сделана из того же материала при чем из той же партии и из того же сырья. На iPhone в частности можно даже достаточно точно выделить участки(пиксели) где есть отпечатки пальцев(они не бликуют). Глянцевые поверхности очень сильно бликуют, и ваша картинке iPhone c контуром наглядно показывает как сильно влияют тени, блики и освещение на выделение контура, да и на все остальное тоже, это все частные случаи и их можно обойти тоже используя другие частные случаи(методы).
Я напишу как нибудь пост на эту тему, думаю практика будет интересна многим, там можно продолжить, а тут уже вроде все и так разобрали больше чем нужно.
p.s.
я написал вам личное сообщение
Вы опять неправильно поняли то, что я хотел сказать. Вы говорите о частных задачах, я говорю о логическом отношении «частное-общее». Рука — это частный случай части тела. Т.е. кроме рук частями тела являются ноги, голова, филейная часть и т.д.
Что я хочу сказать. Вот вам приходит какая-то задача. Вы сразу начинаете искать частное решение, вычленять какие-то особенности задачи, за которые можно зацепиться, изобретать новые алгоритмы. На примере подсчёта площади: вы заметили, что площадь объекта будет пропорциональна количеству различающихся пикселей при сравнении с изображением пустого фона (особенность задачи) и придумали, как из этого извлечь выгоду (изобрели новый алгоритм). То есть вы сразу будете ориентироваться на какое-то специализированное, частное решение.
Другие же люди, в том числе такие как я, в первую очередь подумают, к какому роду относится эта задача, на какие другие задачи она похожа. Нужно подсчитать площадь предметов, значит это задача подсчёта площади. Значит сразу берём интегральные методы. Как именно применить здесь интегральный метод? Ага, вот можно «нарезать» интересующую нас область на «полоски» пикселей и считать их. А как выделить интересующую нас область? Ага, вот можно искать замкнутые контуры, а можно просто сравнить с картинкой без объекта. В итоге человек, решает эту задачу, может прийти к идентичному с технической точки зрения решению, но при этом пройти путь от максимально общей задачи (нахождение плоскости) и максимально общего решения (интегральный метод) до частной задачи (нахождение площади плоского товара на конвеере) и частного решения (сравнивать с фоном). Т.е. двигаться от общего к частному.
Я вижу у второго метода кучу плюсов, в т.ч. он более определённый, простой и быстрый с т.з. поиска решения. Но главное, что он позволяет решать более сложные задачи. Нахождение площади плоского товара — это, согласитесь, довольно простая задача. А представьте, что вам пришла задача распознавать лица. И при этом наработок в этой области вообще ноль. Как вы будете искать частное решение? Какие особенности лиц вы будете выделять? Вы можете сразу начать играть с цветами, искать какие-то контрасты, смотреть, как голова отличается от фона и т.д. Можно много чего придумать и потратить много месяцев на проверку концепций, которые потом окажутся совершенно бесполезными.
Я бы пошёл другим путём. Тем путём, который активно используется в науке (а мы же говорим про разработку чего-то нового, а это ведь тоже в какой-то мере исследование). Я бы для начала попробовал сформулировать задачу в максимально общем виде: нам нужно что-то распознать, т.е. сравнить с образцом и высчитать ошибку. О! Так это же машинное обучение! А почему бы не попробовать применить его здесь?! Всё, через 3 часа у меня есть готовый алгоритм собственных лиц. Да, возможно этот алгоритм не совершенен и его придётся долго допиливать, но у меня уже есть первое приближение. Да, возможно я вообще пойду в неправильном направлении и в итоге вообще откажусь от этого решения, но я потратил всего 3 часа, у меня ещё куча времени. Т.е. общие методы позволяют очень быстро сформировать то, что в английском называют bold hypothesis — смелое предположение. Глядя на частности, на какие-то особенности конкретной задачи это предположение сформировать сложно. Вернее даже, сформировать не сложно, но сложно сходу оценить, насколько это предположение может быть удачным.
В то же время, я не вижу, почему поиск специфического решения для каждой новой задачи может быть более выгодным.
Про контуры. Я понимаю, что если есть хоть минимальное различие, то цвета разделить можно. Но что, если этих различий нет вообще. Т.е. внутри объекта нашлась область, которая на 100% идентична фону? Вот прям по всем цветам одинаковые значения. Пусть это будет небольшая область, пусть какая-то деталь, но если уж так случилось, то ваш алгоритм не посчитает эту область. Я не говорю, что это будет часто, и, возможно, ваш алгоритм всё ещё будет показывать лучший результат, но просто как формальное доказательство того, что в некоторых случаях он может работать некорректно.
Что я хочу сказать. Вот вам приходит какая-то задача. Вы сразу начинаете искать частное решение, вычленять какие-то особенности задачи, за которые можно зацепиться, изобретать новые алгоритмы. На примере подсчёта площади: вы заметили, что площадь объекта будет пропорциональна количеству различающихся пикселей при сравнении с изображением пустого фона (особенность задачи) и придумали, как из этого извлечь выгоду (изобрели новый алгоритм). То есть вы сразу будете ориентироваться на какое-то специализированное, частное решение.
Другие же люди, в том числе такие как я, в первую очередь подумают, к какому роду относится эта задача, на какие другие задачи она похожа. Нужно подсчитать площадь предметов, значит это задача подсчёта площади. Значит сразу берём интегральные методы. Как именно применить здесь интегральный метод? Ага, вот можно «нарезать» интересующую нас область на «полоски» пикселей и считать их. А как выделить интересующую нас область? Ага, вот можно искать замкнутые контуры, а можно просто сравнить с картинкой без объекта. В итоге человек, решает эту задачу, может прийти к идентичному с технической точки зрения решению, но при этом пройти путь от максимально общей задачи (нахождение плоскости) и максимально общего решения (интегральный метод) до частной задачи (нахождение площади плоского товара на конвеере) и частного решения (сравнивать с фоном). Т.е. двигаться от общего к частному.
Я вижу у второго метода кучу плюсов, в т.ч. он более определённый, простой и быстрый с т.з. поиска решения. Но главное, что он позволяет решать более сложные задачи. Нахождение площади плоского товара — это, согласитесь, довольно простая задача. А представьте, что вам пришла задача распознавать лица. И при этом наработок в этой области вообще ноль. Как вы будете искать частное решение? Какие особенности лиц вы будете выделять? Вы можете сразу начать играть с цветами, искать какие-то контрасты, смотреть, как голова отличается от фона и т.д. Можно много чего придумать и потратить много месяцев на проверку концепций, которые потом окажутся совершенно бесполезными.
Я бы пошёл другим путём. Тем путём, который активно используется в науке (а мы же говорим про разработку чего-то нового, а это ведь тоже в какой-то мере исследование). Я бы для начала попробовал сформулировать задачу в максимально общем виде: нам нужно что-то распознать, т.е. сравнить с образцом и высчитать ошибку. О! Так это же машинное обучение! А почему бы не попробовать применить его здесь?! Всё, через 3 часа у меня есть готовый алгоритм собственных лиц. Да, возможно этот алгоритм не совершенен и его придётся долго допиливать, но у меня уже есть первое приближение. Да, возможно я вообще пойду в неправильном направлении и в итоге вообще откажусь от этого решения, но я потратил всего 3 часа, у меня ещё куча времени. Т.е. общие методы позволяют очень быстро сформировать то, что в английском называют bold hypothesis — смелое предположение. Глядя на частности, на какие-то особенности конкретной задачи это предположение сформировать сложно. Вернее даже, сформировать не сложно, но сложно сходу оценить, насколько это предположение может быть удачным.
В то же время, я не вижу, почему поиск специфического решения для каждой новой задачи может быть более выгодным.
Про контуры. Я понимаю, что если есть хоть минимальное различие, то цвета разделить можно. Но что, если этих различий нет вообще. Т.е. внутри объекта нашлась область, которая на 100% идентична фону? Вот прям по всем цветам одинаковые значения. Пусть это будет небольшая область, пусть какая-то деталь, но если уж так случилось, то ваш алгоритм не посчитает эту область. Я не говорю, что это будет часто, и, возможно, ваш алгоритм всё ещё будет показывать лучший результат, но просто как формальное доказательство того, что в некоторых случаях он может работать некорректно.
Если различий нет вообще и «100% идентична фону» — объект становится невидимым и никакой алгоритм не посчитает.
Ну а по остальному я не во всем согласен и думаю что, как вы и написали, если будете «двигаться от общего к частному» то к нему же и придете, только потратите больше времени.
Если задачи просто и хорошо решаются общими алгоритмами, то они, обычно, мне не очень интересны, потому что ничего нового или лучшего нет.
И конечно практика великая сила. Тоже распознавание лиц очень далеко от практического применения еще, хоть и есть неплохие коммерческие реализации, работают они все равно еще мягко выражаясь — не очень. И я думаю что общими алгоритмами большого прогресса тут не достичь, нужно что-то новенькое, креативненькое.
Ну а по остальному я не во всем согласен и думаю что, как вы и написали, если будете «двигаться от общего к частному» то к нему же и придете, только потратите больше времени.
Если задачи просто и хорошо решаются общими алгоритмами, то они, обычно, мне не очень интересны, потому что ничего нового или лучшего нет.
И конечно практика великая сила. Тоже распознавание лиц очень далеко от практического применения еще, хоть и есть неплохие коммерческие реализации, работают они все равно еще мягко выражаясь — не очень. И я думаю что общими алгоритмами большого прогресса тут не достичь, нужно что-то новенькое, креативненькое.
Так отдельные внутренние области идентичны фону, контур остаётся видимым, и по нему можно спокойно вычислить площадь. Ну, опять же, в качестве формального доказательства.
Вот я как раз придерживаюсь мнения, что идя от общего к частному, вы решите задачу гораздо быстрей.
Это ещё смотря что вы имеете ввиду под промышленным применением. Тот же хааровский классификатор в стандартной библиотеке OpenCV даже с дефолтными данными вполне неплохо себя ведёт, а при желании можно и перетренировать под то, что больше подходит к задаче. Я уже не говорю о более крутых штуках типа FaceTracker (страница сейчас недоступна, так что ищите видео по ключевым словам «face tracker jason saragih»).
Вот я как раз придерживаюсь мнения, что идя от общего к частному, вы решите задачу гораздо быстрей.
Это ещё смотря что вы имеете ввиду под промышленным применением. Тот же хааровский классификатор в стандартной библиотеке OpenCV даже с дефолтными данными вполне неплохо себя ведёт, а при желании можно и перетренировать под то, что больше подходит к задаче. Я уже не говорю о более крутых штуках типа FaceTracker (страница сейчас недоступна, так что ищите видео по ключевым словам «face tracker jason saragih»).
Кстати в самом начале статьи я написал что в конкретном случае правильнее было назвать «машинное зрение» — это применение компьютерного зрения для промышленности и производства.
Очень часто наблюдаю, что для решения прикладных задач, в том числе контроля качества, заказчики плачут, колются, но продолжают заказывать лазерные сканеры и решения на их основе. И все требуют точность в доли миллиметра. Хотя это и дорого, и не очень надежно, и удобного софта до сих пор нет. Причем мы их не заставляем (даже рекламы сканера нигде не даем) — они сами приходят. Они мазохисты?
Не знаю, много ли это, или мало, но мы ведем список компаний, которые занимаются КЗ в России graphicon.ru/ru/russia/companies
Это только компании, здесь не указаны исследовательские группы при университетах, например.
Это только компании, здесь не указаны исследовательские группы при университетах, например.
По моему, вы поняли термин Спольски «костыльный программист» с точностью до наоборот. В посте говорилось о том, что есть люди, которые просо берут и делают рабочий код, простейшим путем. В рамках этого поста — это как раз таки вы, по сравнению с командой «математиков». А вот «математики» — это астронавты. Спольски понимает «костыль» несколько по другому. Это у нас он ассоциируется с кривым обходом багов в плохо написанном жутко сложном коде.
возможно да, но я этот термин использовал в посте так как он ассоциируется у нас. Для меня и для большинства это значит буквально: на костылях можно хоть и хреново но как то передвигаться, а нормально ходить и тем более бегать с ними никак не получится. Пример про костыли очень наглядный, т.к. в медицине при сложных переломах после операции, когда кости неправильно срастаются, очень часто бывает что врачи ломают снова и складывают еще раз, иногда даже несколько. Как и в медицине в программировании результат часто сразу нельзя увидеть нужно сложить по другому посмотреть на результат, потом еще может потребоваться несколько раз. Ну а тем временем можно хоть как-то на костылях передвигаться. А если не поломать и не сложить кости правильно, то человек может остаться инвалидом, и в лучшем случае будет прихрамывать всю жизнь.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Почему компьютерное зрение очень мало используется на практике