Несколько лет назад пробовал дообучить тессеракт на распознание довольно специфичного текста, результаты не порадовали. У меня очень базовое понимание всей этой области, но возникло ощущение, что тессеракт остановился в своём развитии много лет назад и лучше использовать что-то более современное.
Непосредственно распознавание текстовых строк производится их самописной нейронной сетью, основанной на LSTM ячейках. Как я понимаю, это всё было очень круто для своего времени (они это реализовали еще до появления Tensorflow,согласно документации), но сильно устарело по сегодняшним меркам. Нет поддержки GPU, устаревшая архитектура (предполагаю, что GRU или вообще популярные сейчас трансформеры на современных tensorflow/pytorch намного обойдут самописную LSTM сеть в тессеракте и по точности и по скорости), сложности с обучением из-за привязки к их скриптам/форматам обучающих данных/C++ коду (т.е. даже напримерtensorboard для более глубокого отслеживания процесса уже не привязать).
Нахождение текста на фото делается классическими алгоритмами CV, которые не очень хорошо работают в сложных условиях. Насколько я помню, по-быстрому прикрученная к проекту модель Advanced EAST (примитивная по сегодняшним меркам) дала намного более качественный поиск текста без необходимости мучиться с бинаризацией и прочим препроцессингом, чем встроенная в сам тессеракт. Менее актуально для обычных сканов документов, чем для фотографий, наверное.
Насколько я вижу, сильно с тех пор в библиотеке ничего не поменялось, если бы понадобилось OCR сейчас - смотрел бы в сторону более современных инструментов, PaddleOCR например.
Как у blender со скоростью рендеринга подобных датасетов и работой с большими сценами?
Для своей задачи сегментации тоже пробую синтетический подход, но пока сделал выбор в сторону Unreal Engine из-за доступности готовых ассетов и даже целых сцен (мне нужно много "фото" объектов в максимально разнообразных окружениях с реалистичной отрисовкой теней, отражений и т.д.), но столкнулся с несколькими проблемами и неудобствами:
Если каждый кадр из скрипта менять позицию камеры, освещение, сегментируемый объект и прочие элементы окружения случайным образом, в реалтайм рендере c Lumen часто появляются артефакты. Впрочем, большую часть этих проблем удалось решить рендером в MovieRenderQueue(рендер фильмов), большим количеством spatial samples и выключением temporal samples в его настройках, а также отключением "выдержки" у виртуальной камеры. Тем не менее, чувствуется, что движок на такое издевательство над ним не очень рассчитан.
Не самая лучшая работа с прозрачными материалами. В первую очередь относится к lumen - например, в первые же дни работы с движком попался на крупный баг с отражением неба от полупрозрачных объектов вроде стекла даже сквозь стены. Пример рендеров. Думаю Cycles Render в блендере с таким намного лучше справляется. В моём случае хотелось предсказывать прозрачность объекта для его точного вырезания с фона, но в unreal очень ограниченная отрисовка полупрозрачных объектов с альфа каналом, вероятно придется в чем-то другом это делать.
Path Tracer отрисовывает всё еще быстро по сравнению с blender (пара тысяч рендеров за ночь на моей RTX2070) и красиво, но у меня почему-то имеет свойство падать при запуске или в процессе рендера если сцена достаточно тяжелая. Например, он в принципе не хочет работать если добавить к стандартному archviz примеру ландшафт для создания простого пейзажа за окном, падает с ошибкой в VertexFactory.
Комбинировать C++ и blueprints бывает довольно муторно, особенно если хочется из C++ получить какие-то данные от blueprint'а или вызвать его метод. Все проблемы конечно удалось решить, но возможно в каком-нибудь unity было бы проще.
Тем не менее, в остальном UE очень радует. По сравнению с blender привел бы такие плюсы:
Большой маркетплейс с готовыми ассетами. Бесплатных не очень много, правда, но есть много платных по цене обычных игр. В сам движок встроено много готового, например за получаса настраивается небо с облаками. Из скрипта потом можно менять время суток/геопозицию и получать разное освещение в т.ч. с красивыми закатами, что позволяет легко разнообразить датасет.
Достаточно простой и удобный редактор/компоновщик сцены с реалтайм предпросмотром. Blender, если я правильно понимаю, всё таки больше ориентирован на разработку отдельных 3D моделей, поэтому с нормальной отрисовкой во viewport и быстрым прототипированием сцен там сложнее. В моём случае важно иметь возможность быстро добавлять новые окружения/объекты для увеличения датасета без необходимости часами всё настраивать, даже если результат будет иметь косметические дефекты (не особо влияющие на качество ML модели).
Для UE4 есть плагины вроде UnrealCV. Я, правда, не использовал, но возможно может помочь сэкономить время для разработки генерации сложных датасетов.
Хотя стоит отметить, что относительно массивов char нам приходится хранить размер, который мы могли бы знать на компиляции.
string_view могут быть constexpr, поэтому если объявить константу вида constexpr std::string_view something = "Test", то её прямое использование в моём понимании скорее всего размер соптимизирует.
Из недавно вышедшего - Nebulous: Fleet Command. Реализм условный (нет орбитальной физики и вообще это tactical RTS), но по эстетике очень напоминает The Expanse. Много механик вроде детальных внутренних повреждений, радарной видимости, ewar и т.д.
Про KSP - реализм при желании выводится близко к уровеню Orbiter с помощью Realism Overhaul (реальная солнечная система, улучшенная аэродинамика, реальные двигатели и топливо и т.д.) и Principia - физика трех тел. От примитивизма исходной игры практически ничего не остается в такой сборке.
Количество сил и времени, вложенных в Principia разработчиками, особенно впечатляет. В репозитории много pdf'ок с математическими выкладками как это работает (рассчеты гравитации, интеграторы орбит и т.д.), Wolfram Mathematica файлы к ним, сам мод включает в себя большое и сложное ядро на c++ для быстрых рассчетов, а для работы со всем этим они сделали новый интерфейс планирования маневров в разных reference frame'ах и даже с учетом ожидаемого времени прожига, а не мгновенным импульсом как в стандартном планнере (т.е. можно даже планировать долгие маневры ионными двигателями).
Про самоосознание "железяк" там намного больше чем в том же Altered Carbon, так что "must watch". Диалоги Форда (А. Хопкинс btw) в первых двух сезонах особенно хороши.
Сейчас как раз 3 сезон заканчивается.
Я так понимаю, у unigine есть заточенные под это фичи (64 битные координаты, готовые и оптимизированные системы для создания масштабного рельефа и лесов и т.д.). Тем же разработчикам Star Citizen 64 битные координаты и физику пришлось добавлять самим в свой потомок Cry Engine, насколько я помню.
Но это только впечатление от прочитанного в сети, конечно, своего опыта ни в том ни в другом толком нет.
Периодически читаю новости в их блоге. Сложилсь впечатление, что это очень мощная платформа, но сейчас движок используют в основном в более узких/профессиональных сферах, чем игры (симуляторы, визуализации и т.д.).
Часто выходят обновления, например до недавнего времени Community версии и поддержки C# не было, только C++ (по которому они еще когда-то проводили курсы).
Наверное идеальный был бы движок для Star Citizen, сейчас из игр на UNIGINE делают Dual Universe (кажется довольно успешно).
Тоже пользуюсь draw.io для рисования несложных схем (например набросок машины состояний).
У меня сложилось впечатление, что это максимально универсальный сервис (много разных наборов элементов, в т.ч. из UML), но, как следствие, для каждой из более узких задач есть варианты получше.
Например, для проектирования БД намного удобнее использовать что-то, что заточено на entity-relationship model и т.д., со всей сопутствующей функциональностью.
Извиняюсь за типичные вопросы из разряда "что купить", но во сколько Вы бы оценили затраты для "вхождения" в базовую астрофотографию?
Думал приобрести базовую экваториальную монтировку и трубу (чтобы попробовать поснимать и deep sky на длинной выдержке, и планеты с луной) и надеялся на значения общей цены в районе 30к, но ответы на аналогичный вопрос на астрофоруме пока подводят меня к выводу, что меньше чем за 100-150к (чтобы какой-нибудь HEQ5 и приличный телескоп) даже пытаться не стоит.
Камера (одна из последних APS-C беззеркалок Sony) уже есть (и на неё также ушло значительно больше, чем ожидалось :D).
Я лично всё еще предпочту Awesome на маломощном железе, а в целом просто захотелось bells & whistles от KDE. Всё более интегрированно, да и настраивать голый wm было бы лень.
Знаю, что еще можно подменить KWin на awesome. Последний раз так пробовал делать пару лет назад с xmonad, оно работало, но были мелкие и не очень проблемы/недоработки/несостыковки, ломавшие ощущение полностью интегрированной среды рабочего стола.
Долгое время пользовался awesome wm, сейчас на свежеустановленной системе пробую KDE в связке с таким скриптом для kwin. В целом нравится, поведение после переназначения хоткеев почти повторяет awesome, за исключением нескольких мелочей и недоработок, но зато доступны все возможности KDE.
Мне изогнутость не мешает, но, вероятно, это индивидуально. В играх/фильмах она совсем незаметна (вообще, там скорее в плюс погружению), в обычных программах видно, что прямые горизонтальные линии немного изогнуты, но мне совершенно не мешает.
Возможно изогнутость может мешать тем, кто работает в Blender/CAD/etc, но у меня возникло ощущение, что мозг без проблем в фоне выполняет корректировку таких искажений.
Проблем с фокусом не замечал, у этого монитора достаточно хорошие углы обзора, чтобы смещения влево/вправо и вперед/назад не особо влияли на картинку. Да и изогнутость сама по себе не очень большая.
Лучше всего увидеть вживую, чтобы понять, будет мешать изогнутость или нет.
Я перед покупкой пытался найти такие дисплеи выставленными в магазинах, чтобы понять, как оно будет выглядеть, но попадались только "танковые щели" 2560x1080, вот такое совсем не понравилось. От большого 3440x1440 в итоге совсем другие ощущения, не жалею, что предпочел его обычным 16:9 4K.
Но с мониторами интереснее. 1920х1200 безусловно лучше 1920х1080, однако последний монитор взяли 2560x1440 (для 100% масштаба) и честно говоря предпочли бы новый взять пошире с той же высотой, т.к. 1440 уже хватает, а вот по ширине хотелось бы больше.
Пользуюсь 35'' 3440x1440 (21:9) BenQ EX3501R, очень доволен всем (кроме разве что цены на ultra-wide мониторы и того, что теперь обычный 24'' FHD 16:9 кажется маленьким и тесным :D).
Для полного счастья хотелось бы разве что 5120x2160, но ценник (особенно с учетом возможных требований к GPU) несколько отпугивает.
Либо я плохо искал, либо здесь еще не упомянули — ко всем IDE от JetBrains есть отличное расширение IdeaVim, которое предлагается поставить прямо со стартовой страницы после установки IDE. Можно, так сказать, взять лучшее от двух миров.
К VS, VS Code и другим IDE/редакторам зачастую тоже есть аналогичные плагины.
Даже для браузеров есть vim-style плагины для более удобной клавиатурно-ориентированной навигации.
Несколько лет назад пробовал дообучить тессеракт на распознание довольно специфичного текста, результаты не порадовали. У меня очень базовое понимание всей этой области, но возникло ощущение, что тессеракт остановился в своём развитии много лет назад и лучше использовать что-то более современное.
Непосредственно распознавание текстовых строк производится их самописной нейронной сетью, основанной на
LSTMячейках. Как я понимаю, это всё было очень круто для своего времени (они это реализовали еще до появленияTensorflow,согласно документации), но сильно устарело по сегодняшним меркам. Нет поддержки GPU, устаревшая архитектура (предполагаю, чтоGRUили вообще популярные сейчас трансформеры на современныхtensorflow/pytorchнамного обойдут самописнуюLSTMсеть в тессеракте и по точности и по скорости), сложности с обучением из-за привязки к их скриптам/форматам обучающих данных/C++ коду (т.е. даже напримерtensorboardдля более глубокого отслеживания процесса уже не привязать).Нахождение текста на фото делается классическими алгоритмами CV, которые не очень хорошо работают в сложных условиях. Насколько я помню, по-быстрому прикрученная к проекту модель Advanced EAST (примитивная по сегодняшним меркам) дала намного более качественный поиск текста без необходимости мучиться с бинаризацией и прочим препроцессингом, чем встроенная в сам тессеракт. Менее актуально для обычных сканов документов, чем для фотографий, наверное.
Насколько я вижу, сильно с тех пор в библиотеке ничего не поменялось, если бы понадобилось OCR сейчас - смотрел бы в сторону более современных инструментов, PaddleOCR например.
Как у blender со скоростью рендеринга подобных датасетов и работой с большими сценами?
Для своей задачи сегментации тоже пробую синтетический подход, но пока сделал выбор в сторону Unreal Engine из-за доступности готовых ассетов и даже целых сцен (мне нужно много "фото" объектов в максимально разнообразных окружениях с реалистичной отрисовкой теней, отражений и т.д.), но столкнулся с несколькими проблемами и неудобствами:
Если каждый кадр из скрипта менять позицию камеры, освещение, сегментируемый объект и прочие элементы окружения случайным образом, в реалтайм рендере c Lumen часто появляются артефакты. Впрочем, большую часть этих проблем удалось решить рендером в
MovieRenderQueue(рендер фильмов), большим количеством spatial samples и выключением temporal samples в его настройках, а также отключением "выдержки" у виртуальной камеры. Тем не менее, чувствуется, что движок на такое издевательство над ним не очень рассчитан.Не самая лучшая работа с прозрачными материалами. В первую очередь относится к lumen - например, в первые же дни работы с движком попался на крупный баг с отражением неба от полупрозрачных объектов вроде стекла даже сквозь стены. Пример рендеров. Думаю Cycles Render в блендере с таким намного лучше справляется. В моём случае хотелось предсказывать прозрачность объекта для его точного вырезания с фона, но в unreal очень ограниченная отрисовка полупрозрачных объектов с альфа каналом, вероятно придется в чем-то другом это делать.
Path Tracer отрисовывает всё еще быстро по сравнению с blender (пара тысяч рендеров за ночь на моей RTX2070) и красиво, но у меня почему-то имеет свойство падать при запуске или в процессе рендера если сцена достаточно тяжелая. Например, он в принципе не хочет работать если добавить к стандартному archviz примеру ландшафт для создания простого пейзажа за окном, падает с ошибкой в
VertexFactory.Комбинировать C++ и blueprints бывает довольно муторно, особенно если хочется из C++ получить какие-то данные от blueprint'а или вызвать его метод. Все проблемы конечно удалось решить, но возможно в каком-нибудь unity было бы проще.
Тем не менее, в остальном UE очень радует. По сравнению с blender привел бы такие плюсы:
Большой маркетплейс с готовыми ассетами. Бесплатных не очень много, правда, но есть много платных по цене обычных игр. В сам движок встроено много готового, например за получаса настраивается небо с облаками. Из скрипта потом можно менять время суток/геопозицию и получать разное освещение в т.ч. с красивыми закатами, что позволяет легко разнообразить датасет.
Достаточно простой и удобный редактор/компоновщик сцены с реалтайм предпросмотром. Blender, если я правильно понимаю, всё таки больше ориентирован на разработку отдельных 3D моделей, поэтому с нормальной отрисовкой во viewport и быстрым прототипированием сцен там сложнее. В моём случае важно иметь возможность быстро добавлять новые окружения/объекты для увеличения датасета без необходимости часами всё настраивать, даже если результат будет иметь косметические дефекты (не особо влияющие на качество ML модели).
Для UE4 есть плагины вроде UnrealCV. Я, правда, не использовал, но возможно может помочь сэкономить время для разработки генерации сложных датасетов.
string_view могут быть constexpr, поэтому если объявить константу вида constexpr std::string_view something = "Test", то её прямое использование в моём понимании скорее всего размер соптимизирует.
Из недавно вышедшего - Nebulous: Fleet Command. Реализм условный (нет орбитальной физики и вообще это tactical RTS), но по эстетике очень напоминает The Expanse. Много механик вроде детальных внутренних повреждений, радарной видимости, ewar и т.д.
Про KSP - реализм при желании выводится близко к уровеню Orbiter с помощью Realism Overhaul (реальная солнечная система, улучшенная аэродинамика, реальные двигатели и топливо и т.д.) и Principia - физика трех тел. От примитивизма исходной игры практически ничего не остается в такой сборке.
Количество сил и времени, вложенных в Principia разработчиками, особенно впечатляет. В репозитории много pdf'ок с математическими выкладками как это работает (рассчеты гравитации, интеграторы орбит и т.д.), Wolfram Mathematica файлы к ним, сам мод включает в себя большое и сложное ядро на c++ для быстрых рассчетов, а для работы со всем этим они сделали новый интерфейс планирования маневров в разных reference frame'ах и даже с учетом ожидаемого времени прожига, а не мгновенным импульсом как в стандартном планнере (т.е. можно даже планировать долгие маневры ионными двигателями).
Именно интерполяцию вида
добавили недавно, в F# 5:
https://devblogs.microsoft.com/dotnet/announcing-f-5/
Касательно printfn: недавно добавили интерполяцию строк как в С#:
https://docs.microsoft.com/en-us/dotnet/fsharp/language-reference/interpolated-strings
https://youtu.be/FxfmfDL6gMI
Про самоосознание "железяк" там намного больше чем в том же Altered Carbon, так что "must watch". Диалоги Форда (А. Хопкинс btw) в первых двух сезонах особенно хороши.
Сейчас как раз 3 сезон заканчивается.
Я так понимаю, у unigine есть заточенные под это фичи (64 битные координаты, готовые и оптимизированные системы для создания масштабного рельефа и лесов и т.д.). Тем же разработчикам Star Citizen 64 битные координаты и физику пришлось добавлять самим в свой потомок Cry Engine, насколько я помню.
Но это только впечатление от прочитанного в сети, конечно, своего опыта ни в том ни в другом толком нет.
Периодически читаю новости в их блоге. Сложилсь впечатление, что это очень мощная платформа, но сейчас движок используют в основном в более узких/профессиональных сферах, чем игры (симуляторы, визуализации и т.д.).
Часто выходят обновления, например до недавнего времени Community версии и поддержки C# не было, только C++ (по которому они еще когда-то проводили курсы).
Наверное идеальный был бы движок для Star Citizen, сейчас из игр на UNIGINE делают Dual Universe (кажется довольно успешно).
Тоже пользуюсь draw.io для рисования несложных схем (например набросок машины состояний).
У меня сложилось впечатление, что это максимально универсальный сервис (много разных наборов элементов, в т.ч. из UML), но, как следствие, для каждой из более узких задач есть варианты получше.
Например, для проектирования БД намного удобнее использовать что-то, что заточено на entity-relationship model и т.д., со всей сопутствующей функциональностью.
Неплохая реклама Beyerdynamic DT-770 :D
Извиняюсь за типичные вопросы из разряда "что купить", но во сколько Вы бы оценили затраты для "вхождения" в базовую астрофотографию?
Думал приобрести базовую экваториальную монтировку и трубу (чтобы попробовать поснимать и deep sky на длинной выдержке, и планеты с луной) и надеялся на значения общей цены в районе 30к, но ответы на аналогичный вопрос на астрофоруме пока подводят меня к выводу, что меньше чем за 100-150к (чтобы какой-нибудь HEQ5 и приличный телескоп) даже пытаться не стоит.
Камера (одна из последних APS-C беззеркалок Sony) уже есть (и на неё также ушло значительно больше, чем ожидалось :D).
Я лично всё еще предпочту Awesome на маломощном железе, а в целом просто захотелось bells & whistles от KDE. Всё более интегрированно, да и настраивать голый wm было бы лень.
Знаю, что еще можно подменить KWin на awesome. Последний раз так пробовал делать пару лет назад с xmonad, оно работало, но были мелкие и не очень проблемы/недоработки/несостыковки, ломавшие ощущение полностью интегрированной среды рабочего стола.
Долгое время пользовался awesome wm, сейчас на свежеустановленной системе пробую KDE в связке с таким скриптом для kwin. В целом нравится, поведение после переназначения хоткеев почти повторяет awesome, за исключением нескольких мелочей и недоработок, но зато доступны все возможности KDE.
https://github.com/telegramdesktop/tdesktop/issues/1121
Извиняюсь, что влезаю не по теме, но ведь есть же https://www.draw.io/, чтобы не приходилось делать так:
Мне изогнутость не мешает, но, вероятно, это индивидуально. В играх/фильмах она совсем незаметна (вообще, там скорее в плюс погружению), в обычных программах видно, что прямые горизонтальные линии немного изогнуты, но мне совершенно не мешает.
Возможно изогнутость может мешать тем, кто работает в Blender/CAD/etc, но у меня возникло ощущение, что мозг без проблем в фоне выполняет корректировку таких искажений.
Проблем с фокусом не замечал, у этого монитора достаточно хорошие углы обзора, чтобы смещения влево/вправо и вперед/назад не особо влияли на картинку. Да и изогнутость сама по себе не очень большая.
Лучше всего увидеть вживую, чтобы понять, будет мешать изогнутость или нет.
Я перед покупкой пытался найти такие дисплеи выставленными в магазинах, чтобы понять, как оно будет выглядеть, но попадались только "танковые щели" 2560x1080, вот такое совсем не понравилось. От большого 3440x1440 в итоге совсем другие ощущения, не жалею, что предпочел его обычным 16:9 4K.
Пользуюсь 35'' 3440x1440 (21:9) BenQ EX3501R, очень доволен всем (кроме разве что цены на ultra-wide мониторы и того, что теперь обычный 24'' FHD 16:9 кажется маленьким и тесным :D).
Для полного счастья хотелось бы разве что 5120x2160, но ценник (особенно с учетом возможных требований к GPU) несколько отпугивает.
Либо я плохо искал, либо здесь еще не упомянули — ко всем IDE от JetBrains есть отличное расширение IdeaVim, которое предлагается поставить прямо со стартовой страницы после установки IDE. Можно, так сказать, взять лучшее от двух миров.
К VS, VS Code и другим IDE/редакторам зачастую тоже есть аналогичные плагины.
Даже для браузеров есть vim-style плагины для более удобной клавиатурно-ориентированной навигации.