Pull to refresh

Comments 43

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

И еще.
В файне меня часто удивляло, насколько хорошим сделан интерфейс и насколько странным выходит текст в ворде. Т.е текст то выходит, но в его стилях записано так много каких то значений (Абзацы, межбуквенное расстояние, даже масштаб кажется, расстояние между строками, какие то встройки текста через «вставить надпись»,) что не быть гуру ворда (а многие его воспринимают как продукт для секретарш, якобы че там знать) не получается. С моей точки зрения, чистка стилей текста в режиме готового результата в docx для редактирования должна быть еще строже. В идеале то что с гугл докс возвращается в docx. Т.е минимум.
Про сохранение — это ко мне :)
Ваш вопрос про Вордовый документ весьма типичный, как и ответ на него: для форматов MS Word (DocX/Rtf/Doc) и OpenOffice/LibreOffice Writer (Odt) есть 4 основных режима сохранения — «Точная копия», «Редактируемая копия», «Форматированный текст» и «Простой текст». От начала к концу этого списка упрощается структура и редактирование текста, но (возможно) ухудшается похожесть результата на оригинал.
Только сам пользователь знает, что ему важнее из этих характеристик — программа лишь исполняет его указания. Так что правильный выбор нужного режима сохранения — первый шаг, который может решить многие или все ваши проблемы.
Кстати, экспериментировать с изменением параметров сохранения довольно просто всего один раз распознав документ, причём рекомендую его сохранять на диске во внутреннем представлении (как «Документ FineReader»), чтобы иметь возможность вернуться к правкам и/или сохранению с другими настройками позже, хоть через месяц или год.
Следующие шаги по укрощению результатов сохранения в Ворде требуют от пользователя понимания — как устроен документ произвольной, иногда весьма сложной структуры в Ворде, и какие его элементы Файнридер использует для передачи визуальной и логической структуры исходного документа (с учётом разметки на области — от её разумности зависит очень много).
К сожалению, осветить эти темы в комментарии не хватит и 10 абзацев, так что правильнее про это написать статью, возможно и не одну.
А я, наверное, не разобрался, что есть 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. Да и сейчас я не вижу в них какого то смысла. Они имею смысл, когда заданы человеком и только.
При этих разбросах мне всегда взрывало мозг разнообразия стилей после файна при редактировании) Потому я так и не смог большие документы редактировать после эткспорта в этом режиме.
По поводу пункта 2. В Файнридере для всех четырёх режимов (plain text, formatted text, exact copy, editable copy) вычисляются одинаковые параметры текста. При экспорте, в зависимости от режима, некоторые из параметров отбрасываются. При экспорте в форматированный текст, действительно, стоило бы приводить межстрочное расстояние к одинарному. Это мы исправим. Но, кстати, эту проблему довольно легко исправить на стороне пользователя. В получившемся документе нужно выделить весь текст и выставить ему одинарное межстрочное расстояние.

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

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