FineReader 12: новое в интерфейсе и сложности конвертирования достижений в проценты

    Мы строили-строили и, наконец, построили!

    Как понятно из названия, мы недавно обрелизились. В связи с этим под катом постараемся простым русским языком объяснить, чем хорош FineReader 12, чтобы те, кому он нужен, могли понять, бежать уже сейчас в онлайн-магазин за новой версией или спокойно ждать пару лет появления счастливой тринадцатой.


    Про интерфейс



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

    Если в FineReader 11 (и, конечно, более старых версий) вбросить документ на k страниц, то тот задумается на n секунд, прежде, чем в нём можно будет сделать что-нибудь полезное руками. На все эти n секунд за дело возьмутся наши технологии, не желая делиться с пользователями доступом к страницам.

    В 12 версии, для начала, добавленные страницы пользователь увидит сразу. А самое главное, что возможность править блоки/делать специальные ручные предобработки изображений при наличии такой необходимости (возникает она обычно, когда на входе плохой, негодный, без преувеличения страшный документ) появляется мгновенно. Более того, в это время распознавание уже может идти. Короче, почти все наши механизмы могут работать одновременно с пользователем, чтобы последний не терял время на ожидание. Непокорёнными вершинами на пути к полной немодальности остались процессы, которые у нас зовутся документным синтезом и экспортом. Особенность этих процессов в том, что они обрабатывают документ целиком, а не постранично, поэтому работать параллельно с пользователем никак не могут. Однако, эти процессы от общего времени занимают обычно меньше 10%, да и происходят на последних этапах, когда пользователь, скорее всего, уже сделал всё, что хотел.

    Кроме того, в новой версии предусмотрен сценарий цитирования. Он предполагает, что пользователю нужен не весь документ в виде файла(/-ов), а только отдельные его куски для дальнейшего их копипащения куда-нибудь. Честно говоря, если в вашей обычной работе речь идёт о цитировании одного-двух абзацев, то я бы рекомендовал использовать наш Screenshot Reader (кстати, он не только продаётся отдельно, но и входит в состав FineReader в виде бонуса). Однако, если из 100-страничного документа надо получить 15 конкретных абзацев, то новая фича будет как нельзя кстати. Ощутимым плюсом в таком сценарии будет то, что FineReader вполне прилично выделяет блоки, а значит, остаётся только найти нужную страницу и нажать Copy на целевом блоке. Если у вас не Pentium 3, а что-нибудь посвежее, то, скорее всего, дело займёт не больше секунды.

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

    Кроме того, у нас теперь есть механизм автообновления. Конечно же, скачивать придётся не целый дистрибутив, а только патч (единицы мегабайт). FineReader сам всё сделает, разве что уточнит, хочет ли пользователь обновиться.

    Я, вообще-то тестированием занимаюсь, поэтому продукт вижу уже давно и, честно говоря, даже не знаю, что ещё добавить — привык я уже к его новому виду и новым фичам. В связи с этим вот вам обзор на 3dnews, а я передаю микрофон 57ded, который поведает о том, почему качество распознавания растёт с 98% уже много лет на 30-40% в продуктовый цикл, но всё ещё не достигло 200%.

    Про технологии


    Про новые или хорошо забытые старые функции обработки изображений всё понятно. С одной стороны, мы, наконец, сделали удаление цветных печатей на офисных документах как на картинке справа, что, IMHO, вполне приемлемо и соответствует нынешнему уровню достижений науки и технологий.

    С другой стороны сдули толстый слой нафталина с функций восстановления баланса белого и прочего «визуального улучшения» изображения, впервые представленных ещё в далёком 2007 в рамках FineReader 8. Помимо этого официально объявлено об улучшении работы на документах с таблицами и диаграммами. Насчёт диаграмм замечу, что, скорее всего, здесь к диаграммам из-за какого-то то ли недоразумения, то ли нежелания разбираться в деталях, отнесли документы с картинками, где на картинке был скриншот – эту-то задачу мы как раз решали целенаправленно.

    Как гласит анонс FineReader’ а (ссылку давать не будем, анонсам тут не место, правда) достигнуты улучшения в “up to” 33% на диаграммах со скриншотами и «до» 40% на таблицах. Ни один нормальный заинтересованный скептик не пропустит просто так эти цифры, потому поясним, откуда они взялись. Капитан Очевидность подсказывает, что точность распознавания обычно меряют, сравнивая результат работы программы OCR с неким эталоном «как должно быть». Если мы меряем точность распознавания текста, когда уже известно, где именно этот текст расположен (задача, пленяющая многих своих красотой и так и зовущая применить всю мощь теории классификаций), то измерить, насколько результат близок к оригиналу, не представляет вообще никаких проблем.

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

    Теперь, чтобы померить точность для таблиц и диаграммо-скриншотиков, осталось всего ничего: посмотреть, сколько таблиц не находила предыдущая версия, сравнить с количеством таблиц, с которыми не справилась нынешняя, «недостачу» таблиц прошлой версии принять за 100% и получить искомый результат… Упс…, снова не всё так просто.

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

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

    В-третьих (вы что, всерьёз полагаете, что загвоздки у меня уже кончились?), в некоторых случаях человечество не может точно сказать, таблица перед нами, или текст. Скажем, как на картинке справа.
    В таких случаях примем соломоново решение «И так, и так правильно».

    Применив упомянутое колдунство, мы пришли к выводу, что на нашей базе…
    «Стоп!» — справедливо возмутится любой оппонент, — «Использовать обучающую базу в качестве тестовой – это за гранью добра и зла!!!». Что ж, придётся с ним согласиться. Действительно, сравнительное тестирование нужно проводить на совершенно новой базе свежескачанных или свежеотсканированных изображений, чтобы была гарантия, что программисты на них и не пытались настроиться. Но тут-то как раз мы и вспоминаем, что размечать эту базу недёшево. Пока что решение состоит в следующем:

    • Уж какую смогли базу, ту и приспособили для честного тестирования;
    • Точно измерить цифры улучшения не получится – так и пишем «улучшили на треть» или «улучшили на две пятых» — что в маркетинговых материалах превращается в 30-33-40 % (иногда мне кажется, что их авторы соревнуются в частоте употребления слова «процент»). Оттуда и наши стыдливые «до» или “up to”.
    • Но зато раз уж база маленькая – можем провести «субъективный» тест – глазами просмотреть эту пару сотен изображений и сказать, какая из версий лучше на них отработала. Упомянутые цифры нашли субъективное подтверждение, что укрепляет нас в уверенности, что это правда.

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

    На этом разрешите откланяться, предложив на прощание ознакомиться с триалом нашего чудо-продукта.
    ABBYY
    Решения для интеллектуальной обработки информации

    Comments 43

      +11
      новое в интерфейсе
      а где скриншоты? Я зашел под кат именно за ними.
        +2
        Т.к. я обозревал фичи, которые невозможно иллюстрировать (как показать на скриншоте немодальность?), решил, что скриншоты не нужны. Некоторое их количество есть в упомянутом обзоре на 3dnews.
        +5
        Это всё прекрасно. А под Линукс будет?
          +3
          1:15 от публикации до этого вопроса? Хабр уже не тот.
          *Ушёл в старые посты искать ответ на этот вопрос
            +1
            Отвечать будет сам Хабр.
            Если надо немного пораспознавать, то это FineReader Online. Самый свежий пост про него тут.
            Если промышленные масштабы и обязательно на Linux, вот другой пост, который призван увести вот сюда. Если промышленные масштабы с распознаванием не на машине пользователя — Cloud SDK.
              +2
              А вас бы самих такой ответ устроил, если бы вашей основной системой был Linux и вам надо было хоть раз в неделю распознавать, и вы не хотели бы, чтобы то, что вы распознаете, было доступно другим, как в случае с on-line сервисами?
                +3
                Я совсем недолго был пользователем Ubuntu. Посидел с полгода, в целом был доволен, но ушёл (такой вот слабак, да), поняв, что задачи, выходящие за рамки ежедневных (CAD, OCR, например) придётся решать с использованием виртуализации. Кстати, сейчас (с ростом производительности железа) это уже не кажется такой уж проблемой.

                В общем, моя личная позиция по этому вопросу: каждый сам выбирает путь.

                Linux так и не набрал критической массы готовых платить пользователей, чтобы производители end user ПО начали массово писать под Linux.
          0
          А можно указать геометрию икажения кривыми (не так как здесь перспективное искажение), а искажение текста текста изгибающихся у корешков страниц? Недавно была отличная фотография страницы и текст хорошо читаемый глазами с хорошим разрешением у корешков, НО FineReader 11 не справился. Пришлось удалять «распознанное» и дописывать текст в начале каждой строчки вручную. Не было весело.
            0
            Пользователь указать не может, но с этим обычно довольно хорошо справляется наш автоматический выпрямитель строк. Печально, конечно, что в Вашем конкретном случае он слажал. Кстати, если пришлёте в личку проблемную картинку, будет здорово.
            +3
            А исправили определение знака "–" в прямой речи, когда он стоит в начале строки, как элемент маркированного списка?
            те прямая речь выводилась как маркированный список.
              0
              Одной из проблем является определение диалогов как списков, т.к. в нумерованных списках тире/дефисы довольно часто используются для обозначения пунктов, и для борьбы с этим есть новая фича — отключение определения списков. При этом исходное форматирование сохраняется полностью.
              Обычно в книгах с диалогами нет маркированных списков, поэтому отключение чекбокса не приведёт к проблемам с настоящими списками, тем более, что форматирование сохраняется и нумерация списков остаётся. Но, само собой, у нас ведутся работы по определению диалогов как диалогов без этих маневров.
                0
                А где находится выключатель?
                Есть ли он в контекстном меню у распознанного списка? ;)
                  0
                  Выключатель есть только в одном месте — в Options на вкладе Read, группа «Detect structural elements». Влияет на весь документ.
                  Чтобы у списка появилось своё контекстное меню, нам надо переделать много чего, т.к. в один блок может (и по текущей задумке это нормально) попадать текст с разными ролями (тогда непонятно, на что влияет контекстное меню).
                    0
                    Я б предпочёл видеть в контекстном меню группы пунктов от всех «ролей» куска экрана, в который ткнул мышкой.
                    И пусть галочка «распознавать маркированные списки с тире» в таком меню влияет на весь документ.

                    А тот выключатель что есть сейчас — глубоковато спрятан. Хотя, если б в контекстном меню любого блока появился б один лишь пункт «Настроить распознавание структурных элементов», открывающий ровно ту вкладку, было б уже неплохо.
                      +1
                      Передам интерфейс-дизайнеру, спасибо за мысль.
              0
              А Lingvo обновлять не планируете в ближайшее время? Особенно под MacOS. Которая и по функционалу и по дизайну — просто каменный век. По сравнению с версиями для Windows и iOS, соответственно.
                +1
                Планируем! Сейчас вовсю идет работа над новой версией Lingvo под MacOS.
                +2
                Вопрос с разрывом шаблона, но тем не менее… А что у вас с accessibility, а именно с читабельностью интерфейса для программ экранного доступа?

                Насколько помню, на протяжении нескольких последних релизов ситуация последовательно становилась хуже. В этот раз также не было предрелизного аудита и тестирования accessibility?

                Значение Fine Reader для слепых трудно переоценить, и в принципе в ABBYY это знают и декларировали важность этого направления, были и специальные скидки, так что всё это я слышал. Интересует чисто технический, а не маркетинговый ответ.
                  +1
                  Перед релизом мы знали о некотором количестве проблем, самые важные (но не все) на наш взгляд исправили.
                  Ещё одна действительно серьёзная проблема (не читались кнопки в окне Tasks) будет поправлена в ближайшем обновлении (ориентировочно, в конце апреля-середине мая).

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

                    То есть я-то со своей стороны готов потратить время на тестирование любого вашего продукта, не только Fine Reader, только мне хотелось бы знать, что информация попадёт непосредственно тем, кто занимается интерфейсом, а главное будет принята во внимание, и реакция на неё будет в адекватные сроки.

                    Вы можете дать какой-то прямой канал связи с людьми, ответственными за accessibility в ABBYY?
                      0
                      У компании есть понимание, что это важно. Есть явное требование, касающееся соответствия Section 508, проводится тестирование на предмет соответствия, исправляются найденные баги.

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

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

                      В связи с этим будет, конечно, очень круто, если Вы сможете провести такое тестирование. С нас, конечно, лицензия на FR12 в виде вознаграждения.

                      Я — один из тех, от кого зависит, какие баги будут исправлены к моменту релиза, а потом и в обновлениях, поэтому могу служить тем самым каналом связи. Сейчас напишу Вам в личку.
                    0
                    Ух ты, это ж почти штука для машинного чтения текста с листа вслух?!
                    Интересно, делает ли кто специализированные аналоги, особенно для мобильных девайсов со встроенной камерой?
                      +1
                      Да, называется читающая машина (reading machine). Например, раз и два.

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

                      Причём тут одновременно прошиты FineReader и OmniPage.

                      Ещё есть такая категория устройств как видео увеличители (video magnifier), куда теперь также стали встраивать OCR.

                      Бывают даже плееры с OCR.

                      Программных решений для мобильных устройств куча. Сейчас OCR везде, куда не плюнь: от того же TextGrabber + Translator от ABBYY до Goggles от Google.
                    0
                    Вопрос — есть ли возможность обновить ABBYY FineReader 8 Corporate, до 12 версии?
                    Если да, то как это правильно называется (делается)?
                    Спасибо
                      0
                      7190 руб.
                      store.abbyy.ru/catalog/basket.php?id=710535&act=buy
                      Ошибся, там с версии 10 только :(
                        0
                        Поэтому и спрашиваю. Поэтому и не апргейдимся )
                          0
                          Добрый день!
                          По правилам компании ABBYY скидка на обновление предоставляется только с двух предыдущих версий программы.
                          Обратитесь, пожалуйста, в техническую поддержку, мы попробуем вам помочь.
                            0
                            По этому продукту поддержка оказывается только по электронной почте support@abbyy.com.
                            Отправил письмо.
                              0
                              И что, помогли?
                                +1
                                Нет. Такой переход не возможен. Покупайте новое )
                                  0
                                  И почему я не удивлён?..
                                    0
                                    Более правильно сказать, что я наивен был, продавить такую возможность через Хабр. Хотя сам продукт уважаю, и ценю. Будем жить пока на старом.
                      +1
                      Моя статья с 2006 года, предложения были отправлены еще тогда в Abbyy. А сегодня вижу, в процессе))))))
                      www.3dcenter.ru/tutors/read.php?sname=reports&articlealias=reports_recognize

                      Если коротко то:
                      «Попробуйте просто перевести изображение в CMYK и удалить все кроме Black канала.»
                        0
                        С ответом промашечка вышла, он чуть ниже
                        +1
                        Решение для специфичного случая может быть таким. Но как быть, если пометки сделаны красным, зеленым, или даже черным, а в книге (или журнале) при этом встречается и цветная печать (тем же синим, например)? Универсального алгоритма тут уже не получается, механизм для вынесения цветных объектов на отдельный слой на практике получается гораздо более сложным, чтобы он устойчиво работал для различных пигментов чернил и оттенков бумаги. Попробуйте провести серию экспериментов с разными чернилами и бумагой, и предложить универсальную последовательность операций для всех случаев. Рассуждать, что «здесь цвет чернил синий, а букв — черный» — не засчитывается, это нужно ещё измерить, анализируя изображение.
                          0
                          Проблемы с цветным шрифтом у finereader были всегда, автоматика и на данный момент ловит кучу глюков на сложной верстке, где текст в каком-нибудь цветном элипсе или подобной рамке белым шрифтом. (Был опыт сканирования в PDF/A английского учебника-тетрадки spotlight ) Много кусочков графики отрезаются от какого либо изображения и воспринимаются как символы.Это я понимаю, разобрать крайне сложно и без ошибок тут ну просто никак. Без ручного выделения границ не обойтись иначе больше проблем с очисткой выходного материала.

                          Распознавание у вас проходит, я понимаю так: автоматическая пост обработка (авто уровни, геометрические искажения, перспективные)-> нахождение блоков, графики и таблиц-> распознавание символов.
                          Если вдруг, алгоритм распознавания сталкивается с резко возросшей трудно читаемой областью внутри текста, которая явно затрагивает строки, ее можно зафиксировать и включить алгоритм вторичной пост обработки только для нее.

                          Для известных нам проблем:
                          1) против бликов из за глянца — фильтр highpass. Распознаем, смотрим процент распознавания с предыдущим.
                          2) для зачеркнутого, грязного текста — что то на подобии разделения на слои по цветам. Распознаем, смотрим процент распознавания с предыдущим. При допущении что цвет всегда тот, который хорошо распознавался до. Если процент распознавания выше — оставляем.
                          3) для блюра возможно обычный unsharp а то и деконволюция. Но это спорно.
                          Я не знаю, насколько это все усложнит скорость работы. но даже сейчас мне не нравится скорость файна.

                          И еще.
                          В файне меня часто удивляло, насколько хорошим сделан интерфейс и насколько странным выходит текст в ворде. Т.е текст то выходит, но в его стилях записано так много каких то значений (Абзацы, межбуквенное расстояние, даже масштаб кажется, расстояние между строками, какие то встройки текста через «вставить надпись»,) что не быть гуру ворда (а многие его воспринимают как продукт для секретарш, якобы че там знать) не получается. С моей точки зрения, чистка стилей текста в режиме готового результата в docx для редактирования должна быть еще строже. В идеале то что с гугл докс возвращается в docx. Т.е минимум.
                            +2
                            Про сохранение — это ко мне :)
                            Ваш вопрос про Вордовый документ весьма типичный, как и ответ на него: для форматов MS Word (DocX/Rtf/Doc) и OpenOffice/LibreOffice Writer (Odt) есть 4 основных режима сохранения — «Точная копия», «Редактируемая копия», «Форматированный текст» и «Простой текст». От начала к концу этого списка упрощается структура и редактирование текста, но (возможно) ухудшается похожесть результата на оригинал.
                            Только сам пользователь знает, что ему важнее из этих характеристик — программа лишь исполняет его указания. Так что правильный выбор нужного режима сохранения — первый шаг, который может решить многие или все ваши проблемы.
                            Кстати, экспериментировать с изменением параметров сохранения довольно просто всего один раз распознав документ, причём рекомендую его сохранять на диске во внутреннем представлении (как «Документ FineReader»), чтобы иметь возможность вернуться к правкам и/или сохранению с другими настройками позже, хоть через месяц или год.
                            Следующие шаги по укрощению результатов сохранения в Ворде требуют от пользователя понимания — как устроен документ произвольной, иногда весьма сложной структуры в Ворде, и какие его элементы Файнридер использует для передачи визуальной и логической структуры исходного документа (с учётом разметки на области — от её разумности зависит очень много).
                            К сожалению, осветить эти темы в комментарии не хватит и 10 абзацев, так что правильнее про это написать статью, возможно и не одну.
                              +1
                              А я, наверное, не разобрался, что есть 4 варианта)) Там же нельзя этого не заметить. Я про то и пишу. ))

                              1) К экспорту как текст все ясно. Стилей там нет никаких. Однако я бы передавал размер шрифта как в оригинале, а не по умолчанию 12pt.
                              2) Экспорт в форматированный текст. Смотрю свойства абзаца. Вижу меж строчный интервал 8,9 пт. Как такое возможно?) Файнридер не может сделать точную (до пункта) копию, но он до пункта вычислил меж строчный интервал. Это невозможно сделать точно. Почему не указать из стандартный вариантов что то? Одинарный, полуторный? То что визуально заметно.
                              3) Редактируемая копия — вдобавок к разному меж строчному интервалу (не только 8.9 а в других абзацах уже 7.7) появились отступы у одного абзаца слева 0,11 см и справа 1,02 см. то есть, если я решил редактировать документ, мне их обнулять придется. Ну не бывает так, чтобы эти миллиметры файном были к месту. Нужно еще догадаться, что они существуют. Поскольку на первый взгляд все вроде бы нормально.
                              dl.dropboxusercontent.com/u/3013858/Untitled-1%20%282%29.png
                              Разные абзацы, разные числа. Как редактировать такой текст в большом количестве с этими числами я не представляю. Обнулить проще и заново разметить. Но ведь это не этот режим файна. Почему нельзя не указывать эти значения, они все равно не точны и в больших количествах текста сводят свой смысл на 0. Да и сейчас я не вижу в них какого то смысла. Они имею смысл, когда заданы человеком и только.
                              При этих разбросах мне всегда взрывало мозг разнообразия стилей после файна при редактировании) Потому я так и не смог большие документы редактировать после эткспорта в этом режиме.
                                0
                                По поводу пункта 2. В Файнридере для всех четырёх режимов (plain text, formatted text, exact copy, editable copy) вычисляются одинаковые параметры текста. При экспорте, в зависимости от режима, некоторые из параметров отбрасываются. При экспорте в форматированный текст, действительно, стоило бы приводить межстрочное расстояние к одинарному. Это мы исправим. Но, кстати, эту проблему довольно легко исправить на стороне пользователя. В получившемся документе нужно выделить весь текст и выставить ему одинарное межстрочное расстояние.

                                По поводу боковых отступов абзаца из пункта 3. Вы бы не могли выслать мне на почту (boris_s@abbyy.com) исходник страницы с вашего скриншота? И если не сложно, пришлите версию вашего FineReader. Просто боковые отступы параграфов мы как раз исправили летом-осенью прошлого года. Эта правка должна была попасть в релиз.

                                А вообще, со всеми этими отступами и межстрочными расстояниями есть следующая проблема. При экспорте документов со сложной вёрсткой нам очень желательно, чтобы строчки находились там же, где они были в оригинале. Иначе, например, текст начинает залезать на какие-нибудь картинки. Поэтому нам проще выставлять жёсткие отступы и межстрочные расстояния. Экспорт получается более предсказуемым. Я планирую добавить выставление относительных межстрочных расстояний там, где это возможно. Просто пока руки не дошли.
                                  0
                                  Добавьте отдельный выключатель для всяких распознанных некруглых отступов и размеров
                                  Было б здорово иметь инструмент управления стилями, способный найти очень похожие стили в распознанном и их объединить и округлить.
                                    +1
                                    Со времён 11 версии продукт стал искать сильно меньше стилей, т.е. автомат уже значительно реже считает схожие стили разными. После того, как автоматы отработали, приходит время для чисто ручной работы — механизм объединения стилей (ручной, да), если я ничего не путаю, имеется с 11 версии.
                                    Это не идеально, конечно, но проблему знаем, пытаемся улучшаться в этом направлении. Что-то даже получается :)
                              +2
                              По поводу постобработок фотографий (для нас они предобработки, кстати). Вы предлагаете проверять несколько гипотез (пусть всего 2-3) до конца, вместо того, чтобы сделать предобработки более интеллектуальными, т.е. проводить некоторый анализ изображения перед их применением. Проверять эффект обработок «полным циклом», т.е. анализ + распознавание получается очень дорого, вы пишете о том, что даже сейчас не нравится скорость файна.
                              Разумеется, предлагаемые в пунктах 1), 2), 3), и многие другие варианты уже проверялись на большом наборе изображений, и среди них были выбраны наилучшие. Но для каких-то конкретных, специфичных ситуаций этот выбор может оказаться другим. Приведенный пример с испорченной студентами книгой, вообще говоря, как минимум нехарактерен для продукта, ориентированного на различные рынки. Обычно в книгах рисовать не принято, тем более после этого пытаться что-то распознать именно из испорченного экземпляра. Типичные искажения на фотографиях документов другие: неравномерность освещения (блики, тени), цифровой шум, смаз, расфокусировка, надрывы, сгибы, стершаяся краска, выцветшая бумага, пятна от кофе, и т.д. Или вы предлагаете сделать специальную кнопку в русской версии для нерадивых студентов? Это возможно, и совсем несложно, но следуя этой логике можно превратить продукт в графический редактор для фотографий с кучей кнопок в интерфейсе, поскольку предлагаемые решения неуниверсальны, для большинства случаев они оказываются вредными хотя бы потому, что необоснованно замедлят работу (или испортят результат, если отбросить проверку всех гипотез в конце).
                                0
                                да, точно) пред обработка) Я писал об анализе и распознавании только участка, где алгоритм неожиданно встречает внутри блока резко неуверенно распознанные символы (где должен быть предполагаемый текст и только). То есть, это подобие некого адаптивного распознавания. Иногда же время не так важно, как качество при большом количестве материала.
                                Я писал скорее про метод, который хоть и применялся мной в 2006 году как студентом, но он мало отличим по логике от отделения цветных печатей. Разделение цвета на слои.Про разные входные материалы и универсальные алгоритмы я понимаю. Но и у вас же заложено допущение цвета как черного (или черного с оттенком из за баланса белого.)

                          Only users with full accounts can post comments. Log in, please.