in reply to OCRing out the Digits
(a nitpick: the challenge asks for "distinct integers": your output for the 1st test is wrong)
It's either you are very lucky, or I'm negative as usual. Just wanted to check at 1st, if the engine applies any heuristics when all glyphs are obviously spaced apart a little (e.g. receipts to be easily readable by the elderly or similar.) I only did a dozen tests with manual image uploading, didn't apply for a free pass key.
use strict; use warnings; use GD; my $width = 1000; my $height = 100; my $image_file = q#output_image.png#; my $image = GD::Image->new($width, $height); my $white = $image->colorAllocate(255, 255, 255); my $black = $image->colorAllocate(0, 0, 0); $image->filledRectangle(0, 0, $width - 1, $height - 1, $white); my $font_path = q#c:/windows/fonts/cour.ttf#; my $font_size = 14; $image->stringFT($black, $font_path, $font_size, 0, 20, 75, '2 5 5 2 5 5 2 5 5'); open TEMP, q/>/, qq/$image_file/; binmode TEMP; print TEMP $image->png; close TEMP;
>>>
****** Result for Image/Page 1 ****** 255 255 255
Obviously not applicable for PWC 329.1. If, as I'd do anyway, the "s" transliteration modifier had been used i.e. string becomes "2 5 5 2 5 5 2 5 5":
****** Result for Image/Page 1 ****** 25525 52 5 5
And another Mars Orbiter kaput. Actually, there are different (wrong) results, i.e. digits groupings, for canvas size and string position as in your example, i.e. it's a factor, too. The reason I changed to larger canvas is because I tried larger font size, at some moment. Then some glyphs are just ignored, up to the point when NO text is found in the image (string as above, 500x500 canvas, 10x50 position, 16 points font, OCR2 engine, auto-enlarge on). Now, YOU ARE LUCKY to get correct results from them.
|
---|