I have a small image of a text in it, a screenshot from a small area in a console application. I need a simplest possible test to tell if it matches a pre-defined pattern. In other words, if text is exactly some specific word, let's say, "root".
Font is fixed, no rotations, but it should be robust to small offsets.
So, my template/pattern image is fixed:
And my test image can be this:
In case of negative result, I don't need to extract text from it or anything. So, I'm looking for the simplest test possible.
I tried to calculate number of white pixels in the image, but that's unreliable.
Related
So I have one image that on paper they were drawing lines/circles on particular areas of the image that they had designated certain sides as area 1-4, then 5-6 in the center and then a few specific spots as area 7. They wanted to make this digital. So I put the image on a win form, made it so they can create lines and circles (eventually I'll have it so the lines are measured and stored in an array) However along with storing that I need to store what number area the line/circle was created in for tracking purpose so they can look back later to see where the majority of, in this case flaws, are being circled on the image. (The image represents a real machine part). So right now I'm stuck trying to figure out how to designate certain areas of this image as area 1-4, 5,6 (and multiple 7's).
Is it better to split each area up into its own photo and piece them together like a puzzle? Or is there a better way in code to do this leaving 1 image to work with?
I believe the text result of OCR not only depends on how good the OCR library is but also depends on the image to scan.
My question is that, for an image, how could I make it easier to recognize?
Change the original color? (for example, to grey)
Change the scale/size? (for example, bigger)
Change the area to recognize? (for example, set the distance to top/left side)
Any other idea?
I'm trying to draw a string using either textrenderer.drawtext, graphics.drawstring or graphicspath.addstring - the main purpose is to extract all fonts to bitmaps to edit them and use them as bitmaps with shaders in a game.
With textrenderer.drawtext and graphics.drawstring, I get a padding on top of varying degrees - so I try graphicspath.addstring. I extract the font family's ascent height and descent height, but they are wildly unusable with emheight. (using ascent and descent with emheight is how microsoft suggest you do what I am trying to do - via http://msdn.microsoft.com/en-us/library/xwf9s90b%28v=vs.110%29.aspx. Has anyone successfully ever draw pixel perfect fonts using C#? Every time I ever try or look it up, textrenderer and graphics always' padding always screwed up drawing and this new graphicspath method seems to have an issue with using a specific scale.
The usual methods using TextRenderer or MeasureString will give you a SizeF, containing the bounds of the string you measure. Most formats include a little slack so you can compose text by adding strings together.
The aim of theses methods is to help create blocks of text by letting you measure when a line will be full or how many pixels to advance for the next line.
They are not really meant for maesuring single characters.
For this there is a special stringformat GenericTypographic as described here which leaves out the white space.
To get an even more precise measurement one can use GraphicsPath.AddString and then GetBounds, maybe after switching antialias off..
Now, if you wanted to draw a single character precisely, say centered on a Button this would do the job.
But you know all that and your aim is different - if I understand you correctl,y you want to create Bitmaps from each character in order to later join them to form text. This means you need them to line up correctly vertically, ie sit on the same baseline.
The sizes of the characters don't help you here; now, normally you'd need the baseline of each charcater, which you don't get, at least not for anything descending like 'f' or even just ',' etc..
But it wouldn't help you either because in GDI you don't print/draw to the baseline anyway..
What you should do, imo is either draw one long string with all characters, so that they're all lined up right and then cut out the characters one by one. Or you could draw each character on its own, but suffix all or some characters you know to have ascenders and descenders and then only pick the first columns from the result.
So the only way I figured out how to do this is is to first draw the string to a graphicpath, then measure all the empty spots in the graphic path, and get it's height only after I've measure every spot, then redraw the string (I have an attempt counter to limit attempts but increase em to pixel accuracy) taking the old size and new size into account by a modifier and then extract the final size and store it.
Only I got to get around the BS of every font having a weird top padding that isn't associated with it's ascent and internal overflow (ex: Ñ), as well as descent, in refrence to a 0,0 point, this way.
I'm essentially re-writing a document viewer with markups to move away from a COTS product and so far everything has been working VERY well. My code is based off of Mark Miller's Extensions to DrawTools (http://www.codeproject.com/Articles/17893/Extensions-to-DrawTools).
The old viewer stores pages and their markups based on x/y coordinates in inches and I have had NO trouble converting this to a pixel-based coordinate system and converting lines, boxes etc to the new viewer. The lines and boxes show up exactly where they are supposed to and have the correct size.
The problem has been displaying text markups, no matter what I do they always end up MUCH smaller than they should be.
I'm doing:
UserControl->OnPaint()
Create a Matrix Transform for:
Scale
Rotate
Translate
Apply Matrix to Graphics Object
Call method that draws the Page Image and then all of the Markups.
I have the X/Y Coords and Font Size of the Text to draw, and the resulting string DOES end up at the correct coordinates but the text is WAY too small. The really bizarre part about this is the original viewer is written in .Net so I know that the Font and Size SHOULD relate especially since everything else scales so well.
Here is an example of what I'm talking about. Please ignore the BackColor and Border of the "This is some Text", I haven't gotten around to getting that transformed yet since I've been so focused on getting the TEXT right.
Original:
My Result:
I ended up having to rework everything to be Inch Unit based. The font simply doesn't have an easy way of scaling between the units and the Inch Unit turned out to be the easiest solution.
I want to cut up the image based on various text markers placed around within it. The font/size of the marker is up to me.
I know commercial OCR packages provide this in their APIs but I'm hoping I can code this up myself.
Ideally I wouldn't have to go pixel to pixel and compare against an image of the marker text.
I'm good with C++/C#, Java, PHP and an other language where a library like this exists...
Ideally I wouldn't have to go pixel to
pixel and compare against an image of
the marker text.
Well, if you're trying to find the marker image, then that's exactly what you'd have to do.
Here's an idea... Set the marker text to a particular color, then process the background image to make sure that it doesn't have any pixels of that color. Finding the markers should become a lot easier at that point.
A barcode would be easier to detect than a text marker. You can always place them together, with the barcode being used for automatic position detection and the text for human user.
If you want to do a really sufisticated solution, you could use the hough transform. It is often used for augumented reality stuff - there it is necessary to find a certain marker in an image. Ofc you would have to change your markers a bit, would this be possible? ;-)
The hough will give you the position of your marker lines and thus the area which you want to cut out.
Here is a link about hough, but there are many others though.
Hough
Or this one
Wiki
A fiduciary marker would be better than text. That's what they use for augmented reality and such.
If the text is always the same size, shape, and oriented in the same direction, you could use normalized cross-correlation.
"Ideally I wouldn't have to go pixel to pixel and compare against an image of the marker text."
Well how else are you going to do it? You're only going to search in part of the image?