Recognition works, but the raw value is wrong

[SilRo991]

Describe the bug
After updating to the latest version, I get the wrong raw value.
The recognition works perfectly. I didn't find anything on the wiki to solve the problem myself.
I played a lot with the focus of the camera and the alignment. I don't think that's the problem though, as the recognition works.

Version
11.3.1
Updated to Version: Branch: 'HEAD', Tag: 'v12.0.1', Revision: dfe2c46 - same behavior

Expected behavior
The value should be the correct one, as it is also output by the recognition.

Screenshots

[Plawasan]

Got a similar issue on 12.0.1 - good recognition, wrong value.. looks like the algo still needs some finetuning:

Correct value should be 170.05287 not 170.05387

[haverland]

Look at ROI configuration. If the ROIs in height not correctly configured, it recognize 2.0 but is 1.8.

[haverland]

@Plawasan your last digit should have the height like the digit before and all other digits should be the height like in picture described.

[Plawasan]

@Plawasan your last digit should have the height like the digit before and all other digits should be the height like in picture described.

I hear you, but recognition is not the issue here, the algorithm is... however I have updated the ROIs to match the recommended settings, no difference in output:

[haverland]

@SilRo991 if you use a class100 or cont model for digits your issue is fixed. Depends on the post-processing of class11.

[haverland]

@Plawasan your last digit should have the height like the digit before and all other digits should be the height like in picture described.

I hear you, but recognition is not the issue here, the algorithm is... however I have updated the ROIs to match the recommended settings, no difference in output:

Class100 and cont models have the same post-processing, but class11 it's own.

EDIT: Your 2.8 => 3 comes from post-process. The models have an inaccuracy of +/- 0.1 in digits. Currently the inaccuracy is set to 0.2 and here it rounds. If you move the ROIs 2px up it should recognize 2.7 until >9.3 of the pointer and then it should calculate it correct.

[Plawasan]

@Plawasan your last digit should have the height like the digit before and all other digits should be the height like in picture described.

I hear you, but recognition is not the issue here, the algorithm is... however I have updated the ROIs to match the recommended settings, no difference in output:

Class100 and cont models have the same post-processing, but class11 it's own.

I've changed the config to use the class 11 model, still the same exact thing

[Digits]
Model = /config/dig-class11_1411_s2_q.tflite

[haverland]

@Plawasan your last digit should have the height like the digit before and all other digits should be the height like in picture described.

I hear you, but recognition is not the issue here, the algorithm is... however I have updated the ROIs to match the recommended settings, no difference in output:

Class100 and cont models have the same post-processing, but class11 it's own.

I've changed the config to use the class 11 model, still the same exact thing

[Digits]
Model = /config/dig-class11_1411_s2_q.tflite

A class11 will recognize "3". The problem here is, only > 9.x on the analog a special post-processing will be used and calculate here a 3(-1)=2. Here is the difference between the pointer and the first digit our biggest problem.

[SilRo991]

@SilRo991 if you use a class100 or cont model for digits your issue is fixed. Depends on the post-processing of class11.

@haverland I forgot to say that I also checked ROI Configuration and Choosing the Model. I thried all but it is always the same raw value. I also did a fresh installation of v11.3.1 and restored my config. Checked the differences in default config settings and mine. My config is basically default except the positioning parameters.

But I am not really sure what it has to do with the ROI or tflite as the recognition page show us the right value.

[Duese123]

I have exactly the same...
The numbers are corrctly recognized but it shows one too less. I tried to Set again prevalue and disable continues check but it will not help...
The 7 is recognized as 6.7 and before i got some readouts which were okay with 7 before....

It is just after updating to newest Version.

Has to be an error in algorithm

[jomjol]

Well, in principle you are right. But you see here one of the current challanges. Although you 0.1 counter is clearly higher than 2 already, the last digit is only at ~6.7.
The algo is teached in that way, that if the 0.1 is outside a tolerance band (here +/-0.2), than the read value is taking for real (here still a "6". If I increase the tolerance band to +/-0.3, it would work here, but not for other counters.

That is still challange for us to fine tune the settings and make them accesible in an understandable way to the user, so he can adjust to the specific model.

That will take some time, as the development here is very time consuming.

[pos-ei-don]

My Suggestion would be to let us users define a value which should gec calculated to the detected value.
I have on Meter with on numbrr which stays to High and another which stays too low. I'd love to add +0.4 to the first one and - 0.3 to the last one.

[Duese123]

@jomjol you are right... now it is 6.8 and the new counter is valid... thats for me ok...

Thanks for this Projekt It is very stable and works reliable

[haverland]

You Van reduce the height on Top of the digits. The ROIs are over the digit window. With newer models Dig-Class100 or dig-cont its essentially to set the ROIs close to the top and bottom of the digit window, to get correct results.

[brandstaetter]

Possibly stupid question (have not looked at the code yet) but would the following process make sense?

1. Recognition of all values
2. start at "lowest" digit, work backwards and do sanity check, not only using the tolerance band....

e.g.: working on a number made up of: dig1 dig2 dig3 ana1 ana2 ana3

dig1 -> recognized as 2.2
dig2 -> recognized as 4.5
dig3 -> recognized as 5.9
ana1 -> recognized as 9.4
ana2 -> recognized as 3.8
ana3 -> recognized as 8.6

in my experience this would yield a raw valui of 246.938 instead of the 275.938 it should be. This regularely leads to phases of error state, until the counter rolls over and it's not suddenly 1 m³ more than before.

I would have expected that the translation from recognition to raw value would be something like...

ana3: 8.6, tolerance 0.2, must be 8.
ana2: 3.8 tolerance 0.2, might be 3.6 to 4. but ana3 tells me, this should be 3.8 -> 3
ana1: 9.4 tolerance 0.2, with the knowledge of ana2 I can correct it as 9.3 -> 9
dig3: 5.9, tolerance 0.2, might be 5.7 to 6.1; with the knowledge ana1=9 I can pin it at 5.9 -> 5
etc...

might also be possible to go the other direction as well as yet another sanity check in the end

am I completely off or is that something that can be implemented to vastly improve accuracy?

[haverland]

in my experience this would yield a raw valui of 246.938 instead of the 275.938 it should be. This regularely leads to
dig3 = 5.9
ana1 = 9.4
In this case the dig3 is not 6, the ana1 is not over 0. So it is 245.938 the correct result, I think.

But I found the tolerance of 0.2 is not useful on the transition ana->dig. The difference between dig and ana is often very much (see @Duese123 dig=6.7, ana=2.2 => value=7.2)

Edit:
In other hand a lokal device: dig=4.8, ana=5.5 => value=4.5

[haverland]

Got a similar issue on 12.0.1 - good recognition, wrong value.. looks like the algo still needs some finetuning:

Correct value should be 170.05287 not 170.05387

@Plawasan : I'm not really shure here. Could you give a screenshot when the analog pointer is between 7-8. And a screenshot when the pointer ist between 9-0?

[Plawasan]

@Plawasan : I'm not really shure here. Could you give a screenshot when the analog pointer is between 7-8. And a screenshot when the pointer ist between 9-0?

Here's 7.2 on the analog counter, all looks good

However here's 7.8 and the reading is incorrect:

[haverland]

Got a similar issue on 12.0.1 - good recognition, wrong value.. looks like the algo still needs some finetuning:
Correct value should be 170.05287 not 170.05387

@Plawasan : I'm not really shure here. Could you give a screenshot when the analog pointer is between 7-8. And a screenshot when the pointer ist between 9-0?

Thx. Looks like the last digit rolling with the analog pointer parallel. Not like the other digits

[haverland]

@Plawasan: In next release you can set AnalogDigitalTransitionStart. Your meters should set here to 7.6-7.7.

All others can use the defaults.