По-разному можно решать данную задачу. Идей и предложений достаточно много, наш вариант вот такой — потому что есть соответсвующие навыки и соответсвующий запрос от поисково-спасательных отрядов.
Не знаю точно, как в реальности происходят поиски, но мне кажется обработка машиной не исключает последующую проверку людьми, если ничего обнаружено не было. Сейчас точно нашей программе на 100% не доверяют, скорее всего ищут и так, и так, и ещё ногами прочесывают. Однако же, чтобы фото начали просматривать добровольцы, пилоту надо вначале добраться до места с широким, устойчивым интернетом и загрузить фото в специальный сервис — а это время. Плюс даже человеческими глазами можно легко потерявшегося пропустить, см. примеры снимков в статье.
В pdf про Mask R-CNN пишут про 195ms — 400ms на изображение на Nvidia Tesla M40 GPU. Для видео это, наверно, многовато, но упоминается, что дальнейшая оптимизация возможна. Судя по тому, что эксперименты так же проводились на Cityscapes-датасете, об и пользовании модели в real-time задачах в будущем авторы задумывались.
Возможно, просто мне не попадались общепринятые на русском, поскольку большую часть материалов приходится на английском читать. Если вышеприведенные действительно часто встречаются, буду использовать их.
Называю их по русски дальше потому что мне показалось, что мои неформальные переводы будет легко связать по смыслу с той или иной задачей. Но если изначально дать собственные обозначения, кто-то потом может не связать их с общераспространёнными терминами в других местах.
Вы могли бы посоветовать что-то лучше? Черезмерное перемешивание русского текста с английским тоже не все любят, а его и так зачастую избежать не получается.
Да, если такой подход настроен и привычен, он определённо удобнее :)
С вашего позволения к себе на гитхаб код про T4 добавлять не буду, чтобы не вносить путаницу (да вы, наверно, и не хотите). Если нужно — выложите где-нибудь у себя, авторских претензий на свои куски кода у меня нет.
Отимизация действительно получилась неплохая. В чём она, если не секрет?
При таком подходе, однако, могут возникнуть проблемы на этапах разработки и сборки, а MsBuild/TfsBuild и динамичный состав команды порой приносят немало боли. Надо обеспечить процесс так, чтобы dll-ка на момент запуска шаблона уже лежала в нужном месте и с нужной версией. Если понадобится добавить ещё сборки, или изменить условие фильтрации — надо каждый раз править шаблон и проверять, чтобы ни для кого из нужных классов сериализаторы не потерялись. Плюс условие выбора классов может не выражаться так просто, а кода в итоге получается много, методы SerializerHelper для каждого из них дублируются (хотя это как раз решаемо). Кто-то может не сообразить, что сериализатор автогенерированный, и руками подхачить (MS обычно на такие случаи предупреждения в начале файла пишет). Если сериализуемых классов не очень большое количество, написание просто EmitSerializer<TheClass> может быть гибче, и не нужно заморачиваться, откуда класс взялся — лишь бы он был в используемых пространствах имен.
Но выигрыш производительности 0.0013/0.0027, повторюсь, интригует. Это именно за счёт T4 или изменений самого способа сериализации?
Мне бы тоже было интересно глянуть на код примера.
Но в целом да, такой подход может быть даже удобнее, когда исходники сериализуемых классов доступны и находятся в том же солюшене. Если в другом/разделяются с другими командами — уже могут быть трудности. Опять же, может всё-таки возникнуть потребность создать десериализатор для старого варианта объекта, который только в виде сборки сохранился. Всё впрочем, зависит от задачи, конечно, и как работа в целом построена.
T4 у нас использовался для сериализации в другом месте, не знаю, почему он в первую очередь в голову не пришёл.
Возможно, попробую позже. Сейчас среда слегка разломана, и есть более актуальные задачи. Насколько я понимаю, Nfx всё-таки под более общие и сложные задачи проектировался, вариант в статье ориентирован на быструю сериализацию, но очень простых объектов.
Да, тоже посмотрю. (Удивительно, что даже для c# есть). Но любой «общий» формат сериализации предусматривает запись хоть каких-то, но метаданных. Тут идея была, что при аккуратном обращении со стабильным форматом классов можно попробовать обойтись вовсе без них.
мне кажется иноязычные аналоги русских названий компании обычно не переводом образуются, а скорее транслитерацией
В pdf про Mask R-CNN пишут про 195ms — 400ms на изображение на Nvidia Tesla M40 GPU. Для видео это, наверно, многовато, но упоминается, что дальнейшая оптимизация возможна. Судя по тому, что эксперименты так же проводились на Cityscapes-датасете, об и пользовании модели в real-time задачах в будущем авторы задумывались.
Возможно, просто мне не попадались общепринятые на русском, поскольку большую часть материалов приходится на английском читать. Если вышеприведенные действительно часто встречаются, буду использовать их.
Вы могли бы посоветовать что-то лучше? Черезмерное перемешивание русского текста с английским тоже не все любят, а его и так зачастую избежать не получается.
С вашего позволения к себе на гитхаб код про T4 добавлять не буду, чтобы не вносить путаницу (да вы, наверно, и не хотите). Если нужно — выложите где-нибудь у себя, авторских претензий на свои куски кода у меня нет.
При таком подходе, однако, могут возникнуть проблемы на этапах разработки и сборки, а MsBuild/TfsBuild и динамичный состав команды порой приносят немало боли. Надо обеспечить процесс так, чтобы dll-ка на момент запуска шаблона уже лежала в нужном месте и с нужной версией. Если понадобится добавить ещё сборки, или изменить условие фильтрации — надо каждый раз править шаблон и проверять, чтобы ни для кого из нужных классов сериализаторы не потерялись. Плюс условие выбора классов может не выражаться так просто, а кода в итоге получается много, методы SerializerHelper для каждого из них дублируются (хотя это как раз решаемо). Кто-то может не сообразить, что сериализатор автогенерированный, и руками подхачить (MS обычно на такие случаи предупреждения в начале файла пишет). Если сериализуемых классов не очень большое количество, написание просто EmitSerializer<TheClass> может быть гибче, и не нужно заморачиваться, откуда класс взялся — лишь бы он был в используемых пространствах имен.
Но выигрыш производительности 0.0013/0.0027, повторюсь, интригует. Это именно за счёт T4 или изменений самого способа сериализации?
Но в целом да, такой подход может быть даже удобнее, когда исходники сериализуемых классов доступны и находятся в том же солюшене. Если в другом/разделяются с другими командами — уже могут быть трудности. Опять же, может всё-таки возникнуть потребность создать десериализатор для старого варианта объекта, который только в виде сборки сохранился. Всё впрочем, зависит от задачи, конечно, и как работа в целом построена.
T4 у нас использовался для сериализации в другом месте, не знаю, почему он в первую очередь в голову не пришёл.
Кошки они такие. Могут везде начать мерещиться...
Не приходилось раньше слышать. Посмотрю внимательнее, спасибо.
Благодарю!