Comments 51
Спросили бы «Какое изображение скручено по часовой?».
А смысл подсовывать капчу ботам, если они её всё равно обойдут? Имхо, намного удобнее и действеннее ловушки ставить.
Можно было бы сделать такую штуку: если вы бот, то введите капчу с картинки. :)
Если каптчу будут распознавать только боты, это тоже хорошо: не распознал белый текст на белом же фоне — значит, человек ты, проходи, милейший!
Любая общая каптча очень легко ломается хотя бы одним из этих способов:
а) Аутсорсом живым индусам/китайцам (которые только и делают, что целый день разгадывают присылаемые им каптчи за копейки)
б) Пробросом каптч по схеме: держим какой-нибудь популярныйпорносайт, на котором крутим каптчу, но не свою, а с ломаемого ресурса. Живой человек ради контента разгадывает, а мы для валидации отправляем его ввод на целевой сервер. Сервер сказал: «свой, проходи» — говорим то же самое на своём ресурсе.
Имхо эта борьба щита и меча никогда не закончится, сколь бы искусно изощрённые методы защиты ни придумывали. До сих пор нет 100% защиты от взлома реальных банковско-денежных систем (включая фальшивомонетчество), хотя что-что, а деньги защищать есть огромный стимул и имеются средства.
Кажись, Митник ещё сказал, что если в системе есть человеческий фактор — она ломается проще простого =).
а) Аутсорсом живым индусам/китайцам (которые только и делают, что целый день разгадывают присылаемые им каптчи за копейки)
б) Пробросом каптч по схеме: держим какой-нибудь популярный
Имхо эта борьба щита и меча никогда не закончится, сколь бы искусно изощрённые методы защиты ни придумывали. До сих пор нет 100% защиты от взлома реальных банковско-денежных систем (включая фальшивомонетчество), хотя что-что, а деньги защищать есть огромный стимул и имеются средства.
Кажись, Митник ещё сказал, что если в системе есть человеческий фактор — она ломается проще простого =).
а как быть, если на картинке изначально будет что-то вроде спирали, да еще и с нечеткими линиями? :)
В демо проверил неправильный ввод.
«No, Mr. Robot, you shall not pass!»
Убило.
«No, Mr. Robot, you shall not pass!»
Убило.
hashcash кажется поможет
Вообще, скручивание плодит края, так что задачу можно решать анализом спектра пространственных частот.
Или использовать оператор выделения края оптимизированный вообще не находить краёв в нормальном изображении, а только когда скрутка их наплодит, и решение принимать на основании суммы всех пикселов после детектора, которую можно посчитать и в самом детекторе. Минимальное значение, суть не искаженное изображение.
Или использовать оператор выделения края оптимизированный вообще не находить краёв в нормальном изображении, а только когда скрутка их наплодит, и решение принимать на основании суммы всех пикселов после детектора, которую можно посчитать и в самом детекторе. Минимальное значение, суть не искаженное изображение.
Идея — шикарна.
Вместо слэша при сборке пути до картинки нужно использовать os.sep
Вместо слэша при сборке пути до картинки нужно использовать os.sep
os.path.join лучше
Чем лучше? В конкретном коде.
os.path.join лучше, потому что:
* умеет правильно работать с абсолютными и относительными путями
* не добавит дублирующих слешей
* эта функция предназначена для формирования путей
Потренируйтесь, и напишите свою функцию которая будет работать аналогично os.path.join
Вот примеры для тестов
* умеет правильно работать с абсолютными и относительными путями
* не добавит дублирующих слешей
* эта функция предназначена для формирования путей
Потренируйтесь, и напишите свою функцию которая будет работать аналогично os.path.join
Вот примеры для тестов
os.path.join('/home','usr')
os.path.join('/home/','usr')
os.path.join('/home/','/usr')
Зачем мне писать уже готовую функцию?
Зачем рассуждать о преимуществах использования данной функции в отрыве от конкретной ситуации?
Я предлагаю исправить код на:
img = cv2.imread(dir + os.sep + str(i) + '.jpg')
Вы на:
img = cv2.imread(os.path.join(dir, str(i) + '.jpg'))
Весь спор — не более чем мнение каждого из нас о том, что такое «pythonic way».
Мне нравится мой вариант.
Кто-то может и вместо оставшегося плюса в вашем варианте какой-нибудь «более правильный» способ формирования строки обосновать. Добавив этим (с моей точки зрения) нечитаемости и наколбасив символов, которые можно не колбасить.
Зачем рассуждать о преимуществах использования данной функции в отрыве от конкретной ситуации?
Я предлагаю исправить код на:
img = cv2.imread(dir + os.sep + str(i) + '.jpg')
Вы на:
img = cv2.imread(os.path.join(dir, str(i) + '.jpg'))
Весь спор — не более чем мнение каждого из нас о том, что такое «pythonic way».
Мне нравится мой вариант.
Кто-то может и вместо оставшегося плюса в вашем варианте какой-нибудь «более правильный» способ формирования строки обосновать. Добавив этим (с моей точки зрения) нечитаемости и наколбасив символов, которые можно не колбасить.
Я не говорю, что вашем варианте есть изьян.
Как и pawnhearts я утверждаю, что os.path.join — правильнее использовать как в общем так и в данном кокнретном случае. Правильнее — потому что всегда для склейки пути стоит использовать os.path.join и забыть о проблеме переносимости, дубликатов слешей, относительности путей,… Даже на секунду не надо задумываться, питоник/непитоник, больше символов/меньше, для склейки путей надо использовать os.path.join
По поводу читабельности и «наколбасить» символов тоже не соглашусь. Код
отлично читается, тут дословно написано: «объединиться путь к файлам»
Как только в коде вы увидите os.path.join — значит формируется путь к файлу, когда в коде используются знакомые общепринятые конктрукции — такой код всегд будет читаться лучше.
Как и pawnhearts я утверждаю, что os.path.join — правильнее использовать как в общем так и в данном кокнретном случае. Правильнее — потому что всегда для склейки пути стоит использовать os.path.join и забыть о проблеме переносимости, дубликатов слешей, относительности путей,… Даже на секунду не надо задумываться, питоник/непитоник, больше символов/меньше, для склейки путей надо использовать os.path.join
По поводу читабельности и «наколбасить» символов тоже не соглашусь. Код
img = cv2.imread(os.path.join(dir, '%s.jpg'%i))
отлично читается, тут дословно написано: «объединиться путь к файлам»
Как только в коде вы увидите os.path.join — значит формируется путь к файлу, когда в коде используются знакомые общепринятые конктрукции — такой код всегд будет читаться лучше.
Есть еще такой вариант решения капчи MintEye с использованием голосовых подсказок и гуглового text2speech API — gist.github.com/4520930
Демо: www.youtube.com/watch?v=u0M7gmS5Eg0
Демо: www.youtube.com/watch?v=u0M7gmS5Eg0
Интересно, будет ли работать такой подход — покрутить на разные углы и прокоррелировать с исходным изображением? Предположительно, наиболее закрученные изображения должны давать более высокие значения корреляции при одинаковых углах поворота.
Просто выводить 3 разных картинки, 1 из которых не скручена.
Возможно, немного сложнее оригинала, но всяко проще рекапчи. Как такое разгадывать будете?)
Неужто нет алгоритма, который определит, что большинство линий изогнуты по одинаковому алгоритму? :) В скрученном изображении не бывает прямых, каждая линия — спиралевидна.
Можно использовать разные алгоритмы искажения. Например, как в эффектах Photo Booth:
Но, как было сказано выше, даже если разместить 6 картинок с одной правильной, то при случайном тыке — будет 30% правильных распознаваний, что вполне себе нормальный результат.
Но, как было сказано выше, даже если разместить 6 картинок с одной правильной, то при случайном тыке — будет 30% правильных распознаваний, что вполне себе нормальный результат.
А если скручивание будет относительно нескольких центров вместо одного — сработает?
Sign up to leave a comment.
Решение MintEye CAPTCHA в 23 строки кода