-
Notifications
You must be signed in to change notification settings - Fork 648
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bogus raw value resulting from dark image assumed as valid measurement #3354
Comments
What did you set at preValueAgeStartup, not coincidentally 180 minutes? You may have to increase "Wait Before Taking Picture" a little because your camera needs some time to get the picture bright and sharp. Experience has shown that values between 3 and 5 seconds are ok. The higher the value, the better the image quality, as the auto functions (Auto Exposure Control............) take a certain amount of time. However, too long a time also has disadvantages (the ESP gets hotter...). |
No, currently I have these settings:
Currently 5 seconds:
But I will jack it up to see if it increases the performance. Another issue though, is that in spite of using the new model (built after I submitted my digits), it appears to still be unrealiable with some digits, such as digit 5 as the first decimal: |
Even having increased the camera delay to 8 seconds, sometimes the image is dark: In this case however it did not interpret as 444.44, which is good.
|
Could tuning of the CNNGoodThreshold help in weeding out these false recognitions (the values seem too close to the threshold in spite of being pitch black images)? |
Does the Live Stream (Light on) work, or do you just get a black picture there? I'm starting to suspect that your camera is getting too hot or is defective. |
Was not able to reproduce during live stream. Only dark for the first couple of seconds. |
Wonder if it can be the cause, but while I was trying to reproduce the issue by opening the livestream several times, in the digitalization round I got another dark picture. Can there be some kind of race condition between the livestream and the recognition loop, causing the dark image when there is concurrent access to the camera? I ask this because I have an integration with Home Assistant to show the camera stream.. |
If you end the LiveStream at the wrong time, the LED goes out during the TakeImage phase or shortly before and then of course there are black images. Likewise, if you run the LiveStream during the TakeImage phase, the LiveStream will turn black because the LED will turn off after the TakeImage phase. |
The Problem
I found a couple of times in a 2 week timespan that sometimes the images are captured when the light is off. It appears to be some kind of synchronization issue between the camera and the LED light. This results in a black picture being captures.
On the other hand, instead of the software invalidating a picture in these conditions, it goes through the recognition cycle which results in a raw value always in the vicinity of 444.44 m3.
In one of the occurrences this raw value stood like that for 3 hours until the correct value was again recognized:
Still, even though I have the following rate validation,
the bogus raw value ended up being assumed, causing the measurement to be incremented from 394.43 to 444.44:
Then after this hallucination period ended for the camera, the correct raw value was again recognized, but being a negative rate, it was no longer accepted:
Would it make sense to fail fast on black images or without any match with the markers, therefore avoiding these errors?
Also, is there anything it can be done regarding the LED light turning on everytime a capture is taken?
Thanks
Version
Development-Branch: main (Commit: 57db60f+)
Logfile
Expected Behavior
Screenshots
No response
Additional Context
No response
The text was updated successfully, but these errors were encountered: