Последние лет восемь я активно занимаюсь задачами, связанными с распознаванием образов, компьютерным зрением, машинным обучением. Получилось накопить достаточно большой багаж опыта и проектов (что-то своё, что-то в ранге штатного программиста, что-то под заказ). К тому же, с тех пор, как я написал пару статей на Хабре, со мной часто связываются читатели, просят помочь с их задачей, посоветовать что-то. Так что достаточно часто натыкаюсь на совершенно непредсказуемые применения CV алгоритмов.
Но, чёрт подери, в 90% случаев я вижу одну и ту же системную ошибку. Раз за разом. За последние лет 5 я её объяснял уже десяткам людей. Да что там, периодически и сам её совершаю…
В 99% задач компьютерного зрения то представление о задаче, которое вы сформулировали у себя в голове, а тем более тот путь решения, который вы наметили, не имеет с реальностью ничего общего. Всегда будут возникать ситуации, про которые вы даже не могли подумать. Единственный способ сформулировать задачу — набрать базу примеров и работать с ней, учитывая как идеальные, так и самые плохие ситуации. Чем шире база-тем точнее поставлена задача. Без базы говорить о задаче нельзя.
Тривиальная мысль. Но все ошибаются. Абсолютно все. В статье я приведу несколько примеров таких ситуаций. Когда задача поставлена плохо, когда хорошо. И какие подводные камни вас ждут в формировании ТЗ для систем компьютерного зрения.
Первые примеры
Плохие
Одна из самых частых идей, про которую меня спрашивают (даже предлагали взяться) — это распознавание этикеток в магазинах: "Добрый день! Я придумал классный стартап: человек приходит в магазин, снимает ценник, мы находим товар, цену и смотрим в каком магазине товар самый дешевый! Я всё уже сделал, но остался только модуль распознавания!". За последние два года с аналогичными предложениями мне писали раз пять…
И действительно! В сознании человека, который редко сталкивается с задачами распознавания, есть чёткая картина: «Распознать строчку текста на этикетке — это расплюнуть!». Ведь есть ABBYY, которые распознают текст страницами, есть Smart Engines (1, 2), у которых и карточки с кучей цифр распознаются, и этикетки даже! Задача давно решена! Какая разница, Ikea или Ашан? Все этикетки похожи, единый модуль справится.
Обычно после такого хочется сказать человеку: "Сходите в три разных сети, сделайте десять кадров и посмотрите на них". На что обычно можно получить ответ: "Что я там не видел! Вчера был в Перекрёстке и смотрел на них!".
Посмотрим?
Это не самые плохие примеры (фотографии кликабельны). На всех примерах тут человек может прочитать/додумать информацию. А машина?
• Фотографии часто нерезкие, текст расплывается и сливается. Зачастую буквы написаны так близко друг к другу, что сегментация практически невозможна.
• По краям ценников очень много артефактов, часто буквы обрезаны, или по ним идёт полоса.
• Если съёмка со вспышкой — будут блики, часто полностью перекрывающие текст.
• На одном ценнике часто 2-3 цены, написанные разными шрифтами (а часто ценники могут стоять в упор друг к другу).
• Шрифт изменяется даже в пределах одной торговой сети.
• Формат ценников изменяется даже в пределах одной торговой сети.
Некоторые, особо упёртые продолжают настаивать: «Вы всё придумали! Вот есть пост у Smart Engines, где всё работает и ценники распознаются!»
И действительно! Замечательный пример корректно поставленной задачи: ищется прямоугольник заданного размера, на красном фоне, шрифт один и тот же. Определив границы прямоугольника можно примерно уже сегментировать код. Эвристика есть, но минимальная: связать три блока на картинке, расположенных в известном порядке.
Да: будут пересветы, будут блики, уголки могут быть загнуты, кто-то черканёт на ценнике свой автограф, а у кого-то камера всегда выдаёт нерезкие кадры. Но когда вы знаете положение каждой цифры, всё остальное уже не так важно. И в большинстве случаев всё будет работать замечательно.
N.B. Я не говорю, что задача распознавания ценников не решаема в общем случае. Решаема. И сегодняшний прогресс делает это решение всё ближе и ближе. Google уже распознаёт номера домов. А ABBYY настраивается под любой заранее заданный формат текста. Но решение такой задачи находится на границе современных технологий, решение будет неидеально, или будет требовать огромного времени и средств на разработку. Конечно, можно сделать распознавание цены на ценниках (без текста) и такая система будет неплохо работать на некоторых ценниках. А иногда можно прочитать штрих-код (из приведённых ценников открытым форматом штрих-код написан на одном). Часто есть способы срезать углы и упростить постановку задачи.
Отвлечёмся от этикеток
Вы скажете что это примеры из воздуха и что так не бывает?.. Приведу пример который даже публиковался на Хабре: habrahabr.ru/post/265209.
Прежде чем читать дальше, попробуйте понять, почему метод не будет работать.
— Для тех кому лень читать. Автор предлагает ставить клеймо на дерево из трёх точек. И считает, что пересечения прямых между точками с годичными кольцами позволят однозначно маркировать и классифицировать бревно с камеры.
Вот такую красивую картинку он приводит. Метод сразу ясен и понятен. Неправда ли?
— Сам автор статьи обращался ко мне где-то за неделю до публикации с вопросом, будет ли это всё работать. Я сказал, что скорее всего не будет, привел несколько примеров, а так же сказал, как нужно модифицировать алгоритм, чтобы всё заработало. Но статью он написал в ключе, что это рабочий метод. И никто в десятке комментариев не возразил. Всего два дислайка… (Чорт, каюсь, один из них — я).
Попробуем разобраться. Во-первых, как выглядит «годичное кольцо»? Попросим Яндекс выдать нам бревно:
Идеальное. Красивые кольца! Прямо как на рисунке выше. Постойте… А что же это?
Тоже кольца… А что если у нас фотоаппарат чуть-чуть промазал с резкостью?
Блин. Половина колец пропало. А если у нас вечереет и поднялось ISO?
Опять…
Ну ладно, может не всё так плохо? Придумаем критерий, чтобы выбирать только достаточно большие годовые полосы, будем генерировать несколько вариантов для каждого дерева. Ок?
Нет, ещё есть трещины, которые могут поменять геометрию и ситуации когда полос вообще почти нет. И это первые 20 идеальных картинок из выдачи Яндекса. Вывод напрашивается за пять минут. Но ведь есть же классная идея! Зачем смотреть картинки из поиска?..
Сама по себе задача, на мой взгляд, скорее решаема. Если брать отметки как опорные точки и сравнивать теми же методами, которыми сравнивают глаза. Но, опять же, пока не протестируешь базу хотя бы на пару сотен примеров — никогда не узнаешь, можно ли работу успешно выполнить. Но почему-то такое предложение не понравилось автору статьи… Жаль!
Это два наиболее осмысленных и репрезентативных, на мой взгляд, примера. По ним можно понять, почему нужно абстрагироваться от идеи и смотреть реальные кадры.
Ещё несколько примеров, с которыми я встречался, но уже в двух словах. Во всех этих примерах у людей не было ни единой фотографии на момент, когда они начали спрашивать о реализуемости задачи:
1) Распознавание номеров у марафонцев на футболках по видеопотоку (картинка из Яндыкса)
Хы. Пока готовил статью натолкнулся на это. Очень хороший пример, на котором видны все потенциальные проблемы. Это и разные шрифты, это и нестабильный фон с тенями, это нерезкость и замятые углы. И самое главное. Заказчик предлагает идеализированную базу. Снятую на хороший фотоаппарат солнечным днём. Попробуйте посмотреть номера спортсменов на майках поискав поиском яндыкса.
Хы.Хы За пару часов до публикации автор заказа внезапно вышел на меня сам с предложением взяться за работу, от которого я отказался:) Всё же это карма, добавить это в статью.
2) Распознавание текста на фотографиях экранов телефонов
3) И, мой любимый пример. Письмо на почту:
" нужна программа в коммерческий сектор для распознания избражений.
Алгоритм работы такой. оператор программы задает изображения предмета(-ов) в нескольких ракурсах и т.п.
потом при появленини этого или максимально похожего изображения предмета, програма совершает требуемое/заданное действие.
деталей естественно не могу пока рассказать." (орфография, пунктуация сохранены)
Хорошие
Но не всё так плохо! Ситуация, когда задача ставится идеально, встречается часто. Моя любимая: «Нужно ПО для автоматического подсчета лосей на фото.
Пример фото с лосями высылаю.»
Оба фото кликабельны.
До сих пор жалею, что с этой задачей не срослось. Сначала кандидатскую защищал и был занят, а потом заказчик как-то энтузиазм потерял (или нашёл других исполнителей).
В постановке нет ни малейшей трактовки решения. Только две вещи: «что нужно сделать», «входные данные». Много входных данных. Всё.
Мысль — вывод
Единственный способ поставить задачу — набрать базу и определить методологию работы по этой базе. Что вы хотите получить? Какие границы применимости алгоритма? Без этого вы не только не сможете подойти к задаче, вы не сможете её сдать. Без базы данных заказчик всегда сможет сказать «У вас не работает такой-то случай. Но это же критичная ситуация! Без него я не приму работу».
Как сформировать базу
Наверное, всё это был приквел к статье. Настоящая статья начинается тут. Идея того, что в любой задаче CV и ML нужна база для тестирования — очевидна. Но как набрать такую базу? На моей памяти три-четыре раза первая набранная база спускалась в унитаз. Иногда и вторая. Потому что была нерепрезентативна. В чём сложность?
Нужно понимать, что «сбор базы» = «постановка задачи». Собранная база должна:
1. Отражать проблематику задачи;
2. Отражать условия, в которых будет решаться задача;
3. Формулировать задачу как таковую;
4. Приводить заказчика и исполнителя к консенсусу относительно того, что было сделано.
Время года
Пару лет назад мы с другом решили сделать систему, которая могла бы работать на мобильниках и распознавать автомобильные номера. Что-то даже получилось, и мы писали серию статей про это (http://habrahabr.ru/company/recognitor/ ). На тот момент мы были весьма умудрённые в CV системах. Знали, что нужно собирать такую базу, чтобы плохо было. Чтобы посмотрел на неё и сразу понял все проблемы. Мы собрали такую базу:
Сделали алгоритм, и он даже неплохо работал. Давал 80-85% распознавания выделенных номеров.
Ну да… Только летом, когда все номера стали чистые и хорошие точность системы просела процентов на 5…
Биометрия
Достаточно много в своей жизни мы работали с биометрией (1, 2, 3). И, кажется, наступили на все возможные грабли при сборе биометрических баз.
• База должна быть собрана в разных помещениях. Когда аппарат для сбора базы стоит только у разработчиков — рано или поздно выяснится, что он завязан на соседнюю лампу.
• В биометрических базах нужно иметь 5-10 снимков для каждого человека. И эти 5-10 снимков должны быть сделаны в разные дни, в разное время дня. Подходя к биометрическому сканеру несколько раз подряд, человек сканируется одним и тем же способом. Подходя в разные дни — по-разному. Некоторые биометрические характеристики могут немножко меняться в течении суток.
• База, собранная из разработчиков нерепрезентативна. Они подсознательно считываются так, чтобы всё сработало…
• У вас новая модель сканера? А вы уверены, что он работает со старой базой?
Вот глаза собранные с разных сканеров. Разные поля работы, разные блики, разные тени, разные пространственные разрешения, и.т.д.
База для нейронных сетей и алгоритмов обучения
Если у вас в коде используется какой-то алгоритм обучения — пиши пропало. Вам нужно формировать базу для обучения с его учётом. Предположим, в вашей задаче распознавания имеется два сильно отличающихся шрифта. Первый встречается в 90% случаев, второй в 10%. Если вы нарежете эти два шрифта в данной пропорции и обучитесь по ним единым классификатором, то с высокой вероятностью буквы первого шрифта будут распознаваться, а буквы второго нет. Ибо нейронная сеть/SVM найдёт локальный минимум не там, где распознаётся 97% первого шрифта и 97% второго, а там где распознаётся 99% первого шрифта и 0% второго. В вашей базе должно быть достаточно примеров каждого шрифта, чтобы обучение не ушло в другой минимум.
Как сформировать базу при работе с реальным заказчиком
Одна из нетривиальных проблем при сборе базы — кто это должен делать. Заказчик или исполнитель. Сначала приведу несколько печальных примеров из жизни.
Я нанимаю вас, чтобы вы решили мне задачу!
Именно такую фразу я услышал однажды. И блин, не поспоришь. Но вот только базу нужно было бы собирать на заводе, куда бы нас никто не пустил. А уж тем более, не дал бы нам монтировать оборудование. Те данные, которые давал заказчик были бесполезны: объект размером в несколько пикселей, сильно зашумлённая камера с импульсными помехами, которая периодически дергается, от силы двадцать тестовых картинок. На предложения поставить более хорошую камеру, выбрать более хороший ракурс для съёмки, сделать базу хотя бы на пару сотен примеров, заказчик ответил фразой из заголовка.
У нас нет времени этим заниматься!
Однажды директор весьма крупной компании (человек 100 штата + офисы во многих странах мира) предложил пообщаться. В продукте, который выпускала эта компания часть функционала была реализована очень старыми и очень простыми алгоритмами. Директор рассказал нам, что давно грезит о модификации данного функционала в современные алгоритмы. Даже нанимал две разных команды разработчиков. Но не срослось. Одна команда по его словам слишком теоретизировала, а вторая никакой теории не знала и тривиальщину делала. Мы решили попробовать.
На следующий день нам выдали доступ к огромному массиву сырой информации. Сильно больше, чем я бы сумел просмотреть за год. Потратив на анализ информации пару дней мы насторожились спросили: «А что собственно вам нужно от новых алгоритмов?». Нам назвали десятка два ситуаций, когда текущие алгоритмы не работают. Но за пару дней я видел лишь одну-две указных ситуации. Просмотрев ещё пачку данных смог найти ещё одну. На вопрос: «какие ситуации беспокоят ваших клиентов в первую очередь?», — ни директор ни его главные инженеры не смогли дать ответа. У них не было такой статистики.
Мы исследовали вопрос и предложили алгоритм решения, который мог автоматически собрать все возможные ситуации. Но нам нужно было помочь с двумя вещами. Во-первых, развернуть обработку информации на серверах самой фирмы (у нас не было ни достаточной вычислительной мощности, ни достаточного канала к тому месту, где хранились сырые данные). На это бы ушла неделя работы администратора фирмы. А во-вторых, представитель фирмы должен был классифицировать собранную информацию по важности и по тому как её нужно обрабатывать (это ещё дня три). К этому моменту мы уже потратили две-три недели своего времени на анализ данных, изучение статей по тематике и написание программ для сбора информации (никакого договора подписано на этот момент не было, всё делали на добровольных началах).
На что нам было заявлено: «Мы не можем отвлекать на эту задачу никого. Разбирайтесь сами». На чём мы откланялись и удалились.
Заказчик даёт базу
Был и другой случай. На этот раз заказчик поменьше. А система, которой занимается заказчик разбросана по всей территории страны. Зато заказчик понимает, что мы базу не соберём. И из всех сил старается собрать базу. Собирает. Очень большую и разнообразную. И даже уверяет, что база репрезентативна. Начинаем работать. Почти доделываем алгоритм. Перед сдачей выясняется, что на собранной базе-то алгоритм работает. И условиям договора мы удовлетворяем. Но вот база-то была нерепрезентативной. В ней нет 2/3 ситуаций. А те ситуации, что есть — представлены непропорционально. И на реальных данных система работает сильно хуже.
Вот и получается. Мы старались. Всё что обещали — сделали, хотя задача оказалась сильно сложнее, чем планировали. Заказчик старался. Потратил много времени на сбор базы.
Но итоговый результат — хреновый. Пришлось что-то придумывать на ходу, хоть как-то затыкать дырки…
Так кто должен сформировать базу?
Проблема в том, что очень часто задачи компьютерного зрения возникают в сложных системах. Системах, которые делались десятки лет многими людьми. И разобраться в такой системе часто сильно дольше, чем решить саму задачу. А заказчик хочет чтобы разработка началась уже завтра. И естественно, предложение заплатить за подготовку ТЗ и базы сумму в 2 раза больше стоимости задачи, увеличить сроки в 3 раза, дать допуск к своим системам и алгоритмам, выделить сотрудника, который всё покажет и расскажет, вызывает у него недоумение.
На мой взгляд решение любой задачи компьютерного зрения требует постоянного диалога между заказчиком и исполнителем, а так же желания заказчика сформулировать задачу. Исполнитель не видит всех нюансов бизнеса заказчика, не знает систему изнутри. Я ни разу не видел чтобы подход: «вот вам деньги, завтра сделайте мне решение» сработал. Решение-то было. Но работало ли оно как нужно?
Сам я как огня пытаюсь шарахаться от таких контрактов. Работаю ли я сам, или в какой-то фирме, которая взяла заказ на разработку.
В целом ситуацию можно представить так: предположим, вы хотите устроить свою свадьбу. Вы можете:
• Продумать и организовать всё самому от начала до конца. По сути данный вариант — «решать задачу самому».
• Продумать всё от начала до конца. Написать все сценарии. И нанять исполнителей для каждой роли. Тамаду для того чтобы гости не скучали, ресторан, чтобы все приготовили и провели. Написать основную канву для тамады, меню для ресторана. Этот вариант — это диалог. Обеспечить данными исполнителя, расписать всё, что требуется.
• Можно продумать большими блоками, не вникая в детали. Нанять тамаду, пусть делает, что делает. Не согласовывать меню ресторана. Заказать модельеру подбор платья, причёски, имиджа. Головной боли минимум, но когда начнутся конкурсы на раздевание, то можно понять что что-то было сделано не так. Далеко не факт, что сформулировав задачу в стиле «распознайте мне символ» исполнитель и заказчик поймут одно и то же.
• А можно всё заказать свадебному агентству. Дорого, думать совсем не надо. Но вот, что получится — уже не знает никто. Вариант — «сделайте мне хорошо». Скорее всего, качество будет зависеть от стоимости. Но не обязательно
Есть ли задачи, где база не нужна
Есть. Во-первых, в задачах, где база — это слишком сложно. Например, разработка робота, который анализирует видео, и по нему принимает решения. Нужен какой-то тестовый стенд. Можно сделать базы на какие-то отдельные функции. Но сделать базу по полному циклу действий зачастую нельзя. Во-вторых, когда идёт исследовательская работа. Например, идёт разработка не только алгоритмов, но и устройства, которым будет набираться база. Каждый день новое устройство, новые параметры. Когда алгоритм меняется по три раза в день. В таких условиях база бесполезна. Можно создавать какие-то локальные базы, изменяющиеся каждый день. Но что-то глобальное неосмысленно.
В-третьих, это задачи, где можно сделать модель. Моделирование это вообще очень большая и сложная тема. Если возможно сделать хорошую модель задёшево, то конечно нужно её делать. Хотите распознать текст, где есть только один шрифт — проще всего создать алгоритм моделирования ( пример такой задачи ).
Научный подход
А как же учёные? Неужели под каждую работу они собирают отдельную базу?
Обычно нет. В интернете можно найти очень много открытых баз данных. Обычно универсальных, для каких-то классических примеров. Например есть несколько сайтов с базами для биометрии (самый известный). Есть сайты с базами для тестирования различных алгоритмов обучения (1 2 3).
Проблема всех этих баз зачастую в том, что они малоприменимы и нерепрезентативны. Взять например легендарный MNIST — базу изображений цифр с ручным написанием:
Все алгоритмы машинного распознавания тестируются на ней. Всё бы хорошо, но… Топовые алгоритмы давным давно имеют точности вида 99.5%, 99.6%, 99.6351%, и.т.д. Не распознаётся 30-40 картинок, которые всем хорошо известны. Половину из них даже человеку нереально распознать. Хитрыми настройками можно чуть-чуть поправить точность и сделать +0.1%. Но ведь понятно, что ни к реальным данным, а уж там более к качественной оценке алгоритма ничего этого отношения не имеет.
Зачастую получается, что написанный по таким базам алгоритм будет работать только в тех условиях и при тех параметрах при которых собрана вся база.
Приводите свои примеры!
На хабре есть множество людей, которые занимаются обработкой изображений и наверняка имеют большой опыт в этом (статьи некоторых из них я читал ещё будучи студентом): SmartEngines sergeypid BelBES mephistopheies rocknrollnerd YUVladimir Nordavind BigObfuscator Vasyutka
(Простите, если кого отметил не по делу, но большинство из отмеченных писали классные статьи по CV и ML). Наверняка у вас есть собственные мысли о том, как сделать постановку задачи идеальной и собрать классную базу. Поделитесь? А может закритикуете написанное, как ересь от начала до конца?:)
Комментарии (53)
kharlashkin
13.01.2016 06:06+5Большое спасибо, Антон! Ваша статься очень сильно дополнила все то, что есть по компьютерному зрению на хабре, с большим удовольствием читаю подобное и надеюсь на продолжения.
AlexTest
13.01.2016 09:00+7А заказчик хочет чтобы разработка началась уже завтра. И естественно, предложение заплатить за подготовку ТЗ и базы сумму в 2 раза больше стоимости задачи, увеличить сроки в 3 раза, дать допуск к своим системам и алгоритмам, выделить сотрудника, который всё покажет и расскажет, вызывает у него недоумение.
Такая ситуация не только с задачами распознавания, это применимо к 99% разработок в других сферах.
YUVladimir
13.01.2016 09:11+3И отдельное спасибо за список людей в конце статьи — почитал статьи, оказывается много пропустил :)
Geograph
13.01.2016 10:15+1В первом примере, на мой взгляд, вместо распознавания строки на ценнике, проще и правильнее использовать сканер штрихкодов
Dreamastiy
13.01.2016 10:26+1Конечно все зависит от конкретной задачи, но вы сделали очень спорное утверждение.
Во-первых не на всех ценниках печатают штрих-коды (например овощи и фрукты).
Во-вторых на один товар может приходиться несколько десятков штрих-кодов (если не больше). Т.е. после сбора всех ШК придется все равно сопоставлять товары и ШК между собой. А как это сделать не имея хотя бы названия — та еще задачка.
Но сканер штрих-кодов безусловно проще в реализации — это да.
ZlodeiBaal
13.01.2016 12:12Мы тоже думали над этим. Но нет:)
90% магазинов используют не стандартный штрих-код, а свой, специализированный. И никто из имеющихся открытых детекторов их не читает.По сути под каждый магазин нужно будет городить свой специальный софт распознавания. Мы не вдавались глубже, но подозреваю, что:
1) Штрих-коды могут иметь какое-то шифрование, или как минимум не тривиальный перевод в информацию.
2) Потребуется для каждого магазина держать актуальную базу текущих особенностей штрих-кодов.
Если понимать как данные проблемы решать, то да, можно пробовать двигаться таким путём. И если вы делаете распознавание под один магазин, то оно безусловно будет стабильнее и оптимальнее.Kinddog
13.01.2016 17:01магазины 100% используют штрихкоды стандартных семейств, просто наполняют их зачастую своей информацией (обычно это ШК стандарта EAN13)
например, в таком штрихкоде обычно хранится «признак весового товара»+«код товара в базе»+ «значение веса»
однако принцип формирования стандартный (с контрольным символом), иначе сканеры на кассах его читать не будут.
тот штрихкод, что у вас на фотках — скорее всего Code128 и на него даже ГОСТ есть , который определяет как формируется графическое изображение кода.
ну а в принципе — надо всех перегонять на QR-коды, тогда будет счастье :)ZlodeiBaal
13.01.2016 17:09Скорее всего стандартный. Просто когда я экспериментировал, то ни одна открытая библиотека, ни один онлайн-распознаватор не смог их распознать. Возможно их только платные считывали.
Но. Из тех примеров, которые выше выложены, мне, например, кажется, что данные штрихкоды имеют разную длину:
hsto.org/files/b5f/bfd/29e/b5fbfd29e6934467baecbe19d82a2e8b.jpg
hsto.org/files/761/7d7/04c/7617d704c0d6441083e7f0feb56d4de4.jpg
hsto.org/files/8e8/2f1/912/8e82f19126a3428eb1449fcebaa9b1b0.jpg
Или стандарт предусматривает такие возможности?
QR код да, это хорошо. Или его аналоги. Но мне кажется, что это невыгодно самому магазину. Именно из-за того, что будет проще спарсить базу текущих товаров.Kinddog
13.01.2016 18:02для Code128 подразумевается разная длина кодируемой строки пруф1, пруф2
а вот на базе символики этого кода реализуются уже различные прикладные семейства штрихкодов с фиксированной длиной строки, типа EAN-128.
есть код Code39 — он тоже допускает переменную длину (нюанс — надо добавлять * в начале и конце кодируемой строки).
хороших распознавалок Code128 на смартфонах не встречал (да и не искал особо), а EAN13 вполне себе распознается.
p.s.
На промышленных терминалах со сканером штрихкодов обычно стоит простенькая тестовая программка от производителя, которая, при считывании штрихкода, помимо информации кода показывает его семейство (Code128, EAN и т.д.).
ZlodeiBaal
13.01.2016 18:27Спасибо, интересно!
Но в любом случае, вопрос парсинга того, что в коде написано и привязки к реальным данным — это большая проблема. К тому же, если там нет цены — то код теряет половину смысла.
Alexufo
14.01.2016 23:22+1Конечно никаких шифрований нет в штрихах. Это тупо ID товара из кассы к которой привязана цена чтобы выдать чек.
Более того, штрихи идут от поставщика товара, а поставщик обязан маркировать штрихкодом сам по стандарту EAN. Так что одинаковые товары открыто гуглятся, то есть многие товары действительно могут быть сравнены по ценам, по вашему кифиру штрих гуглится 4607034870034 — можете проверить)
Вы же себе представьте ситуацию, товар привозят а магазин занимается его перештрихкодированием — такого не бывает если это не частный магазинчик который продает не продукты проышленности цветы какие нить.
Как идея в приципе рабочая — подкачивает только техническая сторона — ну не удобно это. Ну и даже если я увижу что молоко в дикси дороже, я что, уйду в другой магазин? Нет — время дороже. А в магазинах цены прыгают абы как — тут дороже то дешевле. А если этой зависимости не прослеживается то народ и так знает какой магазин дешевле и без смартфонов :-)ZlodeiBaal
15.01.2016 00:24Но это не тот штрихкод, который на пачке. Там совсем другой формат, который хорошо распознаётся бытовыми детекторами.
Kinddog
13.01.2016 11:33+1Добрый день, Антон.
Отдельное спасибо просто за то, что вспомнили о нашем разговоре (я про бревна свои) :)
По поводу набора базы примеров, трещин и всего остального — полностью с Вами согласен.
Для того, чтобы получить что-то реально работающее — безусловно нужно идти таким путем и, возможно, когда-нибудь это станет возможным.
В свое оправдание :) хочу сказать, что не рассматривал данный метод ТОЛЬКО как метод работы с бревнами.
Результат таков:
http://www.fips.ru/cdfi/fips.dll/ru?ty=29&docid=2568259 — Патент РФ на общий метод
http://www.fips.ru/cdfi/fips.dll/ru?ty=29&docid=2572071 — Патент РФ на бревна
ну и,
https://patentscope.wipo.int/search/en/detail.jsf?docId=WO2015167367 — Успешно пройден этап международного поиска, можно патентовать во всех странах (PCT)ZlodeiBaal
13.01.2016 12:34+4Добрый день!
Сам подход того, как ставить метку — интересен и, безусловно, должен помогать при распознавании (ориентацию вычислять с точностью до 2-3 градусов). Но вот насколько реальна сама задача, даже если решать её другими методами, -не понятно.
Патент это, безусловно, хорошо. Но:
1) Вы же понимаете, что патент не гарантирует работоспособность? Я могу запатентовать космический корабль на пирожковой тяге, но это не будет значить, что он существует.
2) Вы уверены, что даже если сможете решить задачу — решение останется в рамках патента? Если нет — то опять по кругу весь процесс.Kinddog
13.01.2016 13:28Я все понимаю и абсолютно ни в чем не уверен :)
Патенты — это просто проба пера, так сказать.
Попробовал самостоятельно пройти весь путь и неожиданно получилось.
Теперь непонятно, что с этим всем делать. :)
Чтобы решать поставленную задачу — нет ресурсов, а так как эта тема самому нравится — просто хочется с народом поделиться.
По принципу похоже на QR-код, но информация формируется на основании структуры поверхности.
Если кому-нибудь интересно это реализовывать — велком.
BelBES
13.01.2016 13:53+11) Вы же понимаете, что патент не гарантирует работоспособность? Я могу запатентовать космический корабль на пирожковой тяге, но это не будет значить, что он существует.
Патент повышает капитализацию компании, т.ч. иногда лучше запатентовать что-то работающее в идеальном мире, чем забыть об идее ;-)
Alexufo
14.01.2016 23:46+1А это не смотрели для маркировки?
youtu.be/QzOKtYSe5-E?t=347Kinddog
15.01.2016 00:32видел такую штуку и слышал немного отзывов от людей, которые этим пользовались.
мне не подошло, потому что работает только от +5 и маркировку нужно наносить на сухую и желательно ровную поверхность.
если промахнешься — поверх или рядом маркировку наносить нельзя, нужно коробку менять и т.д.
плюс, те кто пользовался говорили, что это достаточно капризная штука и для ее эксплуатации нужен квалифицированный человек (ну или как минимум человек, у которого руки не дрожат :)
в общем случае, в российских условиях это устройство долго не живет.
обычно люди побалуются, а потом по старинке — снял этикетку с принтера этикеток, наклеил, снял, наклеил и т.д.
Kinddog
13.01.2016 11:43Прошу прощения, ссылки по клику не работают, а сообщение уже не редактируется.
Правильные ссылки:
http://www.fips.ru/cdfi/fips.dll/ru?ty=29&docid=2568259 — Патент РФ на общий метод
http://www.fips.ru/cdfi/fips.dll/ru?ty=29&docid=2572071 — Патент РФ на бревна
https://patentscope.wipo.int/search/en/detail.jsf?docId=WO2015167367 — PCT
BigObfuscator
13.01.2016 13:09+1Про лосей. Удалось найти решение этой задачи? Как на мой взгляд это из разряда impossible.
Kinddog
13.01.2016 13:38+2как вариант — анализировать несколько последовательных кадров.
точки, которые смещаются — можно посчитать за лосей :)
ZlodeiBaal
13.01.2016 13:49+1Там работа не началась. Судя по всему у заказчика надобность отпала, он пропал. Сама по себе работа сезонная и сводилась к тому что сажалось 2-3 человека и всю работу делали.
На мой взгляд должна неплохо решаться. Достаточно простой локальный детектор детектирует 99% лосей (с огромным количеством мусора). Это я проверил, это работает. Достаточно простой анализ контура + площади позволял отбраковать 99% мусора. Это я проверил, но частично (дня 2-3 потратил). В результате получалось где-то 1-2 ложняка на изображение в целом. Тут, конечно, есть зависимость от типа леса и растительности. То, что я выложил первым изображением, на мой взгляд наихудший пример из выборки был. Там ложняков было больше.
Такая точность, естественно, недостаточна. Поэтому я предлагал заказчику на первом этапе сделать не 100% робота, а систему помощи при разметке (подсветка всех возможных гипотез значительно бы ускорила работу людей). Набрать базу тысяч на 5 лосей и контр примеров, а по ним уж хоть SVM хоть свёрточной сеткой.
У меня было 2 мысли почему это заработает:
-Человек находит лосей даже если раньше их не видел. Просто по описанию (на первой фотке, кстати, два лося). Со 100% точностью.
— Так как все съёмки зимой, то обычно лоси на снегу. К деревьям и кустам они очень редко прижимаются. А контур от куста у них сильно отличен.BigObfuscator
13.01.2016 21:03Только сейчас заметил, что картинки имеют гораздо большее разрешение. На первой действительно нашел два лося (по крайней мере я думаю что это лоси:). А вторая картинка в полном разрешении у вас не открывается.
ZlodeiBaal
13.01.2016 21:33Да, там два лося.
Про вторую — сейчас проверил с нескольких браузеров / ip — открывается. Либо глюк яндекса, на котором она лежит, либо у вас браузер изображение 10к*7к не тянет.
ZlodeiBaal
14.01.2016 00:17+1Вот несколько примеров попроще (правда не на всех есть лоси):
img-fotki.yandex.ru/get/66529/6107910.17/0_823b5_18fad9c9_orig
img-fotki.yandex.ru/get/25541/6107910.17/0_823b4_9bd2602b_orig
img-fotki.yandex.ru/get/37861/6107910.17/0_823b3_35c6bac0_orig
img-fotki.yandex.ru/get/9316/6107910.17/0_823b2_f771675a_orig
img-fotki.yandex.ru/get/27216/6107910.17/0_823b1_be37424d_orig
По-моему задачка красивая и должна была решаться без проблем. А главное — красивые изображения с которыми работать, что — редкость!:)
lightcaster
14.01.2016 06:30+1Похожая по сути задачка была. Распознавание автомобилей. Решили сверточной сетью нестандартного вида. Вот пример одного из «чистых» изображений:
Alexufo
14.01.2016 23:26а людей на митингах так считать можно?
ZlodeiBaal
15.01.2016 00:20Подсчитать число в кадре, наверное, можно. А вот как склеить соседние кадры друг с другом? Я как-то смотрел видео, как толпы на митингах выглядят — оно весьма безумно!
lightcaster
15.01.2016 05:44Как заметил ZlodeiBaal, если обрабатывать видео, будет сложно. Если же по статичному кадру получить приблизительное количество людей, при грамотном датасете это выполнимо. Многое зависит от качества съемки и угла. Я проглядел типичные фото — на многих очень сложно разобрать одельных людей. Все сливается.
mephistopheies
13.01.2016 13:11+1годно, еще если бы вы перевели это на англ, я бы скидывал каждому заказчику, вместо того что бы объяснять всем одно и тоже -) а ну и да, все выше сказанное справедливо не только для компьютерного зрения, а вообще для всех задач анализа данных
ZlodeiBaal
14.01.2016 01:17У меня большинство заказчиков русскоязычные, так что статью поэтому и писал на русском.
Честно говоря у меня обычно и на русском общаться сил еле еле хватает, боюсь подумать каково это объяснять кому-то всё тоже самое на английском. А так, переводите, буду рад!:)
Анализ данных, это да. Сейчас уже между CV задачами и ML задачами тонкая граница.
Dr_Zoidberg
13.01.2016 13:34Отличная статья. Спасибо. С чего стоит начинать обучаться новичку в компьютерном зрении? Например, есть желание попробовать сделать интегрировать фичу CV в iOS приложение. Знаю что есть OpenCV и по нему много разной (зачастую малопонятной и не связанной) информации. С чего начать?
ZlodeiBaal
13.01.2016 15:20+2Самый надёжный способ — сделать хоть что-нибудь. Взять простую задачку и сделать её. Можно начать с банального детектирования лиц, которое уже есть рабочее. Модифицировать его. Можно детектировать кактусы или котиков. Главное в CV (как впрочем и во многих реальных задачах) — самому научиться искать в интернете возможные способы решения, оценивать и реализовывать их. Найти десять статей по задаче, понять какая лучше всего.
Можете взять ORB, HOG, SIFT, SURF из OpenCV и сделать что-то на их базе. Главное- используйте готовые инструменты, ищите их, понимайте как они работают.
sergeypid
13.01.2016 14:23+4Могу поделиться примером, когда стремление составить хороший тренировочный датасет привело к изменению постановки задачи. В медицинской томографии (МРТ) есть проблема планирования видов. Например, при съёмке сердца никто не использует проекцию строго в фас или профиль (на самом деле они называются корональной и сагиттальной проекциями). Доктору нужен вполне определенный срез сердца, и у каждого пациента угол прицеливания отличается. Мы разрабатывали программу для автоматического прицеливания на сердце, и в распоряжении разработчиков было всего штук 100 томограмм разных пациентов. Постановка задачи в нашем случае была такова: обучаем св. нейронную сеть распознавать ключевые точки в 3D-объеме томограммы, и по этим точкам вычисляем ориентацию сердца.
Чтобы обучить сеть требуется гораздо больше примеров, чем 100. Поэтому использовали стандартный прием искажения данных (data augmentation). Одним из вариантов искажения были повороты имеющихся у нас томограмм на различные углы, чтобы получить больше примеров проекции в трехмерном пространстве.
Это работало, но в результате привело к изменению постановки задачи: вместо детектирования ключевых точек мы обучили регрессор сразу выдавать нам эйлеровы углы по скану сердца в одной аксиальной плоскости (перпендикулярно позвоночнику).
Прикинь, да?ZlodeiBaal
13.01.2016 15:14Это сурово. А базу увеличить было нереально? Сканов то много идёт в мире. Возможно в инете базы есть. Недавно находил базу открытых КТшек на 10 тысяч — tuberculosis.by
Самое интересное — а что произошло когда стали реальные данные гонять? Удалось сделать модель которая покрыла все возможные искажения? Или были люди, на которых в упор не заработало?sergeypid
13.01.2016 15:26Базу-то еще размечать нужно. На разметку 3D-объема нужно потратить минут 5-10 достаточно квалифицированному сотруднику. Не врачу.
На реальных данных работало, конечно были и ошибочные результаты. Сердце очень по-разному выглядит у разных людей. Мозг, например, гораздо однотипнее.
Сильно точно отвечать не могу, это все-таки внутрикорпоративная работа. Продукт потом заморозили на уровне штаб-квартиры, так что в серию не пошло.
SKolotienko
13.01.2016 15:20+1Томография, сердце, компьютерное зрение… Сейчас как раз на эту тему соревнование с призовыми в $200k проходит www.kaggle.com/c/second-annual-data-science-bowl
ZlodeiBaal
13.01.2016 16:29О, Серёг, привет:)
Ты вроде эксперт по распознаванию различных шрифтов и текстов! Написанное тут мною про ценники: это реально сейчас, или я отстал от жизни, а в недрах ABBYY есть новый сверхкрутой продукт, который всё везде и всегда распознаёт?:)SKolotienko
13.01.2016 17:48+1Привет!
Про ценники ты написал совершенно справделиво. Насколько я знаю, какого-то супер крутого алгоритма распознавания текста, который умеет «делать всё», да ещё и без высоких требований к обучающей выборке, ещё не придумали. Моё мнение такое, что если хочется достичь высокой точности извлечения данных, то придётся какие-то знания о внешнем мире моделировать в алгоритме. То есть, например, что в ценнике бывают различные цены (с учётом скидки или карты клиента, например), бывают различные названия продукта, производители, развесовки и т.д. В обучающей выборке их желательно также размечать, а ещё лучше — даже вместе с указанием координат регионов, где именно эти данные находятся. Всё это поможет сделать контекст, с помощью которого можно существенно улучшить качество распознавания.
Вообще, в ABBYY работают с задачами, похожими на распознавание ценников — это распознавание визиток, плюс ещё с натяжкой можно назвать похожими задачи распознавания чеков и инвойсов. Но лично я тут не при делах :) Продукты можно загуглить по ключевым словам ABBYY, BCR, Receipt, Invoice, а также найти различные SDK, в том числе облачные.
pihel
13.01.2016 16:21ZlodeiBaal, подскажите, а задача распознавания чеков по сложности схожа с задачей по ценникам?
Который год хочу заняться, но опыта в этом 0. Не знаю, стоит ли браться.ZlodeiBaal
13.01.2016 16:26Нужно смотреть на базу. Если вы не заметили — вся статья, о том, что отвечать на такие вопросы без базы нельзя;)
У ценников как есть плюсы так и минусы. Из плюсов — там текст идёт на белом фоне и расположен построчно. Это сильный признак. В продуктах ABBYY такие тексты умеют хорошо распознавать.
Минус — разные шрифты (часто на чеках печатают термоголовкой, которая буквы печатает точками, это усложняет выделение букв сильно). Минус — это если съёмка с мобильника. И.т.д.
Без базы нельзя понять что за задача вообще.pihel
13.01.2016 16:39Спасибо за ответ.
Я проверял через online сервис ABBYY, текст и цифры распознаются довольно хорошо. В тексте бывают ошибки, но его проще вручную поправить, главное чтоб число позиций и цены соответствовало чеку.
Мне показалось проблема в том, что все чеки разные: товары, итоги и названия торговых точек раскиданы у кого как, хотя, кажется, все стараются двигаться к одному стандарту.
П.с. выложил примеры которые насобирал за некоторое время: homebuh.pro/api/ocr/files/demo.homebuh.pro/index.phpZlodeiBaal
13.01.2016 17:20Попробовал через online-ABBYY. Оно сильно лучше чем я ожидал. И многие вещи для меня удивительно, что распознались. Но всё же. Вот такое качество — yadi.sk/d/94tkeJPgmt4XY на мой взгляд несколько недостаточно, чтобы автоматизированно добавлять параметры с чека в базу. Что-то получиться, что-то нет. Но продукт, который работает только на 50% — не продукт.
С другой стороны, я уверен, что если алгоритмы ABBYY подтянуть к распознаванию именно таких чеков, то этого уже достаточно будет для готового продукта.
Но делать самому, с нуля… На мой взгляд это ад и это нереально. Такой продукт никогда не окупится.
iroln
14.01.2016 01:29+1Очень правильная статья! Хорошо, что вы её написали и всё очень грамотно обосновали. Такие статьи надо показывать заказчикам перед тем как что-то обсуждать.
Какие знакомые лоси. Я даже знаю, кто заказчик. :)ZlodeiBaal
14.01.2016 01:31Вы их делали, или заказчик тоже пропал?:) Аж любопытство пробирает)
iroln
14.01.2016 01:38+1Нет, тоже не срослось с этим заказчиком. Не договорились по срокам и другим вопросам, а потом он тоже пропал.
Он ещё предлагал задачу поиска грязи на стёклах камер уличного видеонаблюдения. И этих камер тысячи.
Скрытый текст
San66
17.01.2016 00:11Вам надо предложить услуги Почте России и фирме Сименс, а то они Пермь найти не могут :-)
chiefsonnew.livejournal.com/60641.html
Alexufo
Молодца Антон. Не грех и в 4 утра почитать, очень интересно
ZlodeiBaal
Спасибо. В 4 утра лучше всего пишется. Ничего не отвлекает.