LINUX.ORG.RU
ФорумJob

Оценка времени и стоимости создания программы распознавания/сортировки изображений по шаблонам.

 , ,


0

2

Оценка времени и стоимости создания программы распознавания/сортировки изображений по шаблонам.

Добрый день. Пожалуйста, подскажите примерные порядки сроков и стоимости для написания ПО с ниже приведенным функционалом. Какими технологиями(помимо opencv) стоит поинтересоваться? *Заранее извиняюсь за несколько скомканное и сбивчивое описание, мне ТЗ проще нарисовать, чем описать не на десятке страниц. )

С фотографии(большого разрешения, на белом\черном фоне) пластиковых распечатанных деталей нужно выделить предметы по контурам (треугольный, параллелепипед, круг), вырезать их с отступами по отдельным файлам, назвать по маске и занести в БД. Далее отдельные предметы идут на автоматическое распознавание внешних и внутренних контуров по принципу:

Параллелограмм

  • прямоугольное (по соотношению сторон, краевым контурам)
    • уголок
      • с 3 круглыми отверстиями
      • с 2 крестообразными
      • с 2 круглыми с зенковкой
    • крышка (варианты разного размера и с разными внутренними элементами - бортики, ребра жесткости, отверстия под болты, надписи и т.п.)
  • квадрат
    • крышка
    • образец

Округлое

  • С ровным краем
    • Имеет внутренние контуры
      • С ободом
        • колесо
      • Без обода
        • шайбы\прокладки
    • Не имеет внутренних контуров
      • Диск(образец)
        • Разные диаметры/материал
  • С зубчатым краем
    • Шестеренка (по размеру, кол-ву зубьев, диаметру оси)
    • Гайка
    • Что-то неудавшееся круглое

Определенное, с допустимой погрешностью, называть по маске с эталона и сохранять. С погрешностями - на ручную доводку контура и дальнейшее автоматическое определение, или пометку тегами и сохранение в другом разделе. Например, изменен угол/геометрия зубьев шестерни, растянутость круглых элементов(овальная зенковка), пильчатый/слоистый край вместо ровного, непараллельность сторон гайки и т.п. - брак.

Контуры, снятые с картинки, сравнивать с заранее созданной библиотекой эталонных контурных масок. Для ее наполнения потребуется ручками доводить до приемлемого уровня контуры снятые с эталонных распечаток. Стирать лишние контуры и шумы, подтягивать/дорисовывать контур до нужного, отмечать контуры с разным приоритетом, и, по итогу, сохранить в БД. Таким образом, туда надо будет прикрутить и графический редактор, простенький, не Paint, но что-то уровня Paint.Net - слои, панельки инструментов, история и т.п. Также нужна возможность наложить на проверяемый предмет изображения эталонного и их контурные маски с настраиваемой прозрачностью/цветом.

Основная проблема мне видится в том, что изделия пластиковые, глянцевые, на них имеется масса бликов, осложняющих не только первоначальное определение формы (из-за блика на сгибе или вытянутой тени, квадрат с освещением под углом видится ромбом, а круг овалом), но и внутренних структур - блики на зенковке и трафаретных лаковых надписях, слоистая текстура самой детальки. Может, при создании эталонной маски к основной линии контура добавлять некий коридор погрешности в мм/пикселах, или прикрутить нейросеть и обучить ее на эталонных предметах, или и то, и другое, для надежности?

Подытоживая, нужна программка содержащая в себе БД, граф.редактор, распознавание образов по шаблонам с построением контуров и обучением нейросети на эталонных изображениях/контурных масках. Что касается части распознавания, то по мне, это должно быть проще лиц, навроде номеров машин, но исходные данные хорошего разрешения, с минимальными искажениями и загрязнениями. Большие сомнения вызывает нейросеть, но без нее задача кажется с трудом решаемой, даже мне не без колебаний получится провести границу между ободом и диском, т.к. в одном месте бликует и граница в пересвете, в другом в тени, да и сам скос пологий, поди разбери.

Все модули нужны не коммерческие, т.е. бесплатные, желательно открытые. Поскольку средства не бюджетные, а свои, да и распространение, продажа или другое коммерческое использование не предполагается, т.е. и к интерфейсу с рабочим окружением требования минимальны. С такими БД и граф.редактором, я думаю, проблем не возникнет, где-то мне попадался и проект открытой распознавалки номеров, может его удастся модифицировать, без написания с нуля всего распознавания на opencv. Основная работа мне видится в сведении всего этого в один инструмент, натягивании GUI и нейросети. В общем, эскиз программки таков. Что скажете?

С учетом не описанного инструментария и еще не оформившихся хотелок, все прикидки умножаю на два.

P.S. У вас тут Как правильно писать объявление о работе ссылка отклеилась www.linux.org.ru/wiki/en/Lorcode

1) Просто делать два (три или более снимка) с «разной выдержкой», потом автоматически сводить в одно с большим динамическим диапазоном.

2) Алгоритм «накладывания» похожего на похожее есть готовый --- «регистрация изображений». Только надо критерий будет «невязки» между шаблоном и снимком разработать.

3) Параметрическую модель придется для каждой детали писать самостоятельно по типу алгоритма распознавания на лице характерных точек.

psv1967 ★★★★★
()
Ответ на: комментарий от psv1967

Зачем параметрическую модель? Товарищ всё правильно сказал - нейросеть. Изображения традиционно распознаются конволюционными сетями. С геометрическими деталями, несмотря на всякие блики, точность будет не сильно меньше 100%

Bell
()
Ответ на: комментарий от Bell

Потому что «распознавать котиков» тут не надо. Задача измерить отклонения от заданного шаблона. Шаблонов у автора столь не много, что задачу «выбора шаблона» можно не напрягаться решать вообще, проще подгонять все сразу.

psv1967 ★★★★★
()
Ответ на: комментарий от psv1967

Брак отсеивать тем же классификатором. Судя по условию, главная проблема «провести границу между ободом и диском», а не измерение отклонения от шаблона. А совмещать с шаблоном можно и параметрической моделью на следющем этапе.

Bell
()
Ответ на: комментарий от Bell

Судя по условию, главная проблема «провести границу между ободом и диском»

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

PlastMove
() автор топика
Ответ на: комментарий от psv1967

1) Я уже склоняюсь к варианту со сканером. С фото выходит немало минусов — непостоянство освещения, ракурса, масштаба и т.д. У сканера из плюсов: сильное и постоянное освещение, относительно простое определение истинных размеров, отличное разрешение и легкость привязки к ПО; из минусов — всё плохо с резкостью, уже в 1,5-2 мм идёт мыло. Но, думаю, решаемо подбором сканера.

2) Спасибо за наводку по алгоритмам, много интересного опять нагуглил, но об этом ниже. Не совсем понял про «критерий невязки». Указать области в которых сравнивать относительные площади и размеры контуров в них или на сколько пикселей/долей мм допустимо отклонение снятого контура от эталонного?

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

Задача измерить отклонения от заданного шаблона.

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

Инверсно-композиционный алгоритм регистрации изображений Программная реализация алгоритма регистрации средствами языка C++ и библиотеки OpenCV

Небольшая статья АВТОМАТИЧЕСКАЯ РЕГИСТРАЦИЯ ИЗОБРАЖЕНИЙ, ОСНОВАННАЯ НА СРАВНЕНИИ КОНТУРОВ

Немного матчасти по сканированию Формирование и регистрация изображения в выводных устройствах

ВНИМАНИЕ! Тяжёлый pdf.Диссертация на доктора. Много матана, решения искажений, смазанности, бликов, размытости и прочее.Методы и алгоритмы автоматической обработки изображений радужной оболочки глаза.

Да и тут поднимались родственные темы: Development Talks

И тут переходим к главной проблеме: Сколько? Найти фрилансера, способного сделать сайт, простенький GUI к БД или бух.учёту, не проблема, даже по знакомым. Но я, к сожалению, не программист. ( И выбор конкретных технических решений для реализации задачи предпочту оставить за узкими специалистами.

По теме топика хотелось бы услышать комментарии людей оперирующих мат.аппаратом из выше приведенных статей или писавших ПО распознавания номеров, документов, лиц и т.п. Сколько часов уйдет у Сферического фрилансера в теме на это, и какой порядок $ это станет. Несколько потыкавшись по открытым (а их немного) прайсам софтверных контор, получилось, что одна разработка ТЗ обойдется в 35 ±5т.р. (

PlastMove
() автор топика
Ответ на: комментарий от PlastMove

По теме топика хотелось бы услышать комментарии людей оперирующих мат.аппаратом из выше приведенных статей или писавших ПО распознавания номеров, документов, лиц и т.п. Сколько часов уйдет у Сферического фрилансера в теме на это, и какой порядок $ это станет.

У меня классификатор таких изображений вероятно занял бы 1-2 месяца до рабочего прототипа на Питоне. Однако к мат.аппарату из приведенных статей прямого отношения это не имеет. В любом случае сначала надо видеть изображения. По деньгам не в курсе. Еще одна идея против бликов - снимать через поляризационный фильтр.

Bell
()
Ответ на: комментарий от PlastMove

Тут есть две задачи на самом деле:

1) Некий CAD(САПР) в котором представимы детальки заданные в параметрическом виде и куда можно загружать некие аппроксимации снятого камерой. Нужно что бы поддерживался режим «наложения одного на другого» с возможностью мышкой по тягать параметрическую модель.

2) Нужен алгоритм фита параметров параметрической модели, что бы она наиболее точно заполнила контур детали.

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

То есть нужно искать спеца по CAD прежде всего.

psv1967 ★★★★★
()
Ответ на: комментарий от Bell

1-2 месяца до рабочего прототипа

Т.е. около 200 часов. Попробовал отсканировать рубли. Масштаб деталей практически аналогичный, те же проблемы с бликами и границами, только с резкостью получше, рельеф низкий. При размере в 5-10 раз меньше заготовок, разделение 1 и 10 руб. или по годам, думаю, что будет достаточно. Если еще и знак мон.двора различится, вообще прекрасно, можно будет искажения слоев ловить.

поляризационный фильтр

Ай, спасибо! Уж и сам забыл как рыбачил в очках с ним. Где здесь в карме отметиться можно?

Пойду искать убитый ЖК и апгрейдить сканер.

PlastMove
() автор топика
Ответ на: комментарий от psv1967

1) Да! Но, САПР немного громко сказано. Какой-то гибрид 2D САПР без инженерно-вычислительной части и Adobe Illustrator, низведенный до уровня Paint. 2;3) Попытка загуглить «фита параметры» принесла кучу фитоняшек. ) Я не программист, и такие уточнения более подходят для раздела Development или при обсуждении ТЗ. Мне бы на пальцах, и в возможности реализации не за «1 год и миллион рублей»©

То есть нужно искать спеца по CAD прежде всего.

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

PlastMove
() автор топика
Ответ на: комментарий от greenman

Забавная штучка, но заготовка — система распознавания номеров автомобилей. Отсюда подсмотрю элементы GUI на БД и методы работы с тегами, но папки нужны. )

PlastMove
() автор топика

Есть ещё одна похожая отрасль, которая пользует по, сильно схожее на то, что ты хочешь создать - системы регистрации торговых марок. Те, программный комплекс состоящий из БД и распознавалки помогает оператору принять решение о том, что рассматриваемая эмблема торговой марки ниоткуда не сплагиачена.

По поводу составления тз - уменьш количество фич до минимума, который можно по времени реализации оценить. А по поводу матметодов распознавания - то тут каждый кулик будет хвалить своё болото, кто нейросети, кто вапника, кто скрытые марковские модели итд. Многое зависит от выбора набора признаков, качества предварительной обработки картинки, поэтому выше написали, что нужно видеть реальные изображения перед тем как делать какие-либо оценки.

Насчёт редактора, думаю что применяя подход минимизации нужных операций в начале проще наговнякать что-то своё используя например QtGui.

nikitos ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.