I think there are different approaches here (hoping that it will help to see things clearer and not add confusion). They will be better or worse depending on how "clever" their implementation is
- OpenCV "alone": pre-process the image, train for chars and numbers, detect "zones", detect the chars in each one, and add a final logic level to "build" this data based on detected chars, their position, some coherence filtering, .... --> This will give you total flexibility, but will need more programming.
- OpenCV + OCR (either Google Vision or Tesseract lib): OpenCV to pre-process the image (noise filter, lightness add/substract), also detect zones --> and give them to OCR (with options: for instance the known font, no dictionary,...) to get the data. Anyway a next-step processing level will also be needed to convert the 'spare' detected chars into values, apply the same coherence-filtering, ....
- OCR standalone (whichever option): seems that OCR by itself can throw good results. Additionally, playing with options can help (but make things worse if not correctly used). But I'm not sure (just because I haven't tested, nothing else) if it will be true for all situations, since in this case there will not be dictionary -> as the setup for an ocr-based solution should be quite easy, I would anyway implement this one and use it to compare against the others.
Also, some questions/checklist before starting, that can help to decide how to implement it:
- Must is work real-time from a camera preview, or can it be processed from a photo and take, for instance, 10 seconds?
- Picture: will the picture always be taken from more or less a certain distance and light conditions?
- It seems that some chars/combinations can (or must) always appear --> the algorithm should always take advantage of what is known, and also of their expected relative positions in order to make a more accurate guess -> For instance, if it detects "KG" or "LB", it will be after some numbers. Also, there is "CMAU","FCIU","MEDU",..... no idea of what they mean, but if there is a limited set of them, the algorithm should also take advantage from it .
- Seems that the fonts are similar. If there is a standard, the algorithm (whichever approach you use) should also take advantage of that.
Last but not least, as detection related solutions are never perfect, so you should measure how good your successive approaches are by a hit-rate measurement. A good approach in these cases is to get a lot of test images (including some edge cases) in order to test how each approach improves or not the previous one.
If I had to do it, I would build a "customizable" multi-phase-step detector in which I could play with many chained options (being able to tune, enable/disable each one), and measure performance on the test images.
