Wie Tv aus A620 auslesen?

[BigDaddy]

Hallo Leute,

mein erster Beitrag im Forum. Habe schon vor einem Jahr mal kurz mit CHDK gespielt, aber jetzt bin ich etwas intensiver dran. Ist ja ne super Sache. Herzlichen Glückwunsch auch zu diesem Forum; ist extrem interessant!

Ich habe die letzten Tage mein altes uBASIC Primitiv-Intervall-Script etwas verbessert (und dabei gnadenlos von 7UpLight von gehtnix abgekupfert ).

Jetzt habe ich es mir in den Sinn gesetzt, die anfängliche Berechnung der Gesamtlaufzeit so gut wie möglich hinzukriegen. Und da ich später das Script auch für (sehr) lange Belichtungszeiten einsetzen will, soll eben unbedingt auch Tv in die Rechnung eingehen, sonst würde das gar keinen Sinn machen.

Jetzt stosse ich aber auf ein blödes Problem, für das ich auch nach Stöbern im Netz keine Lösung gefunden habe: Ich schaffe es einfach nicht, Tv aus meiner A620 auszulesen.

Folgende Befehle bisher versucht:

get_tv: Hängt Kamera auf.
Im engl. Forum steht zwar nur was davon, dass es Kameras mit ND-Filter statt Blende aufhängen soll. Die A620 hängt aber definitiv. In jedem Fall aber scheint es so, dass sowieso davon abgeraten wird, den Befehl zu benutzen, und man sollte nur die untenstehenden benutzen.

get_user_tv_id: Funktioniert, liefert aber nur die "bekannten" IDs zurück, also nur jene, die die Standard-Firmware kennt, egal welchen override ich gewählt habe. Also eher nicht brauchbar.

get_tv96: Das wäre eigentlich das richtige, denke ich. (Ich finde einige Scripts im Netz, wo das eingesetzt wird, auch für Nicht-Standard Tv-Werte.) Aber auf meiner A820 liefert es immer nur 0 zurück, egal welchen Modus und welche Belichtungszeit ich gewählt habe.

Bin momentan am Ende meines Lateins. Hat vielleicht jemand ne Idee?

Grüße
BigDaddy

[gehtnix]

Hi BigDaddy,

die Zeiten von 15" bis 1/2500 kannst Du ja auslesen (get_user_tv96 bzw. get_user_tv_id).
Mit der ID-Kennung musst Du Dir dann eine Liste bauen, so wie bei HDR-Hyper.bas mit der Blende.

Bei dem Override wäre zu prüfen ob man die durch das Script setzen kann. Das geht wohl eher nicht, mal ungeprüft so vor mich hingedacht.

Da Du dann aber ohnehin mit dem Override die Zeit von z.B. 45 Sekunden wählst, würde es sich anbieten diesen Wert über Parameter einzufügen und damit die Endzeit zu berechnen.

Oderrr,

Code: Alles auswählen

a=get_tick_count
shoot mit den 45 Sekunden

do
    b=get_tick_count
until get_shooting=0

if z=0 then
   c=b-a
   if c>Intervall dann,
       zeitberechnung = Anzahl*Zeit, print usw.
   ansonsten
       Intervall*Bildzahl=Endzeit
    endif
endif

rem und dann erst den Bildzähler, wird also nur einmal berechnet
z=z+1


mal so hingetippt.

So hättest Du zwar erst nach dem ersten Bild eine (sehr) gute Zeitberechnung. Der zusätzliche Parameter ist weg. Die Zeit der Bild-Bearbeitung (Daten werden bearbeitet) ist dann auch in der Zeitberechnung mit drinnen, gerade getestet, bei 6 Sekunden Verschlusszeut werden 15 Sekunden Gesamtzeit zurückgeliefert. Das würde bei Berechnung der reinen Verschlusszeit nicht so sein.

gruß gehtnix

[BigDaddy]

Hi gehtnix,

vielen Dank für deine Antwort und deine Ideen!

Die erste Idee, d.h. den Override durch das Script zu setzen, ist eher nicht brauchbar für mich. Ich denke, i.d.R. muss ich das für die Szene geeignete Tv vor Scriptstart manuell bestimmen usw.

Mit der zweiten Idee (die ich auch schon mal kurz hatte) kann ich mich dagegen immer mehr anfreunden. Der einzige Nachteil wäre nur, dass die Zeit eben erst nach dem ersten Bild bekannt würde, wie du selber ja schon schriebst. (Bei sehr langen Bel.-Zeiten ist das natürlich schon ein wenig doof...). Der Vorteil ist aber sicher, dass das sehr genau wäre und immer funktionierte.

Ich hatte gestern schon eine ganze Menge Messreihen gemacht, um rauszufinden, von welchen Faktoren die resultierende Intervallzeit abhängt. U.a. habe ich untersucht, ob sie womöglich z.B. vom Displayzustand abhängt (könnte ja sein, dass der Aufbau des Displayinhalts Zeit kostet), von der gewählten Bildauflösung usw. (Erfreuliches Ergebnis war, dass es da keine Abhängigkeiten im Rahmen der Messgenauigkeit gab.)

Ein merkwürdiges Ergebnis in diesem Zusammenhang war aber folgendes:
Ich habe auch die Zeiten bestimmt für den Fall wo Tv > 1 sec, also wenn die Kamera die automatische Dunkelbildsubtraktion ("Rauschverminderung") macht. Ich habe einen linearen Zusammenhang angenommen, also T = a*Tv + b, wobei ich erwartete, dass a exakt gleich 2 ist und b einen konstanten kleinen Offset verursachen könnte (für die Zeit, die die Kamera für die Subtraktion braucht). Ich habe mit 10 verschiedenen Tv Werten gemessen und die erhaltene Gerade dann gefittet. Das überraschende: a ist nicht 2, sondern ca. 2.1! (Dieses Ergebnis war so robust, dass ich denke, es lag deutlich ausserhalb der Messfehlergrenze.)

Wie auch immer, man sieht, dass die Zusammenhänge komplizierter sein können als man zunächst denkt.

Da ist die Herangehensweise, das zu messen statt zu berechnen, natürlich schon ein großer Vorteil. (Und hat nebenbei noch den Vorteil, dass das auch dann noch korrekt bleibt, selbst falls ich später mal was an dem Script verändern sollte, so dass die Scriptzeit selber sich verändert usw.)

Ich denke, so gehe ich das dann also mal an (sobald ich wieder Zeit habe).

Nochmals danke für deinen Rat!

(P.S.: trotzdem komisch, dass es keine Möglichkeit gibt, Tv auszulesen. Bei anderen Kameramodellen geht das anscheinend ...).


Grüße
BidDaddy

[BigDaddy]

Hi,

habe gerade eben rausgefunden, dass das get_tv96 doch funktioniert, inkl. der override Werte!

Man muss aber vorher den Shutter halb durchgedrückt haben, also z.B. so:

Code: Alles auswählen

@title testTV96
@param a delay
@default a 500
press "shoot_half"
sleep a
release "shoot_half"
get_tv96 t
print t
end

Das Gemeine ist, dass a nicht zu kurz sein darf, sonst geht es nicht (wird dann der vorherige alte Wert zurückgeliefert).

Es scheint also, als ob erst durch durch diesen Shutter-Druck der Wert in der Kamera "aktiviert" wird oder so.

Bei mir scheint es erst dann zuverlässig zu funktionieren, wenn ungefähr a >= 600 ms.

Hmm, muss ich noch genauer untersuchen ...

Grüße
Uwe

[gehtnix]

Hi,

man lernt ja nie aus.

Ich hab das so abgeändert dass 3 Werte angezeigt werden.

Code: Alles auswählen

@title testTV96
@param a delay
@default a 5

a=a*100

press "shoot_half"
print get_tv96
sleep a
print get_tv96
release "shoot_half"
print get_tv96

end



Die beiden unteren laufen immer synchron, der obere will nicht immer so richtig wie er sollte. Insofern ist das (hohe) sleep schon richtig

gruß gehtnix

[BigDaddy]

Hi gehtnix,

alsooo, ich hab' jetzt noch einiges rumprobiert, ist aber alles nicht so einfach

Konzept A (Berechnung mittels get_tv96 usw.):
Ist ja schön und gut, dass ich nun weiß, wie ich diesen Wert auslesen kann, aber der Umgang mit diesen 96er Zahlen ist natürlich schrecklich.
Auf keinen Fall will ich irgendeine riesige "Tabelle" o.ä. im Code verwenden. Also stellt sich die Frage, wie kann ich T (in s oder ms) aus Tv96 berechnen ohne Fliesskomma. Dafür habe ich sogar mittlerweile eine math. Lösung, wie das im Prinzip gehen kann. Aber ist dermassen von hinten durchs Auge, dass sich alles in mir dagegen sträubt ...

Also doch eher Konzept B (Messung mittels tick_count usw.):
Zunächst hätte ich da eine Frage zu deinem Codefragment von vorher. Ich sehe nicht, wozu der Aufwand mit "until get_shooting" nötig sein soll. Nach meinen Tests hier läuft das Script nicht weiter, während die Kamera das Bild aufnimmt. Also Folgendes läuft tadellos (ohne sich zu "verschlucken", auch bei sehr langen Bel.-Zeiten):

Code: Alles auswählen

@title MessZeit1
@param n Number of pics
@default n 50
for i = 1 to n
  c = get_tick_count
  shoot
  c = get_tick_count - c
  print c
next i
end


Aber es tut sich mal wieder eine andere kleine Merkwürdigkeit auf: Eigentlich sollten ja alle oben ausgegebenen Zeitwerte c gleich lang sein. (Benutze auch MF, um keine Varianz durchs Fokussieren zu kriegen.)

Das stimmt auch ganz gut für alle i >= 2. Aber stets das erste Bild in der Reihe braucht immer länger als die anderen, und nicht zu knapp. Bei kurzen Tv-Werten ist die Differenz ca. 200 bis 300 ms, bei etwas längeren (um 1 s) ca. 400 ms, und bei noch längeren 800 ms. Das ist sehr gut reproduzierbar, also weit ausserhalb der Messfehler. (Kann übrigens gut sein, dass mein früheres Ergebnis von wegen "Steigung = 2.1" ein Artefakt war, welches genau hiervon rührte.)

Ich kann mir einfach nicht vorstellen, was es für einen Grund für die Kamera gibt, sich so zu verhalten...

Sind natürlich auch schlechte Nachrichten für mein "Konzept B". Da müsste ich ja jetzt mit der Messung sogar bis nach dem zweiten Bild warten. Oder diesen komischen variablen Zeitoffset explizit hinzuaddieren. Sehr unhübsch...

Grüße
BidDaddy

[gehtnix]

Hi BigDaddy,

Aber ist dermassen von hinten durchs Auge, dass sich alles in mir dagegen sträubt ...

Wenn es denn geht, warum nicht von hinten durchs Auge?

Ich sehe nicht, wozu der Aufwand mit "until get_shooting" nötig sein soll.

Ich auch nicht Muss gestehen dass ich da was zusammenkopiert hatte wo das get_shooting drinnen stand. Nachdem es tat was es sollte habe ich es so belassen. Ein shoot_half braucht wohl immer ein "Verweilzeit" nachher. Mit get_shooting wird die halt auf das kürzeste gehalten , ohne ein festes sleep.

Eigentlich sollten ja alle oben ausgegebenen Zeitwerte c gleich lang sein.

Das da nicht die gleichen Werte rauskommen hatte ich bei meinem Kurztest auch schon festgestellt. Habe jetzt mal Dein Script durchlaufen lassen. 4/10 ist die größte Abweichung. Damit musst Du leben.

Ich kann mir einfach nicht vorstellen, was es für einen Grund für die Kamera gibt, sich so zu verhalten...

Ist halt keine Seiko! Und wird auch keine mehr.

Formatier mal Deine SD-Karte und schau mal ob sich das großartig verändert. Ich hatte mal bei mir festgestellt dass Karten auf dem PC formatiert bei mir schneller sind. Frach mich aber nicht wieso dem so ist.


Grüße gehtnix

[BigDaddy]

Hi,

Wenn es denn geht, warum nicht von hinten durchs Auge?

Ist wirklich ziemlich mühselig, und habe bisher nur das Prinzip aufgeschrieben aber noch keinen echten Code. Mach' ich wahrsch. erst später mal weiter dran. Wenn ich das mal habe, kann ich es ja posten, falls Interesse besteht.

Ein shoot_half braucht wohl immer ein "Verweilzeit" nachher. Mit get_shooting wird die halt auf das kürzeste gehalten , ohne ein festes sleep.

Ja, verstehe. Dann ist in allen solchen Fällen aber anscheinend die Verwendung von "shoot" das Einfachste, weil hier das Script in jedem Fall erst dann weiter läuft, wenn die Kamera auch mit dem Bild fertig ist. Keinerlei sleep nötig.

Das da nicht die gleichen Werte rauskommen hatte ich bei meinem Kurztest auch schon festgestellt. Habe jetzt mal Dein Script durchlaufen lassen. 4/10 ist die größte Abweichung.

Ich hatte mich in meinem vorherigen Post verschrieben. Das erste Bild ist immer schneller da, nicht langsamer. Bei meiner Kamera können die Abweichungen aber leicht größer sein als 4/10, wie ich schrieb. Bei Bel.-Zeiten von 8 sec waren es schon ca. 8/10. Macht bei einer langen Intervallaufnahme schon einiges aus.

Damit musst Du leben.

Ist klar, dass es schlimmeres gibt im Leben

Formatier mal Deine SD-Karte...

Kann ich mal versuchen. Kann aber den systematischen Effekt sicher nicht erklären.

Grüße
Uwe

[gehtnix]

Hi BigDaddy,

hier habe ich noch einen Link für Dich, http://doug.kerr.home.att.net/pumpkin/APEX.pdf. Vielleicht kommst Du damit weiter. Ich hatte da mal einen Anlauf mit den Blendenwerte genommen.

Wenn ich das mal habe, kann ich es ja posten, falls Interesse besteht.

Klar doch, posten. Mir ist aber noch nicht klar wieso das soooo genau sein muss. Solange die Intervallzeit größer als diese Gesamtzeit ist kommt das eh nicht zum Vorscheinen.

Kann aber den systematischen Effekt sicher nicht erklären.

Wenn wir mal Voraussetzen dass die Kamera samt CHDK zeitlich korrekt arbeitet dann wäre doch nur noch der Speicherprozess auf der Karte übrig der Sperenzchen machen könnte. Wie man es aber auch dreht und wendet, das kann man nicht beeinflussen.

Mit print_screen habe ich vorhin das Log mitlaufen lassen, 4x 50 Bilder. Die einzigste Systematik die in Excel erscheint ist .... Chaos.

gruß gehtnix

[gehtnix]

Hi BigDaddy,

hier noch zwei Merkwürdigkeiten mit denen man leben muss.

Beitrag 1
td will so schnell wie möglich knipsen. Weiter unten komme ich dann zu folgender Aussage: "Doch, mit Sleep 1000 bekommst Du einen Intervall von 1,030 Sek". Würde also Kamera und CHDK akkurat zusammen arbeiten könnte so ein Intervall mit 1/250 Belichtung gar nicht zustande kommen. Das kannst Du ja mit Deiner A620 mal nachvollziehen.

Beitrag 2
Da macht get_shooting auch nicht das was es soll.

Manchmal ist es doch einfacher von hinten durchs Auge zu gehen

gruß gehtnix

[BigDaddy]

Hi gehtnix,

Klar doch, posten.

Jetzt habe ich sogar den Code für diese Berechnung ausgetüftelt, und woran scheitere ich? Am "nested if"-Bug! Arrrghh! Da mach' ich nachher gleich nen extra Thread auf.

Mir ist aber noch nicht klar wieso das soooo genau sein muss.

Jaja, ich geb's ja zu, da geht's mir ein wenig ums Prinzip. Ich hab's mir jetzt einfach in den Kopf gesetzt und will sehen, wie weit ich damit komme.

Mit print_screen habe ich vorhin das Log mitlaufen lassen, 4x 50 Bilder. Die einzigste Systematik die in Excel erscheint ist .... Chaos.

Also ich hab' jetzt nochmal genau dasselbe gemacht und krieg nun das selbe Ergebnis wie du: total zufällige Schwankungen um ca. 200 bis 300 ms, unabhängig von Bel.-Zeit, und auch nicht mehr dieses eindeutige Muster, was ich gestern hatte (gestern war das erste immer kürzer und alle nachfolgenden dann ziemlich konstant länger).

Was soll's, du hast recht, beeinflussen kann man's eh nicht. Genauer geht's dann halt wohl nicht.

Grüße
BigDaddy

[BigDaddy]

Hi gehtnix,

sorry, ich hatte jetzt keine Zeit, deinen "Beitrag 1" zu lesen, hole ich später mal nach.

Aber diesen Thread hier:

Beitrag 2
Da macht get_shooting auch nicht das was es soll.

den kannte ich schon.

Und da kann ich eben überhaupt nicht nachvollziehen, was da Kompliziertes gesprochen wurde. Ich hatte es so verstanden, dass der OP sicherstellen wollte, dass sein Script sich nicht "verschluckt", wenn er lange Bel.-Zeiten benutzt. Da wurde dann geraten, auf get_shooting zu warten, sleep ausreichend lange zu machen usw. usf. Der Witz ist aber, dass "shoot" (wohl im Gegensatz zu "press_full shoot") das alles automatisch macht sozusagen.

Irgendwie habe ich noch immer den Eindruck, dass der Punkt noch nicht so richtig rübergekommen ist. (Oder doch?) Also nochmal: ich benutze ausschließlich "shoot", keinerlei "Warten", keinerlei sleep, und es funktioniert alles perfekt. Auch bei sehr langen Bel.Zeiten (getestet bis 30 s). Und ohne Bilder beim Abspeichern zu unterschlagen oder dergl.

Also in diesem Fall scheint mir die allereinfachste Lösung die mit Abstand beste. (Es sei denn, ich übersehe ständig irgendwas. Reden wir aneinander vorbei?)

Grüße
BigDaddy

[gehtnix]

Hi BigDaddy,

die Links zu den Beiträgen sollten Dir nur zeigen das CHDK manchmal ein unbekanntes Eigenleben entwickelt.

Mit Deinem alleinigen shoot ist alles gut.

den kannte ich schon.

Das war aber kein Witz was ich da schrieb

get_shooting wird in dem Beispiel 2 ignoriert, arbeitet zumindest da nicht zuverlässig.
Und Beispiel 1, mit einem sleep von 1000 und einer Belichtungszeitvon 1/250 (Summe=1,250) bekommt man einen Bild-Intervall von 1,030 Sekunden hin. Da wird irgendwas gnadenlos unterschlagen. Aber wenn´s geht, warum nicht.

Jetzt alles klar?

Das mit If hast Du ja auch schon entdeckt.

Mit case könntest Du das if eventuell lösen, notfalls dann mit gosub wenn es mehr als nur der print-Befehl ist.

Hier noch ein Link mit uBasic Anleitung
http://chdk.setepontos.com/index.php/topic,3783.0.html

gruß gehtnix

[BigDaddy]

Hi gehtnix,

die Links zu den Beiträgen sollten Dir nur zeigen das CHDK manchmal ein unbekanntes Eigenleben entwickelt.

OK, ich verstehe jetzt, was du sagen wolltest.

Mit Deinem alleinigen shoot ist alles gut.

Gut!

Hier noch ein Link mit uBasic Anleitung

Danke, dieser Draft 0.4 war schon vor ein paar Tagen meine Bettlektüre.

Grüße
BigDaddy