0

If I have the following 4 images:

6

5

9

6

How can I determine that the two '6's are the same but 5 and 6, 6 and 9, 9 and 5, etc are not?

The images will always be monochrome (i.e only black and white, no other colors)

At the moment, I'm simply counting the number of black pixels in the image, and that seems to work okay, but I'm not sure if its reliable or if there's a better method. In the above example, both '6's have 29 black pixels, while 5 has 26, and 9 has 28. So the difference between 6 and 9 is only 1 pixel.. however in other fonts, 9 and 6 have identical number of pixels. E.g:

6

6

have both got an identical number of foreground pixels.

user2790209
  • 339
  • 2
  • 5
  • 17
  • 1
    Do you mean the images are the same or that the recognition detect the same number? By monochrome, do you mean there are no shades of grey? Have you tried an OCR library to detect the numbers and see if the detections match? 6 and 9 should be almost the same given one is upside down of the other. – Peter Lawrey Sep 22 '13 at 11:33
  • @PeterLawrey I have only the images, and from that I need to determine if they are duplicates or not. Can't use any existing OCR, need to write it myself. Yes, completley monochrome, no colors except white and black. – user2790209 Sep 22 '13 at 11:36
  • In that case, I suggest you look at the techniques existing OCR libraries use and write that yourself. Counting pixels is unlikely to be reliable (or what they had in mind) Which machine learning algos have you been show or have been suggested to you? – Peter Lawrey Sep 22 '13 at 11:38
  • @PeterLawrey Any suggestions where I look, or which technique I should look into? – user2790209 Sep 22 '13 at 11:40
  • 1
    I like neural networks and I did my thesis in using it for character recognition in 1993. When the project is assessed, an important factor is how closely you using the expected algo, so going and finding your own which may happen to work won't get you the marks. You have to know what they expect of you. I can't tell what that is, only they can. – Peter Lawrey Sep 22 '13 at 11:46
  • @PeterLawrey This isn't for a thesis or anything like that.. its for a real work project. – user2790209 Sep 22 '13 at 11:58
  • How do you get these images? From a camera? From web pages? What is the nature of the variation. e.g. can the images be at an angle? – Peter Lawrey Sep 22 '13 at 20:07
  • @PeterLawrey The images are generated by screen scraping. They won't be at an angle, they'll always be the same way, the only difference can be that some might be 2-8 pixels wider or longer than others, but the extra size will only contain background and no foreground. – user2790209 Sep 22 '13 at 21:38
  • @user2790209 what is the size of input I mean are you required to identify numbers from 0-9 or it can be anything in the integer range? – Prateek Sep 23 '13 at 19:48

1 Answers1

3

Are you trying to detect exact-identicals, or detect near-identicals/ approximate matches (which is what real OCR is about)?

You may as well start by finding a weighted center of the image/glyph, perhaps scaling size for comparability (if you have to match at different sizes), and then comparing pixel-to-pixel similarity (as % similarity) between the two images.

Of course if the images are all cropped & sized for you then you just have to scan the images comparing all pixels, to achieve a brute-force "similarity" measure.

See BufferedImage.getRGB(): http://docs.oracle.com/javase/1.5.0/docs/api/java/awt/image/BufferedImage.html#getRGB(int,%20int)

You can write a function to take two RGB pixel values (as ints up to 0xffffff), separate the components, & sum the component differences.

Thomas W
  • 13,940
  • 4
  • 58
  • 76
  • Near identicals / strong matches are what I'm trying to find. Scaling is a great idea... – user2790209 Sep 22 '13 at 11:57
  • How would I compare pixel to pixel similarity? Comparing colors? – user2790209 Sep 22 '13 at 11:59
  • Yes, splitting the pixel RGB ints into R,G,B components & summing the difference across all components. – Thomas W Sep 22 '13 at 12:08
  • Well, given that the images in this case will all be monochrome, and will have no colors except black & white, I won't need to split the RBG components and can instead just compare the RBG code returned by `getRBG`, right? One question, say if I have two images of `5`, but one image is 2-8 pixels wider or longer (containing just the background), and I scaled both images to be the same size, in that case will the `getRBG()` give me the same value of each pixel for both images? – user2790209 Sep 22 '13 at 12:11
  • You'll still need to separate components by bit-manipulation, and difference them separately, to get a valid result. You would not expect to see all pixels absolutely identical, especially in the case of scaling. – Thomas W Sep 22 '13 at 23:27
  • But if the only colors are black and white, why would I need to split them? And can you elaborate on how I would compare them in the case of scaling? – user2790209 Sep 23 '13 at 05:16
  • The topmost byte is Red `((rgb >> 16) & 0xff)`. If you subtract across the entire RGB int, differences in red will outweigh other components by a factor of 256 or 65536. So you should either flatten RGB to a B&W 'brightness' for comparison, or compare components separately. – Thomas W Sep 23 '13 at 06:12
  • But, the image is black & white. It literally has no other colors or shades of colors. If I loop over all the pixels in the image, store their `getRGB()` values in a `HashSet`, and then print the size / values of `HashSet`, it contains only 2 values, one is -1 (white) and the other is the -161... code for black. – user2790209 Sep 23 '13 at 06:19
  • I would subtract marks if you munged the subtraction. Converting to B&W brightness, or proper component subtraction, would be fine. Your result needs to be a well-defined difference. Good luck with your project. – Thomas W Sep 23 '13 at 06:26
  • I really wish I knew what those words mean – user2790209 Sep 23 '13 at 06:40
  • Ask it as a separate question. – Thomas W Sep 23 '13 at 10:41