SRL Archive - Development

This is currently a problem in the Mufasa OCR. Identifying is fine.

There are currently two methods, and both are far from perfect:

• Blob search by BenLand100. Slow(relatively, it is still faster than SCAR), and not very accurate. (It may be better with tweaking?)
• I made a quick filtering method, using posterizing, and contrast. It should get an extra (Floodfill) filter procedure, to filter noise. It's pretty fast (3x faster than SCAR), and quite accurate; but it fails in situations where the uptext colors are very much alike to the background colours.

My quick method could use some extra tweaking, but I don't believe it will be the best solution in the end… We need a more specific algorithm.

This algorithm could be relatively slow; as long as it very accurate.
We could collect a lot of colour data. HSL/RGB/Lab and other. If we can filter out the uptext with pure tolerance, that would be a huge advantage.
However, I don't think that alone won't work. So we will have to check each pixels. Add several checks. (Is it an edge pixel, if so, is there a shadow pixel? If not, is it even part of a character?)
Perhaps a floodfill of some sort, with tolerance comparisons, and some other extra checks.

Perhaps it is time we define these checks. (Or come up with another algo)

~Wizz

Can you use the shadow to find the color of the text (go up and left 1 pixel) and not have to deal with tolerance at all?

From: Widget
Can you use the shadow to find the color of the text (go up and left 1 pixel) and not have to deal with tolerance at all?

Shadows are transparent. They will not appear when the background is dark; and they all differ in colour, depending on the background.

From: Wizzup?
Shadows are transparent. They will not appear when the background is dark; and they all differ in colour, depending on the background.

Aw, worth a shot I guess though

Some kind of edge detection might be an option? I remember that the uptext came out pretty clear when detected like that.

1. Collect list of colours
2. Increment count as checking progresses
3. Certain colours will be outside a tolerance of the different accepted UpText colours, remove/set them appropriately.
4. Compare the exact count of specified colours to a Max/Min range of counts for the actual uptext colours. Creating a list of possible colours that have the appropriate counts.
5. Copy area of interest into a new bitmap for less pixel checks, (idk if that is faster than using say a boolean array for the indexes. Probably would be.)
6. Since colours are constant per showing, perhaps Some form of filter to get the pixels together with the largest density, grouping the sections of text into a single TPA for green cyan yellow white etc.
7. Some form of ocr based on the bitmaps:D

I'm not sure if thats already being done, but I figured I would write out my best idea :(

Doing the actual OCR is not necessary - we already have already covered that.


Nava:
Go ahead and write it - see how close you can get. I don't care if it is SCAR or another language, it is probably easily portable. Speed isn't much of a problem.

From: Nava2

1. Collect list of colours
2. Increment count as checking progresses
3. Certain colours will be outside a tolerance of the different accepted UpText colours, remove/set them appropriately.
4. Compare the exact count of specified colours to a Max/Min range of counts for the actual uptext colours. Creating a list of possible colours that have the appropriate counts.
5. Copy area of interest into a new bitmap for less pixel checks, (idk if that is faster than using say a boolean array for the indexes. Probably would be.)
6. Since colours are constant per showing, perhaps Some form of filter to get the pixels together with the largest density, grouping the sections of text into a single TPA for green cyan yellow white etc.
7. Some form of ocr based on the bitmaps:D

I'm not sure if thats already being done, but I figured I would write out my best idea :(

Sounds like a color count of text area? And highest density/count is probably the correct color. Since the others in area will probably have slightly different tolerances so they won't be exact even if its say a all green background.

From: Narcle
Sounds like a color count of text area? And highest density/count is probably the correct color. Since the others in area will probably have slightly different tolerances so they won't be exact even if its say a all green background.

That was more or less what I was getting at.