У меня нет оригинала :(
Это для како-то интервью снимали, и оригинал утерян.
Но вы можете дать свою фотку и мы попробуем на ней.
А потом вы опубликуете оригинал.
Это обзорная лекция — задача была за полтора часа рассказать старшеклассникам о компьютерном зрении в целом.
Глубоко и серьезно у нас компьютерное зрение преподается на в малом, а в основном ШАДе. Может быть дойдем до публикации этих лекций.
Именно для поиска аппаратное ускорение нам не особо поможет. Другое дело классификация, катетеризация, сегментация… — тут, конечно, мы рассматриваем возможность использования различных аппаратных средств.
Водяные знаки вообще никак не влияют. Мы находим картинки с гораздо более сильными модификациями: кропы, фотожабы, коллажи… Иногда даже удается найти совсем другое изображение того же самого объекта.
У нас такой картинки действительно нет в индексе. Но вы правы: раз картинки нет в индексе, то и не надо ее на стартовой странице держать. Убрали, спасибо.
Использование OCR довольно обойдется дорого с точки зрения ресурсов. OCR отрабатывает на картинке на порядок медленнее, чем получение визуальных слов. И даже если с этим смириться, то встает вопрос о целесообразности. У нас, конечно, пока статистики нет — мы только запустились. Но предположу, что среди загружаемых картинок текст будет в лучшем случае у 5%. А скорее всего еще реже.
Вы же решаете задачу кластеризации при поиске копий? Модели нейронного газа и растущих нейронных сетей как раз для этого и разработаны.
Решаем, да. Но так сложилось, что сейчас мы это делаем без использования сетей.
А про способы масштабирования можно поподробней? Это ведь самая интересная часть вашей системы.
В основном масштабирования мы добиваемся не столько алгоритмами, сколько архитектурой. Посмотрите на схему: довольно очевидно, что компенсировать рост объемов индекса можно большим дроблением и увеличением количества базовых поисков (CBIR search на схеме).
Но если решать задачу в жестких рамках — скажем, если есть условие, что количество картинок в индексе растет, а количество «железа» нет — то можно «играть» размерами индекса, убирая наиболее частотные визуальные слова. И, кроме того, можно строже отбирать кандидатов для валидации, что несколько уменьшит полноту, но заметно увеличит скорость.
SURF — это один из возможных способов получения локальных дескрипторов.
Мы его не используем, но это не принципиально. Можно и SURF использовать. Выбор дескриптора — это далеко не самое важное.
И спасибо, за комплимент.
Это для како-то интервью снимали, и оригинал утерян.
Но вы можете дать свою фотку и мы попробуем на ней.
А потом вы опубликуете оригинал.
Глубоко и серьезно у нас компьютерное зрение преподается на в малом, а в основном ШАДе. Может быть дойдем до публикации этих лекций.
Решаем, да. Но так сложилось, что сейчас мы это делаем без использования сетей.
В основном масштабирования мы добиваемся не столько алгоритмами, сколько архитектурой. Посмотрите на схему: довольно очевидно, что компенсировать рост объемов индекса можно большим дроблением и увеличением количества базовых поисков (CBIR search на схеме).
Но если решать задачу в жестких рамках — скажем, если есть условие, что количество картинок в индексе растет, а количество «железа» нет — то можно «играть» размерами индекса, убирая наиболее частотные визуальные слова. И, кроме того, можно строже отбирать кандидатов для валидации, что несколько уменьшит полноту, но заметно увеличит скорость.
Мы его не используем, но это не принципиально. Можно и SURF использовать. Выбор дескриптора — это далеко не самое важное.