I have a Mega2560 and I would like to OCR a 7 segment display. The segments are lighted. I would like trace masks onto a bitmap similar to how security systems use masks to filter unwanted motion detection. Where can I research separating a portion of a camera image and turning it into a bitmap and applying multiple masks or something analogous for character recognition?
Thank you.
You have a very similar query here.
Most people here will try to dissuade you from attempting image processing on an AVR.
Yes, I thought it may be best to create a unique thread. I can delete the other post if need be. The other commenter seemed to have some insights, I'm interested in getting pointed to some resources. My feeling is that using masks as opposed to deep learning should require little computational power; however, image preprocessing, even modest, may exceed what is practical for the mega2560.
You have 8k bytes of RAM.
Even if that is all used and the input image is already processed into a binary bitmap, that's an image of 256 x 256.
No room for other variables, no intermediate results.
What sort of size of datasets did you envisage?
I imagine the image will be taken in 720p. I'm not sure what the maximum file size of 720p is for the format it would put out or what the format would be. I know that I can get a post processed image down to those constraints and work within them.
If you've got a processor powerful enough and enough RAM to hold a 1920x720 image processed down, doesn't it make sense to use the power and memory of that processor to do the rest of the process?
For sure. Though, I am seeing cameras that can take 160x120 jpegs.
OK, so do you have a processor capable of decoding your jpegs, with memory spare to do your OCR processing?
Well, I was hopeful that I might be able to do this with my arduino, but it seems not to be a good fit. I drew some hope from the other post where someone said they had successfully used a c64 to perform OCR.
I'm open to any way to work around this if it exists. As you pointed out, if I have to buy a more powerful device then it makes sense to do everything on that device. Is there any way that you can think of to make it work, even if making it work would be undesirable for you?
One thought would be to glue a light sensor to each segment of the display. That could get pretty complex for a multiple digit display.
An LED can act as a light sensor. So what if you got another display of the same dimensions and attached it flat against the original display face to face? Each segment of the sensor display should output a small voltage when the corresponding segment of the output display was lit. You will not be able to use the standard driver chip (e.g. TM1637) on the sensor display.
That would work for a LED seven segment, but not an LCD.
True. I forgot about seven segment LCDs.
Why do you want to OCR the display? Why not just tap into whatever is driving the display?
Indeed, tapping into the lines that drive the display is the easier way to do this. Seven lines, seven inputs and GND connections. After that it's simple pattern matching.
It isn't possible due to bureaucratic, for lack of a better term, constraints. This will be used both to take a photo of the odometer (which is necessary to prevent potential claims of fraud) and to manually read the odometer. It would be simpler to just use gps, however reimbursement for gas requires a reading of the vehicle's odometer for this particular use. OBDII appears to off no solution to this either. The best one could potentially get from that is the raw data used to calculate the value that the odometer reads, but it doesn't satisfy the requirement to capture the actual odometer displayed value.
There are for sure better ways to do it, but none that comply with this scenario's requirements.
So the OP changes the requirements mid thread once again. It would be nice if just once someone would just be forthcoming about what they're up to so we don't waste so much time trying to figure out what it is that we're building for them.
Are there any other details you'd like to add to this?
Hi Delta_G, the requirements are not changed. I'm in the room, Please call me Elijah 
The requirements haven't changed. Not listing the reasons why I must perform the task as I described isn't changing the requirements. I'm heartened by the suggestions for work arounds, and I am open to them. But I believe I must stick with OCR.
What I mean is only giving us the partial requirements, waiting for us to come up with a potential solutions and only then adding in the details is a time waster. You should just come out with it from the get-go.
What is it that you are building? If you can't answer that question then it probably isn't appropriate for you to be getting the work done here. Simple enough question. What are we building here?
I left out the details because I believed I could save time if it was just taken for granted that I am using OCR. I fielded the question to a few friends, OBDII was recommended but from my previous research that doesn't seem viable. My attempt seems to have defeated itself, heheh.
Great question! So, what I would like to do is have a camera mounted between the steering wheel and the odometer. I would like to wire a connection to some device that can take that image, OCR the image, and store both the value and the image in some way. I have different thoughts about this, but I'll leave that there. I need to be able to extract those odometer readings, and preferably also have the distance traveled as the difference of two readings stored as well. I would like to have dash mounted buttons to take a starting snapshot and a destination snapshot.
This next bit may seem needlessly complex, but I wish to incorporate it as a form of error detection. Because OCR may not always be 100% reliable, I would like to also track distance using gps. If I could avoid the employer requirement to read the dash odometer I would just use gps. Here, I would take the value of the gps distance travelled (also started and stopped by the dash buttons) and compare is to the difference of two odometer readings and if the numbers are off by some margin of error then I would like a way to input the distance manually.
The end result would be to have a .xls file that has the data populated, but this needn't be done in the arduino unless somehow it can be.
There's a lot of moving parts here, but off the top of my head I believe I've laid it out as clearly as I can manage without creating a high level overview diagram. My next step is to create a high level overview diagram, but before I do that I need to test the feasibility of possible solutions. That's what I hope this discussion accomplishes.
Thank you for your feedback.