Обе эти проблемы решаются сравнением ответов 2-3-х разных пользователей на одну картинку. Если они независимо отвечают одинаково, ответ признается правильным. Есть небольшие организационные проблемы в этом подходе, но их можно разрешить…
Мы, конечно же, рассматриваем такую возможность. Для реализации могут быть использованы два подхода:
1) более простой — пользователь загружает картинку, мы ее, возможно, узнаем по точной побайтовой контрольной сумме, если она встречалась нашему роботу в интернете, выдаем более развернутую информацию, рассчитанную в оффлайне, о ее точных дубликатах и «полудубликатах». Если не узнаем, то сообщаем об этом пользователю.
2) более сложный — перетащить процесс поиска дубликатов по нечеткой сигнатуре из оффлайна в онлайн. Тут потребуется немало дополнительного программирования, которое само себе не принесет пользы для основного применения алгоритма поиска дубликатов. Хотя, возможно сделать и это.
Будем ли мы делать эту задачу, и как именно, мы сообщим, скорее всего, уже после запуска, если он будет… До этого нам нужно будет взвесить много факторов при принятии окончательного решения.
Фотографии мы уже умеем отличать, есть переключатель на параллельном поиске. Портретный поиск, действительно, — полезная функция, в зачетку Гугл.Картинкам.
Над качеством поиска все поисковики работают непрерывно, хотя об этом пишут мало. По нашим измерениям на оцененных коллекциях среднее качество поиска Я.Картинок и Гугл.Картинок по русскоязычным запросам сейчас примерно на одном уровне, у Я.Картинок — чуть-чуть ниже. Различия в ту или иную сторону обычно заметны на отдельных классах запросов, суммарная оценка зависит от их процента в потоке.
По качеству поиска идет соревнование, мы очень постараемся Гугл.Картинки обогнать в обозримом будущем. В любом случае, пользователи обоих систем от этой ситуации только выигрывают. ;)
Спасибо за информацию. По поводу поиска по точному размеру — мы думаем, надеюсь, вы нам поможете оценить востребованность фичи.
По поводу поиска по имени файла: в расширенном поиске есть переключатель, который позволяет выбрать «зону» для поиска — «подпись», «прикартиночный текст». Если перейти на страницу результатов поиска, то видно, что генерируется запрос вида
itext[yandex logo] и idesc[yandex logo]
есть еще одна недокументированная зона iurl. В нее попадают некоторые осмысленные слова из урла картинки. С ее помощью можно решить часть поисковых задач.
Предлагаю такой сценарий использования, который мы давно предлагаем пользователям веб-поиска и картинок. Сначала ищем в Яндексе, если результат неудовлетворительный, то по ссылке Google, Yandex, Picsearch внизу страницы продолжаем на других поисковиках. По-моему, честный конкурентный подход ;)
Пока эта задача упирается в качество имеющихся OCR. Надписи обычно бывают не на белом фоне, а на чем-то очень мешающем, в результате получается много шума. Кроме того, существенная часть, которая обеспечивает качество нынешних OCR, например, FineReader, это — словари и лингвистика. Они хорошо работают на связных текстах на белой бумаге, а на отдельных надписях метод может страдать. Например, слова «камрад» и «аська» вполне могут оказаться несловарными…
Альтернативные подходы — это вовлечь пользователей в процесс написания подписей. Либо в виде игры по типу Google Image Labeler. Либо еще более остроумно — подсовывать картинки с надписями вместо капч ;) Говорят, недавно таким образом распознали архив New York Times.
На странице запроса есть палитра, на которую можно кликать. Мы недавно провели юзабилити тестирование, которое показало, что не все воспринимают эту палитру как фильтр-переключатель. Будем что-нибудь перерисовывать в этом месте, обязательно.
Есть еще стандартная старая идея — по запросу со словом «красный» принудительно включать фильтр по преобладающему красному цвету. Но мы колеблемся и не делаем ее в таком простом варианте, ибо очень часто результаты не будут соответствовать ожиданиям пользователей.
А пока можно поиграть на веб-поиске яндекса с цветовыми запросами. Дизайнерам, вроде бы, очень нравится ;)
Да, привязывать картинки к картам в том или ином виде — это хорошая идея. Как я себе представляю ситуацию, Я.Карты сейчас очень интенсивно развиваются, и там есть много энтузиастов с горящими глазами, которые обсуждают все такие возможности. Что они выберут для запуска в первую очередь, трудно сказать, нужно подождать анонсов. На сегодняшний день на московских Я.Картах показываются фотографии домов, что бывает довольно полезно с практической точки зрения.
Поиск по месторасположению можно делать двумя способами:
1) контент-сервисы с отобранными качественными фотографиями, которые пользователь самостоятельно привязывает к местности, типа panoramio.com. Это — очень интересный сервис для части пользователей, который скорее ближе к теме фотохостингов и карт.
2) поиск с учетом GPS координат, которые могут быть записаны в Exif заголовок. Несомненно, такая функция касается поиска по картинкам и будет в свое время очень востребована. На сегодняшний день есть несколько сдерживающих факторов: крайне небольшой процент проникновения камер с интегрированным GPS; преимущественно — это камерофоны, в которых недостаточно качественная камера, и снимки получаются некачественными. Кроме того, в момент публикации фото в веб, а не на фотохостинг, используются программы для уменьшения картинки, которые, как правило, выкидывают Exif заголовки…
Поисх похожих действительно можно делать по ключевым словам, по статистическим характеристикам изображений, текстурам, преобладающим цветам и т. д. Хотя, в реализации все эти методы не так уж и просты. Но основные препятствия в другом:
— не совсем понятно, что будет выдавать такой поиск, и удовлетворит ли это разных пользователей? Поняние «похожие картинки» — слишком неопределенно и означает разное для разных людей и задач. А для того, чтобы хорошо решать задачу, мы должны ее как минимум хорошо формулировать. Настройка качества поиска всегда основывается на измерениях на размеченной человеком базе. Те, кто ее размечают, должны сначала между собой договориться о том, что они считают правильным?
— юзабилити тестирование говорит нам о том, что любая лишняя ссылка в интерфейсе ухудшает качество сервиса для пользователей, которым она не нужна. Поэтому при включении фич в массовый продукт мы должны 10 раз подумать о том, как это отзовется нам всех пользователях в целом.
Даже такая фича Яндекс. Картинок, как поиск картинок с разным преобладающим цветом, вызывает непонимание у некоторых пользователей.
Окончательное решение о том, запускать ли конкретную функцию в нашем сервисе, мы будем принимать, исходя из многих факторов, и расскажем о нем, видимо, сразу после запуска.
На мою просьбу предоставить аккаунт редакторы откликнулись сразу же, проблема для меня была в том, чтобы догадаться, что они есть и можно попробовать поискать их контакты. ;) До этого решал другую задачу — поиск инвайтов.
Применив некоторое количество смекалки вы сможете соорудить форму, возможно, с JavaScript, которая будет показывать дубликаты по урлу картинки. Нужно только учитывать, что Яндекс кладет в индекс не все урлы картинок, а только те, описания которых он отобрал для поиска по запросу.
Для поиска дубликатов мы строим относительно компактные сигнатуры картинок, в основе которых распределение яркостей и цветов по площади изображения, а также некоторые другие признаки. Выбор данных для включения в сигнатуру зависит от самой картинки, в разных классах изображений отдельные виды сигнатур работают с переменным успехом. Сигнатуры укладываются в индексы сложной структуры для нечеткого поиска. В частично кластеризованном виде эти индексы удается загрузить в память.
С момента формулировки общего подхода до запуска в продакшн нам пришлось преодолеть большое количество практических проблем, которые разрешались разнообразными остроумными алгоритмами. Оказалось, что одной простой идеи — недостаточно.
Большинство известных алгоритмов по поиску дубликатов или похожих изображений основаны на поиске особых точек (feature extraction) на картинках или наборов статистических свойств изображений. Первый подход позволяет «выравнивать» и отождествлять изображения, полученные обрезанием, но требует почти квадратичной сложности вычисления, поэтому используется на ограниченных коллекциях, например, на выдаче поиска по одному запросу. Второй подход не дает достаточно хорошей разрешающей способности на больших коллекциях.
images.yandex.ru/yandsearch?icolor=red&isgray=0&text=%D0%BF%D1%82%D0%B8%D1%86%D0%B0&rpt=image
images.google.com/images?imgcolor=red&hl=en&q=%D0%BF%D1%82%D0%B8%D1%86%D0%B0&btnG=Search+Images&aq=f&oq=
По англоязычному [bird] + красный — у Гугла сильно лучше за счет полноты по зарубежному вебу
images.google.com/images?imgcolor=red&hl=en&q=bird&btnG=Search+Images&aq=f&oq=
images.yandex.ru/yandsearch?icolor=red&isgray=0&text=bird&rpt=image
1) более простой — пользователь загружает картинку, мы ее, возможно, узнаем по точной побайтовой контрольной сумме, если она встречалась нашему роботу в интернете, выдаем более развернутую информацию, рассчитанную в оффлайне, о ее точных дубликатах и «полудубликатах». Если не узнаем, то сообщаем об этом пользователю.
2) более сложный — перетащить процесс поиска дубликатов по нечеткой сигнатуре из оффлайна в онлайн. Тут потребуется немало дополнительного программирования, которое само себе не принесет пользы для основного применения алгоритма поиска дубликатов. Хотя, возможно сделать и это.
Будем ли мы делать эту задачу, и как именно, мы сообщим, скорее всего, уже после запуска, если он будет… До этого нам нужно будет взвесить много факторов при принятии окончательного решения.
Над качеством поиска все поисковики работают непрерывно, хотя об этом пишут мало. По нашим измерениям на оцененных коллекциях среднее качество поиска Я.Картинок и Гугл.Картинок по русскоязычным запросам сейчас примерно на одном уровне, у Я.Картинок — чуть-чуть ниже. Различия в ту или иную сторону обычно заметны на отдельных классах запросов, суммарная оценка зависит от их процента в потоке.
По качеству поиска идет соревнование, мы очень постараемся Гугл.Картинки обогнать в обозримом будущем. В любом случае, пользователи обоих систем от этой ситуации только выигрывают. ;)
По поводу поиска по имени файла: в расширенном поиске есть переключатель, который позволяет выбрать «зону» для поиска — «подпись», «прикартиночный текст». Если перейти на страницу результатов поиска, то видно, что генерируется запрос вида
itext[yandex logo] и idesc[yandex logo]
есть еще одна недокументированная зона iurl. В нее попадают некоторые осмысленные слова из урла картинки. С ее помощью можно решить часть поисковых задач.
images.yandex.ru/yandsearch?text=iurl%5Byandex+logo%5D&stype=image
По поводу более точного поиска по имени файла — мы подумаем.
Альтернативные подходы — это вовлечь пользователей в процесс написания подписей. Либо в виде игры по типу Google Image Labeler. Либо еще более остроумно — подсовывать картинки с надписями вместо капч ;) Говорят, недавно таким образом распознали архив New York Times.
Есть еще стандартная старая идея — по запросу со словом «красный» принудительно включать фильтр по преобладающему красному цвету. Но мы колеблемся и не делаем ее в таком простом варианте, ибо очень часто результаты не будут соответствовать ожиданиям пользователей.
А пока можно поиграть на веб-поиске яндекса с цветовыми запросами. Дизайнерам, вроде бы, очень нравится ;)
yandex.ru/yandsearch?text=%D0%BA%D1%80%D0%B0%D1%81%D0%BD%D1%8B%D0%B9
1) контент-сервисы с отобранными качественными фотографиями, которые пользователь самостоятельно привязывает к местности, типа panoramio.com. Это — очень интересный сервис для части пользователей, который скорее ближе к теме фотохостингов и карт.
2) поиск с учетом GPS координат, которые могут быть записаны в Exif заголовок. Несомненно, такая функция касается поиска по картинкам и будет в свое время очень востребована. На сегодняшний день есть несколько сдерживающих факторов: крайне небольшой процент проникновения камер с интегрированным GPS; преимущественно — это камерофоны, в которых недостаточно качественная камера, и снимки получаются некачественными. Кроме того, в момент публикации фото в веб, а не на фотохостинг, используются программы для уменьшения картинки, которые, как правило, выкидывают Exif заголовки…
— не совсем понятно, что будет выдавать такой поиск, и удовлетворит ли это разных пользователей? Поняние «похожие картинки» — слишком неопределенно и означает разное для разных людей и задач. А для того, чтобы хорошо решать задачу, мы должны ее как минимум хорошо формулировать. Настройка качества поиска всегда основывается на измерениях на размеченной человеком базе. Те, кто ее размечают, должны сначала между собой договориться о том, что они считают правильным?
— юзабилити тестирование говорит нам о том, что любая лишняя ссылка в интерфейсе ухудшает качество сервиса для пользователей, которым она не нужна. Поэтому при включении фич в массовый продукт мы должны 10 раз подумать о том, как это отзовется нам всех пользователях в целом.
Даже такая фича Яндекс. Картинок, как поиск картинок с разным преобладающим цветом, вызывает непонимание у некоторых пользователей.
Окончательное решение о том, запускать ли конкретную функцию в нашем сервисе, мы будем принимать, исходя из многих факторов, и расскажем о нем, видимо, сразу после запуска.
help.yandex.ru/search/?id=481939
Применив некоторое количество смекалки вы сможете соорудить форму, возможно, с JavaScript, которая будет показывать дубликаты по урлу картинки. Нужно только учитывать, что Яндекс кладет в индекс не все урлы картинок, а только те, описания которых он отобрал для поиска по запросу.
С момента формулировки общего подхода до запуска в продакшн нам пришлось преодолеть большое количество практических проблем, которые разрешались разнообразными остроумными алгоритмами. Оказалось, что одной простой идеи — недостаточно.
Большинство известных алгоритмов по поиску дубликатов или похожих изображений основаны на поиске особых точек (feature extraction) на картинках или наборов статистических свойств изображений. Первый подход позволяет «выравнивать» и отождествлять изображения, полученные обрезанием, но требует почти квадратичной сложности вычисления, поэтому используется на ограниченных коллекциях, например, на выдаче поиска по одному запросу. Второй подход не дает достаточно хорошей разрешающей способности на больших коллекциях.