Comments 51
Спросили бы «Какое изображение скручено по часовой?».
+5
UFO just landed and posted this here
А смысл подсовывать капчу ботам, если они её всё равно обойдут? Имхо, намного удобнее и действеннее ловушки ставить.
+1
Можно было бы сделать такую штуку: если вы бот, то введите капчу с картинки. :)
+1
UFO just landed and posted this here
Если каптчу будут распознавать только боты, это тоже хорошо: не распознал белый текст на белом же фоне — значит, человек ты, проходи, милейший!
0
UFO just landed and posted this here
Любая общая каптча очень легко ломается хотя бы одним из этих способов:
а) Аутсорсом живым индусам/китайцам (которые только и делают, что целый день разгадывают присылаемые им каптчи за копейки)
б) Пробросом каптч по схеме: держим какой-нибудь популярныйпорносайт, на котором крутим каптчу, но не свою, а с ломаемого ресурса. Живой человек ради контента разгадывает, а мы для валидации отправляем его ввод на целевой сервер. Сервер сказал: «свой, проходи» — говорим то же самое на своём ресурсе.
Имхо эта борьба щита и меча никогда не закончится, сколь бы искусно изощрённые методы защиты ни придумывали. До сих пор нет 100% защиты от взлома реальных банковско-денежных систем (включая фальшивомонетчество), хотя что-что, а деньги защищать есть огромный стимул и имеются средства.
Кажись, Митник ещё сказал, что если в системе есть человеческий фактор — она ломается проще простого =).
а) Аутсорсом живым индусам/китайцам (которые только и делают, что целый день разгадывают присылаемые им каптчи за копейки)
б) Пробросом каптч по схеме: держим какой-нибудь популярный
Имхо эта борьба щита и меча никогда не закончится, сколь бы искусно изощрённые методы защиты ни придумывали. До сих пор нет 100% защиты от взлома реальных банковско-денежных систем (включая фальшивомонетчество), хотя что-что, а деньги защищать есть огромный стимул и имеются средства.
Кажись, Митник ещё сказал, что если в системе есть человеческий фактор — она ломается проще простого =).
0
а как быть, если на картинке изначально будет что-то вроде спирали, да еще и с нечеткими линиями? :)
0
В демо проверил неправильный ввод.
«No, Mr. Robot, you shall not pass!»
Убило.
«No, Mr. Robot, you shall not pass!»
Убило.
+2
hashcash кажется поможет
0
Вообще, скручивание плодит края, так что задачу можно решать анализом спектра пространственных частот.
Или использовать оператор выделения края оптимизированный вообще не находить краёв в нормальном изображении, а только когда скрутка их наплодит, и решение принимать на основании суммы всех пикселов после детектора, которую можно посчитать и в самом детекторе. Минимальное значение, суть не искаженное изображение.
Или использовать оператор выделения края оптимизированный вообще не находить краёв в нормальном изображении, а только когда скрутка их наплодит, и решение принимать на основании суммы всех пикселов после детектора, которую можно посчитать и в самом детекторе. Минимальное значение, суть не искаженное изображение.
0
Идея — шикарна.
Вместо слэша при сборке пути до картинки нужно использовать os.sep
Вместо слэша при сборке пути до картинки нужно использовать os.sep
0
os.path.join лучше
+5
Чем лучше? В конкретном коде.
0
os.path.join лучше, потому что:
* умеет правильно работать с абсолютными и относительными путями
* не добавит дублирующих слешей
* эта функция предназначена для формирования путей
Потренируйтесь, и напишите свою функцию которая будет работать аналогично os.path.join
Вот примеры для тестов
* умеет правильно работать с абсолютными и относительными путями
* не добавит дублирующих слешей
* эта функция предназначена для формирования путей
Потренируйтесь, и напишите свою функцию которая будет работать аналогично os.path.join
Вот примеры для тестов
os.path.join('/home','usr')
os.path.join('/home/','usr')
os.path.join('/home/','/usr')
+1
Зачем мне писать уже готовую функцию?
Зачем рассуждать о преимуществах использования данной функции в отрыве от конкретной ситуации?
Я предлагаю исправить код на:
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».
Мне нравится мой вариант.
Кто-то может и вместо оставшегося плюса в вашем варианте какой-нибудь «более правильный» способ формирования строки обосновать. Добавив этим (с моей точки зрения) нечитаемости и наколбасив символов, которые можно не колбасить.
0
Я не говорю, что вашем варианте есть изьян.
Как и 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 — значит формируется путь к файлу, когда в коде используются знакомые общепринятые конктрукции — такой код всегд будет читаться лучше.
0
Есть еще такой вариант решения капчи MintEye с использованием голосовых подсказок и гуглового text2speech API — gist.github.com/4520930
Демо: www.youtube.com/watch?v=u0M7gmS5Eg0
Демо: www.youtube.com/watch?v=u0M7gmS5Eg0
+1
Интересно, будет ли работать такой подход — покрутить на разные углы и прокоррелировать с исходным изображением? Предположительно, наиболее закрученные изображения должны давать более высокие значения корреляции при одинаковых углах поворота.
0
Просто выводить 3 разных картинки, 1 из которых не скручена.
+1
Возможно, немного сложнее оригинала, но всяко проще рекапчи. Как такое разгадывать будете?)
+2
UFO just landed and posted this here
Неужто нет алгоритма, который определит, что большинство линий изогнуты по одинаковому алгоритму? :) В скрученном изображении не бывает прямых, каждая линия — спиралевидна.
0
Можно использовать разные алгоритмы искажения. Например, как в эффектах Photo Booth:
Но, как было сказано выше, даже если разместить 6 картинок с одной правильной, то при случайном тыке — будет 30% правильных распознаваний, что вполне себе нормальный результат.
Но, как было сказано выше, даже если разместить 6 картинок с одной правильной, то при случайном тыке — будет 30% правильных распознаваний, что вполне себе нормальный результат.
0
9 картинок, 3 правильные
+2
А если скручивание будет относительно нескольких центров вместо одного — сработает?
0
Sign up to leave a comment.
Решение MintEye CAPTCHA в 23 строки кода