мы говорим не о теории, любые приближения подразумевают погрешность, а в моем алгоритме единственная возможная погрешность в разрешении камеры, т.е. входящих данных, но они для вычисления берутся с камеры такого же разрешения для любого метода и алгоритма. Не говоря уже о том чтобы брать бесконечно малые пределы интеграции на практике(это очень ресурсоемкая задача учитывая что обрабатывать нужно 25 кадров в секунду), поэтому на практике будет погрешность.
> Президент Украины Виктор Янукович подписал Закон…
Законом предусмотрено временно, с 1 января 2013 года до 1 января 2023 года
Обратите внимение на это. Больше похоже на предвыборные обещания, как раз только началась кампания предвыборная.
Типа ИТ-шники голосуйте за Януковича…
А пройдут выборы в октябре, даже если выиграет, в ноябре парламент с такой же легкостью отменит закон и все дела а президент не виноват, сделал все что смог.
>> сложные математические модели — это не есть абсолютное зло, они действительно имеют право на жизнь и на практике используются довольно часто
Я полностью согласен, но всегда есть исключения и в этом случае это именно оно.
Даже математических способов решения задач бывает очень много и далеко не всегда выбираются самые лучшие или хотя бы простые. Обычно чем сложнее решение, тем оно менее надежно, и вероятность поломки или неправильной работы растет пропорционально сложности, это не только в программировании и компьютерах но и практически в любой технике чем больше узлов и деталей тем более вероятна ошибка или просчет.
А в CV еще более вероятно, потому что нужно правильно выбрать мат. модели, правильно скомпоновать все последовательности, очень много испытаний проводить не в лабораторных условиях. Не говоря уже о инструментах и проектировании.
И конечно же ни в коем случае не пытаться делать универсальных решений, типа как вы писали выше… это ошибочный, если хотите, — тупиковый путь, за универсальность как правило расплачиваются качеством, надежностью или чем-то другим. Это тоже, не только в компьютерах а в общем. Когда будут уже готовые, отточенные и хорошо работающие решения для разных задач, вот тогда можно при необходимости попробовать скомбинировать некоторые.
Это наиболее правильный подход подход и конечно же применим в общем случае для всего, а не только CV.
возможно да, но я этот термин использовал в посте так как он ассоциируется у нас. Для меня и для большинства это значит буквально: на костылях можно хоть и хреново но как то передвигаться, а нормально ходить и тем более бегать с ними никак не получится. Пример про костыли очень наглядный, т.к. в медицине при сложных переломах после операции, когда кости неправильно срастаются, очень часто бывает что врачи ломают снова и складывают еще раз, иногда даже несколько. Как и в медицине в программировании результат часто сразу нельзя увидеть нужно сложить по другому посмотреть на результат, потом еще может потребоваться несколько раз. Ну а тем временем можно хоть как-то на костылях передвигаться. А если не поломать и не сложить кости правильно, то человек может остаться инвалидом, и в лучшем случае будет прихрамывать всю жизнь.
это же совершенно разные задачи… если так подходить, «а если камеру пальцем зактнуть» — включается подстветка и камера превращается в биометрический сканер, сканирует отпечаток, проводит идентификацию и связывается с ФБР, ну сами подумайте… не нужно за уши притягивать то чего нет.
Перспективные искажения есть в любой камере в данном случае они очень малы поэтому и не учитываются, к тому же калибровка частично учитывает и эти искажения.
Если будут такие задачи то конечно же я не будут использовать этот алгоритм, т.к. он для этого не предназначен.
А ребята из другой компании делали абсолютно тоже самое и провалили заказ, клиент вынужден был отказаться от ихнего решения, они пытались клиента убедить что лучшего результата достичь невозможно и т.п. после этого мне с большим трудом удалось уговорить клиента хотя бы посмотреть мое решение.
Ну это не тот случай, вы или не понимаете что такое «хак»или не понимаете как работает алгоритм или не знаете мат.часть. посмотрите внимательно ссылку выше там где картинка в моем комментарии.
Если снимать фон без предмета будет правильно показывать ноль, стабильность фона тоже, т.к. цвета корректируются по очень многим параметрам, и никакие «более сложные модели» не окажутся устойчивыми «к таким изменениям». И главное отличие от хака, в том что точность будет выше при любых раскладах т.к. это идеальный алгоритм для определения площади по изображению с камеры.
В этом алгоритме тоже очень много практических применений, в разных отраслях и типах объектов измерения, возможно отраслей даже больше чем в распознавании образов.
На счет Google я тоже надеюсь что ждать осталось недолго.
Я имел ввиду разработчики — компании, которые выпустили что-то реально работающее, а людей интересующихся конечно больше. Не думаю что это «хак». Это как раз полноценный и правильный алгоритм для решения конкретной задачи, и именно для этой задачи он предназначен изначально. Для других задач лучше делать другие хорошие алгоритмы. Сделать универсальный алгоритм для решения «широкого круга задач» — практически не реально. Думаю что и в будущем ни один другой алгоритм не сможет превзойти этот, потому что как я выше писал про мат.часть, — площадь вычисляется абсолютно, без каких либо искажений, приближений и погрешностей самого вычисления т.е. при идеальных условиях будет абсолютно точная площадь.
На счет убеждения заказчиков согласен, вот только стадия созревания слишком затянулась.
да, скорее больше ранний этап развития области, хотя он наверно не такой уже и ранний, например биометрия используется намного больше, хотя появилась чуть позже.
Тут наверно не столько кривизна рук конкретных разработчиков, сколько кривизна мозгов и подходе в общем, во всяком случае в рамках этого примера, я думаю подобных примеров у многих есть, так что этот пример не редкость вообще, а в этой области в частности, учитывая что в этом направлении не так уж много разработчиков работает, на сколько я знаю их всего несколько десятков, и вполне возможно что просто нет удачных решений еще. Инфраструктура возможно тоже играет роль.
Тот же openCV, как я писал, была гораздо хуже, с последней версией я еще пока не работал, так что ничего не могу сказать пока, но я просматривал код, в общем конечно лучше намного, но на практике еще не пробовал.
Еще такой момент, что на этом заработать сложновато, даже просто убедить заказчика попробовать готовое решение не так просто и особого смысла развивать это направление я пока не вижу, поэтому больше занимаюсь биометрией и другими проектами.
В любом случае для меня это все еще вопрос без ответа. Я надеюсь больше на Google когда они свои автопилоты запустят в серийные авто и откроют код, вот это я думаю и будет рывок.
они очень малы, обычно высота продукции очень мала, а камера относительно высоко крепится, ну и калибровка по однотипной продукции делается, во всяком случае по высоте однотипная в основном.
Например оптический шум, тени, блики, освещение гораздо сильнее влияют на погрешность.
Если кто не знает почитайте обязательно, там погрешность в самом методе вычисления, картинка выше из WiKi наглядно это иллюстрирует. Я не стал писать мат. часть в посте т.к. подумал что это многих бы утомило, для меня это понятно все, почему решил что все понятно написал, нужно было хоть этот рисунок вставить и ссылку.
да, где-то так, а если серьезно то в моем алгоритме площадь точнее вычисляется, т.к. она вычисляется абсолютно, а не математически. Если кто не знает посмотрите мат. часть:
Из WiKi "интегральное исчисление возникло из потребности создания общего метода нахождения площадей"
Если просто, то на самом деле площадь примерно как на картинке и вычисляется с помощью интегралов в общем случае для разных фигур.
Если чисто по алгоритму у меня немного проще, если по системе то намного сложнее. Больше всего кода на обработку картинки, фильтрацию шума, и корректировки цветов, в зависимости от освещения и и т.д.
Если не работали с обработкой изображений, особенно с видео (25 кадров в секунду) то сразу так может быть трудно понять, много тонкостей, а описывать подробно все очень долго тут. Если коротко то очень много параметров нужно учитывать и даже определить изменения пикселя не так просто как кажется, многое зависит от самой камеры, от разрешения, от платы захвата видео и типа и кодирования сигнала, а в статье я все упрощенно написал конечно.
да, и это тоже. Если делать эту систему с использованием ООП то все равно нужно сначала реализовать алгоритм без ООП, посмотреть какие параметры функции можно сгруппировать, обычно это сразу видно и они аж сами просятся, и потом только их вынести в класс, обычно это делается когда все уже четко работает, для упрощения понимания, дальнейшей работы и сопровождения.
Абстрагирую вот так сначала что-то сотвори, а потом уже «разделяй и властвуй». А когда еще ничего нет лучше этого не делать.
Да можно конечно сделать сразу классы и т.д. и сразу угадать что все будет именно так, что мало вероятно но бывает, только в простеньких проектах, и когда делают это очень и очень опытные программисты, имеющие очень большой опыт при работе с конкретной задачей, в этом случае как раз и применяют шаблоны проектирования сверху вниз.
А вот когда это не так и функциональный код пытаются подогнать под структуру проекта(классов) и т.п. вот это уже скорее и есть то зло о котором я писал.
В принципе это не противоречит ООП, просто чаще всего его используют сверху вниз, вот как примерно Вы «сходу» 3 класса, в том числе ключевой алгоритм и т.д. при этом не имея еще никакого понятия, как будет работать алгоритм, какие параметры, коэфициенты цветов, когда их нужно корректировать и т.п. В том то и дело что в этой системе, как и в большинстве других подобных ООП в принципе не нужно, да можно коненчо и с ним, но все лучше сделать без единого класса и на чистом Си, даже код будет понятней и быстрее работать, т.к. эта система критична к скорости, потом можно даже вынести в отдельный модуль/библиотеку. Если вы не можете представить себе такое и сразу беретесь за классы — то я думаю это плохо, это то что я пытался донести в этом посте.
Раньше я тоже очень увлекался ООП и сходу клепал классы и т.д. но позже я с этим стал очень осторожен, а часто не использую вовсе, в зависимости от проекта.
Законом предусмотрено временно, с 1 января 2013 года до 1 января 2023 года
Обратите внимение на это. Больше похоже на предвыборные обещания, как раз только началась кампания предвыборная.
Типа ИТ-шники голосуйте за Януковича…
А пройдут выборы в октябре, даже если выиграет, в ноябре парламент с такой же легкостью отменит закон и все дела а президент не виноват, сделал все что смог.
Я полностью согласен, но всегда есть исключения и в этом случае это именно оно.
Даже математических способов решения задач бывает очень много и далеко не всегда выбираются самые лучшие или хотя бы простые. Обычно чем сложнее решение, тем оно менее надежно, и вероятность поломки или неправильной работы растет пропорционально сложности, это не только в программировании и компьютерах но и практически в любой технике чем больше узлов и деталей тем более вероятна ошибка или просчет.
А в CV еще более вероятно, потому что нужно правильно выбрать мат. модели, правильно скомпоновать все последовательности, очень много испытаний проводить не в лабораторных условиях. Не говоря уже о инструментах и проектировании.
И конечно же ни в коем случае не пытаться делать универсальных решений, типа как вы писали выше… это ошибочный, если хотите, — тупиковый путь, за универсальность как правило расплачиваются качеством, надежностью или чем-то другим. Это тоже, не только в компьютерах а в общем. Когда будут уже готовые, отточенные и хорошо работающие решения для разных задач, вот тогда можно при необходимости попробовать скомбинировать некоторые.
Это наиболее правильный подход подход и конечно же применим в общем случае для всего, а не только CV.
Перспективные искажения есть в любой камере в данном случае они очень малы поэтому и не учитываются, к тому же калибровка частично учитывает и эти искажения.
Если будут такие задачи то конечно же я не будут использовать этот алгоритм, т.к. он для этого не предназначен.
А ребята из другой компании делали абсолютно тоже самое и провалили заказ, клиент вынужден был отказаться от ихнего решения, они пытались клиента убедить что лучшего результата достичь невозможно и т.п. после этого мне с большим трудом удалось уговорить клиента хотя бы посмотреть мое решение.
Если снимать фон без предмета будет правильно показывать ноль, стабильность фона тоже, т.к. цвета корректируются по очень многим параметрам, и никакие «более сложные модели» не окажутся устойчивыми «к таким изменениям». И главное отличие от хака, в том что точность будет выше при любых раскладах т.к. это идеальный алгоритм для определения площади по изображению с камеры.
В этом алгоритме тоже очень много практических применений, в разных отраслях и типах объектов измерения, возможно отраслей даже больше чем в распознавании образов.
На счет Google я тоже надеюсь что ждать осталось недолго.
На счет убеждения заказчиков согласен, вот только стадия созревания слишком затянулась.
Тут наверно не столько кривизна рук конкретных разработчиков, сколько кривизна мозгов и подходе в общем, во всяком случае в рамках этого примера, я думаю подобных примеров у многих есть, так что этот пример не редкость вообще, а в этой области в частности, учитывая что в этом направлении не так уж много разработчиков работает, на сколько я знаю их всего несколько десятков, и вполне возможно что просто нет удачных решений еще. Инфраструктура возможно тоже играет роль.
Тот же openCV, как я писал, была гораздо хуже, с последней версией я еще пока не работал, так что ничего не могу сказать пока, но я просматривал код, в общем конечно лучше намного, но на практике еще не пробовал.
Еще такой момент, что на этом заработать сложновато, даже просто убедить заказчика попробовать готовое решение не так просто и особого смысла развивать это направление я пока не вижу, поэтому больше занимаюсь биометрией и другими проектами.
В любом случае для меня это все еще вопрос без ответа. Я надеюсь больше на Google когда они свои автопилоты запустят в серийные авто и откроют код, вот это я думаю и будет рывок.
Например оптический шум, тени, блики, освещение гораздо сильнее влияют на погрешность.
Из WiKi "интегральное исчисление возникло из потребности создания общего метода нахождения площадей"
Если просто, то на самом деле площадь примерно как на картинке и вычисляется с помощью интегралов в общем случае для разных фигур.
Если не работали с обработкой изображений, особенно с видео (25 кадров в секунду) то сразу так может быть трудно понять, много тонкостей, а описывать подробно все очень долго тут. Если коротко то очень много параметров нужно учитывать и даже определить изменения пикселя не так просто как кажется, многое зависит от самой камеры, от разрешения, от платы захвата видео и типа и кодирования сигнала, а в статье я все упрощенно написал конечно.
Абстрагирую вот так сначала что-то сотвори, а потом уже «разделяй и властвуй». А когда еще ничего нет лучше этого не делать.
Да можно конечно сделать сразу классы и т.д. и сразу угадать что все будет именно так, что мало вероятно но бывает, только в простеньких проектах, и когда делают это очень и очень опытные программисты, имеющие очень большой опыт при работе с конкретной задачей, в этом случае как раз и применяют шаблоны проектирования сверху вниз.
А вот когда это не так и функциональный код пытаются подогнать под структуру проекта(классов) и т.п. вот это уже скорее и есть то зло о котором я писал.
Раньше я тоже очень увлекался ООП и сходу клепал классы и т.д. но позже я с этим стал очень осторожен, а часто не использую вовсе, в зависимости от проекта.