Pull to refresh

Comments 20

Просто удивительно, что цветовые характеристики оказались настолько важнее яркостных!
Если настройки съемки одни и те же, в круговой панораме в солнечный день яркости в противоположных частях круга будут разные.
Поэтому цвет более показателен.
Вообще задача выделения снимков, составляющих одну панораму, из большого набора — стандартная. Она хорошо описана в литературе и решается во всех программах для склейки панорам. Но в данном случае задача стояла несколько шире, т.к. изображения являлись фрагментами панорамы, но могли не составлять единую мозаику.
Это не может не натолкнуть на вопрос: для чего это может понадобиться?
Оперативное обновление панорам на основе пользовательских фотографий, например.Берем актуальные фотки с GPS тегами и имеем профит.
Зачем это понадобилось Яндексу нам не известно. Если же говорить в целом, то подобную задачу (когда между изображениями панорамы нет пересечений) можно использовать, к примеру, для таких приложений:

  • Кластеризация фотографий по месту. Например, уехала компания друзей вместе в отпуск и каждый сделал кучу снимков. Будет удобно объединить все фотографии вместе, автоматически разбить на группы по тому месту, где были сделаны снимки, и получить единый альбом со структурированными фотографиями.
  • В результате работы над конкурсом получилась функция сравнения двух изображений. Её в принципе можно использовать, например для поиска по изображению: пользователь даёт своё изображение и система находит похожие снимки из базы. Причём могут будут найдены не только снимки, скажем, того же дома, но и с той же улицы.

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