[uBasic] HYPer-Blitz Skript - Update IV

CHDK-Skripte, CHDK-Entwicklung, PC-Zusatzprogramme, Informationen für Tüftler

HYPer-Blitz Skript - Update IV

Beitragvon gehtnix » 17.08.2009, 18:07

Ein Hallo an die Freunde des Hyperfokalen Fokus,

Update 17.07.2010
- Skript aktualisiert
- Änderungen

Update 01.05.2010
- Skript an den neuen DOF-Rechner angepasst.
- Skript sollte jetzt auch für die IXUS passen

Update 03.11.2009
- Ein paar Feinheiten an CHDK-DE angepasst.

Update 28.08.2009
- Das Skript wurde verfeinert und aktualisiert. Die Details dazu findet ihr hier.

ich habe das MD-Fast-Skript von chiptune mit dem Hyperfocalen aus HDR-Hyper zusammengeschmissen.

Bei dem letzten Gewitter hier in München ging mir Alles zu langsam. Die Vorbereitung der Kamera und dann kamen Meldungen mit denen ich nun gar nicht gerechnet habe, Blitz abschalten z.B., wobei ich doch einen Blitz aufnehmen wollte. :roll:
Da kam mir der Gedanke das Skript so abzuändern dass so einiges in den Meldungen/Hinweise deutlicher werden sollte, wenn möglich sollten die Funktionen automatisch abgestellt werden (Blitz), oder schon Tasten voraktiviert werden, aber auch sollte meine A610 schneller auf den Standpunkt der Kamera eingestellt sein. Da ich nur einen Position habe wo ich die Kamera bei einem Gewitter Gefahrenlos aufstellen kann, sollte der Zoom automatisch auf "Die Position", die zuvor mal ermittelt wurde, einfahren. Auch, und das bietet sich doch an, sollte der Hyperfocale Fokus gesetzt sein.

MD-Fast habe ich ein wenig abgeändert damit es noch schneller ist. Das Auslösen habe ich mit einem einfachen shoot ersetzt, soll ja nach Handbuch der schnellste Weg zu einem Foto sein. Die "500" im MD-String habe ich mit "25" ersetzt, dadurch steht MD schneller in Bereitschaft.

Die Reihenfolge der Parameter habe ich geändert. Die Wichtigen sind zum schnellen Zugriff sichtbar und stehen ganz oben.

@param w 0=Aufnahme,1=Autoschwellwert
@default w 1
Mit 0=Aufnahme geht es sofort zum Bild, mit 1 bleibt es bei der genialen Schwellwertermittlung von chiptune.

@param t Session ja=1 nein=0
@default t 1
Aktiviert die Laufzeit der Session die unter "@param v Dauer Minuten" eingestellt wurde. Danach schaltet die Kamera ab. Mit 0 = "open End" oder mit einem längeren beherztem Druck auf den Auslöser geordnet Abbrechen.

@param s Starte mit Zoom
@default s 2
Hier stellt man die Brennweite auf "seinen" Standort ein. Damit kann man dann links und rechts die nahstenden Häuser/Bäume ausblenden. Mit 0 bleibt alles so wie bisher. Dennoch kann man wie im HDR-Hyper auch, auf jede andere Stelle, mit Nachführung vom Hyperfocalen Fokus, zoomen. Die Tasten für die Schnellverstellung der Brennweite sind wie beim HDR-Hyper belegt.

@param f Schwellwert 0-255
@default f 2
Der CHDK-MD-Viel-Blitzer stellt fest dass der Autoschwellwert bei seiner Kamera z.B. immer bei 2 oder 3 liegt. Das kann er hier dann vorgeben und mit 0=Aufnahme spart er sich dann die Schwellwertermittlung.

In der Warteposition kann man wie gewohnt mit einem "Click Unten", RAW EIN/AUS-schalten.

Mit halber Druck geht es in die MD-Session.

Vorzugsweise im AV oder M Modus.

Wie schon gehabt, das Skript ist für die Reihe A610-650. Die anderen Nutzer müssen unten halt von ihren Kamera spezifischen Daten rüberkopieren. Achten auf die Hinweise im Skript, das müssen 2 Parameter in dem kopierten Teil gelöscht werden (b=1 und b=2).

Vielleicht reicht es ja für Mitteldeutschland zum Testen, da knatterte es gerade zur Zeit recht heftig.

Und bitte aus jeder Lage heraus diese Skript starten, die erscheinenden Meldungen sollten dann KLAR ergeben was zu tun ist! Also Serienbilder aktivieren, die wollen wir beim Blitz bestimmt nicht haben, das sollte abgefangen werden.

Gut Blitz und immer schön Abstand halten ;)

gruß gehtnix
Dateianhänge
HYPer-Blitz.bas
Nur mit CHDK-De lauffähig
(5.71 KiB) 2559-mal heruntergeladen
Zuletzt geändert von gehtnix am 18.07.2010, 00:50, insgesamt 12-mal geändert.
Benutzeravatar
gehtnix
CHDK-Legende
CHDK-Legende
 
Beiträge: 2406
Bilder: 8
Registriert: 17.04.2008, 12:42
Wohnort: München
Kamera(s): A610 100e+f + IXUS990 IS

Beitragvon gehtnix » 20.08.2009, 22:08

@msl,

Du hast ja im Handbuch etliches beschrieben und erklärt.

Mir stellt sich die Frage wie es sich mit den Zellen verhält?
Hier mal Deine Grafik aus dem Handbuch ein wenig verändert, wenn auch nicht perfekt.
Bild
Ich habe den oberen Bereich (versucht..Hitze) als eine Zelle darzustellen.

Was auffällt, die Zellenstöße im unteren Bereich, die Hot-Pixel verdoppeln sich in der waagerechten, in der vertikalen entstehen "Löcher". Das wird man vernachlässigen können.

Wie verhält es sich aber mit der Reaktionszeit obiger großen Zelle zu den unteren drei Zellen? Welche Muster löst schneller aus?

Vergleichsparameter e
Alle 30ms ein neues Bild ist soweit klar. Mit den 10ms (e Vergleichsparameter) wird, soweit ich es verstanden habe, festgelegt nach wieviel ms die Checksumme der Zelle gebildet wird. Nach der ersten Auswertung braucht es dann aber doch immer 30 ms bis zur nächsten Auswertung? Anders ausgedrückt, Bild wird aufgenommen, 10ms Ruhe, Auswertung (die Zeit dazu vergessen wir mal jetzt), 20ms Ruhe. Nächstes Bild, die selbe Prozedur, also alle 30ms Beginn der Auswertung.
Da würde ich doch für den Blitz e=10ms auf e=1 setzen, da bin ich doch (schreibe ich jetzt mit Vorsicht) näher am Geschehen.
Kommt der Blitz jetzt nach der 1ms, haben wir halt Pech gehabt, ist halt so, bzw. könnte ich Glück haben und den noch nach 29ms auswerten und aufnehmen uns später sehen was davon noch da ist.
Der Unterschied besteht also ...... ja wo ist der eigentliche Unterschied? Der Blitz kommt ja bestimmt nicht bei 0ms, (höchsten bei Akira2007 ;) )

Pixelschrittweite o
Je kleiner der Wert, desto mehr rote Pixel in der Grafik, desto detaillierter wird Bewegung erkennt CHDK. Dauert aber dadurch das Erstellen der Checksumme bedeutend länger? Ich nehme an es ist unerheblich wo die Bewegung erkannt wird, CHDK stellt nur einen Unterschied der Checksumme fest und löst aus. Bricht CHDK die Auswertung weiterer Zellen ab wenn bereits in der ersten Zelle Checksummenunterschiede festgestellt wurden? Eine weiter Auswertung wäre ja Überflüssig.

Im Handbuch:
"Interessant ist jedoch, dass die Kamera für das Live-Vorschaubild 720 Punkte in der
X-Richtung und 240 Punkte für die Y-Richtung anbietet. Die meisten LCD-Displays
der Kameras zeigen jedoch nur die Hälfte der in X-Richtung zur Verfügung
stehenden Bildpunkte an."
Wie ist das, "meisten LCD-Displays der Kameras zeigen jedoch nur die Hälfte", zu verstehen? Meinst Du damit unsere Canon´s? Wenn ja welche zeigen dann die vollen 720 an?

habe fertig Bild

gruß gehtnix
Benutzeravatar
gehtnix
CHDK-Legende
CHDK-Legende
 
Beiträge: 2406
Bilder: 8
Registriert: 17.04.2008, 12:42
Wohnort: München
Kamera(s): A610 100e+f + IXUS990 IS

Beitragvon msl » 20.08.2009, 22:39

Darf ich die Frage(n) mal weiterleiten. Bild

Den Artikel inkl. Grafiken hat CHDKLover erstellt. Er kann das bestimmt besser erklären, weil er sich auch mit dem Quellcode auseinandergesetzt hat.

Gruß msl
Benutzeravatar
msl
Super-Mod
Super-Mod
 
Beiträge: 4567
Bilder: 271
Registriert: 22.02.2008, 11:47
Wohnort: Leipzig
Kamera(s): A720 1.00c
SX220 1.01a

Beitragvon CHDKLover » 20.08.2009, 23:19

Hallo gehtnix,

Zur Übersicht für die folgenden Beiträge:
MD = Motion Detection = Bewegungserkennung
Code: Alles auswählen
h = md_detect_motion a, b, c, d, e, f, g, (h), i, j, k, l, m, n, o, p

a Anzahl Spalten zur Zellaufteilung
b Anzahl Zeilen zur Zellaufteilung
c Messmethode für die Auswertung der Bewegungserkennung
d Zeitbeschränkung (Timeout)
e Intervall in ms
f Schwellwert (Empfindlichkeit)
g Zellenanzeige
h Anzahl der Zellen, in der eine Bewegung erkannt wurde
i Maskierungsart
j Maske linke Spalte
k Maske obere Zeile
l Maske rechte Spalte
m Maske untere Zeile
n Parameter für spezielle Funktionalität
o Schrittweite Pixel
p Startverzögerung in ms

Quellcodeauszüge dienen als Beleg.

wenn ich deine Zeichnung richtig interpretiert habe, fängst du in jeder "clipping_region" neu an mit setzen der roten Punkte. Das ist meines Wissens nicht so. Du musst dir vorstellen das Live-View Bild was zur Bestimmung herangezogen wird ist ein hintereinanderliegender Speicherbereich. Das heißt um auf die n. Zeile und das m. Pixel in der Zeile eines Bildes zu kommen musst du die Startadresse+Bildbreite*n+m rechnen. Genau so macht es das CHDK:
Syntax: [ Download ] [ Verstecken ]
Benutze C Syntax Highlighting
    vp_h=vid_get_viewport_height();

    vp_w=vid_get_viewport_width();



    x_step=vp_w/motion_detector->columns;

    y_step=vp_h/motion_detector->rows;



            for(x=col*x_step;x<(col+1)*x_step;x+=motion_detector->pixels_step){

                for(y=row*y_step;y<(row+1)*y_step;y+=motion_detector->pixels_step){

                    int cy,cv,cu;



                    cy=img[ (y*vp_w+x)*3 + 1];

 
Erstellt in 0.004 Sekunden, mit GeSHi 1.0.8.9
Die *3 hängt mit den RGB Triebeln zusammen und die +1 ist eine Korrektur.

Um so kleiner du den Parameter e wählst um so schneller kommst du an den Live-View refresh Zyklus ran. (Ich hatte mir mal überlegt man könnte am Anfang anhand einer Markierung im Live-View die Sache synchronisieren. Aber das ist noch Zukunftsmusik.) Also wenn es die Kamera schafft würde ich bei Blitzen e so weit es geht herabsetzen.
gehtnix hat geschrieben:Bricht CHDK die Auswertung weiterer Zellen ab wenn bereits in der ersten Zelle Checksummenunterschiede festgestellt wurden? Eine weiter Auswertung wäre ja Überflüssig.

Nein, soweit ich weiß werden alle Unterschiede im Bild berechnet und die Anzahl über h zurückgeben.
quote hat geschrieben:Wie ist das, "meisten LCD-Displays der Kameras zeigen jedoch nur die Hälfte", zu verstehen? Meinst Du damit unsere Canon´s? Wenn ja welche zeigen dann die vollen 720 an?
Zur Zeit keine, aber das kann sich ja ändern.

Ich weiß, ich bin jetzt nicht im Detail auf alle Fragen eingegangen, aber vielleicht hilft es deinem Verständnis trotzdem weiter. Bei Fragen einfach noch mal nachharken.

CHDKLover
Zuletzt geändert von CHDKLover am 23.08.2009, 11:10, insgesamt 5-mal geändert.
A610 100e CHDK-DE: aktuelle Version
Benutzeravatar
CHDKLover
Super-Mod
Super-Mod
 
Beiträge: 878
Bilder: 8
Registriert: 12.09.2007, 18:25
Wohnort: Dresden
Kamera(s): a610 100e

Beitragvon gehtnix » 21.08.2009, 03:09

Hallo CHDKLover,

jetzt habe ich mich schon gefragt wo ich die große Harke herbekomme, aber sie muß gar nicht so groß sein.

Um es mal simpel darzustellen, wir haben diese 720x240 Pixel auf dem TFT. Mit o=5 lege ich fest, jedes 5. Pixel über den obigen Bereich wird bei der Checksumme berücksichtigt. Mit den Masken lege ich nur fest welcher Bereich, und damit welche Pixel, bei der Checksummenprüfung nicht berücksichtigt werden.
Richtig?

Damit fällt die Anhäufung der roten Pixel (Zeichnung) weg.

Dann bleibt die Auswertgeschwindigkeit gleich bei
- 1 Spalte x 1 Zeile
- 3 Spalten 3 Zeilen
- 4 Spalten x 6 Zeilen

Richtig?

"e" auf klein setzen, ist soweit klar, unterstützt meinen Gedanken.

CHDKLover hat geschrieben:Nein, soweit ich weiß werden alle Unterschiede im Bild berechnet und die Anzahl über h zurückgeben.
Ausgewertet werden immer alle Pixel, OK. h muss bei bei 1x1 oder 6x4 die gleiche Pixelanzahl zurückliefern. Jedoch bei Masken dürfen doch die "tauben" Pixel nicht mit ausgegeben werden.
Richtig?

Also gibt es mit wenig oder viel Zellen oder Masken kein Vor- oder Nachteil in der Auslöse-Geschwindigkeit.
Richtig?

Ob o auf 2 oder 10 gesetzt wird beeinflusst nur die Feinheit des Auswertbereiches. Zeitlich in der Auswertung zu Vernachlässigen.
Richtig?

Also kann man für Gewitterblitze 1 Spalte x 1 Zeile hernehmen.

Blinkende ADAC-Schilder oder Autos die auf den Straßen fahren werden dann, so wie es chiptune gemacht hat, mit 3 Spalten davon 1 inaktiv, ausgeblendet.

Oder ich belasse das bei 1x1 und mache die Autoschwellwertmittlung die mir dann z.B. f=25 liefert. Dann kann ich aber Pech haben und ADAC blinkt gerade nicht und der Blitz kommt in dieser Zeit und jetzt habe ich nur h=20, besser also doch den ADAC-Bereich maskieren.

gruß gehtnix
Benutzeravatar
gehtnix
CHDK-Legende
CHDK-Legende
 
Beiträge: 2406
Bilder: 8
Registriert: 17.04.2008, 12:42
Wohnort: München
Kamera(s): A610 100e+f + IXUS990 IS

Beitragvon CHDKLover » 21.08.2009, 11:49

Hallo gehtnix,
gehtnix hat geschrieben:Um es mal simpel darzustellen, wir haben diese 720x240 Pixel auf dem TFT. Mit o=5 lege ich fest, jedes 5. Pixel über den obigen Bereich wird bei der Checksumme berücksichtigt. Mit den Masken lege ich nur fest welcher Bereich, und damit welche Pixel, bei der Checksummenprüfung nicht berücksichtigt werden.
Richtig?
Ja, so würde ich das auch sehen.

gehtnix hat geschrieben:Dann bleibt die Auswertgeschwindigkeit gleich bei
- 1 Spalte x 1 Zeile
- 3 Spalten 3 Zeilen
- 4 Spalten x 6 Zeilen
Richtig?
Nein gleich ist sie nicht, da ein gewisser Mehraufwand für eine zusätzliche for-Schleife nötig ist.
Syntax: [ Download ] [ Verstecken ]
Benutze C Syntax Highlighting
    for(row=0, col=0; row < motion_detector->rows ; ){
 
Erstellt in 0.002 Sekunden, mit GeSHi 1.0.8.9


gehtnix hat geschrieben:Ausgewertet werden immer alle Pixel, OK. h muss bei 1x1 oder 6x4 die gleiche Pixelanzahl zurückliefern. Jedoch bei Masken dürfen doch die "tauben" Pixel nicht mit ausgegeben werden.
Richtig?
Ich glaube nicht. H repräsentiert die Anzahl der Zellen bei den die Abweichung über der Empfindlichkeit lag. Also bei 1x1 kann H maximal 1 werden. Bei 6x4 kann es entsprechend mehr sein.

gehtnix hat geschrieben:Also gibt es mit wenig oder viel Zellen oder Masken kein Vor- oder Nachteil in der Auslöse-Geschwindigkeit.
Richtig?
Doch Masken und Zellen beeinflussen die Auslösegeschwindigkeit, da die "Checksummenbildung" nur durchgeführt wird wenn der "rote" Pixel im Auswertungsbereich (Von einer aktiven Zelle umschlossen) liegt.

gehtnix hat geschrieben:Ob o auf 2 oder 10 gesetzt wird beeinflusst nur die Feinheit des Auswertbereiches. Zeitlich in der Auswertung zu Vernachlässigen.
Richtig?
Nein, o beeinflusst gleich 2 häufig abzuarbeitende for-Schleifen siehe meinen letzten Post (motion_detector->pixels_step). Ist somit eine große Stellschraube im MD-Script.

gehtnix hat geschrieben:Also kann man für Gewitterblitze 1 Spalte x 1 Zeile hernehmen.
Ja könnte man, die Anzahl der Zellen sollten immer im Verhältnis zur Empfindlichkeit stehen. Es kommt darauf an ob du nur große Blitze erkennen willst oder auch kleine in der Ferne.

OK, ich hoffe deine Vorstellung wird immer klarer, CHDKLover
A610 100e CHDK-DE: aktuelle Version
Benutzeravatar
CHDKLover
Super-Mod
Super-Mod
 
Beiträge: 878
Bilder: 8
Registriert: 12.09.2007, 18:25
Wohnort: Dresden
Kamera(s): a610 100e

Beitragvon gehtnix » 22.08.2009, 03:29

Hallo CHDKLover,

so langsam nähern wir uns dem Kern. Mit der Zeit wird mir ja doch einiges klarer.

Vom dem C-Code verstehe ich aber nun mal garnix.

h ist Verstanden, bei 1x1 max h=1, 6x4 max h=24, zurückgeliefert wird ja nicht die Pixelanzahl sondern die Zellenanzahl.

Die Auswertezeiten (for-Schleife, Anzahl Zellen, Masken) sind doch so gering dass man sie in der Betrachtung vergessen kann. Oder gibt es signifikante Zeitunterschiede zwiscne 1x1 und 6x4 Zellen?

Kann der 30ms Zyklus von der Auswertezeit beeinflusst werden? Was ist wenn ich e=29 setze? msl schreibt dass bei e=100 keine Auswertung mehr vorgenommen wird. 31 könnten aber auch schon zum selben Ergebnis führen?

Was bringt mit eigentlich ein höherer e-Wert? Das Bild wurde doch bei 0 erfasst. Wird denn bei/bis e noch mal ein/mehrere Bild/er erfasst? Oder beginnt bei e "nur" der Auswerteprozess? Wenn e gleich die Häufigkeit wäre, würde der ja bei e=2 15 mal verglichen?

chdklover hat geschrieben:Ja könnte man, die Anzahl der Zellen sollten immer im Verhältnis zur Empfindlichkeit stehen. Es kommt darauf an ob du nur große Blitze erkennen willst oder auch kleine in der Ferne.
Das verstehe ich nicht. Was hat jetzt die Anzahl der Zellen mit der Empfindlichkeit zu tun? Sollte der Unterschied bei 1x1 oder 4x4 doch nur der h-Wert sein, die Anzahl der roten Pixel bleibt doch gleich. Die kleinen Blitze die ich da mal eingefangen habe, waren mit MD-Fast, bei Schwellwert 2, o=5, 1x3, die untere Zeile maskiert.

Ich habe mal eine detailliertere Grafik erstellt
Bild
Da haben wir 21 Pixel die ausgewertet werden. Bei 1x1 liefert mit h eine 1 zurück, bei 4x4 ohne Maske eine 3, und wenn ich rechts Oben (straffiert) ausblende dann muss h=2 ergeben.

Würde jetzt o=6 sein, so würde gar nichts erkannt weil der Blitz kein rotes Pixel trifft. Daher mein Gedanke der Feinheit.

Dann haben wir noch den Schwellwert. Bezieht sich der Wert auf jede einzelne Zelle oder die gesamte Fläche?

gruß gehtnix
Benutzeravatar
gehtnix
CHDK-Legende
CHDK-Legende
 
Beiträge: 2406
Bilder: 8
Registriert: 17.04.2008, 12:42
Wohnort: München
Kamera(s): A610 100e+f + IXUS990 IS

Beitragvon CHDKLover » 22.08.2009, 09:44

Hallo gehtnix,
gehtnix hat geschrieben:Die Auswertezeiten (for-Schleife, Anzahl Zellen, Masken) sind doch so gering dass man sie in der Betrachtung vergessen kann. Oder gibt es signifikante Zeitunterschiede zwiscne 1x1 und 6x4 Zellen?
Das kannst du nur Testen. Aber o (Schrittweite) ist wahrscheinlich recht ausschlaggebend, da sie Quadratisch den Auswertungsaufwand beeinflusst. Dagegen wird die Anzahl der Zellen und Masken eine untergeordnete Rolle spielen.

gehtnix hat geschrieben:Kann der 30ms Zyklus von der Auswertezeit beeinflusst werden?
Nein, die 30ms für die Live-View Synchronisation stehen fest. Aber es lässt sich beeinflussen wie zeitnah man nach einer Live-View Aktualisierung die Auswertung anschiebt. e>30 lohnt sich nur wenn 2 aufeinanderfolgende Live-View Bilder keinen nennenswerten unterschied zeigen.

gehtnix hat geschrieben:Wenn e gleich die Häufigkeit wäre, würde der ja bei e=2 15 mal verglichen?
Ja es würde 14 mal sinnlos ausgewertet, da sich das LV-Bild nicht verändert hat. Aber du erkennst die Bewegung nach maximal 30ms/15=2ms.

gehtnix hat geschrieben:Das verstehe ich nicht. Was hat jetzt die Anzahl der Zellen mit der Empfindlichkeit zu tun?
In jeder Zelle wird die Abweichung zum Vorherigen Bild ermittelt und durch die Anzahl der Messpunkte (rote Punkte) geteilt. Das heißt bei nur einer Zelle würde der Quotient recht gering ausfallen der dann gegen den Empfindlichkeitswert getestet wird. Hast du kleinere Zellen, dann ist das Verhältnis Veränderung zu Empfindlichkeit größer.

Ich weiß du tust dich schwer mit c code aber hier der Quellcodeausschnitt dafür:
Syntax: [ Download ] [ Verstecken ]
Benutze C Syntax Highlighting
            if(motion_detector->points[idx]>0){
                motion_detector->prev[idx] = (motion_detector->curr[idx]-motion_detector->prev[idx])/motion_detector->points[idx];
                tmp2 = ( motion_detector->prev[idx] < 0 ) ? -motion_detector->prev[idx] : motion_detector->prev[idx] ;
            }
   
            if( tmp2 > motion_detector->threshold ){
                if (motion_detector->start_time+motion_detector->msecs_before_trigger < tick){
                    motion_detector->detected_cells++;
                }
            }
 
Erstellt in 0.003 Sekunden, mit GeSHi 1.0.8.9


gehtnix hat geschrieben:Da haben wir 21 Pixel die ausgewertet werden. Bei 1x1 liefert mit h eine 1 zurück, bei 4x4 ohne Maske eine 3, und wenn ich rechts Oben (straffiert) ausblende dann muss h=2 ergeben.
Richtig

gehtnix hat geschrieben:Würde jetzt o=6 sein, so würde gar nichts erkannt weil der Blitz kein rotes Pixel trifft. Daher mein Gedanke der Feinheit.
Du musst aber auch bedenken, dass die Blize nicht nur ein Pixel breit sind. In der Regel wirst du breitere Blitze detektieren wollen.

gehtnix hat geschrieben:Dann haben wir noch den Schwellwert. Bezieht sich der Wert auf jede einzelne Zelle oder die gesamte Fläche?
Auf eine Zelle, siehe oben.

CHDKLover
A610 100e CHDK-DE: aktuelle Version
Benutzeravatar
CHDKLover
Super-Mod
Super-Mod
 
Beiträge: 878
Bilder: 8
Registriert: 12.09.2007, 18:25
Wohnort: Dresden
Kamera(s): a610 100e

Beitragvon gehtnix » 22.08.2009, 14:58

Hi CHDKLover,

CHDKLover hat geschrieben:Ich weiß du tust dich schwer mit c code aber hier der Quellcodeausschnitt dafür:
Nein, ich tue mich überhaupt nicht schwer. Ich versteh ihn glattweg nicht! Der Code enthält für mich, und für die anderen Mitleser keine verständliche Erklärung.

o wird Einfluss auf die Auswertezeit haben. Den muss ich aber eben hinnehmen wenn 0 klein gewählt ist.

CHDKLover hat geschrieben:Du musst aber auch bedenken, dass die Blize nicht nur ein Pixel breit sind.
Ein Bild sagt mehr als tausend Worte! Darum habe ich das so überdeutlich groß dargestellt? Aber ansonsten ist das Bild jetzt korrekt.

CHDKLover hat geschrieben:Live-View Synchronisation
Wo wir denn was synchronisiert? Alle 30ms wird ein Bild gespeichert und im Speicher Bild A mit Bild B verglichen. Wenn Differenzen in einer Zelle auftreten, wird ausgelöst.

e wird mir immer unverständlicher. Außer dass es klein sein sollte bei ereignissnaher Auslösung.

CHDKLover hat geschrieben:e>30 lohnt sich nur wenn 2 aufeinanderfolgende Live-View Bilder keinen nennenswerten unterschied zeigen.
Der Bild-Unterschied sollte doch durch h geliefert werden und nicht durch eine Zeit e.
e ist in meinen Auge inzwischen nutzlos für eine MD-Steuerung. Den könnte man fix auf 3ms einstellen und aus der Parameterliste nehmen.
Und immer daran denken ms, das können wir nix mehr messen! 100ms ein zehntel Sekunde.
Zumal wir nicht bestimmen können wann das Ereignis (Blitz) in die Zeitachse der 30ms eintritt.

CHDKLover hat geschrieben:In jeder Zelle wird die Abweichung zum Vorherigen Bild ermittelt und durch die Anzahl der Messpunkte (rote Punkte) geteilt. Das heißt bei nur einer Zelle würde der Quotient recht gering ausfallen der dann gegen den Empfindlichkeitswert getestet wird. Hast du kleinere Zellen, dann ist das Verhältnis Veränderung zu Empfindlichkeit größer.
Für das Beispielbild,
Bei 1x1 und den 3 getroffenen Pixel 3/21=0,14.
Bei 2x2 , Zelle links Oben 1/6=0,16 und für die Zelle darunter und rechts Oben heißt es dann 2x 1/5=0,2. Zelle rechts unten mit 0.
Addiere ich die 4 Zellen-Quotienten/4=0,14, das Gleiche wie bei einer Zelle.
Das leuchtet mir noch nicht ein. Bild

Aber, das haben wir noch nicht gewusst, dass pro Zelle ein Quotienten dem Empfindlichkeitswert (Schwellwert) gegenübergestellt wird. Da war meine bisherige Annahme falsch.
f ist aber doch immer eine ganze Zahl. Wie geht das jetzt mit z.B. den obigen 0,14 zusammen?

Löcherfragend versuche ich

geschmeidig zu bleiben

gruß gehtnix
Benutzeravatar
gehtnix
CHDK-Legende
CHDK-Legende
 
Beiträge: 2406
Bilder: 8
Registriert: 17.04.2008, 12:42
Wohnort: München
Kamera(s): A610 100e+f + IXUS990 IS

Beitragvon CHDKLover » 22.08.2009, 16:06

Hallo gehtnix,
auf in die nächste Runde und diesmal ohne eine Zeile Quellecode. ;)

gehtnix hat geschrieben:Ein Bild sagt mehr als tausend Worte! Darum habe ich das so überdeutlich groß dargestellt? Aber ansonsten ist das Bild jetzt korrekt.
Fast, den einzigen Fehler den ich jetzt sehe ist, dass in x-Richtung zwischen den Messpunkten immer o-1 ungenutzte Pixel liegen müssten. Das ist in den Übergängen z.B. von der 0. Zeile zur 5. Zeile nicht beachtet wurden. Du hättest den Messpunkt in der 5.Zeile 3 Pixel weiter rechts malen müssen. Siehe meine Zeichnung im Anhang.

gehtnix hat geschrieben:Wo wir denn was synchronisiert? Alle 30ms wird ein Bild gespeichert und im Speicher Bild A mit Bild B verglichen. Wenn Differenzen in einer Zelle auftreten, wird ausgelöst.
Canon berechnet/aktualisiert/synchronisiert aller 30ms ihr LV-Bild anhand aktueller Sensordaten und schreibt es in einen von der Canon Firmware verwalteten Puffer. Es wird kein Bild vom CHDK gespeichert. Die Bewegungserkennung holt sich bei jedem Erkennungslauf die benötigten Daten aus dem Puffer und speichert die Checksummen. Bei einem erneuten Erkennungslauf (e ms später) wird die neue Checksumme von der letzen Checksumme subtrahiert und durch die Anzahl der berücksichtigten Messpunkte geteilt.

gehtnix hat geschrieben:e wird mir immer unverständlicher. Außer dass es klein sein sollte bei ereignissnaher Auslösung.
Ja e (Intervallverzögerung) ist nicht leicht zu verstehen. Sie wird nur benötigt, da die Canon Firmware und das CHDK völlig eigenständig nebeneinander laufen und das CHDK kein Ereignis von Canon bekommt, wann das LV-Bild aktualisiert wurde. Somit muss das CHDK auf den LV-Puffer "pollen" (häufiges meist unnützes auslesen des Puffers).

gehtnix hat geschrieben:Der Bild-Unterschied sollte doch durch h geliefert werden und nicht durch eine Zeit e.
Sorry, da hab ich mich wahrscheinlich vorhin ungünstig ausgedrückt. Es gibt vielleicht Situationen in denen innerhalb von 30ms kaum größere Veränderungen (Farbveränderungen der Pixel) als das normale Bildrauschen auftreten. Um dennoch kleinste Veränderungen erkennen zu können (sehr langsames hereinbewegen in das Bild) darf nicht jedes LV-Bild ausgewertet werden sondern nur z.B. jedes 10. Dadurch ergeben sich größere unterschiede in 2 aufeinanderfolgende Auswertungen und die Bewegung kann erkannt werden. Um Blitze zu erkennen eher uninteressant.

gehtnix hat geschrieben:Bei 1x1 und den 3 getroffenen Pixel 3/21=0,14.
Bei 2x2 , Zelle links Oben 1/6=0,16 und für die Zelle darunter und rechts Oben heißt es dann 2x 1/5=0,2. Zelle rechts unten mit 0.
Addiere ich die 4 Zellen-Quotienten/4=0,14, das Gleiche wie bei einer Zelle.
Der Dividend ist nicht gleich der Anzahl der "getroffenen" Pixel, sondern er repräsentiert die Summe der Deltas der Farbwerte des zu überwachenden Farbkanals in einer Zell. (kein leicht zu verstehender Satz) Beispiel: ist der zu überwachende Farbkanal = Y (Helligkeitsintensität), dann kann ein Delta zwischen 0 und 219 liegen. (Weil der Werteberreich des Farbkanales Y: [16..235])
Das folgende Beispiel ist bezogen auf die Zeichnung:
Hast du jetzt nur eine Zelle und wir sagen, dass bei dem 1. getroffenen Punkt (oben) ein Delta von 200 ermittelt wird, bei dem 2.Punkt ein Delta von 150 und bei dem 3. Punkt ein Delta von 160, dann ergibt sich folgende Rechnung:
200+150+160=510
510/21=24,xxx
Ist deine Empfindlichkeit < 24 dann würde h eins liefern und die Veränderung erkannt werden.
Gleiche Ausgangssituation nur mit 2x2 Zellen:
1.Zelle: 200/6=33,xxx
2.Zelle: 150/5=30
3.Zelle: 160/5=32
4.Zelle: 0/5=0
Jetzt würde sogar eine Empfindlichkeit < 33 ausreichen.

gehtnix hat geschrieben:f ist aber doch immer eine ganze Zahl.
Ja reicht aus, die Nachkommastellen werden ignoriert.

CHDKLover
Dateianhänge
MD.zip
Microsoft Visio Zeichnung
(49.11 KiB) 547-mal heruntergeladen
MD.jpg
Schema: o=5; 2x2 Zellen
Zuletzt geändert von CHDKLover am 23.08.2009, 10:38, insgesamt 1-mal geändert.
A610 100e CHDK-DE: aktuelle Version
Benutzeravatar
CHDKLover
Super-Mod
Super-Mod
 
Beiträge: 878
Bilder: 8
Registriert: 12.09.2007, 18:25
Wohnort: Dresden
Kamera(s): a610 100e

Beitragvon gehtnix » 22.08.2009, 23:23

Hallo CHDKLover,

konnte ich doch vorhin schon die Ziellinie riechen. Ein Anruf, kannste nicht mal eben was für mich googeln. Tab zu, Ziellinie weg.

Auf ein Neues

CHDKLover hat geschrieben: Das ist in den Übergängen z.B. von der 0. Zeile zur 5. Zeile nicht beachtet wurden.
OK, verstanden, da wird stur weitergezählt. Wenn in der Zeile kein Platz mehr ist, geht in der nächsten Zeile damit weiter. Zeile 5 auf Zeile 10.

CHDKLover hat geschrieben:Canon berechnet/aktualisiert/synchronisiert aller 30ms ihr LV-Bild ….
Ahaa, Canon bestimmt diesen 30ms Rhythmus. Hätte ich auch selbst drauf kommen können. Da sehe ich aber zunächst mal nix von Synchronisation.
Jetzt liest CHDK alle e(ms) den Puffer aus und bildet eine Checksumme. Durch den anschließenden Vergleich zur alten Checksumme wird die Veränderung erkannt. Und je kleiner e, desto näher komme ich die neue Checksumme heran, desto besser stimmt die Synchronisation. MD ist also ständig bemüht dem 30ms Rhythmus der Canon hinterherzulaufen.
Also e=5 reicht allemal. (Blitz)

e könnte wohl auch Synchronisationsintervall heißen.

CHDKLover hat geschrieben:….darf nicht jedes LV-Bild ausgewertet werden sondern nur z.B. jedes 10. Dadurch ergeben sich größere unterschiede in 2 aufeinanderfolgende Auswertungen….
Das ist jetzt auch soweit verständlich, mit e=95 wird also nur die dritte Checksumme verglichen.
Damit fliegt mir aber die Synchronisation aus der Kurve! Gut, kann man dann bei einer Schnecke sicherlich vergessen. Nun wird der Synchronisationsintervall zu einer echten Verzögerung von mittlerweile 0,1 Sekunden.

Ist der Hintergrund bewegt und das eigentliche Motiv bewegt sich vom Fleck weg, dann bietet es sich doch an mit Masken zu arbeiten.

Der Dividend ist verstanden. Ebenso die Empfindlichkeit und Zellen.

Von f haben wir noch gar nicht gesprochen

Für den Blitz würde ich jetzt:

Die Zellen auf 2x3 stellen
e=5
Mit dem Autoschwell den geeigneten f-Wert ermitteln

Und jetzt brauchen wir nur noch einen Blitz

Gruß gehtnix
Benutzeravatar
gehtnix
CHDK-Legende
CHDK-Legende
 
Beiträge: 2406
Bilder: 8
Registriert: 17.04.2008, 12:42
Wohnort: München
Kamera(s): A610 100e+f + IXUS990 IS

Beitragvon CHDKLover » 23.08.2009, 10:20

Hallo gehtnix,
ich glaube die Ziellinie "tiefes MD-Verständnis" hast du bald erreicht.

gehtnix hat geschrieben:Das ist jetzt auch soweit verständlich, mit e=95 wird also nur die dritte Checksumme verglichen.
Fast richtig. Nicht jede dritte Checksumme sondern jedes dritte LV-Bild.

gehtnix hat geschrieben:Von f haben wir noch gar nicht gesprochen
Die Empfindlichkeit (f) bekommt man nur durch Probieren heraus oder mit dem Autoschwellwertermittler. Da sie auch von Kamera zu Kamera unterschiedlich und Situationsabhängig ist (Rauschverhalten andere Lichtverhältnisse, Grundbewegung im Bild).

CHDKLover
A610 100e CHDK-DE: aktuelle Version
Benutzeravatar
CHDKLover
Super-Mod
Super-Mod
 
Beiträge: 878
Bilder: 8
Registriert: 12.09.2007, 18:25
Wohnort: Dresden
Kamera(s): a610 100e

Beitragvon gehtnix » 23.08.2009, 13:32

Hallo CHDKLover,

jetzt glaube ich auch dass die Ziellinie in greifbarer Nähe gerückt ist. Du hast sie mir ja auch immer näher gerückt.

Dritte LV-Bild, na klar.

f, das war auch mehr rhetorisch gemeint.

Seit Tage suche ich eine Lösung wie man generell MD-Testen kann, ausprobieren was passiert wenn ich an der einen oder anderen Schraube drehe. Dazu brauche ich natürlich immer das gleiche Szenario. Insbesondere auf Blitze ist da absolut kein Verlass, die wiederholen sich nicht.
Was spricht dagegen Blitz-Bilder auf dem PC-Monitor (Fernseher) wieder mit MD einzufangen? Gilt natürlich für andere "Situationen", also Bilder auch.
Ich denke es wird kein (? - ich habe es noch nicht probiert.) allzu großer Unterschied sein
Und über Dein Viso-Bild ist es doch nur ein Gedanken-Schritt zu Powerpoint! Da kann man doch schnelle Bildwechsel gestalten, oder mit einem Fotoprogramm, 5 Sekunden schwarz dann wechseln auf Blitz-Bild. Das kann man ja auch mit simplen Grafiken machen, die können doch noch besser zum Verstehen präpariert werden (3 Sekunden ganz schwarz, wechsel auf schwarz mit gelben Strich-Blitz). Und wenn man sich jetzt so einen Bilderreihe festlegt, ist es ja möglich mit ein und derselben MD-Einstellung diese jetzt zu testen wann MD erkannt wird. Mangels Blitzen kann ich mir ja hier Fotos entleihen. Videos sollten auch gehen.
Man wird mehr Gefühl für MD und die Einstellungen und Parameter bekommen.

Ich habe mal eben ein vom Notebook einen Gewitterblitz abgelichtet und dann gegen das Original gestellt. Der Blitzstrahl ist fast gleich dick wie auf dem Original. Aber klar doch, es ist nicht so schön, Streifen vom Monitor sind sichtbar, die werden aber von MD dann in der Checksumme mit erfasst, sollte also keine Rolle spielen.

Bei dem Abbruchvideo, da gibt es eine Stelle wo erst einmal nicht passiert und dann kommt der Bagger hinter den Bäumen hervor, das ist geeignetes Übungsmaterial. Ständige Hintergrundbewegung und nun rechtzeitig den Bagger erwischen. Am eingefangenen MD-Bild sieht man wie lange es zur Auslösung gebraucht hat. Da mal e auf 300 stellen, da sieht das Bild gleich anders aus.

viel Spaß

gruß gehtnix
Benutzeravatar
gehtnix
CHDK-Legende
CHDK-Legende
 
Beiträge: 2406
Bilder: 8
Registriert: 17.04.2008, 12:42
Wohnort: München
Kamera(s): A610 100e+f + IXUS990 IS

Beitragvon gehtnix » 27.08.2009, 23:10

Ein Hallo an die Hyperfocalen unter uns,

den HYPer-Blitz habe ich nochmals verfeinert.

Wahlweise kann nun die Hintergrundbeleuchtung (c Backlight aus n. x Zykl.) abgestellt werden. Der LCD wird nach x MD-Zyklen abgeschaltet. Das kann jetzt durch ein MD-Ereignis geschehen oder aber wenn in dieser Zeit nicht passiert wird nach X x Timeout(120000=120 Sek. aus der MD-Zeile) der LCD automatisch abgeschaltet. Also im einen Fall nach 2 Bildern die hintereinander ausgelöst werden oder aber nach 4 Minuten.
Bis zum LCD-Abschalten wird eine Rückschau (r Reviewzeit Sek.) für das geschossnen Bild angezeigt. Danach wird mit dem schnelleren shoot-Befehl weiter gearbeitet. Die Rückschau wird mit r=0 abgeschaltet.

Wenn die Kamera sich im MD-Zyklus befindet reagiert sich nicht sofort auf einen Abbruch mit restore. Drückt man den Auslöser fest durch und bewegt die Kamera genügend, so wird ein Foto gemacht und das restore wird danach ausgeführt, das Script wird abgebrochen.

Nachdem das Script wegen der Optikdaten ohnehin auf den Kameratyp angepasst werden muss, habe ich diesen Parameter
@param h Circles of Confusion
@default h 6

nun hier fest eingestellt.

rem -------------------- Kameraspezifisch --------------------
rem In Zeile 313 (6*B) muss der Circles of Confusion (5 oder 6) an die Kamera angepasst werden
:hfrechner
E=(A/10*A/10)/(6*B)

Diese 6 muss also hier für die jeweilige Kamera abgeändert werden.

Meine A610 braucht vor dem set_backlight ein sleep von 3/100 Sekunden, sonst wird der LCD nicht abgeschaltet. Mit dem Parameter (d Sleep f. Backlight 1/100) kann jeder selbst ausprobieren ob es kürzer auch funktioniert. Bei der SX100 vom Hamster.78 geht es mit 50ms. Ich hab aber bei meiner A610 den Eindruck dass die Sleepzeit nicht ordentlich abgearbeitet wird. Stelle ich Sleep auf 7/100 geht das genau so schnell.

Parameter (e Vergleichsintervall ms) habe ich auf 6ms voreingestellt. Da reicht allemal.

Das Script ist oben aktualisiert.

gruß gehtnix
Zuletzt geändert von gehtnix am 24.11.2009, 02:35, insgesamt 1-mal geändert.
Benutzeravatar
gehtnix
CHDK-Legende
CHDK-Legende
 
Beiträge: 2406
Bilder: 8
Registriert: 17.04.2008, 12:42
Wohnort: München
Kamera(s): A610 100e+f + IXUS990 IS

Beitragvon Hamster.78 » 29.08.2009, 14:10

Hallo gehtnix,

Spezialist des Hyperfocalen Focus und jetzt auch der Bewegungserkennung Bild

Hast ja MD_Fast von Chiptune um einige Funktionen erweitert und holst mit der Bewegungserkennung das maximal mögliche aus der Canon raus.

Wer seine Kamera hier wiederfindet oder die benötigten Kamera-spezifischen Daten liefert, den könnte ich auch behilflich sein, in den Genuss des hyperfocalen Focus zu kommen.

Danke Dir gehtnix für den unermüdlichen Einsatz
gruß Hamster Bild
◄ SX100 v100c ◄ Samsung NX10

CHDK DEThe Canon Camera Hackers Manual schon gelesen?
Benutzeravatar
Hamster.78
CHDK-Begeisterter
CHDK-Begeisterter
 
Beiträge: 318
Registriert: 24.01.2009, 11:21
Wohnort: Sachsen / Chemnitz

Nächste

Zurück zu Code-Ecke

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 9 Gäste

cron