Pull to refresh
10
0
Viktor Sarbash @sarbash

Full Stack Developer

Send message
Такое часто бывает когда продукт(проект) сильно вырастает и меняется на столько что он перестает быть тем чем планировался быть(чем проектировался). Очень часто заказчики заказывают одно — получают это, и понимают что лучше сделать по другому, и не программную часть, а сами процессы, иногда даже принципы и структуры предприятий меняются, когда заказчики получают данные и понимание. Кроме того с течением времени все быстро меняется, техника, технологии, структуры, объемы и т.д.
Так что в этом случае действительно нужно остановиться и завязать шнурки, а лучше сменить на обувь без шнурков или даже скорее вместо того чтобы бежать — пересесть на велосипед и ехать быстрее, потом автомобиль, самолет… ракету… Ведь задача не в беге ради бега в обуви со шнурками, а нужно преодолевать бОльшие расстояние за меньшее время… в нашме случае это наверно меньше кода — больше и лучше выполняемых операций… эволюция, как-то так.
вот нашел кстати возможно оно — Symantec 50-Day Education Corporate Pass
Ключевой момент тут 50 дней, явный триал, поэтому скорее всего это генератор или активатор(валидатор) ключей или лицензий, система защиты дающая возможность работать с каким-то корпоративным продуктом в течении 50 дней в сети.
Если различий нет вообще и «100% идентична фону» — объект становится невидимым и никакой алгоритм не посчитает.

Ну а по остальному я не во всем согласен и думаю что, как вы и написали, если будете «двигаться от общего к частному» то к нему же и придете, только потратите больше времени.
Если задачи просто и хорошо решаются общими алгоритмами, то они, обычно, мне не очень интересны, потому что ничего нового или лучшего нет.
И конечно практика великая сила. Тоже распознавание лиц очень далеко от практического применения еще, хоть и есть неплохие коммерческие реализации, работают они все равно еще мягко выражаясь — не очень. И я думаю что общими алгоритмами большого прогресса тут не достичь, нужно что-то новенькое, креативненькое.
вот правильно сказали «частный случай», и на практике все будет частными случаями, а многие методы не будут работать совсем или с такой погрешностью что их реально использовать нельзя. Да еще в добавок придется написать алгоритм выбора методов по картинке, т.к. результаты будут прямо-пропорциональны правильности определения методов.

Я не говорил что мат. методы просты или сложны, они разные, я говорил что их неправильно выбирают и применяют, понимание приходит когда начинаешь делать на практике а не в теории, но иногда и не приходит, и тогда получаются плохие результаты.

На счет контуров, тоже еще раз говорю — цвета не идентичны и будут отличаться и достаточно четко даже в плохой ч/б камере, если только поверхность не сделана из того же материала при чем из той же партии и из того же сырья. На iPhone в частности можно даже достаточно точно выделить участки(пиксели) где есть отпечатки пальцев(они не бликуют). Глянцевые поверхности очень сильно бликуют, и ваша картинке iPhone c контуром наглядно показывает как сильно влияют тени, блики и освещение на выделение контура, да и на все остальное тоже, это все частные случаи и их можно обойти тоже используя другие частные случаи(методы).
Я напишу как нибудь пост на эту тему, думаю практика будет интересна многим, там можно продолжить, а тут уже вроде все и так разобрали больше чем нужно.

p.s.
я написал вам личное сообщение
я и не говорил о них, это вы предлагали «более общие» алгоритмы, контуры, кривые и т.д. и только когда «разделали шкуру» наверно поняли. Если еще глубже разобраться то я думаю увидите четко и ясно что мой метод лучше и Ваш iPhone и моя шкура :) считается в один проход моментально без выделения контура, интегрирования и других общих методов. Если хотите продолжить давайте поговорим о получении контуров, чтобы понять что это тоже ничего не дает с точки зрения даже не знаю уже чего, наверно «более общих методов», но по-моему их лучше называть как-то конкретно?
А там я могу много рассказать о коррекции(нормализации) цветов, о том как определить фон без снимка фона и что на практике получается (почему лучше со снимком), как влияет цвет поверхности фона, блики, тени, освещение и т.д., правда наверно слишком много получится, лучше написать еще один пост на эту тему.
я все прекрасно понимаю, и вижу что начали понимать, вы говорите о методе применения, а я говорю о сути (сущности) самого метода интегрирования. Когда вы только называете слово интегрирование это уже подразумевает разложение, преобразование, приведение и т.д. и кривые от этого не станут прямыми и погрешность никуда не уйдет.
Есть погрешность и в моем методе я же писал, но она обусловлена размером пикселя(клетки) и высотой от камеры, если вы поняли суть интегрирования то должны понять что мой метод в сущности это тоже самое только намного проще и быстрее с минимальной погрешностью и никак не зависит от сложности фигуры, не требует разбиения и т.д. ну и тем более что это не хак или что там еще вы писали, а очень простой и хороший алгоритм, кроме того проверенный на практике. И никакие «более общие методы» не дают никаких преимуществ.
На счет 3D в нашем случае зная угол камеры, можно добвить ось Z и ее длину (дальность камеры) и реконструировать изображение до положения камеры сверху, это только один из способов. Но речь в общем не об этом шла 3D я как один из вариантов.

В том-то и дело что я хорошо понимаю и как считается и как это работает, поэтому и говорю что погрешность в самом методе, если только не интегрировать до бесконечных пределов, а на практике это не реально.
Это погрешность часто называется интегральная нелинейность, из этого же рисунка выше видно, что кривые аппроксимируется прямой линией по методу наименьших квадратов. Понимаете?
Причем эта погрешность есть даже на уровне АЦП в любых интегральных чипах на уровне сигналов, и вообще в любом АЦП и DSP процессорах, в том числе в CISC процессорах. Более того скажу что в современных процессорах используется RISC архитектура с некоторыми инструкциями в которых по этой же причине точность вычислений меньше. Есть байка, и многие считают что это правда, что в NASA было несколько провалов миссий из-за того что они делали все просчеты на новых RISC процессорах. На самом деле погрешность очень маленькая и связана она уже с самими вычислителями, но тем не менее, интегральная погрешность есть, и даже не спорьте.

И вот вы все же пришли наконец к тому что нужно делить на области. А как определить эти области(точки)? я имею ввиду алгоритм для любой произвольной фигуры типа шкуры только например еще сложнее, например с сотней различный по форме ответвлений, с заворотами и т.п.?
3D реконструкцию как раз можно сделать достаточно точно, собственно то что вы написали ранее т.е. просчет при известном наклоне камеры по сути и есть 3D реконструкция, т.к. картинку вы фактически должны перевести из одной плоскости в другую так или иначе. Более того есть готовые приставки которые конвертируют видео 2D в 3D на лету, в новых дорогих телевизорах есть встроенная такая система по крайней мере в samsung и вполне нормально работает.

Вот примерно как у вас на картинке контуры так и будет все работать, нужно было сделать еще под двойным углом и на таком же фоне, как вы предлагали… догадываетесь какой бы получился контур.

Кроме того мы говорим о произвольной фигуре и общем методе для всего, представьте например шкуру животного, график функции говорите..., ну посчитайте такой контур
image

Составьте хотя бы определенный интеграл, не говоря уже о разбивке (алгоритме построения этого интеграла) и я надеюсь поймете. Вы говорите о применении интеграла по графику функции а я говорил о самом принципе интегрирования, т.е. сама суть интегрального метода на практике неизбежно приводит к погрешности. Если бы вы прочитали внимательно хотя бы ту ссылку что я писал выше в самом начале про суть интегрального исчисления то может и не писали бы тут столько, но в любом случае это полезно, может быть и я чего-то не понимаю, или вы и это позволит нам хотябы посмотреть на это с другой стороны.
конечно, можно даже сделать реконструкцию 3D и заодно посчитать объем, но это в теории, а на практике не получается пока нормально.

Я не понимаю что вы имеете ввиду «кривые» уже определены как они определены? каким методом? как разбивается фигура? есть же много методов.

И не надо пожалуйста менять мой алгоритм, он работает совсем не так, а то что вы написали не понято что делает и при чем тут четные/нечетные
ну не сможете Вы решить эту проблему с приемлемым уровнем погрешности, если будет камера слишком далеко, высоко, под большим углом, если в кадре будет наложение других объектов и т.п. все что вы придумывали.
Конечно представляю, и простейший я написал выше, а тот где «тупо берётся интеграл разницы между значениями первой кривой и второй» еще сложнее с точки зрения реализации алгоритма разбивки и определения этих кривых, т.к. графики и кривые не заданы еще, их нужно разбить и определить для начала.
Зарплату работнику, который считает вручную. Я как раз и говорю что организационно решить проблему и установить систему будет дешевле чем платить зарплату. Камеру установить вертикально или с минимальным углом наклона, в подавляющем большинстве случаев не представляет проблемы.

И опять таки с ватманом притянуто, и если даже так то на практике полного совпадения цветов не будет, если только ватманы эти из одного рулона. А если нет то цвета можно отличить, ну и конечно на практике никто не будет на белом фоне мерять белый ватман, а с контуром или любым другим общим методом при совпадении цветов — контур получить очень проблематично и моим методом тоже.

Самая простая интеграция требует разбивки полученного контура на составляющие фигуры и интеграцию в пределах числа этих фигур и их площадей, поэтому мой метод никак не становится эквивалентным интегрированию потому что нет никакой разбивки в принципе и площадь считается в чистом виде. Если притянуть за уши, и принять что есть попиксельная разбивка, то она максимально приближена к мельчайшей фигуре их число и их и площади известны поэтому только простейшее суммирование. А интегральным методом сначала нужно разбить на разные части, посчитать их площади, и потом только сложить. А алгоритмы разбивки на части еще сложнее и тоже масса нюансов.
Может конечно я плохо объяснил, но раз такое пишите то похоже что не до конца поняли.
На практике фон не сливается с объектами, а если и сливается то объект становится не видимым. Но не забывайте что камера может лучше человека различать цвета, в картинке можно увеличить контраст и уже будет разница достаточная для определения, которую человек не увидит. плюс камеры видят в ИК диапазоне и в темноте с ИК подсветкой может отлично работать.
Закрепить камеру правильно и создать условия освещения, все равно вышло бы дешевле чем платить все время зарплату.

Цвета металла или чего другого никак не повлияет, а вот если метал или что угодно будет сливаться с фоном, то это ставит крест на любом методе. Ни один алгоритм не сможет этого сделать.
И кстати найдя замкнутые контуры можно также посчитать площадь моим методом, а не математическим.
Кстати в самом начале статьи я написал что в конкретном случае правильнее было назвать «машинное зрение» — это применение компьютерного зрения для промышленности и производства.
ну опять за уши притягиваете… во первых площадь там не нужна, а животное или еще что-то определять не нужно, чтобы там не было разметка или препятствие, оно определяется совсем другими алгоритмами.
А разметку на дороге нужно отслеживать совсем по другому вот один из свежих и то достаточно большая погрешность, с этим неплохо справлялась даже OpenCV 5 лет назад. А посчитать площадь моим алгоритмом можно без проблем с любым фоном, и с любым углом камеры, только погрешность увеличится. В моем посте снимок фона делался для большей точности, но цвет фона можно легко определять например по бОльшему числу откорректированых значений цветов пикселей, определяются значимые и фоновые пиксели или др. способом.
В идеале детектится полоса разметки любым методом, а площадь считается по числу пикселей, а не интегральным методом, мы же говорили о мат. методе подсчета.

> определение площади грузовиков в Ираке по снимкам со спутника, определение площади товаров при наклоне камеры, определение площади товара на произвольной поверхности (произвольного цвета и интенсивности)

Хоть и нереальные задачи вы придумываете но еще раз говорю этот алгоритм вычислит площадь и в этих и любых других задачах лучше любого другого!!!

Моя позиция в том что что-то не так с CV и возможно, я не уотверждаю, что да, проблема в излишней сложности, иногда в самих подходах к решению задачи, в то время как их можно решить намного проще и эффективнее. Хотя бы исходя из того преимущества, что входные данные уже есть, что не нужно тратить ресурсы на лишние вычисления, а только правильно воспользоваться входящими данными, и мой пост тому пример.
и опять вы туда же…
>Возьмите задачу «измерение площади товара» и уберите из него «товар», заменив его на более общее «объект»

«объект» очень растяжимое понятие… но все что касается площади — мой алгоритм ее решит точнее и быстрее любых других.

>более общие алгоритмы не способны дать достаточную для продакшена точность

Я этого не говорил, но я утверждаю что конкретно этот алгоритм даст наивысшую точность и скорость в задаче «определения площади по картинке камеры», и более того применим в любой отрасли и для любых «объектов», возможно с небольшими корректировками чисто по обработке изображений но без изменения метода вычисления площади.

Если вы пытаетесь доказать что общий метод в общем случае может быть лучше, то я с этим не спорю, честно говоря я уже даже не понимаю что вы имеете ввиду под «обобщеными методами» если чисто мат. метод итегрального исчисления то я согласен, в общем случае и многих частных тоже, но только не в этом, он сильно проигрывает в точности и скорости.

>можете привести примеры более распространённых задач (читать как: задачи, над которыми работала больше, чем одна группа разработчиков)

не могу, по крайней мере таких которые реально работают не видел, даже на выставках крайне редко что-то хорошо работает.

>2:0 в пользу более общих алгоритмов
Я не понимаю что такое «более общие» алгоритмы, я за то чтобы общие алгоритмы (их много) состояли из хороших и проверенных на практике а общих или нет, это уже вопрос, если их станут применять большинство то они станут общими, если нет то нет.
Вот конкретно в CV в общие алгоритмы можно спокойно добавить как составную часть определение плошади по моему алгоритму и от этого CV только выиграет и проиграет если будет считать площадь интегральными или другими методоми
Ну так задачи же совершенно разные, и нельзя, нет скорее невозможно придумать один алгоритм для решения всех задач с использованием камеры. Давайте абстрагируем так: даже если бы удалось придумать супер алгоритм с ИНС и возможностями приближенными к человеческим, все равно он не позволит с такой же точностью и легкостью вычислить площадь любой фигуры, но зато будет прекрасно определять открытие двери, фильтровать погоду и шумы камер.

Я этот пост написал для того чтобы задумались, может быть в этом и проблема, что CV до сих пор никак не выйдет на должный уровень, потому что возможно одна из причин есть «наиболее общие алгоритмы», которые на практике сильно теряют эффективность. Если оно никак не выходит из начинающей стадии, может стоит пересмотреть «общепринятый (по крайней мере в научных работах) подход». Научные работы нужно адаптировать к реалиям.
Я считал что проблема больше связана с подходами в программировании в общем и реализациями в этой области в частности, но если вы так усиленно доказываете что это плохо, то похоже она еще глубже.

Вот давайте так, «общепринятый» подход — хорошо, я не против него, он состоит из одного алгоритма? одной формулы? Нет, он включает в себя множество других алгоритмов, формул и методик и т.д. так вот эти отдельные алгоритмы тоже могут применяться в рамках реализации одной конкретной задачи отдельно, и одни хороши для одной задачи и совершенно не пригодны для другой.

>вы всё время ищете ad hoc алгоритмы
Конечно же я этого не делаю, я честно говоря очень удивлен, тем что вы все время искажаете все, например что я ищу, я применяю, причем «все время» и хуже всего что совершенно разные задачи пытаетесь свести вместе
с чего вы решили что это мой подход? я же нигде не писал что этот подход применим для всех задач, а наоборот акцентировал на том, что именно для этой конкретной задачи он самый лучший. Вы все время пытаетесь перевести на другие задачи этот алгоритм, предназначенный и отработанный исключительно для площади, я уже устал писать что этого делать не нужно.
Относительно метода с ИНС (нейронная сеть) для таких задач может неплохо работать для одних задач, и плохо для других, об «обучении» и нечеткой логике тут затевать спор я думаю не стоит, но даже если идеально подобрать все параметры и смоделировать сложную, гибридную ИНС для этой задачи, все равно не будет 100% надежного определения, а простой метод детекции пикселей с указанием зоны на камере, может работать лучше и быстрее и кстати на практике в охранном видеонаблюдении вполне нормально работает в помещениях в большинстве случаев.
Но я согласен что ИНС метод может работать в определенных условиях намного лучше чем простой детектор движения, я занимался таким детектором для охранки, в результате получилась намного меньше ложных сработок при детекции движения во время дождей, снега и др. и в темное время суток, намного лучше работает в ночном режиме при плохом освещении, когда камера дает много шума.

Information

Rating
Does not participate
Location
Киев, Киевская обл., Украина
Date of birth
Registered
Activity