[Lua] Log-File-Handling * Anhängen neuer Daten * How-to

[Sinter]

Hallo,

aktuelle Skript-Entwicklungen von Msl und Rudi nutzen die Möglichkeit, neue Log-Daten an bereits bestehende Log-Files anzuhängen. Nachdem dies für viele Anwendungen und auch für Erkenntnisgewinnungen interessant sein könnte, fände ich hilfreich, wenn wir hier Grundlagenmuster sammeln und dokumentieren könnten, auf welche Weise sich solch ein Log-File-Handling funktionsfähig gestalten lässt.

Probehalber habe ich nun auf Anregung von Msl unter Übernahme/Abwandlung der Lösungen von Msl und Rudi versucht, ein Test-Handling für eine *.csv-Datei zu realisieren, die man dann auf einfache Weise in eine Tabellenkalkulation importieren kann:

Einige Dinge (Anlage der Datei, Anhängen von Daten) klappen sehr gut, indes bin ich mir nicht sicher, ob sich neben einem Linefeed („\n“) auch ein CarriageReturn („\r“) einarbeiten lässt, sofern man dies zur Anzeige auf einfacheren Editoren wünscht. Auch ein Backspace (\b“) erscheint mir fraglich, nachdem ich in diesem kleinen Test-Skript an alle Daten einfach grundsätzlich ein Komma anhänge, und dann nach dem hintersten Datenfeld innerhalb eines Datensatzes ein überflüssiges Komma gelöscht werden müsste.

Hier das Beispiels-Skript:

Syntax: [ Download ] [ Verstecken ]

Syntax: [ Download ] [ Zeigen ]

Benutze Lua Syntax Highlighting

--[[
@title csv_test
@param c CarriReturn  0=AUS 1=EIN
@default c 0

rem
rem 2012 by Sinter
]]

carriagereturn = c

function log_name()
    file_existierte_noch_nicht = false          -- Initialisierung
    log_path = "A/CHDK/LOGS/"
    log_file_name = "csv_test"
    log_file_ending = ".csv"
    log_name = log_path..log_file_name..log_file_ending
    if os.stat(log_name) then
        logfile=io.open(log_name,"a+b")         -- Falls File bereits existierte
    else
        logfile=io.open(log_name,"wb")          -- Falls File noch nicht existierte
        file_existierte_noch_nicht = true
           
    end
   
    io.output(logfile)
   
    if file_existierte_noch_nicht then
        log("Datum,Wert1,Wert2,Wert3,Wert4,Wert5,Wert6,Wert7,Wert8")  -- Kopfzeile des CSV-File schreiben
    end

end

function log(...)
    io.write(...)
    io.write("\n")
end


function logdatenfeld(ddd)
    io.write(ddd..", ")
                                --  io.write("\n")
end


function loglinefeed()
                                --  io.write(...)
        io.write("\b")      -- FUNKTIONIERT NICHT: backspace: um letztes Komma des hintersten Datenfelds eines Datensatzes zu loeschen         
    if carriagereturn then
        io.write("\r\n") -- FUNKTIONIERT NICHT: carriage_return plus linefeed -- BEWIRKT keinen Unterschied zu Linefeed allein laut Hexeditor?
    else
        io.write("\n")          --  nur linefeed
    end
end


function restore()
    cls()
                            --set_console_layout(0,0,25,5)
    logfile:close()
end



-- MAIN:

log_name()          -- darf innerhalb des Scripts wohl nur einmalig aufgerufen werden, sonst Fehlermeldung
for i=1,3 do
   

    --logdatenfeld("Test: ", os.date("%d.%m.%Y %X"))   -- Datum wird damit leider nicht eingetragen
    logdatenfeld(os.date())  -- So wird Datum nun doch eingetragen, aber Format unbefriedigend
        for j=1,8 do
            logdatenfeld(j*10+i)
        end
       
    loglinefeed()
end
       
restore()

Erstellt in 0.012 Sekunden, mit GeSHi 1.0.8.9

Hier der Inhalt des entstandenen csv-Files nach viermaligem Start des Skripts, zweimailg mit aktiviertem CR, zweimalig ohne aktiviertem CR:

Syntax: [ Download ] [ Verstecken ]

Syntax: [ Download ] [ Zeigen ]

Benutze Text Syntax Highlighting

Datum,Wert1,Wert2,Wert3,Wert4,Wert5,Wert6,Wert7,Wert8
MAR 18 23:34:42:2012, 11, 21, 31, 41, 51, 61, 71, 81, 
MAR 18 23:34:42:2012, 12, 22, 32, 42, 52, 62, 72, 82, 
MAR 18 23:34:42:2012, 13, 23, 33, 43, 53, 63, 73, 83, 
MAR 18 23:34:48:2012, 11, 21, 31, 41, 51, 61, 71, 81, 
MAR 18 23:34:49:2012, 12, 22, 32, 42, 52, 62, 72, 82, 
MAR 18 23:34:49:2012, 13, 23, 33, 43, 53, 63, 73, 83, 
MAR 18 23:35:01:2012, 11, 21, 31, 41, 51, 61, 71, 81, 
MAR 18 23:35:02:2012, 12, 22, 32, 42, 52, 62, 72, 82, 
MAR 18 23:35:02:2012, 13, 23, 33, 43, 53, 63, 73, 83, 
MAR 18 23:35:04:2012, 11, 21, 31, 41, 51, 61, 71, 81, 
MAR 18 23:35:04:2012, 12, 22, 32, 42, 52, 62, 72, 82, 
MAR 18 23:35:04:2012, 13, 23, 33, 43, 53, 63, 73, 83, 

Erstellt in 0.001 Sekunden, mit GeSHi 1.0.8.9

Viele Grüße,
Sinter

[CHDKLover]

Hallo Sinter,
schön mal wieder etwas von dir zu lesen. Bisher dachte ich, dass das Anhängen von Daten an eine Datei schon lange möglich war, aber schlussendlich ist das ja auch egal. Bei meiner Kamera funktioniert das Schreiben von "\r\n" problemlos.
Für eine bessere Übersicht habe ich dein Testskript etwas angepasst. Steuerzeichen wie "\b" würde ich immer vermeiden, stattdessen könnte die letzte Schreiboperation einer Zeile besonders behandelt werden (verg. folgendes Beispiel).

Syntax: [ Download ] [ Verstecken ]

Syntax: [ Download ] [ Zeigen ]

Benutze Lua Syntax Highlighting

--[[
@title csv_test

rem
rem 2012 by Sinter

]]

function log_name()
    file_existierte_noch_nicht = false          -- Initialisierung
    log_path = "A/CHDK/LOGS/"
    log_file_name = "csv_test"
    log_file_ending = ".csv"
    log_name = log_path..log_file_name..log_file_ending
    if os.stat(log_name) then
        logfile=io.open(log_name,"a+b")         -- Falls File bereits existierte
    else
        logfile=io.open(log_name,"wb")          -- Falls File noch nicht existierte
        file_existierte_noch_nicht = true
    end
   
    io.output(logfile)
   
    if file_existierte_noch_nicht then
        logdatenfeld("Datum, Wert1, Wert2, Wert3, Wert4, Wert5, Wert6, Wert7, Wert8", true)  -- Kopfzeile des CSV-File schreiben
    end
end

function logdatenfeld(ddd, isLast)
    if( isLast ) then
        io.write(ddd.."\r\n")
    else
        io.write(ddd..", ")
    end
                                --  io.write("\n")
end

function restore()
    cls()
                            --set_console_layout(0,0,25,5)
    logfile:close()
end


-- MAIN:

log_name()          -- darf innerhalb des Scripts wohl nur einmalig aufgerufen werden, sonst Fehlermeldung
for i=1,3 do
    --logdatenfeld("Test: ", os.date("%d.%m.%Y %X"))   -- Datum wird damit leider nicht eingetragen
    logdatenfeld(os.date())  -- So wird Datum nun doch eingetragen, aber Format unbefriedigend
    for j=1,8 do
        logdatenfeld(j*10+i, j==8)
    end
end

restore()

Erstellt in 0.008 Sekunden, mit GeSHi 1.0.8.9

Grundsätzlich müsste man vor dem Schreiben der Daten prüfen, ob das Erstellen der Datei erfolgreich war. Dies könnte die Funktion log_name() über einen Rückgabewert signalisieren.

CHDKLover

[Sinter]

Hallo CHDKLover,

vielen Dank für Dein hilfreiches Feedback. Ja, das Anhängen von Daten ist selbstverständlich schon lange möglich. Mir geht es hier darum, das dahinterstehende Grundlagenmuster, bzw. die dazu nötigen Lua-Strukturen, auch für Nicht-Programmierer als How-to-Beispielsskript abzubilden, möglichst nachvollziehbar und nutzbar zu machen, so dass es leichter fällt, diese Strukturen zu verstehen und in eigene Lua-Skripte einzubauen. Ähnlich wie die sehr hilfreiche Shooting-Übersicht von Msl, in welcher verschiedene Shooting-Varianten vorbildlich als Musterbeispiele aufgezeigt werden.

Wenn man kein Profi-Programmierer ist, so erleichtern solche Übersichten/Musterbeispiele manche komplexere Ideenumsetzung erheblich. Mir fällt es jedenfalls deutlich leichter, so kleine Musterskripte zu verstehen und nachzuvollziehen, statt aus einem mehrere Seiten umfassenden Skript versuchen herauszulesen, welche Teilbestandteile des Skripts zur Lösung eines bestimmten Sachverhaltes nötig sind, bzw. in einem anderen neuen Skript eingebaut werden müssen.

In diesem Fall hier sind für mich auch mögliche Attribute des io.open-Befehls ("a+b", „wa“, „wb“) interessant, wie man deren Bedeutung interpretieren kann,
sowie ob es gelingen kann, bei einem Linefeed auch noch ein CR „\r“ einzufügen.
Das Schreiben des CR klappt inzwischen auch bei mir. Ich hatte da im Skript offenbar einen Bug beim Setzen der CR-Flag über die Variable c. Ich hätte die Variable „Carriagereturn“ gleich nur mit True/False besetzen müssen. Jedenfalls bin ich froh darüber, nun sicher zu wissen, auf welche Weise ich das CR realisieren kann. Ich glaube, das brauche ich zukünftig noch dringend.



Ein Backspace könnte sich mir zwar auch noch nützlich erweisen, aber in der Tat sollte man sich vielleicht besser gleich mit einer separaten Schreibfunktion des letzten Werts behelfen. Deine Vorschlagslösung gleicht hier einem genialen Schachzug, wobei mir bislang nicht bekannt war, dass man hier auf so elegante und einfache Weise mittels des Arguments „j==8“ an dieser Stelle eine True/False-Entscheidung einbauen kann. Darauf muss man erst mal kommen. Deine Lösung gefällt mir!
Dein Musterskript funktioniert reibungslos und ist sehr übersichtlich.

Nebenbei sehe ich, ich hatte Dich mit dem Skript zu der idealen Annahme verleitet, dass hier ein Table bereits bis zum letzten Wert gefüllt ist, die Anzahl der Werte feststeht, und Du schreibst sämtliche Werte in einer einzigen Schleife. Im Einzelfall, für Situationen bei denen vorab beim Schreiben der einzelnen Werte weder der Umfang des Datensatzes bekannt ist, und man noch nicht weiß, ob es sich bereits um den letzten Wert des Datensatzes handelt, könnte hingegen noch eine Löschmöglichkeit des letzten Zeichens (Komma) hilfreich sein. Aber das scheint wohl nicht so einfach.

Oder ich muss das Schreiben jedes Werts so lange zurückhalten, bis mir die Information vorliegt, ob es sich um den letzten Wert des Datensatzes handelt. Das wäre zwar realisierbar, aber keine elegante Lösung.

Oder ich nutze einen anderen Ansatz und schreibe lieber VOR jeden Wert ein Komma (welches ich mittels IF-Entscheidung weglassen kann falls es sich um den ersten Wert eines Datensatzes handelt) da es für mich einfacher zu prüfen ist, ob ich gerade den ERSTEN Wert eines Datensatzes schreibe (statt zu erkennen, ob es bereits der letzte Wert sein wird). Dann kann ich das Komma weglassen, falls es sich um den ersten Wert handelt. Denn manchmal warte ich nicht erst ab, bis ein Table gefüllt ist, sondern möchte einfach nacheinander Werte in einen File „werfen“. Vor allem wenn der Umfang des Datensatzes während des Schreibens einiger erster Daten noch nicht bekannt ist.



Etwas irritiert bin ich, weshalb bei mir die Formatierung des Datums nicht funktionierte, so wie ich sie aus einem anderen Skript übernommen hatte. Da muss ich etwas übersehen haben. Ich habe mir im Lua-Reference Manual die Datum-Formatierung angesehen, aber die ist dort nicht gerade aufschlussreich erläutert. Daher musste ich aktuell einfach nur die Standard-Datumanzeige nehmen, mit der ich nicht besonders glücklich bin. Ich wünschte, ich hätte eine kleine detailliertere Lua-Referenz zur Datum-Formatierung, vielleicht mit einem kleinen Beispiel.

Einen anderen Punkt, den Du erwähnst, verstehe ich noch nicht genau: Du meintest, man müsste vor dem Schreiben der Daten prüfen, ob das Erstellen der Datei erfolgreich war, und dass dies die Funktion log_name() über einen Rückgabewert signalisieren könnte. Ich hatte mich einfach an log_name() aus dem all_dist.lua-Skript angelehnt. Wäre das denn mittels weniger Zeilen möglich?

Vielen Dank und viele Grüße,
Sinter

[msl]

Hallo Sinter,

ich muss mich auch öfters von den Leuten, die wesentlich mehr vom Programmieren verstehen, zu Recht ermahnen lassen, dass eine Funktion wenigstens einen Status (true oder false) zurückgeben sollten. Somit können Fehler, die in einer Kettenreaktion enden, vermieden werden. Und darauf wollte CHDKLover sicherlich aufmerksam machen.

Im konkreten Fall sollte überprüft werden, ob die Datei auch wirklich existent ist.

Syntax: [ Download ] [ Verstecken ]

Syntax: [ Download ] [ Zeigen ]

Benutze Lua Syntax Highlighting

if os.stat(log_name) then
    return true
else
    return false
end

Erstellt in 0.003 Sekunden, mit GeSHi 1.0.8.9

Im Verlauf Des Skripts kannst du dann einen möglichen Fehler abfangen.

Syntax: [ Download ] [ Verstecken ]

Syntax: [ Download ] [ Zeigen ]

Benutze Lua Syntax Highlighting

if log_name()  then
    ...
else
   print("Fehler")
end

Erstellt in 0.003 Sekunden, mit GeSHi 1.0.8.9

Das ganze kann sicherlich geschickter gestaltet werden. Es dient lediglich als Beispiel.

Gruß msl

[Sinter]

Hallo Msl,

vielen Dank für den schnellen Hinweis. Deine vorgeschlagenen Beispiels-Zeilen Lua-Code halte ich durchaus bereits für geschickt, nachdem sich das offenbar mit derart geringem Aufwand lösen lässt. An solchen Musterbeispielen kann man sich sehr leicht orientieren. Die Sammlung von Musterbeispielen könnte man fast noch als eigenes Forenthema einrichten.

Mir fällt gerade noch ein, ich glaube, Naddel hatte früher mal Erkenntnisse gewonnen, dass das Filesystem etwas träge sein kann. Ob das auch in diesem Fall kritisch sein kann, weiß ich noch nicht. Vielleicht ist es sogar notwendig, ähnlich wie Naddel es damals löste, zusätzlich noch eine prüfende Verweilschleife einzubauen.

Ich bin stets froh und dankbar wenn erfahrene Programmierer auf solche interessanten Details hinweisen, um eventuelle Schwächen im Skript zu vermeiden.

Kennst Du Dich vielleicht auch noch mit der Formatierung des Datums aus, weshalb man das nicht einfach aus all_dist.lua übernehmen konnte?

Vielen Dank und viele Grüße,
Sinter

[msl]

Hallo Sinter,

die Formatierung in der Datum-Funktion war schon ok. Scheinbar wird sie aber nicht richtig in die Funktion logdatenfeld() übernommen. Vielleicht lässt sich das umgehen, indem man die Zeile aufteilt.

Hier noch ein Link zum Thema Formatierung date(): http://www.lua.org/pil/22.1.html

Wenn ich es richtig verstehe, vergleicht CHDKLover das Datum. Dazu wird es im Standardformat benötigt. Um das Datum formatiert auszugeben, wird zusätzlich ein formatierter Datum-String gebraucht.

Das Dateisystem kann in der Tat träge werden. Insbesondere dann, wenn die SD-Karte schon eine Menge an Dateien beinhaltet. Deshalb ist eine prüfende Schleife ein guter Gedanke. Allerdings sollte diese zeitlich begrenzt sein, damit man nicht unfreiwillig eine unendliche Schleife erzeugt.

Gruß msl

[Sinter]

Hallo Msl,

vielen Dank für Deinen Hinweis.
Die Datum-Formatierung werde ich mir genauer ansehen um die Daten schöner zu loggen.

Und bezüglich der Trägheit des Filesystems werde ich nun schauen, wie Naddel damals die Schleife bemessen und gesteuert hatte. Ich kann mich erinnern, da war etwas, aber mit den Details hatte ich mich nicht befasst.

Falls ich CHDKLover korrekt deute, dann braucht man auch ausschließlich die Erstellung des File überprüfen, jedoch nicht die späteren weiteren Schreibvorgänge. Demnach gäbe es auch einzig dann eine kleine Verzögerung im Skriptablauf, wenn das Skript erstmalig den csv-File anlegt, und nicht mehr bei späteren Schreibvorgängen.

Viele Grüße,
Sinter

[CHDKLover]

Hallo Sinter,
viele Standardfunktionen geben Rückschluss über den Erfolg. io.open gibt zum Beispiel "nil" zurück, falls ein Fehler beim öffnen aufgetreten ist. Diese Information könntest du auswerten und darauf angemessen reagieren.

CHDKLover

[rudi]

Hallo zusammen,

wenn ich das richtig verstehe, dann entsteht hier ein CSV-LOG-Modul. Dafür verweise ich erst einmal auf einen älteren Beitrag. Das Skript dort ist ganz gut dokumentiert. Als Besonderheit werden auch berechnete Felder mit in die CSV geschrieben. Das Semikolon hat sich als sinnvolles Trennzeichen erwiesen.

Der Fehler bei

Code: Alles auswählen

logdatenfeld("Test: ", os.date("%d.%m.%Y %X"))   -- Datum wird damit leider nicht eingetragen

ist darin begründet, dass die Funktion logdatenfeld() mit zwei Argumenten definiert ist:

Code: Alles auswählen

function logdatenfeld(ddd, isLast)

Somit wird os.date() in isLast übergeben. Daher fassen wir den String zusammen:

Code: Alles auswählen

logdatenfeld("Test: " .. os.date("%d.%m.%Y %X"))

Gruß rudi

[Sinter]

Hallo zusammen,

vielen Dank für Euer wertvolles neues Feedback!


@CHDKLover:
Falls ich Deinen Vorschlag korrekt interpretiere, so wäre bei meiner Zeile

Syntax: [ Download ] [ Verstecken ]

Syntax: [ Download ] [ Zeigen ]

Benutze Lua Syntax Highlighting

logfile=io.open(log_name,"wb")

Erstellt in 0.003 Sekunden, mit GeSHi 1.0.8.9

im Falle eines Fehlschlags des Öffnungsversuchs dann die Variable logfile mit dem Wert nil besetzt. So könnte ich anschließend eine Abfrage einbauen:

Syntax: [ Download ] [ Verstecken ]

Syntax: [ Download ] [ Zeigen ]

Benutze Lua Syntax Highlighting

if logfile == nil then

Erstellt in 0.003 Sekunden, mit GeSHi 1.0.8.9

Ich frage mich, ob ich diese Abfrage gleich als unmittelbar nächste Programm-Zeile einfügen kann, oder ob das Filesystem hier vielleicht so träge sein könnte, dass man dazwischen noch eine Verweilschleife einbauen sollte?

Und ist es auch ratsam, die Abfrage (if logfile == nil ) nach dem Append-Open-Befehl

Syntax: [ Download ] [ Verstecken ]

Syntax: [ Download ] [ Zeigen ]

Benutze Lua Syntax Highlighting

logfile=io.open(log_name,"a+b")

Erstellt in 0.003 Sekunden, mit GeSHi 1.0.8.9

einzusetzen?

EDIT: Vielleicht kannst Du auch noch einen kurzen Blick auf meinen EDIT-Abschnitt hier in diesem Beitrag ganz unten werfen, ob das vielleicht noch ein CHDK-Bug beim Befehl get_dofinfo() sein könnte. Das ist eine Zufallsentdeckung aufgrund Rudis CSV-Log-Skripts. Ich glaube unser CHDK-Befehl get_dofinfo() liefert bei der Ixus60 wirre Blendenwerte.


@rudi:
Dein professionelles Skript mit Deinem CSV-LOG-Modul war mir noch unbekannt. Ich habe es mir gleich ausgedruckt. Bereits auf den ersten Blick scheint es recht gut meiner Log-Zielsetzung zu entsprechen, denn genau wie bei Dir geht es mir darum, zur Erkenntnisgewinnung eine größere Menge an gemessenen und berechneten Werten in einen CSV-File zu loggen. Pro Datensatz vermutlich mindestens 30 Datenfelder, mittlerweile denke ich sogar schon an etwas mehr als 100 Datenfelder pro Datensatz.

Ich muss mir Dein Skript bei Gelegenheit noch ganz genau anschauen und mich in Deine Details hineindenken.

In Deinem Skript fällt mir auf, du verwendest bei der Zeilenabgrenzung kein CarriageReturn („\r“), sondern ausschließlich das Linefeed („\n“). Ich habe Dein Skript bei mir gerade zu Probe noch um das CR ergänzt, also „\r\n“. Zumindest die Open-Office-Tabellenkalkulation scheint auch noch ein eingefügtes zusätzliches CR zu akzeptieren.

Spannend ist in Deinem Skript, wie Du offenbar auch noch Excel-Formeln mit einfügst. Die Idee gefällt mir, denn das könnte vielleicht auch bei mir äußerst nützlich sein.

Ich sehe schon, mit Deinem beispielhaften Skript muss ich mich genauer beschäftigen. Mittlerweile denke ich sogar, ich muss vielleicht in meinem Skript nicht nur einen einzigen File erstellen, sondern parallel zwei Log-Files handhaben. Einen kleineren jeweils für jedes Foto einzeln, und einen richtig großen CSV-File zum Sammeln von Erkenntnisdaten, um sie danach auswerten zu können. Ich hoffe, das Filesystem lässt einen derart großen File, mit mindestens 50 Datensätzen zu jeweils etwa 100 Datenfeldern zu.

Vielen Dank auch für die Auflösung der Fehlerursache bei der Datum-Formatierung. Kleine Ursache, große Wirkung. Jetzt begreife ich, was ich übersehen hatte.


Nochmals vielen Dank und viele Grüße,
Sinter
EDIT: CHDK-Bug in get_dofinfo(), bzw. dofinfo.aperture?:
@Rudi:
Dein Skript habe ich auch in meiner Cam laufen lassen. Im Zahlenwerk meines dabei entstandenen doflog.csv fällt mir indes eine ganz andere Sache auf, wenn ich meinen doflog.csv mit dem eines anderen Users in Deinem Thread vergleiche: Täusche ich mich, oder stimmt bei meiner Cam etwas mit dem Blendenwert nicht? In der Folge vermutlich ebenfalls die Hyperfokaldistanz. Sind das bei mir im Blendenwert nicht viel zu krumme Zahlen? Meine doflog.csv-Tabelle habe ich als PDF (nochmals um einige Messungen erweitert) unten angefügt.

Meine Ixus60 darf doch für jede Brennweite aufgrund des ND-Filters jeweils höchstens nur zwei (!) mögliche Blendenwerte aufweisen (ND-Filter ein-/ausgeklappt). (Eigentlich aufgrund des dennoch gleichbleibenden Irisdurchmessers nur ein einziger Wert?) Für Brennweite 5800 werden in meiner Tabelle lauter verschiedene Blendenwerte „gemessen“.
Ähnlich bei den anderen Brennweiten, auch hier lauter verschiedene Blendenwerte.

Nachdem ich in Deinem Skript keinen Fehler erkennen kann, ist das vielleicht noch ein kleiner CHDK-Bug im Ausleseprozess des Blendenwerts (get_dofinfo, bzw. dofinfo.aperture)?

Auch in der DOF-Rechner-Anzeige bekomme ich bei gleichbleibender Brennweite je nach Fokusentfernung sehr verschiedene HYP-Fok-Distanzen angezeigt. So wie ich die Tabelle deute, dann rechnet Dein DOF-Rechner mit den ihm vorliegenden Werten vermutlich durchaus korrekt, aber ihm liegen bei meiner Cam vermutlich verfälschte Werte zugrunde, so dass in der Folge auch Dein vorbildlicher DOF-Rechner hier zwangsweise ein verfälschtes Ergebnis ermittelt.
Aber scheinbar sind bei weitem nicht alle Cams davon betroffen.