В третьем баннере (последняя картинка) кнопка имеет небольшой горизонтальный градиент. Поэтому давайте мерять сделаем какой-то порог по горизонтальному градиенту. Мы получили тут какой-то Edge Detector, который детектит только вертикальные границы.
Отвечая на ваш вопрос — да, конкретно для кнопок он скорее всего будет работать. Описанный вами алгоритм идейно очень похоже на вариацию на тему Contour detection — а именно и он показал себя лучше всего.
>Можно дополнительно проверить что за краем прямоугольника есть контрастные пиксели (рамка кнопки).
Эту проверку можно совместить с предыдущим этапом: проверять не только горизонтальную компоненту градиента, а весь градиент. Оно будет работать потому что вертикальная компонента внутри кнопок тоже достаточно мала. В таком случае процедуру «склейки» полосок в прямоугольник можно свести к нахождению связанных компонент пикселей, отмеченных как «равнины» (градиент меньше порога), окруженных «стенами» (градиент выше порога). А затем полученные «равнины» пофильтровать по критериям. В такой вариации сходство с описанным в статье подходом ещё более явно.
Хорошее замечание! Альтернативные решения за пределами «написать своё» в статье не рассмотрены — вместо этого сделан фокус на обзор методов Computer Vision, а баннеры — лишь повод. Поэтому расскажу про актуальность проблемы тут.
Да, мы не первые в мире люди, которые столкнулись с такой задачи. Существует множество сторонних решений, начиная с плагинов Фотошопа, и заканчивая отдельными тулами постобработки svg-шек, которые позволяют локализовать креативы. К сожалению, в этих инструментах предполагается, что они будут использоваться дизайнерами, работающем в конкретной программе, или в конкретном формате файла. В наших условиях тяжело навязать дизайнеру какой-то дополнительный функционал ввиду разнообразия используемых программ, того, что они фрилансеры, и из-за их общей загруженности (они — боттлнек производства баннеров). Для этого был неприхотливый инструмент, который умеет работать с разными форматами изображений, не использует какие-то предположения о том, где они были сделаны, и умеет решать наши проблемы по локализации без создания дополнительной рутины. Такого инструмента мы не нашли.
Поэтому между «заставить всех дизайнеров пересесть на единый конкретный пайплайн и набор инструментов» и «сделать свою тулу для менеджера кампаний Adwords» было выбрано второе. К слову — массовое создание и управление кампаниями в Adwords у нас тоже автоматизировано, что сыграло роль в решении (по сути, произошла автоматизация ещё одного кусочка жизненного цикла кампании).
Ради «пары десятков» баннеров это было бы и вправду нецелесообразно. Но у нас одна «болванка» превращается в несколько десятков баннеров (под разные языки, регионы и валюты), и количество производимых картинок измеряется сотнями в неделю.
* К слову, насчёт баннерогенерации — у Criteo есть интересная технология, в которой они собирают баннеры «налету» под пользователя из заготовленных кусков, и оптимизируют при этом CTR. Это занятная концепция, которая кроме локализации ещё решит ряд других наших проблем, типа оптимизации и увеличения количества создаваемых баннеров. Но риски, и потребовало бы перепостроения всего пайплайна вокруг одного конкретного продукта Criteo.
Кнопки и вправду бывают разных форм и цветов, и количество разных графических решений высоко. Но в подавляющем большинстве случаев мы ищем объект конкретных размеров и конкретной формы. У нас нет задачи замены каких-то других элементов (нарисованных товаров, например). Мы просто рисуем на готовом изображении текст для разных локалей.
В чём его особенность, в чём «фишка» подхода? У него есть какая-то новизна, не по сравнению с предыдущей версией, а глобальная? Подобная нейросетевая архитектура, с двумя сетями, одна из которых кодирует запрос, а другая — информацию о документе — давно изучена и используется, например DSSM от Microsoft (Deep Structured Semantic Model). Добавили туда текст? Так тоже делали.
Кеширование векторов — это интересный, но типовой приём (например, ещё часто запихивают вектора документов в какой-нибудь индексатор типа ElasticSearch, чтобы потом быстро дёргать ближайших соседей к вектору — у вас наверняка свой продукт для этого). Серьёзно, вы и вправду раньше считали вектора всех документов заново на каждый чих?
Хитрая многоуровневая фильтрация и индексы? Да, это нужно. Это касается скорее оптимизации, не так ли?
Отвечая на ваш вопрос — да, конкретно для кнопок он скорее всего будет работать. Описанный вами алгоритм идейно очень похоже на вариацию на тему Contour detection — а именно и он показал себя лучше всего.
>Можно дополнительно проверить что за краем прямоугольника есть контрастные пиксели (рамка кнопки).
Эту проверку можно совместить с предыдущим этапом: проверять не только горизонтальную компоненту градиента, а весь градиент. Оно будет работать потому что вертикальная компонента внутри кнопок тоже достаточно мала. В таком случае процедуру «склейки» полосок в прямоугольник можно свести к нахождению связанных компонент пикселей, отмеченных как «равнины» (градиент меньше порога), окруженных «стенами» (градиент выше порога). А затем полученные «равнины» пофильтровать по критериям. В такой вариации сходство с описанным в статье подходом ещё более явно.
Да, мы не первые в мире люди, которые столкнулись с такой задачи. Существует множество сторонних решений, начиная с плагинов Фотошопа, и заканчивая отдельными тулами постобработки svg-шек, которые позволяют локализовать креативы. К сожалению, в этих инструментах предполагается, что они будут использоваться дизайнерами, работающем в конкретной программе, или в конкретном формате файла. В наших условиях тяжело навязать дизайнеру какой-то дополнительный функционал ввиду разнообразия используемых программ, того, что они фрилансеры, и из-за их общей загруженности (они — боттлнек производства баннеров). Для этого был неприхотливый инструмент, который умеет работать с разными форматами изображений, не использует какие-то предположения о том, где они были сделаны, и умеет решать наши проблемы по локализации без создания дополнительной рутины. Такого инструмента мы не нашли.
Поэтому между «заставить всех дизайнеров пересесть на единый конкретный пайплайн и набор инструментов» и «сделать свою тулу для менеджера кампаний Adwords» было выбрано второе. К слову — массовое создание и управление кампаниями в Adwords у нас тоже автоматизировано, что сыграло роль в решении (по сути, произошла автоматизация ещё одного кусочка жизненного цикла кампании).
Ради «пары десятков» баннеров это было бы и вправду нецелесообразно. Но у нас одна «болванка» превращается в несколько десятков баннеров (под разные языки, регионы и валюты), и количество производимых картинок измеряется сотнями в неделю.
* К слову, насчёт баннерогенерации — у Criteo есть интересная технология, в которой они собирают баннеры «налету» под пользователя из заготовленных кусков, и оптимизируют при этом CTR. Это занятная концепция, которая кроме локализации ещё решит ряд других наших проблем, типа оптимизации и увеличения количества создаваемых баннеров. Но риски, и потребовало бы перепостроения всего пайплайна вокруг одного конкретного продукта Criteo.
Кнопки и вправду бывают разных форм и цветов, и количество разных графических решений высоко. Но в подавляющем большинстве случаев мы ищем объект конкретных размеров и конкретной формы. У нас нет задачи замены каких-то других элементов (нарисованных товаров, например). Мы просто рисуем на готовом изображении текст для разных локалей.
Кеширование векторов — это интересный, но типовой приём (например, ещё часто запихивают вектора документов в какой-нибудь индексатор типа ElasticSearch, чтобы потом быстро дёргать ближайших соседей к вектору — у вас наверняка свой продукт для этого). Серьёзно, вы и вправду раньше считали вектора всех документов заново на каждый чих?
Хитрая многоуровневая фильтрация и индексы? Да, это нужно. Это касается скорее оптимизации, не так ли?