Как стать автором
Обновить

Комментарии 54

Молодца Антон. Не грех и в 4 утра почитать, очень интересно
Спасибо. В 4 утра лучше всего пишется. Ничего не отвлекает.
Большое спасибо, Антон! Ваша статься очень сильно дополнила все то, что есть по компьютерному зрению на хабре, с большим удовольствием читаю подобное и надеюсь на продолжения.
А заказчик хочет чтобы разработка началась уже завтра. И естественно, предложение заплатить за подготовку ТЗ и базы сумму в 2 раза больше стоимости задачи, увеличить сроки в 3 раза, дать допуск к своим системам и алгоритмам, выделить сотрудника, который всё покажет и расскажет, вызывает у него недоумение.
Такая ситуация не только с задачами распознавания, это применимо к 99% разработок в других сферах.
И отдельное спасибо за список людей в конце статьи — почитал статьи, оказывается много пропустил :)
В первом примере, на мой взгляд, вместо распознавания строки на ценнике, проще и правильнее использовать сканер штрихкодов
Конечно все зависит от конкретной задачи, но вы сделали очень спорное утверждение.

Во-первых не на всех ценниках печатают штрих-коды (например овощи и фрукты).
Во-вторых на один товар может приходиться несколько десятков штрих-кодов (если не больше). Т.е. после сбора всех ШК придется все равно сопоставлять товары и ШК между собой. А как это сделать не имея хотя бы названия — та еще задачка.

Но сканер штрих-кодов безусловно проще в реализации — это да.
Мы тоже думали над этим. Но нет:)
90% магазинов используют не стандартный штрих-код, а свой, специализированный. И никто из имеющихся открытых детекторов их не читает.По сути под каждый магазин нужно будет городить свой специальный софт распознавания. Мы не вдавались глубже, но подозреваю, что:
1) Штрих-коды могут иметь какое-то шифрование, или как минимум не тривиальный перевод в информацию.
2) Потребуется для каждого магазина держать актуальную базу текущих особенностей штрих-кодов.

Если понимать как данные проблемы решать, то да, можно пробовать двигаться таким путём. И если вы делаете распознавание под один магазин, то оно безусловно будет стабильнее и оптимальнее.
магазины 100% используют штрихкоды стандартных семейств, просто наполняют их зачастую своей информацией (обычно это ШК стандарта EAN13)
например, в таком штрихкоде обычно хранится «признак весового товара»+«код товара в базе»+ «значение веса»
однако принцип формирования стандартный (с контрольным символом), иначе сканеры на кассах его читать не будут.
тот штрихкод, что у вас на фотках — скорее всего Code128 и на него даже ГОСТ есть , который определяет как формируется графическое изображение кода.

ну а в принципе — надо всех перегонять на QR-коды, тогда будет счастье :)
Скорее всего стандартный. Просто когда я экспериментировал, то ни одна открытая библиотека, ни один онлайн-распознаватор не смог их распознать. Возможно их только платные считывали.
Но. Из тех примеров, которые выше выложены, мне, например, кажется, что данные штрихкоды имеют разную длину:
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 код да, это хорошо. Или его аналоги. Но мне кажется, что это невыгодно самому магазину. Именно из-за того, что будет проще спарсить базу текущих товаров.
для Code128 подразумевается разная длина кодируемой строки пруф1, пруф2
а вот на базе символики этого кода реализуются уже различные прикладные семейства штрихкодов с фиксированной длиной строки, типа EAN-128.
есть код Code39 — он тоже допускает переменную длину (нюанс — надо добавлять * в начале и конце кодируемой строки).
хороших распознавалок Code128 на смартфонах не встречал (да и не искал особо), а EAN13 вполне себе распознается.

p.s.
На промышленных терминалах со сканером штрихкодов обычно стоит простенькая тестовая программка от производителя, которая, при считывании штрихкода, помимо информации кода показывает его семейство (Code128, EAN и т.д.).

Спасибо, интересно!
Но в любом случае, вопрос парсинга того, что в коде написано и привязки к реальным данным — это большая проблема. К тому же, если там нет цены — то код теряет половину смысла.
Конечно никаких шифрований нет в штрихах. Это тупо ID товара из кассы к которой привязана цена чтобы выдать чек.
Более того, штрихи идут от поставщика товара, а поставщик обязан маркировать штрихкодом сам по стандарту EAN. Так что одинаковые товары открыто гуглятся, то есть многие товары действительно могут быть сравнены по ценам, по вашему кифиру штрих гуглится 4607034870034 — можете проверить)
Вы же себе представьте ситуацию, товар привозят а магазин занимается его перештрихкодированием — такого не бывает если это не частный магазинчик который продает не продукты проышленности цветы какие нить.
Как идея в приципе рабочая — подкачивает только техническая сторона — ну не удобно это. Ну и даже если я увижу что молоко в дикси дороже, я что, уйду в другой магазин? Нет — время дороже. А в магазинах цены прыгают абы как — тут дороже то дешевле. А если этой зависимости не прослеживается то народ и так знает какой магазин дешевле и без смартфонов :-)
Но это не тот штрихкод, который на пачке. Там совсем другой формат, который хорошо распознаётся бытовыми детекторами.
Добрый день, Антон.
Отдельное спасибо просто за то, что вспомнили о нашем разговоре (я про бревна свои) :)
По поводу набора базы примеров, трещин и всего остального — полностью с Вами согласен.
Для того, чтобы получить что-то реально работающее — безусловно нужно идти таким путем и, возможно, когда-нибудь это станет возможным.
В свое оправдание :) хочу сказать, что не рассматривал данный метод ТОЛЬКО как метод работы с бревнами.
Результат таков:
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)
Добрый день!
Сам подход того, как ставить метку — интересен и, безусловно, должен помогать при распознавании (ориентацию вычислять с точностью до 2-3 градусов). Но вот насколько реальна сама задача, даже если решать её другими методами, -не понятно.
Патент это, безусловно, хорошо. Но:
1) Вы же понимаете, что патент не гарантирует работоспособность? Я могу запатентовать космический корабль на пирожковой тяге, но это не будет значить, что он существует.
2) Вы уверены, что даже если сможете решить задачу — решение останется в рамках патента? Если нет — то опять по кругу весь процесс.
Я все понимаю и абсолютно ни в чем не уверен :)
Патенты — это просто проба пера, так сказать.
Попробовал самостоятельно пройти весь путь и неожиданно получилось.
Теперь непонятно, что с этим всем делать. :)
Чтобы решать поставленную задачу — нет ресурсов, а так как эта тема самому нравится — просто хочется с народом поделиться.
По принципу похоже на QR-код, но информация формируется на основании структуры поверхности.
Если кому-нибудь интересно это реализовывать — велком.
1) Вы же понимаете, что патент не гарантирует работоспособность? Я могу запатентовать космический корабль на пирожковой тяге, но это не будет значить, что он существует.

Патент повышает капитализацию компании, т.ч. иногда лучше запатентовать что-то работающее в идеальном мире, чем забыть об идее ;-)
А это не смотрели для маркировки?
youtu.be/QzOKtYSe5-E?t=347
видел такую штуку и слышал немного отзывов от людей, которые этим пользовались.
мне не подошло, потому что работает только от +5 и маркировку нужно наносить на сухую и желательно ровную поверхность.
если промахнешься — поверх или рядом маркировку наносить нельзя, нужно коробку менять и т.д.
плюс, те кто пользовался говорили, что это достаточно капризная штука и для ее эксплуатации нужен квалифицированный человек (ну или как минимум человек, у которого руки не дрожат :)
в общем случае, в российских условиях это устройство долго не живет.

обычно люди побалуются, а потом по старинке — снял этикетку с принтера этикеток, наклеил, снял, наклеил и т.д.
Прошу прощения, ссылки по клику не работают, а сообщение уже не редактируется.
Правильные ссылки:
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
Про лосей. Удалось найти решение этой задачи? Как на мой взгляд это из разряда impossible.
как вариант — анализировать несколько последовательных кадров.
точки, которые смещаются — можно посчитать за лосей :)
Там работа не началась. Судя по всему у заказчика надобность отпала, он пропал. Сама по себе работа сезонная и сводилась к тому что сажалось 2-3 человека и всю работу делали.
На мой взгляд должна неплохо решаться. Достаточно простой локальный детектор детектирует 99% лосей (с огромным количеством мусора). Это я проверил, это работает. Достаточно простой анализ контура + площади позволял отбраковать 99% мусора. Это я проверил, но частично (дня 2-3 потратил). В результате получалось где-то 1-2 ложняка на изображение в целом. Тут, конечно, есть зависимость от типа леса и растительности. То, что я выложил первым изображением, на мой взгляд наихудший пример из выборки был. Там ложняков было больше.
Такая точность, естественно, недостаточна. Поэтому я предлагал заказчику на первом этапе сделать не 100% робота, а систему помощи при разметке (подсветка всех возможных гипотез значительно бы ускорила работу людей). Набрать базу тысяч на 5 лосей и контр примеров, а по ним уж хоть SVM хоть свёрточной сеткой.
У меня было 2 мысли почему это заработает:
-Человек находит лосей даже если раньше их не видел. Просто по описанию (на первой фотке, кстати, два лося). Со 100% точностью.
— Так как все съёмки зимой, то обычно лоси на снегу. К деревьям и кустам они очень редко прижимаются. А контур от куста у них сильно отличен.
Только сейчас заметил, что картинки имеют гораздо большее разрешение. На первой действительно нашел два лося (по крайней мере я думаю что это лоси:). А вторая картинка в полном разрешении у вас не открывается.
Да, там два лося.

Про вторую — сейчас проверил с нескольких браузеров / ip — открывается. Либо глюк яндекса, на котором она лежит, либо у вас браузер изображение 10к*7к не тянет.
Вот несколько примеров попроще (правда не на всех есть лоси):
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
По-моему задачка красивая и должна была решаться без проблем. А главное — красивые изображения с которыми работать, что — редкость!:)
Похожая по сути задачка была. Распознавание автомобилей. Решили сверточной сетью нестандартного вида. Вот пример одного из «чистых» изображений:

а людей на митингах так считать можно?
Подсчитать число в кадре, наверное, можно. А вот как склеить соседние кадры друг с другом? Я как-то смотрел видео, как толпы на митингах выглядят — оно весьма безумно!
Как заметил ZlodeiBaal, если обрабатывать видео, будет сложно. Если же по статичному кадру получить приблизительное количество людей, при грамотном датасете это выполнимо. Многое зависит от качества съемки и угла. Я проглядел типичные фото — на многих очень сложно разобрать одельных людей. Все сливается.
а как боролись с поворотом?
годно, еще если бы вы перевели это на англ, я бы скидывал каждому заказчику, вместо того что бы объяснять всем одно и тоже -) а ну и да, все выше сказанное справедливо не только для компьютерного зрения, а вообще для всех задач анализа данных
У меня большинство заказчиков русскоязычные, так что статью поэтому и писал на русском.
Честно говоря у меня обычно и на русском общаться сил еле еле хватает, боюсь подумать каково это объяснять кому-то всё тоже самое на английском. А так, переводите, буду рад!:)

Анализ данных, это да. Сейчас уже между CV задачами и ML задачами тонкая граница.
вам человек намекает, что при долларе в 75 английский вам дастся легче :-)
Отличная статья. Спасибо. С чего стоит начинать обучаться новичку в компьютерном зрении? Например, есть желание попробовать сделать интегрировать фичу CV в iOS приложение. Знаю что есть OpenCV и по нему много разной (зачастую малопонятной и не связанной) информации. С чего начать?
Самый надёжный способ — сделать хоть что-нибудь. Взять простую задачку и сделать её. Можно начать с банального детектирования лиц, которое уже есть рабочее. Модифицировать его. Можно детектировать кактусы или котиков. Главное в CV (как впрочем и во многих реальных задачах) — самому научиться искать в интернете возможные способы решения, оценивать и реализовывать их. Найти десять статей по задаче, понять какая лучше всего.
Можете взять ORB, HOG, SIFT, SURF из OpenCV и сделать что-то на их базе. Главное- используйте готовые инструменты, ищите их, понимайте как они работают.
возьмите мои бревна (см. выше) в качестве простой задачки, плз… :)
Могу поделиться примером, когда стремление составить хороший тренировочный датасет привело к изменению постановки задачи. В медицинской томографии (МРТ) есть проблема планирования видов. Например, при съёмке сердца никто не использует проекцию строго в фас или профиль (на самом деле они называются корональной и сагиттальной проекциями). Доктору нужен вполне определенный срез сердца, и у каждого пациента угол прицеливания отличается. Мы разрабатывали программу для автоматического прицеливания на сердце, и в распоряжении разработчиков было всего штук 100 томограмм разных пациентов. Постановка задачи в нашем случае была такова: обучаем св. нейронную сеть распознавать ключевые точки в 3D-объеме томограммы, и по этим точкам вычисляем ориентацию сердца.

Чтобы обучить сеть требуется гораздо больше примеров, чем 100. Поэтому использовали стандартный прием искажения данных (data augmentation). Одним из вариантов искажения были повороты имеющихся у нас томограмм на различные углы, чтобы получить больше примеров проекции в трехмерном пространстве.

Это работало, но в результате привело к изменению постановки задачи: вместо детектирования ключевых точек мы обучили регрессор сразу выдавать нам эйлеровы углы по скану сердца в одной аксиальной плоскости (перпендикулярно позвоночнику).

Прикинь, да?
Это сурово. А базу увеличить было нереально? Сканов то много идёт в мире. Возможно в инете базы есть. Недавно находил базу открытых КТшек на 10 тысяч — tuberculosis.by

Самое интересное — а что произошло когда стали реальные данные гонять? Удалось сделать модель которая покрыла все возможные искажения? Или были люди, на которых в упор не заработало?
Базу-то еще размечать нужно. На разметку 3D-объема нужно потратить минут 5-10 достаточно квалифицированному сотруднику. Не врачу.
На реальных данных работало, конечно были и ошибочные результаты. Сердце очень по-разному выглядит у разных людей. Мозг, например, гораздо однотипнее.

Сильно точно отвечать не могу, это все-таки внутрикорпоративная работа. Продукт потом заморозили на уровне штаб-квартиры, так что в серию не пошло.
Томография, сердце, компьютерное зрение… Сейчас как раз на эту тему соревнование с призовыми в $200k проходит www.kaggle.com/c/second-annual-data-science-bowl
Спасибо!
О, Серёг, привет:)
Ты вроде эксперт по распознаванию различных шрифтов и текстов! Написанное тут мною про ценники: это реально сейчас, или я отстал от жизни, а в недрах ABBYY есть новый сверхкрутой продукт, который всё везде и всегда распознаёт?:)
Привет!
Про ценники ты написал совершенно справделиво. Насколько я знаю, какого-то супер крутого алгоритма распознавания текста, который умеет «делать всё», да ещё и без высоких требований к обучающей выборке, ещё не придумали. Моё мнение такое, что если хочется достичь высокой точности извлечения данных, то придётся какие-то знания о внешнем мире моделировать в алгоритме. То есть, например, что в ценнике бывают различные цены (с учётом скидки или карты клиента, например), бывают различные названия продукта, производители, развесовки и т.д. В обучающей выборке их желательно также размечать, а ещё лучше — даже вместе с указанием координат регионов, где именно эти данные находятся. Всё это поможет сделать контекст, с помощью которого можно существенно улучшить качество распознавания.

Вообще, в ABBYY работают с задачами, похожими на распознавание ценников — это распознавание визиток, плюс ещё с натяжкой можно назвать похожими задачи распознавания чеков и инвойсов. Но лично я тут не при делах :) Продукты можно загуглить по ключевым словам ABBYY, BCR, Receipt, Invoice, а также найти различные SDK, в том числе облачные.
ZlodeiBaal, подскажите, а задача распознавания чеков по сложности схожа с задачей по ценникам?
Который год хочу заняться, но опыта в этом 0. Не знаю, стоит ли браться.
Нужно смотреть на базу. Если вы не заметили — вся статья, о том, что отвечать на такие вопросы без базы нельзя;)
У ценников как есть плюсы так и минусы. Из плюсов — там текст идёт на белом фоне и расположен построчно. Это сильный признак. В продуктах ABBYY такие тексты умеют хорошо распознавать.
Минус — разные шрифты (часто на чеках печатают термоголовкой, которая буквы печатает точками, это усложняет выделение букв сильно). Минус — это если съёмка с мобильника. И.т.д.
Без базы нельзя понять что за задача вообще.
Спасибо за ответ.
Я проверял через online сервис ABBYY, текст и цифры распознаются довольно хорошо. В тексте бывают ошибки, но его проще вручную поправить, главное чтоб число позиций и цены соответствовало чеку.
Мне показалось проблема в том, что все чеки разные: товары, итоги и названия торговых точек раскиданы у кого как, хотя, кажется, все стараются двигаться к одному стандарту.

П.с. выложил примеры которые насобирал за некоторое время: homebuh.pro/api/ocr/files/demo.homebuh.pro/index.php
Попробовал через online-ABBYY. Оно сильно лучше чем я ожидал. И многие вещи для меня удивительно, что распознались. Но всё же. Вот такое качество — yadi.sk/d/94tkeJPgmt4XY на мой взгляд несколько недостаточно, чтобы автоматизированно добавлять параметры с чека в базу. Что-то получиться, что-то нет. Но продукт, который работает только на 50% — не продукт.
С другой стороны, я уверен, что если алгоритмы ABBYY подтянуть к распознаванию именно таких чеков, то этого уже достаточно будет для готового продукта.
Но делать самому, с нуля… На мой взгляд это ад и это нереально. Такой продукт никогда не окупится.
Очень правильная статья! Хорошо, что вы её написали и всё очень грамотно обосновали. Такие статьи надо показывать заказчикам перед тем как что-то обсуждать.

Какие знакомые лоси. Я даже знаю, кто заказчик. :)
Вы их делали, или заказчик тоже пропал?:) Аж любопытство пробирает)
Нет, тоже не срослось с этим заказчиком. Не договорились по срокам и другим вопросам, а потом он тоже пропал.

Он ещё предлагал задачу поиска грязи на стёклах камер уличного видеонаблюдения. И этих камер тысячи.
Скрытый текст

Икра – минтая, вес – Путина.
Вам надо предложить услуги Почте России и фирме Сименс, а то они Пермь найти не могут :-)
chiefsonnew.livejournal.com/60641.html
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.