i have a requirement to read data from a gif. The gif is exported from a Bloomberg terminal and contains Stock Prices. Is there anyway of reading the Stock Prices off this gif?
I'd prefer to do it in C#, but if there is any other programming language that is recommended, i would be grateful if you can share that with me.
regards
A GIF is a graphic file. The only way to read data from it would be to use some form of OCR.
These software packages/libraries usually aren't free, but you could look at FreeOCR and try out what's there. Or look at the Tessnet2 Tesseract .NET library (most of the free/open source OCRs use the Tesseract engine).
I also feel compelled to point out that this is probably violating some sort of license agreement or TOC. Even if it isn't, you'd have a hard time guaranteeing any sort of accuracy for the information, and inaccuracy is an extremely bad thing when you're talking about stock prices. Be careful.
This sounds very dodgy to me. You would have to:
Have a high enough resolution such that optimization of the gif doesn't cause you to loose accuracy
You would have to use edge and corner detection to re-plot the time series / line from the gif. This is inherently inaccurate
You would have to now relative price/time for the gif dimensions. If this changes between gifs then forget it. Reading the values on the side/bottom would be a nightmare.
In short, find another source of data would be my recommendation. Image analysis on a gif to produce financial information isn't exactly a FIX update
Related
I have very many folders with a large number of image files in there. Occasionally a scanned document image ends up in a folder by accident and short of someone visually scanning the folder, these remain undetected but could cause problems if published to the wrong location.
Since they could have been scanned as any file type and sizes are broadly in the range of the genuine images, they are very hard to detect from metadata.
Does anyone know of a way to detect a scanned document from a genuine image - either a tool or a programmatic way?
I would recommend taking a look at the Accord Framework: http://accord-framework.net/. Check out the Computer Vision features. I think it should be up to the task you are describing, plus it is a fun new area to learn. Good luck.
Assuming that scanned documents will look like documents any image processing library should do. You simply have to pick a few features to sort out anything that is not a document. Apply some basic classification or machine learning using these features.
The few remaining files can either be checked by a human or using some ORC. I would not run OCR on all files as it will take more computation time than a simple classification.
Documents (especially the confidential ones) tend to have a bright background with high frequency dark foreground. The dark stuff is grouped in lines. There are little to no colours and if those colours usually are only at a small fraction of the document (logos and such)
I can't think of many images that share those properties.
So unless you have a lot of pictures of newspapers and books in your collection you are fine.
Of course scanners and cameras have different imaging properties and optical aberrations and I'm sure you can find some of them in the files but that won't work for all images. Especially not if those images were cropped from bigger ones.
Can there be other text-on-background images in the folders? Are large pictures common in these scanned documents? One non-foolproof way of filtering mostly text documents out of a non-simple image haystack would be to high-pass the images based on Shannon's (histogram) entropy. Most images have entropy values an order of magnitude above simple documents.
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'm working with a set of DICOM images that are 512(columns) X 384(rows)
Is there a tool that would make the images 512X512? That is, filling the rows in this case to make it 512.
I've researched VTK with no luck.
Thanks!
Argh, you was almost there! In fact, VTK is not the proper tool for that. ITK is.
To be precise, VTK is for 3D visualization (that is, rendering of 3D objects), while ITK is specifically concerned for image processing.
So, using ITK, you could use a padding filter, here's a complete example from the official wiki, ready to be compiled and executed: http://public.kitware.com/pub/itk/Examples/src/Filtering/ImageGrid/PadAnImageWithAConstant/Documentation.html.
But, if you want to do the things in an easier way, I suggest MATLAB (ITK could be difficult to configure). In this case, this post could help: Padding an image in MATLAB.
Good luck!
I have a one-off project where the company is auditing a small amount of data for a huge amount of people. It is probably easiest to get each of these people to audit themselves, but not all people have computer access, so I will have to use a paper-based approach.
Have you seen those paper-based multiple-choice answer sheets? The ones where you fill in the circles with a dark pen/pencil. For putting in dates of birth, names, etc there is a vertical array of numbers and/or letters. On the top/bottom and left/right edges of the paper there're bars which are for alignment and timing.
I'd like to create my own sheet to hand out, and then parse on the computer. Are there any open source libraries for this? As I'm probably only going to use this once, it's probably not efficient to purchase scanners, etc - however our office multifunction can scan a pile of sheets and email them in PDF format. I could either interpret the PDFs directly or extract the embedded images.
Sounds like you're looking for Optical Mark Recognition.
There's an open source OMR project on source forge, and several others mentioned within the Wikipedia article on OMR.
I am currently working on a project and my goal is to locate text in an image. OCR'ing the text is not my intention as of yet. I want to basically obtain the bounds of text within an image. I am using the AForge.Net imaging component for manipulation. Any assistance in some sense or another?
Update 2/5/09:
I've since went along another route in my project. However I did attempt to obtain text using MODI (Microsoft Office Document Imaging). It allows you to OCR an image and pull text from it with some ease.
This is an active area of research. There are literally oodles of academic papers on the subject. It's going to be difficult to give you assistance especially w/o more deatails. Are you looking for specific types of text? Fonts? English-only? Are you familiar with the academic literature?
"Text detection" is a standard problem in any OCR (optical character recognition) system and consequently there are lots of bits of code on the interwebs that deal with it.
I could start listing piles of links from google but I suggest you just do a search for "text detection" and start reading :). There is ample example code available as well.
recognizing text inside an image is indeed a hot topic for researchers in that field, but only begun to grow out of control when captcha's became the "norm" in terms of defense against spam bots. Why use captcha's as protection? well because it is/was very hard to locate (and read) text inside an image!
The reason why I mention captcha's is because the most advancement* is made within that tiny area, and I think that your solution could be best found there.
especially because captcha's are indeed about locating text (or something that resembles text) inside a cluttered image and afterwards trying to read the letters correctly.
so if you can find yourself a good open source captcha breaking tool you probably have all you need to continue your quest...
You could probably even throw away the most dificult code that handles the character recognition itself, because those OCR's are used to read distorted text, something you don't have to do.
*: advancement in terms of visible, usable, and practical information for a "non-researcher"
If you're ok with using an online API for this, the API at http://www.wisetrend.com/wisetrend_ocr_cloud.shtml can do text detection in addition to just OCR.
Stroke width transform can do that for you. That's at least what MS developed for their mobile phone OS. A discussion on the implementation is here at https://stackoverflow.com/