Wizzup?
2009-12-09 15:04:29
Hey,
So there's this thing Raymond and I have been wanting to do for a long time, and soon we're finally going to get some time… (Well, at least I'll be getting some time.)
And what we have to make is a function that filters out all the pixels in the uptext area, that are not part of the uptext. And this isn't as trivial as it looks.
We have some idea's, and I'm going to describe them here later.
I'm also posting this because I'm looking for some help.
I'd like your ideas on how you would filter the uptext. I don't care about speed, but I care about accuracy.
If you have time, it would be totally awesome if you could give the filtering a go yourself, and see how far you can come. Again, speed doesn't matter. Even if it is 30 seconds. As long as we have a working accurate algorithm. We can always speed it up heaps later.
So basically… Suggestions and idea's are welcome, and so is code.
Wizzup?
2009-12-09 17:17:27
At the moment, something like this:
Posterize. Get the colours that are possibly uptext. (we will also get garbage this way.)
Use points that are retrieved with posterize on real image to filter most of the garbage out; floodfills, tol checks, shadow checks.
Possibly floodfill again.
Pass to OCR.
EDIT: Ben's OCR doesn't care if some internal pixels are missing, but does care about ``external'' pixels. Ones that don't belong to a character, so we must be sure to eliminate those.
Wizzup?
2009-12-19 07:16:27
OK, I wrote the first base of the filter two days ago. It works pretty well, actually. (Without any sort of floodfill.)
There are just a few things I *must* implement, and some other things are optional/observations that require further brainstorming.
"Must":
Make sure the pixels at the line (x, 0) are also filtered. Adjust colour filter more Rewrite the OCR to a more nice and feature-full structure/API. Procedure reasonable output in rs_getUpText
Optional:
Test how well shadows alone works (Works good…) Add character splitting. This will help with identifying noise. If the above happens, we can revert to shadows. - Make a distinction in the uptext colours when splitting.
- Add checks to see if it's going wrong. EG, lots of noise, making everything one white blob.
- If something indeed went wrong, make sure we tell that to the client by means of a boolean.
- We can filter with tolerances, by observing that the pixels with the following identity most likely are from the text; it has a pixel at (x+1,y+1) that is shadow. This isn't the case of the noise that `bleeds' through it, like the falador walls. This way we can compare the colours that are more likely uptext against colours that can be noise.
- If a colour occurs often in a certain (small) area then it is probably noise.
Wizzup?
2009-12-22 11:18:06
Output after some more changes to the code.
Explanation:
1: Normal pic
2: Colour filter
3: Characteristics filter
4: Shadows
5: Characters
6: Characters, split
7: Shadows, split. (Using the split Characters + extra checks and possible splits)
EDIT: Added OCR, and it works nicely. Will mess more with it later.
"To do" just means I have to bind this new filter to the ocr.
Wizzup?
2009-12-22 17:53:17
Added a more accurate version to the repository. Without debug, it is 5ms for filtering + OCR it seems. But I guess anything < 30 ms is fine.
I still need to add the noise detection and failure detection. I don't know how I am going to do it yet.
mastaraymond
2009-12-23 12:44:32
C-C-C-C-Combo breaker..
No one cares Wizzup.
Wizzup?
2010-05-09 18:07:03
BUMP.
I guess the other stuff will need to be implemented as well.
Currently we have provided the same (but updated) OCRBench tool:
http://wizzup.org/simba/article/8You can use it to load Bitmaps or read directly from the client.