В спокойной ситуации — да. Но есть нюансы. Например, можно переключиться на другую вкладку пока страница грузится и не заметить, что капча появилась. Или изображение может отказаться загружаться, пока не обновить страницу. Можно просто затупить и запутаться в лабиринте. Способов не уложиться в 20 секунд — масса.
Ну и потом, после первой сотни проходить эти лабиринты надоедает.
Интересный способ поиска свободных клеток. Когда я посмотрел лабиринты мне пришел в голову такой вариант:
Дано:
1. свободные клетки всегда ярче;
2. треугольники, как я понимаю, всегда проходят диагонально через центр;
3. вокруг лабиринта всегда есть непроходимая граница.
Алгоритм:
1. выбираем четыре заведомо занятых клетки для каждого из направлений (север, юг, запад, восток) не зависимо от наличия треугольников;
2. находим для каждой из них средний цвет;
3. в цикле сравниваем (яркость заведомо непроходимой клетки (из 2) + порог) и (яркость определяемой клетки) если яркость проверяемой клетки больше тогда она проходима, иначе это стена.
Это интересный вариант. Наверное, тогда лучше сравнивать не яркость, а просто сумму разностей по трём цветам (или сумму квадратов разностей). А можно выбрать заведомо занятую клетку и заведомо свободную, и смотреть, на какую из них проверяемая больше похожа. Если бы цвет дорожек менялся, наверное, стоило бы использовать одно из этих решений.
Я понимаю, что это уже за пределами задачи, которую вы решаете в статье, но это так звучит… Вы играете в «простую и монотонную» игру, а когда в ней открывается вставная игра, «нетривиальная», даёте её пройти скрипту.
Это тонкий ход — дать возможность программистам и поиграть, и подзаработать (продавая скрипты игрокам).
А там, глядишь, авторов лучших скриптов и на работу позовут, хех.
Авторам следовало бы делать эти треугольники градиентами, тогда бы было веселее. Да и сами лабиринты делать кривыми, это гораздо забавнее, хотя и нагрузит сервер сильнее.
Автору топика же я порекомендую почитать про бинаризацию и алгоритм «волна», а то мое естество всячески протествовало во время чтения от увиденного кода
Все можно сделать гораздо проще — беглый взгляд на картинку показывает, что цвет элементов лабиринта не меняется при наложении треугольников, меняется лишь яркость. Поэтому первый этап — преобразуем картинку в цветовое пространство Lab по формулам:
Для примера, возьмем эту картинку:
Выделяем канал b:
Простейшая фильтрация и пороговая обработка:
Далее заливка любым FloodFill алгоритмом с входа и получаем конечный результат:
Идея классная, но не лишена нюансов. Вы взяли одну конкретную картинку и на ее основе построили рабочую математическую модель. Но если глянуть шире, то уже даже на 6 тестовых примерах из статьи выходит не всё так радужно.
Канал a:
Канал b:
Нужно выбирать наиболее контрастный, нужно подбирать порог… Например на пятой не хватает контраста ни в одном из каналов.
Да, все примеры, за исключением пятого вполне неплохо преобразовались. Что уже дает весьма хорошую точность распознавания. А выбор одного из двух каналов можно сделать просто — прогнать алгоритм на обоих и посмотреть площадь залитой зоны — там где она относительно небольшая, то и считать нормальным.
Порог выбирается также практически любым алгоритмом бинаризации — на таких картинках должен хорошо работать
Попробовал своим фильтром бинаризации и был очень удивлен, когда получил голый шум. Я правда выбирал значения по наибольшему компоненту в RGB, отсюда оно и шумит, пытается сохранить максимум деталей и в результате голый шум. Блюр (на картинке в углу) тоже не слишком помог. Впрочем, фильтр я делал для книжек больше, на них он работает идеально.
Можно даже попробовать использовать один из многих алгоритмов адаптивной (динамической) бинаризаци.
Вот пример описания: it-claim.ru/Library/Books/ITS/wwwbook/ist4b/its4/fyodorov.htm
И пара примеров работы с той статьи:
Прохождение капчи «Лабиринт» на Javascript