Option to discard entire digitalization round if any digits cannot be read

[mekaneck]

The Feature

I have had several instances where something happened to my camera and caused the image to have artifacts or distortions that affected the digitalization. (I am using this to digitize a 7-segment digital display on my water meter). Whenever the program has an issue with detecting a digit I'd like the logic to be to discard the entire digitalization process and wait for the next round to try again.

What happens instead is that the program attempts to read the values it can read and assumes the other values haven't changed. This almost always results in bad readings. Sometimes the bad readings are rejected due to my settings of not allowing negative readings and limiting the calculated rate. But sometimes they are accepted because they meet that criteria, and then when a correct reading comes through, the correct reading won't be accepted due to a negative rate or a rate that is too high. And when this happens, the error is not recoverable. The program will stay in this faulted state indefinitely even though it continues to capture good images and digitize them successfully.

My goal is for this device to run without intervention, and I think the easiest way to do that is to completely ignore any image where a digit cannot be determined.

[mekaneck]

Attached is a log with an example. This particular example is a ~5 hour period where not a single image was able to have all the digits successfully digitized. There may have been something (a spider?) on the meter during that time period. Also I noticed the rate is calculated from the time of the last round, whether or not a "good" meter reading was achieved. Looking at the log, there were no good readings after 07:40:59 until 12:58:57 (318 minutes). If the images can be discarded, I would prefer the rate calculation to be performed on the last "good" round. In the attached file, at 12:58:57 the first good image is taken, but it calculates the rate from the reading in the previous round, even though that reading had been stagnant for 318 minutes due to errors. So instead of 35.58 gal/min the calculation instead should be from the reading and timestamp of the last error-free image, which is (119239.16-119167.98)/318 = 0.22 gal/min. log_example.txt

[SybexX]

Do I understand correctly that you are suggesting that all the complex logic that has been introduced over the years and is constantly being improved should simply be ignored because you can't cope with the system ^^ I would rather suggest that you look into it more to solve your problem. For example, the wiki page or the closed bug reports could be helpful, and there is definitely something there that comes close to your problem and provides a solution.

experimental firmware: AI-on-the-edge-deviceupdatecamsettings(d9de8ac).zip

[mekaneck]

I didn't intend for this suggestion to be an insult to all the great work that has been put into this software over the years. I realize now this likely would have come across more positive and productive had I created a discussion first and worked through any suggestions. Having read the documentation and looked through issues, I thought I had a fairly good understanding of the configuration options and various techniques available to address the issue. The closest I've come is these two options:

• Set the previous value to the raw value via the API when a home automation system detects that the meter is stuck in this condition.
• Set the CNNGoodThreshold closer to 1 so that numbers are more likely to be interpreted as N (and therefore replaced by previously read values). This doesn't really fix the issue, and this is only applicable to the dig-class100 models, which are not the recommended models for digital displays.

In the discussions and bug reports that I've looked through, I haven't found a real resolution to the fundamental root cause, which is (in my opinion) images being taken that have something wrong with them and should just be completely discarded, instead of assuming there is useful information contained therein and proceeding to apply all the various intelligent methods to extract it. This is why I created this feature request. But it hindsight I agree this FR definitely comes off as coming from someone new, unwilling to evaluate available options, and looking for someone else to create an easy way out to solve my own unique problem. I apologize for that.

Here are a few relevant discussion topics that I believe would benefit from this FR: https://github.com/jomjol/AI-on-the-edge-device/discussions/2934 https://github.com/jomjol/AI-on-the-edge-device/discussions/2928 https://github.com/jomjol/AI-on-the-edge-device/discussions/2737

I believe the scenario where this FR is beneficial is a setup that meets these conditions:

1. A meter with digits that are "easily" digitized and have essentially a 100% error-free conversion rate when the image does not have obvious problems
2. A short cycle time between digitization rounds, where discarding an image does not result in the loss of much time-history data

The "obvious" problems I refer to in item 1 could be, for example:

• The meter's digital display not actually showing the meter reading. Could be showing nothing, or some other data due to timing issues or the meter detecting light from another source.
• Something blocking the view of the digits, such as a fast-moving rotating dial, or an insect.
• The image having some digital error causing it to be missing part of the image, or the image cut in half with the bottom half on top and the top half on the bottom, or most of the image some weird purple color, etc. I don't know what causes these artifacts but it is probably some random hardware issue (camera, SD card, etc.)

As I write this out, perhaps a smarter method to discard an image would be, instead of discarding anything with a NaN, to use some algorithm to compare the entire new image to the entire previous image. Some type of comparison that could be done with little computing power. Just for discussion's sake, an example could be to convert both images to binary (black & white pixels only) and if >50% of the pixels are different, then skip the round of digitization. Or, perhaps, only perform comparison to the previous image if NaN's are detected. The comparison could then be used to decide whether to proceed with the logic of utilizing previous values or to instead discard entirely.

I do very much appreciate the experimental version and will try it out. But I think this type of support would be useful to more than just me. However feel free to close out if you feel different.

Thank you for your help!

[SybexX]

Since the ESP has limited resources, the number of ROIs in connection with the size of the ROIs must be taken into account, otherwise image problems can occur. The best solution against external influences, such as a spider or external light, is the simplest and quickest solution, a closed housing. https://github.com/jomjol/AI-on-the-edge-device/discussions/2980

The idea of ​​comparing two images is a good one, but it cannot be implemented with the camera. The quality of the images is not that good or not consistent, which is why incorrect evaluations occur again and again. To improve this you would have to use a higher quality camera and this would be reflected in the price, which is not the point of this project.

[mekaneck]

I've been using d9de8ac for about 2 weeks now, and it is working great. My NaN issues that I've seen recently are due to misaligned images, so I may have to play around with the alignment to make it more robust. I thought formerly there was an option to save the aligned images, but all I'm seeing in the options is the raw image or the digits. But regardless, discarding the bad images has eliminated the need to actively intervene which is what I was hoping for.

[feserdel]

In my case, I have a Digital water meter that outputs every few minutes the software version number of the device: Always recognized as 2024-05-22T02:04:25+0200,main,NNNNN.N669,123.5198,123.5198,0.000000,0.0000,no error,N,N,N,N,N,N,6,6,9

This is normal reading value:

Value is not correct due a previous overflow if by chance software version number is detected as correct value.

So for me this feature is mandatory.

Thank you.

[mekaneck]

Just following up on this; I have been running the d9de8ac software for about 4 months now, and have not had to manually intervene a single time. I have a notification set up when the meter status changes to "Problem" and I get that notice around 1-2 times per month, but the camera ignores the values and keeps moving along without skipping a beat, and the problem goes away. It's great!

My obviously biased opinion is that this would be a great option to pull into the main branch.