Комментарии 16
про граф интересно вы придумали, для поиска пробелов; я вот к этой проблеме подходил с другой стороны, от машинного обучения, для начала взял статистики n-грам и нагенерил большое количество строк, используя марковскую генерацию, получил кучу строк статистически валидных в языковой модели, разной длины, стиля, шрифта и размера. затем для каждой тройки символ_межсимвольноеРастояние_символ вычислил ряд фич и одно наблюдение у меня было эти фичи и различные статистики строки, которые использовались для нормализации фич, дабы получить какую то инвариантность относительно размера. потом нагенерил для каждого наблюдения некоторые совместные фичи от базовых фич. и в обучил несколько деревьев решений на разных метриках, и выбрал лучшее, оказалось что существует одна комплексная фича и порог для нее, такой что именно отсеивания по порогу было достаточно что бы классифицировать правильно 99.9% тестовой выборки.
но там как видите есть другая проблема — это склейки символов, было бы интересно почитать как вы разделяете символы которые образуют одну связную компоненты
получалось что то в этом роде
но там как видите есть другая проблема — это склейки символов, было бы интересно почитать как вы разделяете символы которые образуют одну связную компоненты
Коллега 57Ded в общем все правильно ответил — для склеек мы смотрим горизонтальный профиль фрагмента и находим на нем подозрительные точки локальных минимумов. Для каждой возможно точки порезки мы еще ищем путь порезки — сверху до низу с минимальным разрезанием черного и без сильных скачков. И все такие точки порезки добавляются в ГЛД как отдельные вершины.
Ну и два дополнительных очень полезных чита:
Ну и два дополнительных очень полезных чита:
- Некоторые пары символов лучше распознавать сразу целиком как один символ без порезки. Потому что в типографиях они печатаются вместе (это то, что называется лигатурами) — fi, fl, ft, ...
- Для некоторых символов уже на этапе формирования варианта распознавания слова стоит сгенерить вариант, как если бы в букве была незамеченная порезка. Скажем, если видим букву «m» — стоить проверить варианты распознавания с «r»+«n»
Кстати — идея нагенерить с помощью Марковских цепей примеров для машинного обучения очень крутая. Мы используем отдельные классификаторы, чтобы подтвержать линии порезки между некоторыми парами символов. Но количество пар ограничено — просто потому что в нормальных текстах количество встречающихся пар сильно меньше возможно и распределено очень неравномерно — поэтому приходится обходится только совсем частыми парами для обучения.
Пока автор молчит, попробую ответить частично.
Посмотрите на пятую сверху иллюстрацию, с ГЛД для слов PREFACE и Cambridge. Синие вертикальные черточки под текстом — это гипотезы вершин символьного ГЛД, соответствующие возможным местам порезки склеенных букв. Эти гипотезы выдвинули, исследуя проекцию слова на горизонтальную ось (сама проекция нарисована как раз под этими черточками). Какие из вершин выберут в итоге, описано сразу после иллюстраций в посте.
Посмотрите на пятую сверху иллюстрацию, с ГЛД для слов PREFACE и Cambridge. Синие вертикальные черточки под текстом — это гипотезы вершин символьного ГЛД, соответствующие возможным местам порезки склеенных букв. Эти гипотезы выдвинули, исследуя проекцию слова на горизонтальную ось (сама проекция нарисована как раз под этими черточками). Какие из вершин выберут в итоге, описано сразу после иллюстраций в посте.
Для описания алгоритмов лучше всего проходит исходный код. Не виде в посте ссылки на репозиторий. Плохо.
Я бы выложил исходный код, но он:
Но вообще спасибо за замечание — может быть в других статьях я попробую сложные вещи хотя бы псевдокодом описывать (помимо текста), для удобства восприятия.
- Закрыт. Хорошо это или плохо — тема для длинного и скучного холивара, но на данный момент это такой факт.
- Чтобы в нашем коде разобраться и понять что же там за алгоритмы в основе используются нужно много бессонных ночей. У меня эти ночи были — поверьте словесное описание иногда бывает сильно проще и понятнее.
Но вообще спасибо за замечание — может быть в других статьях я попробую сложные вещи хотя бы псевдокодом описывать (помимо текста), для удобства восприятия.
Если бы тебе приходилось видеть и разбираться в сложных проектах, где алгоритм не очевиден и сильно зависит от разных многих внешних параметров, которые ещё надо как-то добыть, то ты бы так не говорил.
Словесное описание практически всегда проще, чем исходный код.
Словесное описание практически всегда проще, чем исходный код.
Сегодня сдавал в универе лабу по поиску пути на графе. Так уболтал препода, вырисовывая на бумажке свой алгоритм, что даже забыл показать код, так поставил оценку. Так что описание всегда интереснее и занимательнее, чем сам код.
> Так уболтал препода, вырисовывая на бумажке свой алгоритм, что даже забыл показать код.
Ждём с нетерпением компилятор от ABBYY
Ждём с нетерпением компилятор от ABBYY
А это идея!
Семантический анализатор у нас уже (ABBYY Compreno). До компилятора осталась всего ничего.
Семантический анализатор у нас уже (ABBYY Compreno). До компилятора осталась всего ничего.
НЛО прилетело и опубликовало эту надпись здесь
Если текст в строке написан разным шрифтом, то у нас есть специальный механизм, который пытается такие строки поделить на части с одинаковым размером шрифта — еще до разбиения строки на слова. Но даже если этот алгоритм не сработал, то особой проблемы не будет — большинство методов дальше все равно закладываются что какие-то символы могут больше или меньше, чем средняя высота символов в слове.
Забавляют такие скриншоты в статьях.
- Проверка орфографии отключается.
- Проверка орфографии иногда бывает права...
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Распознавание текста в ABBYY FineReader (1/2)