Captcha
My teacher once talked about that...gfoot wrote:I thought the standard way to crack arbitrary captchas on a large scale was to proxy them to porn site surfers, and get the guinea-pigs to do the work without realising it.
Of course, to do that you need (a) lots of bandwidth, (b) lots of visitors, and (c) lots of porn. Hmm.
Anyway porn site is illegal in my country.
10.001 images? Are you serious?
How long did it take for the 32 who solved it?
If I would use my standard OCR-approach, I guess it would take about 0.5-1.0 seconds per picture:
10001/(60*60) = 2 hours 46 minutes. As I would have to train it a bit, lets say 3 hours, but I have to interact only about 15 minutes, then it'll know the font .... well ... acceptable at the weekend, if I have nothing to do and a good book to read
How long did it take for the 32 who solved it?
If I would use my standard OCR-approach, I guess it would take about 0.5-1.0 seconds per picture:
10001/(60*60) = 2 hours 46 minutes. As I would have to train it a bit, lets say 3 hours, but I have to interact only about 15 minutes, then it'll know the font .... well ... acceptable at the weekend, if I have nothing to do and a good book to read
Ok, I've tried something much simpler as my algorithm for rotating the images makes some strange things (Has anyone experience with imagemagick? Why is the font getting smaller each time I rotate the picture?)megabreit wrote:I did not use an OCR approach but "simply" reduced the number of possible candidates.
But, reading the solved forum, there were other approaches working far better... none of them used OCR.
As 10,001 files are given, you can make 10,001² = 100,020,001 comparisons. I have reduced them with a very simple method to 245,536. But it might be possible that my method has errors. Anyway, it's too much.
-
- Forum Admin
- Posts: 496
- Joined: Sat May 28, 2011 9:14 am
- Location: Germany
I don't think so, since if you have compared file M with file N already, you don't need to compare file N with file M anymore. Also you don't compare a file to itself. Example:moose wrote: As 10,001 files are given, you can make 10,001² = 100,020,001 comparisons.
Compare 4 things with each other:
#1 with #2
#1 with #3
#1 with #4
#2 with #3
#2 with #4
#3 with #4
= 6 comparisons total
= sum of (1 to n) where n is 3
Thus, comparing 10,001 files with each other should need sum of (1 to n) where n is 10,000. With the fomula n*(n+1)/2, that is 50,005,000 comparisons. If I am not mistaken.
-
- Posts: 35
- Joined: Tue May 12, 2009 6:08 pm
- Location: Greece
Its because rotation != n*90 degrees is lossy.moose wrote:Ok, I've tried something much simpler as my algorithm for rotating the images makes some strange things (Has anyone experience with imagemagick? Why is the font getting smaller each time I rotate the picture?)megabreit wrote:I did not use an OCR approach but "simply" reduced the number of possible candidates.
But, reading the solved forum, there were other approaches working far better... none of them used OCR.
As 10,001 files are given, you can make 10,001² = 100,020,001 comparisons. I have reduced them with a very simple method to 245,536. But it might be possible that my method has errors. Anyway, it's too much.