@jomjol Ich hab das CNN auch mal bei mir trainieren lassen, um zu sehen, ob es taugt und auch um die Fehlerrate mal zu verringern. Auf meine 16000 SourceImage der letzten Tage angewendet habe ich > 50% NaN in den letzten 4 Ziffern, bzw. tatsächlich in der letzten Ziffer. Daher meine Frage:
Was darf alles in den NaN Ordner rein zum trainieren und was nicht?

Wenn ich mich auf das Bild von @michaeljoos beziehe:
Käme hier die letzte Ziffer in NaN oder in 9 oder sollte man sie für das Trainieren komplett vermeiden? D.h. sollte man nur Bilder, die exakt zwischen 2 Ziffern liegen, in NaN kopieren?
Ich habe die Erfahrung gemacht, dass sehr oft zwischen 6 und 7 als 9 erkannt wird. Der Kringel der 6 und der schräge Balken der 7 sind da anscheinend gewichtiger als die Tatsache, dass beide Teile nicht durchgängig verbunden sind.

In diesem Zusammenhang noch eine Frage:
Sollte ich (siehe Bild in einem der vorherigen Posts) die letzte Ziffer (digit8) bei mir kleiner ausschneiden? Beim letzten Rad ist offenbar der sichtbare Bereich größer, so dass ich grundsätzlich immer Teile einer anderen Ziffer sichtbar habe, was dann sehr stark in Richtung NaN oder Fehlinterpretation geht.

Außerdem habe ich mich noch gefragt, ob man das CNN auf 21 Klassen erweitern könnte und exakt solche Werte, 2.5, 6.5, etc. zulassen kann, wenn man sie erkennt. Habe damit ein bisschen probiert, aber zu wenig Daten dafür. Dies würde ggf. auch die NaN Rate reduzieren.

Resultat:

out.zip
Neuer Schnitt und mehr Ziffern

Wäre das hier ein besserer Schnitt?

Oder geht das zu weit runter? Hab versucht, mich an die 23% und 78% zu halten. Die 3 an Pos. 5 ist warum auch immer recht tief und der blaue Rand hat da eine Wölbung. Ist dann aber auch weiß mit auf dem Bild ganz unten.

@jomjol Ich kann in der config doch im modelfile eine tflite Wählen. Die sollte doch dann verwendet werden. Im Code wird ja auf die tflite zurückgegriffen. So nur mein Verständnis. Ich befürchte halt, dass wenn alle Ziffern in einer Datei zusammengefasst sind, dass das System hier Fehlalarm schlägt, da er jetzt schon statt einer weiß-auf-schwarz 4 eine schwarz-auf-weiß 8 erkennt.

Ich bin gerade parallel dabei, die Python Version etwas zu modifizieren. Hauptsächlich refactorings, die wir natürlich besprechen müssten.
Das Ganze bräuchte ich, um einen Zähler mit Vor- und Nachkommazahlen zu betreiben.
Auf dem ESP wäre das natürlich auch willkommen, wenn das ginge. Allerdings ist das schwieriger zu aktualisieren, da mann dafür den ESP jedesmal rausnehmen, oben anschließen, programmieren und wieder einsetzen muss. Geht auch, aber der Entwicklungszyklus ist definitiv länger, wenn man das häufiger machen muss.
Bin gespannt.
Wenn du reviews benötigst, gib bescheid. Meinen github account kennst du ja.

@jomjol Ok, kann ich einstellen. Ich bin allerdings schon am Rand des Rades. Wenn ich oben/unten mehr dazu gebe, dann kommt blaue Umrandung dazu.

Noch was: Da meine 4 bereits oft als 8 falsch erkannt wird (und andere auch), macht es wahrscheinlich Sinn, für die weiß auf schwarz/rot gelagerten Ziffern eine eigene tflite Datei anzulegen, die man dann auswählen kann. Ansonsten dürfte es schwierig werden, was erkannt wird am Ende.

Und hier eine erste Fuhre weiß auf schwarz. (0,2,3,4). schwarz.zip

Wie es ausschaut gibt's hier keine in 10, da der Zähler scheinbar sauber umspringt. Zumindest erkenne ich das so aus den Bilder, aber ist noch nicht vie Zeit ins Land gezogen.

Wenn noch jemand einen Sensus 620 hat, kann er gerne hier mithelfen, Bilder hochzuladen.

@jomjol hier einmal mit rotem Hintergrund. rot.zip
Viel Variation im Licht ist nicht, da es ziemlich konstant und in einer abgeschlossenen Halterung verbaut ist.

@jomjol Noch ein Hinweis: man kann jetzt mit einmalig

docker build --tag watermeter:local -f Dockerfile_synology .

und

docker run -p 3000:3000 --mount type=bind,source=(PATH_TO_LOCAL_CONFIG,target=/app/config --mount type=bind,source=/PATH_TO_LOCAL_LOG,target=/app/log --rm --mount type=bind,source="/path/to/water-meter-system-complete/code",target=/app watermeter:local

den Code bearbeiten und lokal laufen lassen (läuft bis jetzt sauber unter MacOS).
Nach Code-Änderungen reicht ein CTRL-C und erneutes docker run ..., um den Container auf den neuesten Stand zu bringen. Neues docker build ist nicht notwendig, da das code Verzeichnis in /app gemountet ist.

Leider reicht es in Python nicht aus, den Code einfach zu ändern, wie in anderen Sprachen bzw Frameworks, die code dynamisch nachladen können. Aber es sollte ein Geschwindigkeitsboost sein, auf das build verzichten zu können.

@jomjol alles klar.

Schwarzer Hintergrund kann leider etwas dauern, da das die Vorkommastellen sind.
Du erwähntest irgendwo 3-4 Bilder pro Ziffer. Sollten die dann von verschiedenen Stellen sein, da sie sich ja ggf (Winkel, Licht) leicht unterscheiden? Und brauchst du die auch mit verschiedenem Drehwinkel, also Bilder, wo die 2 zwar komplett zu sehen ist, aber mal mittig, mal am oberen Rand, mal am unteren? Das könnte dann noch länger dauern.

Roter Hintergrund dürfte bald durch sein, zumindest wenn du sie nicht von jeder Stelle brauchst, sondern die letzte und ggf. vorletzte ausreicht.

Zwecks Wertigkeit: kein Thema, dafür nehm ich mir mal die Zeit. Will es ja zum Laufen bekommen

@jomjol kann ich absolut verstehen, dass man nicht immer Zeit hat. Kenne ich selber. Trotzdem schonmal großen Dank für die schnelle Rückmeldung. Ein paar neue Fragen ergeben sich:

zu 1) Danke für das PDF. Das hilft (hoffentlich). hier ist von einem prealignment parameter die Rede. Ist das das selbe wie

[alignment]
initial_rotation_angle=-1.0

Nach einigem hin und her hat er dann auch dir Bilder akzeptiert. Man muss allerdings einen AnalogCounter definieren, auch wenn es Disabled ist, da sonst auch das script im Dockerimage meckert.

1. Ich speichere jetzt Ziffern in den digital_digit-Unterordnern, d.h. meist NaN, manchmal halt auch falsch (oder in 10?!)
   Zum Lernen muss ich sie dir dann wahrscheinlich zusenden, richtig?
   Es reicht nicht, d.h. er lernt nicht, wenn ich die Bilder nur in den richtigen Ordner (0-9) verschiebe.
   Oder kann ich das irgendwie anders selber?

2. Habe mich gefragt, ob es ausreicht, das Bild zu negieren und in s/w zu konvertieren - dann hätte ich ja schwarz auf weiß bzw. schwarz auf grau beim rotem Hintergrund.

3. Was ich noch ändern werde ist, dass du momentan davon ausgehst, dass digital = vorkomma und analog = nachkomma. Da ich nur digital habe, muss ich ihm eine Wertigkeit der Ziffern mitgeben. Evtl. als Parameter in der config. Ich schau mal.
   In diesem Zuge habe ich mich gefragt, ob es klappen könnte, wenn ich meine drei letzten Ziffern als AnalogCounter erstelle, aber als Modelfile das digitale nehme. Könnte das klappen? Ich kann ja in der config dx und dy beliebig wählen und muss es dort nicht quadratisch eingeben. Da ich noch keine Ziffern habe, die funktionieren, kann ich das nicht richtig ausprobieren.