I am generating a barcode label and sending it to the user as a .pdf (this is a web app). The user has already purchased barcode labels that are only 2 inches wide. I want to use an image so that I don't have to install fonts on all of the users machines that will be using the web site. I am able to get the barcodes small enough if I use fonts from IDeautomation.com but I would much rather use an image generated using BarCodeRenderer
or some other opensource project but I can not get the barcodes small enough as the system has pre-existing ID's of around 20 characters in length. What is the smallest Barcode font (I am trying to use 128 as the IDS are alphanumeric) and how can I resize the generated image in a way to make it fit in the width that I have available?(Other ideas or Libraries that do this are also accepted as answers)
IDautomation has several products.
Specifically they have one for Crystal reports with a Code 128 checksum calculator. It bypasses the need for a font and generates the font right in the report, which can go straight to PDF. The smallest size I have been able to use this feature is at about 12 point font. Specifically they have broken down the Code 128 font spec to allow you the smallest barcodes possible. This does not render as a font, or an image as far as I recall.
Alternatively I recall them having a product that will render a font as an image.
Another product that might be useful is Barbeque. Maybe you can find something along that line.
The other factors that weigh in when trying to print and read small barcodes are:
How long is the value that you are encoding in the barcode. 20 Characters is a lot.. Is there any way you can concatenate it, or shrink it somehow? Tricks I have used in the past include using a hashed value (or record number) that would link to all the values I needed. The shorter you can get your barcode, the smaller you can make it and still have it super clear.
Will the barcode get longer over time? If so, you might need a wider label, or consider a different format. I am starting to like a few of the 2D barcodes a lot.
Label material. I have seen issues with using colored or overly shiny labels instead of white, matte ones making it much harder to read.
The barcode readers can make a big difference. Having a laser based reader instead of an optical based one will give you greater resolution in reading barcodes. This means you can read them from further away, or read smaller ones. Symbol has some great $150 laser based barcode scanners.
The bar code printing and reading systems I've worked on have done in the range of a few million prints and reads with barcodes of small to medium sizes, so I hope some of the suffering and learning I've had above helps!
What I've done is to take the barcode and make it fit the width that I want by resizing it down. What then happens is that the height is not good enough for most readers, so I copy the image and duplicated it above it, so it now is the width I want and double the height of the generator. That makes it more readable to most common off-the-shelf barcode readers.
If your barcodes only consist of an even number of numeric digits, you can quite easily switch to the Code C variant to get them down to half the size.
Generating a small barcode as an image in a PDF is going to be error prone, since you can't optimize to the dot size of the printer. Your barcode widths are going to be off by plus or minus half a dot; the wider your bars are, the less of an issue this will be. I've worked with label printers that are 203 DPI, and they would be nearly impossible to support with a generic image. Fonts are better since they can be hinted to be an exact multiple of dots. I don't know if any of the commercial barcode fonts have the necessary hinting, but I presume at least one of them does.
I have had good luck using Data Matrix format as you can have varying amounts of data, and you can size the barcode as you wish.
Here are some links that may help:
libdmtx
Aspose.BarCode for .NET and Java
Barcode Writer in Pure PostScript
The checkbox "Use Unicode UTF-8 for worldwide language support" should not be checked.
Related
So I am using Tesseract with C# to read english text and it works like a charm. I use pre-trained data from the tesseract repo:https://github.com/tesseract-ocr/tessdata
So far, so good. However, I fail to understand how to solve the following situation: I have an image with a maximum of three numbers on it:
I also followed this tutorial in order to train my own data but I failed to understand what exactly I am doing mid-way:https://pretius.com/how-to-prepare-training-files-for-tesseract-ocr-and-improve-characters-recognition/
In this tutorial, they used some existing font and train their network accordingly. However, I do not know what this font is. I tried to figure it out myself but was overwhelmed by the huge amount of information about tesseract and actually do not have any idea where to start.
I was wondering if the following would be possible: I have lots of pictures looking like that(in fact, every possible character with every possible color, only difference is that the background is different):
etc...
And with those pictures, I want to train the network, without using any existing font files.
My algorithm right now does not use tesseract, it just screenshots the position of the numbers and I compare pixel-wise. I do not like this appoach though, as the accuracy is something like 60%.
Thanks for your help in advance
I'm trying to develop a Windows Phone 8.1 App but I need to recognize some numbers from different Displays.
I was following this example:
http://bsubramanyamraju.blogspot.com/2014/08/windowsphone-81-optical-character.html
That is using the Microsoft OCR Runtime Library:
https://www.nuget.org/packages/Microsoft.Windows.Ocr/
However, it doesn't work when I'm trying to recognize those kinds of pics. Even I found this site:
https://www.unix-ag.uni-kl.de/~auerswal/ssocr/
Does anyone have a recommendation? Or Does anyone know any code related to it?
Thank for your worthy knowledge.
I wish the answer to your question would be "Sure, here it is" with link to a black-box process-anything OCR tool, but there are several aspects involved, which are best considered separately.
First, there is some work on image pre-processing BEFORE you even consider any OCR. Your image samples are very drastically different, and include full range of issues.
SAMPLE 1 has low contrast, so when it is binarized to black and white layer, which most OCR will perform internally at some stage, there are no characters to process. It looks like this after binarization:
See this OCR Blog post for additional details on image pre-processing: http://www.ocr-it.com/guide-to-better-mobile-images-from-cell-phone-camera-for-higher-quality-ocr.
Secondly, the image has no dpi information in the header, which some OCR technologies use to determine appropriate scaling of the image. Without header information, some OCR programs may set some default dpi, which may or may not match your image, thus affecting the OCR result. This is NOT critical, but preferred if this can be implemented at the time of picture creation.
SAMPLE 2 has sufficient contrast and adaptive notarization returns a clear image. It is also missing dpi resolution value in the header.
SAMPLE 3 has very clear contrast, but it also has no resolution dpi in the header.
Once you have images that are optimized for OCR processing, the next step is to look at OCR technologies.
I did NOT test the once you mentioned, assuming you had correct implementation and yet no success with them. I tested other OCR tools I have used in the past.
In general, there is no 7-segment OCR known to me. However, I was able to adapt to other generic OCR for this specialized task. Every OCR I tried'out-of-box' or with default settings is unable to handle this recognition. And it is logical and expected. Why? Because most generic OCR are written to recognize inseparable pixel patterns for each character. This is related to the "character separability" principle used to separate words into separate characters. In other words, inner OCR algorithms look for connected strokes which make up each character. More powerful commercial OCR allows some breaks in pixel patterns, but they are expected to be minimal to none, like defects in print or scan, which may result in missing character pieces.
7-segment display by nature will have multiple breaks in each character, conflicting with the character separability principle.
More powerful OCR technologies have a) more tolerance to breaks in pixel patterns and/or b) have special settings to handle these cases.
I will perform further testing with OCR-IT web-based OCR API platform, which is well known to me. I worked as a developer on its OCR capabilities. I also use it extensively in my own iOS and Android apps. OCR-IT API is based on a strong commercial OCR engine, so it is having good tolerance to character imperfections as well as some controls to help in this case.
SAMPLE 3. This is the easiest sample to process, so I tested it first. Using OCR-IT API, and making a request with default settings, requesting the output to TXT format, I get the following:
It appears that OCR is a) segmenting characters into two separate lines, and b) tries to read resulting patters as close as possible to valid characters.
Based on this quick analysis, making one adjustments to OCR settings results in the following recognition:
The setting that made substantial difference in OCR result is switching from default print type to using "DotMatrix", which is in the middle of this entire OCR-IT API settings XML:
<Job>
<InputURL>http://i.stack.imgur.com/wOtFx.jpg</InputURL>
<CleanupSettings>
<Deskew>false</Deskew>
<RemoveGarbage>false</RemoveGarbage>
<RemoveTexture>false</RemoveTexture>
<RotationType>NoRotation</RotationType>
</CleanupSettings>
<OCRSettings>
<PrintType>DotMatrix</PrintType>
<OCRLanguage>English</OCRLanguage>
<SpeedOCR>false</SpeedOCR>
<AnalysisMode>MixedDocument</AnalysisMode>
<LookForBarcodes>false</LookForBarcodes>
</OCRSettings>
<OutputSettings>
<ExportFormat>Text</ExportFormat>
</OutputSettings>
</Job>
The use of DotMatrix print type turned on necessary algorithms to increase tolerance for breaks in character structure, which commonly occurs by nature of dot-matrix printers in dot-matrix prints. Alternatively, a "Typewriter" print type could be used, since character breaks are also expected in typewritten fonts, thus being automatically handled by OCR.
There could be one more change to the API setting to run OCR using "Digits" character set (language), effectively eliminating any possibility of misreading 1 as I, etc.
SAMPLE 2. In this sample, the gaps in each character's structure are much wider. Even standard algorithms for handling DotMatrix or Typerwriter print types cannot accommodate these wide gaps. The use of all possible setting variations returned something like this:
Character segmentation seems to be the issue. One technical solution goes back to image pre-processing. A simple algorithm can be implemented to fill in gaps between each segment of the 7-segment character. It does not have to be very precise, something like this:
But that is enough to produce a perfect OCR result.
Since it may be unknown in advance which 7-segment LCD display will require filled in gaps, and which does not, I recommend applying this algorithm to all LCD 7-segment images, with small or large gaps. I would limit the size of the gap to no wider than the width of a segment. Given these screens come in various background and segment colors, this pre-procession algorithm can be substantially simplified if it is performed on binarized (black & white) image.
Overall, this task is possible with OCR and near out-of-box functionality, assuming that some image pre-processing is performed. In general, I believe that image pre-processing is required for any OCR-related project anyway, specific to that project.
If you have any further questions about OCR or image pre-processing, pm me.
Despite it has been a while since Ilya's answer and thanks to his advice and other ones, especially this one:
Seven Segment Optical Character Recognition
I was able to create my own class in C#:
https://github.com/FANMixco/7-segment-ocr-reader/blob/master/OCR/SevenSegmentOCR.cs
Feel free to use it and improve it.
I am trying to OCR and extract the email form the images. The images are supposed to have one line of text which is the email address.
I am using EmguCV.OCR to extract the text (email address) from those images. The target is to have 100% accurate result.
We can fix the font and size of the text. For example Ariel, 12pt, so that all the images will have email written in Ariel 12pt with black on white background.
The problem is that Tesseract OCR in EmguCV is not recognizing the text properly. It recognizes only 80% of the characters accurately.
I am using preprocessing with Leptonica library.
Here are some sample images I am trying to recognize.
Is there any way to achieve the target of 100% accuracy
With those sample images I can suggest two ways to solve the same problem. In those images JPEG artifacts are present (the result of lossy compression). Because of this, the letters are becoming connected to each other (zoom in on the image in a program where you can see the actual pixels, windows photo viewer worked fine for me). TesseractOCR relies on spacing between letters (it uses connected components) to do character recognition. Have any pieces connected throws off the recognition process which means it tries to recognize the combination of "co" as one letter.
Two possible solutions:
I'm not sure what preprocessing steps are already being done, but you'll want to do some thresholding to removing the lighter shades on the image (disconnecting the characters). However, you have to be careful with this as it may remove more than what you want.
If at any time during this process you have a higher resolution image, or a non-jpeg/lossy format (i.e. png), then keep it in this format as you do other processing steps. Try to avoid any lossy compression that might happen. It sounds like these images don't come to you as shown above. This is the preferable solution as you wont risk losing too data.
I tried to recognize your images with ABBYY Cloud OCR SDK and got 100% accuracy.
You can use Demo Tool to make sure of recognition accuracy.
I work for ABBYY and can give you more information about our technologies if you need.
I have following scanned document, with the logo on it, and I have another black and white image with same logo and style (Shown in black and white color below).
How do I make sure that the logo is present on this image or not?
Usually I will have many scanned documents, OCR will pickup MTNL, but sometimes these logos are just made up of symbols not recognized easily by OCR.
Size and position of logos change, they are not fixed many times. They may be placed anywhere on the document.
I want to organize and catalog scanned images based on the logos and symbols present. Most documents may or may not be in english, may or may not contain any bar codes, in such case logo match will help.
I have seen Aforge.NET library, but I am not very much sure which methods to combine to do search. Pixels search is very slow and fails if source destination are of different size.
I have heard that YouTube does some sort of Histogram or Heat Signature match to see if the video contains any copyrighted material. I will be helpful if someone can guide me in this case.
My ideal choice would be C# and Aforge.NET, otherwise some command line tool will be appreciated.
You can try using Aforge.net
Check these links
1) http://www.aforgenet.com/articles/shape_checker/
2) http://www.codeproject.com/Articles/9727/Image-Processing-Lab-in-C
3) http://www.aforgenet.com/forum/viewtopic.php?f=4&t=323
Detect useful features in your logo image, and look for those features in the scanned document. SIFT is a useful feature descriptor that is scale and rotation invariant. Other descriptors include SURF and HOG.
If you look around, there will be plenty of implementations, some of them even in C#.
You can use this small utility:
https://github.com/remdex/logoDetect
It worked for me. Perhaps it will work for you also.
I've been looking for solutions and so far the best one I think for my project is to use a free Code 39 font. However, I've tried printing some samples and my barcode scanners can't read them.
I researched a bit more and stumbled upon this.
I printed Code 39 barcodes using that library and it worked just fine, the scanners are able to read them.
Problem is, the library is written in C# but not for ASP.net. I've tried playing around with the code but it's too complex for my basic knowledge. There are a lot of functions included in that library code and has a lot of other barcode types, making it harder for me to analyze.
Are there other ways to generate a Code 39 barcode? The library in codeproject seems a little to complex for my requirements.
Barcode scanners require your code 39 barcodes to be prefixed and suffixed with asterisks to read. Example: *12345*
First off, you say the library isn't written for ASP.NET, but if you can produce images with it then the easiest thing to do is write an HttpHandler that sits overtop of the library and returns the generated images to the browser. If it's a .NET library, I don't see any reason why that shouldn't work.
That being said, there are a couple things to look out for when generating Code39 barcodes:
Are you producing a valid Code39 barcode (see other answers, a Code39 barcode should start and end with *)?
Is the barcode you are printing sharp enough to be scanned?
For #1, I would check to make sure the images you are printing from your Code39 font look the same as the ones from the library. If they are, then image quality is probably the issue.
As far as #2 goes, I've successfully used a free Code 39 font with GDI+ to generate barcode images that I then displayed in HTML pages for printing. One of the problems I ran into when trying to scan the printed barcode images was that the images were not sharp enough (the edges of the barcode lines were blurry) and were not able to be read by the scanners.
The way I got around low quality images was to generate a large Code39 barcode image (say 1000 x 400), and then on the <img> tag that was displaying that barcode, I would set the width to something much smaller, say (200px, or 2.0 in). I would be sure to set only the width, the height will scale proportionally with the image. That would effectively increase the DPI of the image when it is printed, allowing us to produce barcode images that are easily able to be scanned (especially if you are printing using a laser printer).
EDIT
Almost forgot, one other good practice to use when generating these barcodes is to always print what you are barcoding underneath the barcode image. That's your failsafe in case the barcode image will not scan for whatever reason. You can see an example of this if you look at any standard UPC symbol. The numbers at the bottom are exactly what the barcode will read when it is scanned.