Hi, I’m the maintainer of fast-plate-ocr. I was asked to make it compatible with Hailo my license plate OCR model, and after some tweaks (see issue), I was able to parse and compile the model to run it with Hailo. The problem is it’s getting difficult to me to actually debug the .py script for doing inference with it, and seems the Hailo converted model is outputting gibberish.
Is there any way I can run/debug inference with a Hailo chip? This is the code I used to run Google Colab . Is there anything suspicious in the logs which might indicate the culprit? I’m hopping I can end up adding support for Hailo for my open-source license-plate reader. I haven’t found any other for Hailo, btw.
We’re excited to help you get your project running on Hailo hardware.
For getting started, I’d suggest checking out our GitHub repository with application code examples (GitHub - hailo-ai/Hailo-Application-Code-Examples). It’s a great place to begin testing and has some really useful stuff in there. We actually have an OCR application that you might find helpful, or if you prefer, you could start with our detection app - whatever works best for what you’re trying to accomplish!
Hi thanks for the reply. The available OCR models you mention are not suitable for license plate recognition, since (1) they are slow and (2) they were developed in mind for different use cases. My goal is to be able to run with similar accuracy fast-plate-ocr models. I’m not the only one having this problem, seems something is corrupted when running the the Hailo version since the .onnx works as expected. Is there any technical staff that can take a look at this? Would be great to run this model, it supports lots of countries plates and performs very fast.
Could you please send the HEF file so I can test it? Alternatively, I can try compiling it for Hailo hardware myself, but I’d prefer to receive the HEF file from you if possible. This issue might be related to post-processing or another factor that I can help identify through testing.
I did some personal digging as well. I compiled the hef and also ran emulation for the native model, the optimized floating point model, and the quantized model.
The native model and the optimized floating point model gives the same probits and postprocessing them gets the same answer as an onnx inference. The quantized emulation does not give the same probits but post processing gets the same (correct) answer as an onnx inference.
However, inference using the hef does not give the same output as the emulated quantized model. They are not even close (I know that they won’t be an exact match).
Here is part of the output to demonstrate the issue (last “slot” of the OCR model):
Thanks Lawrence for diving deeper into it! Is the issue specifically from the last layer of the hef one? Is there any alternative that might work, i.e. maybe exporting to ONNX from torch instead of TF or removing any known problematic layer? I can retrain or tweak the model, there is no problem from that perspective.
cc @omria let me know if you know any workaround .
We’re currently working on this issue. Exporting to ONNX would be very helpful for model segmentation. I’m reviewing the HEF file you provided and will send an update later today.
Great @omria! Let me know when that happens so I can train the exact same model with the full dataset / longer training for better accuracy, happy to do that
.