Comments 20
Просто удивительно, что цветовые характеристики оказались настолько важнее яркостных!
+7
Вообще задача выделения снимков, составляющих одну панораму, из большого набора — стандартная. Она хорошо описана в литературе и решается во всех программах для склейки панорам. Но в данном случае задача стояла несколько шире, т.к. изображения являлись фрагментами панорамы, но могли не составлять единую мозаику.
Это не может не натолкнуть на вопрос: для чего это может понадобиться?
Это не может не натолкнуть на вопрос: для чего это может понадобиться?
+2
Оперативное обновление панорам на основе пользовательских фотографий, например.Берем актуальные фотки с GPS тегами и имеем профит.
+1
Зачем это понадобилось Яндексу нам не известно. Если же говорить в целом, то подобную задачу (когда между изображениями панорамы нет пересечений) можно использовать, к примеру, для таких приложений:
А вообще мы тоже удивились как так вышло, что у Яндекса перепутались фотографии с Яндекс.Карт и им нужно их распутать :)
- Кластеризация фотографий по месту. Например, уехала компания друзей вместе в отпуск и каждый сделал кучу снимков. Будет удобно объединить все фотографии вместе, автоматически разбить на группы по тому месту, где были сделаны снимки, и получить единый альбом со структурированными фотографиями.
- В результате работы над конкурсом получилась функция сравнения двух изображений. Её в принципе можно использовать, например для поиска по изображению: пользователь даёт своё изображение и система находит похожие снимки из базы. Причём могут будут найдены не только снимки, скажем, того же дома, но и с той же улицы.
А вообще мы тоже удивились как так вышло, что у Яндекса перепутались фотографии с Яндекс.Карт и им нужно их распутать :)
+1
Тем не менее можно попробовать подумать, зачем решение этой задачи могло понадобиться и Яндексу.
- Судя по условиям съемки панорам Яндекс.Карт, Яндекс действительно может иметь дело с неперекрывающимися снимками, потому что при съемке движется их автомобиль и окружающая среда тоже (например, другой транспорт может занимать немалую часть кадра). Да, у них имеется GPS, но, как известно, иногда он дает большие ошибки. Нужно уметь корректировать результаты GPS и не разбивать или объединять изображения там, где он ошибся.
- Возможно, что делая съемку по городу для Яндекс.Карт, их автомобиль вынужден проезжать одни и те же места несколько раз за день (например, один и тот же перекресток). И здесь тоже возможно отсутствие достаточного перекрытия (другой ракурс и т.п.), и GPS по-прежнему не очень точный. А детектировать такое событие, что мы проезжаем уже известное место, может быть полезно для дополнения, уточнения панорам.
- Возможно, как уже писал mungobungo, эту задачу можно будет расширить до построения панорам на основе пользовательских снимков (не только специально оборудованным автомобилем).
+4
Вообще, я не могу понять почему не учитывается время съемки? Допустим выбрать из массива в 100.000 фото 3 сделанных такого-то числа ровно в 15:34:07 (ну ок, +-1 сек) и всё! Тот же GPS передаёт точнейшее время со своих встроенных в спутники атомных часов.
+2
Да, это хорошая идея учитывать время и она действительно может помочь в пункте 1. Но есть проблемы с изменением ориентации и скорости движения автомобиля, к тому же цель – строить длинные панорамы (больше, чем из 3х снимков). Поэтому, думаю, даже учет времени не решит проблем во всех случаях пункта 1. В пунктах же 2 и 3 использовать время не получится.
+2
Если отбросить интересность задачи, то месяц работы высококлассной команды за 100к — афигенно выгодная сделка!
+10
Поздравляю с победой! И большое спасибо за описание. Очень интересно! Гистограммы удивили, думал основа будет на SIRFе или подобных, ан нет.
+1
Я вот пробовал использовать только классический SifrGPU, который используется во всех панорамных движках, и результат был неутешительным в процентах Яндекса. Само собой, часто этот Sift не мог найти никаких похожестей, да и я на глаз в таких случая их тоже не мог найти. А всё потому, что в настоящей панораме обязательно всегда должны быть пересечения. А в этих данных было всё что угодно, полная каша, но не панорамы, следующие этому критерию. Фраза «Основа каждой серии — последовательные фрагменты панорамы с частичным перекрытием» часто не выполнялась.
Так что я не понимаю для чего нужен такой бесполезный набор данных.
Вот взять к примеру Рис. 1. из статьи. Там все данные с точки зрения классической панорамы, снятой из одной точки, лишние. 1 и 4 картинка — один и тот же дом, но снятые с разных точек. 2,3,4 — аналогично, все три точки снимка разные. На Рис.4 тоже видно что точка съёмки переместилась. Как это может называться панорамой?
mdim предположил в комментарии зачем это может быть нужно Яндексу, но:
1. Перекрытие у панорам обязано быть, иначе это не панорама.
2. Машина может хоть 10 раз проезжать по одной улице, но у кадров опять же должно быть перекрытие и все составные кадры панорамы должны быть сделаны в один момент, а не в прошлые проезды. Иначе это не панорама а хрень какая-то получится.
3. Для наложение UCG на панорамы (как делает например Гугл в стритвью) используются штуки наподобие PMVS (много открытых инструментов есть на www.visual-experiments.com), делающие 3D реконструкцию на основе фотографий, с помощью чего можно определить место, с которого было сделано фото. Гистограммы там точно не нужны, так как освещение очень разное.
Так что я не понимаю для чего нужен такой бесполезный набор данных.
Вот взять к примеру Рис. 1. из статьи. Там все данные с точки зрения классической панорамы, снятой из одной точки, лишние. 1 и 4 картинка — один и тот же дом, но снятые с разных точек. 2,3,4 — аналогично, все три точки снимка разные. На Рис.4 тоже видно что точка съёмки переместилась. Как это может называться панорамой?
mdim предположил в комментарии зачем это может быть нужно Яндексу, но:
1. Перекрытие у панорам обязано быть, иначе это не панорама.
2. Машина может хоть 10 раз проезжать по одной улице, но у кадров опять же должно быть перекрытие и все составные кадры панорамы должны быть сделаны в один момент, а не в прошлые проезды. Иначе это не панорама а хрень какая-то получится.
3. Для наложение UCG на панорамы (как делает например Гугл в стритвью) используются штуки наподобие PMVS (много открытых инструментов есть на www.visual-experiments.com), делающие 3D реконструкцию на основе фотографий, с помощью чего можно определить место, с которого было сделано фото. Гистограммы там точно не нужны, так как освещение очень разное.
+1
Да, мы тоже думали, что в изображениях всегда будут перекрытия, и удивились, когда оказалось иначе. Можно ли называть это панорамой или это должно называться как-то по-другому — вопрос чисто терминологический. Да, это получается уже другая задача, но это не делает её менее интересной. А зачем именно это нужно было Яндексу — можно только гадать. Может, просто хотел посмотреть, какие идеи смогут придумать участники, если нарушить стандартное условие о наличии перекрытий :)
+1
Круто. А что компания получила за победу?
+1
Всё, кроме 100к :) — более опытных и радостных от победы сотрудников, а также этот пост в корпоративном блоге на Хабре.
+3
Sign up to leave a comment.
Конкурс «Интернет-математика: Яндекс.Карты» — опыт нашего участия и описание победившего алгоритма