Sonnenauf- & Untergang, Blaue Stunde - Berechnungen

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

Sonnenauf- & Untergang, Blaue Stunde - Berechnungen

Beitragvon msl » 24.11.2012, 13:47

Hallo CHDK-Rechenkünstler, :D

durch die Grundlagenarbeit von rudi können wir nun auch mit CHDK Winkelberechnungen durchführen. Damit der Grundlagen-Thread nicht zu sehr mit Anwender-Fragen vermischt wird, hat mich rudi gebeten, zu solchen Anwendungen ein neues Thema zu eröffnen.

Für den Fotografen ist die Blaue Stunde ein sehr interessante Tageszeit, weil da besonders interessante Lichtverhältnisse herrschen. Sicherlich wird auch schon jeder, der mal ein CHDK-Zeitrafferprojekt starten wollte, über Sonnenauf- und Untergang nachgedacht haben.

Warum sollen wir da nicht die technischen Möglichkeiten nutzen, die uns CHDK bietet. Per Skript lässt sich so einiges berechnen. Durch die Bereitstellung von Winkelfunktionen können wir astronomische Berechnungen durchführen.

Zur Berechnung von Sonnenauf- und Untergangszeiten scheint folgende Seite eine Art Referenz zu sein, wenn es um die Vereinfachung der Formeln geht: http://lexikon.astronomie.info/zeitgleichung/

Wer also Ideen oder Fragen zu dieser Thematik hat, sollte diese hier posten.

Gruß msl
■ "Hey you, don't tell me there's no hope at all. Together we stand, divided we fall."CHDK inside FAQCHDK-Neuigkeiten auf Twitter
Benutzeravatar
msl
Super-Mod
Super-Mod
 
Beiträge: 4512
Bilder: 271
Registriert: 22.02.2008, 12:47
Wohnort: Leipzig
Kamera(s): A720 1.00c
SX220 1.01a

Re: Sonnenauf- & Untergang, Blaue Stunde - Berechnungen

Beitragvon Sinter » 26.11.2012, 18:41

Hallo Msl,

es wäre schön, wenn sich neben den Uhrzeitangaben zusätzlich auch ein Maß für die aktuelle „Intensität“ bzw. Resthelligkeit (unter Annahme eines wolkenfreien Himmels?) der Blauen Stunde anzeigen lässt, denn je nach Jahreszeit schreitet die Intensität/Helligkeit der Dämmerung schneller oder langsamer voran. Die Sonne taucht im Winter wesentlich flacher in den Horizont ein als im Sommer. Somit würde es Sinn machen, nicht ausschließlich Sonnenaufgang und Sonnenuntergang zu berechnen, sondern ebenfalls den Dämmerungsverlauf, bzw. den Verlauf der Sonne unterhalb des Horizonts.

Evtl. als „Intensitätsmaß“ den Winkel der Sonne gegenüber dem Horizont berechnen und anzeigen.

Oder aber wir orientieren uns an „bürgerlicher Dämmerung“ h= -6°, „nautischer Dämmerung“ h = -12° und „astronomischer Dämmerung“ h = -18°, wie in der Internetbeschreibung der Näherungsrechnung erwähnt.
Aber wie rechnet man mit diesen Dämmerungen? Die Frage ist, in welchem Größenmaß wir den Sachverhalt am sinnvollsten darstellen. In Prozent, oder vielleicht doch lieber das absolute Winkelmaß unterhalb des Horizonts. Und bedeutet h= -6° dass dann 100% der bürgerlichen Dämmerungshelligkeit bereits erreicht sind, oder beginnt die bürgerliche Dämmerung bei h= -6° und endet bei h= -0°?
Wir könnten vielleicht einblenden, wie viel Prozent der jeweiligen drei Versionen der Dämmerungsintensität fortgeschritten sind:
Oder aber wir blenden nur ein, in welcher Dämmerungsphase man sich befindet?


Als Gedanke, evtl. macht es Sinn, stets die Intensitäten der drei Dämmerungsdefinitionen anzuzeigen (mit ~ 0%=“dunkel gemäß jeweiliger Dämmerungsdefinition“, 100%=“hell“=Sonne am Horizont):

Vielleicht falls die Sonne gerade 12° unter dem Horizont steht:
Morgens vor Sonnenaufgang:

BLAUE STUNDE endet in xy Minuten (denn die Berechnung der Differenz der aktuellen Uhrzeit bis zum Sonnenaufgang muss uns die Cam abnehmen)
Sonne unter Horizont: -12°
Bürgerliche Dämmerung: beginnt in xx Minuten
Nautische Dämmerung: 0% (= sie beginnt gerade)
Astronomische Dämmerung: 33% (= „Die Astronomische Dämmerung ist aktuell in bereits 33-prozentiger Intensität erreicht)


Abends nach Sonnenuntergang:

BLAUE STUNDE begann vor yz Minuten
Sonne unter Horizont: -12°
Bürgerliche Dämmerung: -- (= bürgerliche Dämmerung ist bereits überschritten)
Nautische Dämmerung: 0% (= nautische Dämmerung ist sozusagen abgeschlossen)
Astronomische Dämmerung: 33%; endet in zy Minuten (= derzeit nur noch 33-prozentige Intensität)


Und tagsüber:
BLAUE STUNDE beginnt in x Stunden y Minuten
Sonne über Horizont: xyz°


Weiterer Gedanke: Gibt es in der Astronomie vielleicht auch noch ein Maß für die Sichtbarkeit/Erkennbarkeit von Sternen/Mond/Planeten, ab welcher Dunkelheit sie sich gegenüber dem Himmel abzeichnen? Dann könnte man auch dies noch einpflegen.


(Ein weiteres Feature wäre die Berechnung, bis auf welche Höhe die Sonne aktuell noch scheint, also in welcher Höhe aktuell noch immer Wolken/Flugzeuge/Berge angestrahlt werden, obwohl unten auf dem Boden die Sonne bereits untergegangen ist. Dieses Feature könnte sich aber angesichts seiner enormen Zeitsensibilität und der Näherungsgleichung als nicht hinreichend präzise erweisen.)

Viele Grüße,
Sinter
Ixus 60 (SD600) Firmware 1.00a
CHDK-DE aktuelle Version
Benutzeravatar
Sinter
CHDK-Begeisterter
CHDK-Begeisterter
 
Beiträge: 416
Bilder: 2
Registriert: 14.08.2009, 14:16
Wohnort: München

Re: Sonnenauf- & Untergang, Blaue Stunde - Berechnungen

Beitragvon msl » 27.11.2012, 00:37

Hallo Sinter,

deine Gedanken sind interessant und richtig. Du kannst dir hier einen tabellarischen Überblick verschaffen, wie die unterschiedlichen Zeiten in Verbindung stehen. Wenn man mit dem Mauszeiger auf die Tabellenüberschriften geht, erhält man weiterführende Informationen zur bedeutung der einzelnen Spalten.

Das alles gehört zum 2. und 3. Schritt. Als erstes muss aber die mathematische Umsetzung geklärt werden. Es ist nicht so einfach, mit Ganzzahlen, limitiert +/- 2147483647, und emulierten Winkelfunktionen, die mit Grad rechnen, Formeln umzusetzen, die mit Bogenmaß und mit Dezimalzahlen, die 5 Stellen hinter dem Komma haben, daherkommen. Wenn das geklärt ist, haben wir alle Möglichkeiten.

Gruß msl
■ "Hey you, don't tell me there's no hope at all. Together we stand, divided we fall."CHDK inside FAQCHDK-Neuigkeiten auf Twitter
Benutzeravatar
msl
Super-Mod
Super-Mod
 
Beiträge: 4512
Bilder: 271
Registriert: 22.02.2008, 12:47
Wohnort: Leipzig
Kamera(s): A720 1.00c
SX220 1.01a

Re: Sonnenauf- & Untergang, Blaue Stunde - Berechnungen

Beitragvon rudi » 28.11.2012, 22:09

Hallo zusammen,

neues von der cordicLib (Version: 0.3) gibt es hier.

Gruß rudi
Benutzeravatar
rudi
CHDK-Spezialist
CHDK-Spezialist
 
Beiträge: 500
Registriert: 11.09.2009, 12:27
Kamera(s): A590IS_101B, SX260_100B

Re: Sonnenauf- & Untergang, Blaue Stunde - Berechnungen

Beitragvon rudi » 30.11.2012, 13:32

Hallo zusammen,
cordicLib ist aktuell die Version 0.4.

msl hat geschrieben:Es ist nicht so einfach, mit Ganzzahlen, limitiert +/- 2147483647, und emulierten Winkelfunktionen, ... die 5 Stellen hinter dem Komma haben ... .
Wenn man alle Berechnungen als Bruchrechnung auslegt sollte das eine ganze Menge bringen. Ich stelle mir vor, die Grundrechenarten in einer Bibliothek zusammenzufassen und die Werte als Gemischte Brüche (evtl. als Mantisse mit zusätzlichem Exponent) in einer Tabelle je Wert zu übergeben.
Da auch Werte der Kamera als erweiterte Nachkommawerte übergeben werden, sollte dort Bruchrechnung für LUA ebenfalls sinnvoll sein.

Gruß rudi
Benutzeravatar
rudi
CHDK-Spezialist
CHDK-Spezialist
 
Beiträge: 500
Registriert: 11.09.2009, 12:27
Kamera(s): A590IS_101B, SX260_100B

Re: Sonnenauf- & Untergang, Blaue Stunde - Berechnungen

Beitragvon Sinter » 30.11.2012, 15:21

Hallo Rudi,

das klingt alles schon sehr vielversprechend und du scheinst dir auch schon sehr konkrete Gedanken über das Handling mit deinen neuen Werkzeugen gemacht zu haben. Aktuell bist du offenbar weiter am Optimieren. Sobald du meinst, eine gewisse Basis bereits weitgehend abgeschlossen zu haben, vielleicht kannst du bei Gelegenheit irgendein kleines Beispiel für das Handling geben. Das eilt aber nicht.

Viele Grüße,
Sinter
Ixus 60 (SD600) Firmware 1.00a
CHDK-DE aktuelle Version
Benutzeravatar
Sinter
CHDK-Begeisterter
CHDK-Begeisterter
 
Beiträge: 416
Bilder: 2
Registriert: 14.08.2009, 14:16
Wohnort: München

Re: Sonnenauf- & Untergang, Blaue Stunde - Berechnungen

Beitragvon msl » 30.11.2012, 18:56

Hallo zusammen,

ich habe nun mal versucht, Schritt für Schritt die Formeln der genannten Seite in einem Skript umzusetzen. Erstes Ziel war, ein schlüssiges Ergebnis zu erreichen. Aufgrund der Ganzzahlen-Problematik muss man ganz schön mit den Zahlen "jonglieren"

Bei der Berechnung im Lua-Skript habe ich mich an das Beispiel der Formelseite gehalten. Von der Verwendung von Mantissen möchte ich noch nicht sprechen. Ich habe die Werte einfach nur soweit erweitert, dass die jeweiligen Ziffernfolgen als Ganzzahlen verfügbar waren.

Im Ergebnis habe ich bei der Aufgangszeit eine 7:49 berechnet, was der Zeit in der Beispielrechnung 7:50 sehr nahe kommt. Die Ernüchterung kam dann bei der Untergangszeit. Hier errechnete ich 16:35. Die richtige Zeit wäre 16:48. Diese Abweichung ist dann nicht mehr vertretbar.

Trotzdem muss ich sagen, dass es sicherlich machbar ist, solche komplexen Berechnungen durchzuführen. Die Bibliothek zu den Winkelfunktionen ist einfach nur sensationell.

Gruß msl
■ "Hey you, don't tell me there's no hope at all. Together we stand, divided we fall."CHDK inside FAQCHDK-Neuigkeiten auf Twitter
Benutzeravatar
msl
Super-Mod
Super-Mod
 
Beiträge: 4512
Bilder: 271
Registriert: 22.02.2008, 12:47
Wohnort: Leipzig
Kamera(s): A720 1.00c
SX220 1.01a

Re: Sonnenauf- & Untergang, Blaue Stunde - Berechnungen

Beitragvon Werner_O » 01.12.2012, 14:04

Hallo msl,

Die Ernüchterung kam dann bei der Untergangszeit. Hier errechnete ich 16:35. Die richtige Zeit wäre 16:48.

Diese Zeitdifferenz entspricht dem Wert für die Zeitgleichung, welche im Beispiel -0,217h bzw. umgerechnet -13m entspricht. Dieser negative Wert muß bei der Gleichung für den Sonnenuntergang abgezogen werden, wobei das im Beispiel zu einer Addition führt:
16:35 + 0:13 = 16:48.

Bitte überprüfe darum Deine Formel für den Sonnenuntergang diesbezüglich.

Ansonsten arbeite ich seit etlichen Tagen an einem Programm für einen HP48 S/SX/G/GX bzw. EMU48, welches nach den genannten Formeln schnell und genau astronomische, nautische oder bürgerliche Dämmerungszeit als auch Sonnenauf- und Untergang sowie den Meridian (Sonne genau im Süden bezogen auf Längengrad und Zonenzeit) errechnen kann.
Die Arbeiten stehen dabei kurz vor dem Abschluß - es fehlen nur noch zwei Eingabe- und eine Ausgaberoutine - und ich hoffe, damit spätestens morgen fertig zu sein.
Sobald ich fertig bin werde ich es hier posten.

Dieses Programm ist u.a. als Hilfe von mir an euch als CHDK-Programmierer gedacht, um schnell per CHDK-Skript errechnete Ergebnisse mit den mathematisch genauen Ergebnissen eines HP48 vergleichen zu können.
EMU48 kann ja über meine Website sehr schnell eingerichtet werden, siehe meine Websunterseite Easy EMU48.

Liebe Grüße
Werner_O
Zuletzt geändert von Werner_O am 01.12.2012, 17:36, insgesamt 2-mal geändert.
Benutzeravatar
Werner_O
CHDK-Legende
CHDK-Legende
 
Beiträge: 1013
Registriert: 22.10.2010, 14:12
Wohnort: Köln
Kamera(s): SX20 1.02d
SX240 1.01a
S100 1.01a
S3 1.00a

Re: Sonnenauf- & Untergang, Blaue Stunde - Berechnungen

Beitragvon msl » 01.12.2012, 15:18

Hallo Werner_O,

dein Hinweis klingt logisch. Bei einer Prüfung der Formeln habe im Augenblick aber keinen Fehler entdeckt.

Die Abweichung ergibt sich m.M. nach aus den vielen Umrechnungen. Im Beispiel wird eine Zeitdifferenz von 4.479 h ermittelt. Wenn ich diesen Wert einsetze, komme ich auf

Aufgang: 07:44 Uhr
Untergang: 16:41 Uhr

Das wäre schon fast optimal. Meine mit den CHDK-Lua-Möglichkeiten ermittelte Zeitdifferenz beträgt 4.382 h . Daraus folgt dann

Aufgang: 07:49 Uhr
Untergang: 16:35 Uhr

Ich denke, wenn man durch Optimierung der Berechnungen die Abweichungen im Bereich von 5 Minuten begrenzen könnte, wäre das ein Wert, mit dem man bei so einer Anwendung leben könnte.

Gruß msl
■ "Hey you, don't tell me there's no hope at all. Together we stand, divided we fall."CHDK inside FAQCHDK-Neuigkeiten auf Twitter
Benutzeravatar
msl
Super-Mod
Super-Mod
 
Beiträge: 4512
Bilder: 271
Registriert: 22.02.2008, 12:47
Wohnort: Leipzig
Kamera(s): A720 1.00c
SX220 1.01a

Re: Sonnenauf- & Untergang, Blaue Stunde - Berechnungen

Beitragvon Werner_O » 01.12.2012, 16:38

Hallo msl,

einmal berechnet, liegen die für alle Berechnungen grundlegenden Werte für die Zeitdifferenz (im Beispiel +4,479h) , die Deklination der Sonne (im Beispiel -17,58 in rad) und die Zeitgleichung (im Beispiel -0,217h bzw. -13m) ja vor, und Du kommst ja auch zu einem passabel genauen Ergebnis für den Sonnenaufgang mit nur 1min Dîfferenz.

Die Zeiten für Sonnenauf- und Untergang errechnen sich dabei sowieso nur noch aus Additionen bzw. Subtraktionen dieser errechneten Werte. Diese einfachen mathematischen Operationen sollten doch m.E unter CHDK bereits jetzt auch noch ohne emulierte Winkelfunktionen möglich sein.

Insofern wundert es mich, daß Du (zumindest schon recht genau) auf die korrekte Sonnenaufgangszeit kommst, was ja auf korrekt berechnete Variablen für die vorgenannten Werte hindeutet.

Warum das beim Sonnenuntergang noch nicht klappt und offensichtlich der Wert für die Zeitgleichung noch fehlt ist mir schleierhaft, da für diese Berechnung eigentlich alle nötigen Varablen bereits vorliegen sollten und wie gesagt nur noch Berechnungen vom Typ Addition/Subtraktion nötig sind, was unter CHDK bereits ohne emulierte Winkelfunktionen möglich sein sollte.

M.E. kann das nur an einem Fehler im Ablauf bzw. Programmierung des Skriptes liegen.
Mit den bereits korrekt errechneten Variablen für die Zeitdifferenz, die Deklination und die Zeitgleichung für den Sonnenaufgang sollte auch der Sonnenuntergang einigermaßen korrekt (+/- 1min) berechnet werden können.

Hier noch mal die nötigen Formeln für Sonnenauf- und Untergang bezogen auf einen Längengrad (LG in Grad) und eine Zeitzone (ZZ in hours/Stunden) :
Aufgang = 12 - Zeitdifferenz - Zeitgleichung - LG/15 + ZZ
Untergang = 12 + Zeitdifferenz - Zeitgleichung - LG/15 + ZZ


Insofern kann ich nur erneut darauf hinweisen, Deine CHDK-Skript-Formeln nochmals zu überprüfen. Du mußt da etwas übersehen haben.
Der einzige Unterschied zwischen den Gleichungen für Auf- und Untergang der Sonne besteht ja darin, daß für den Untergang die Zeitdifferenz addiert und nicht subtrahiert wird. Alles andere bleibt rechnerisch gleich.
Dabei sollte die Untergangszeit auch separat berechnet werden und nicht von der Aufgangszeit abgeleitet werden, um unnötige zusätzliche Rundungsfehler zu vermeiden.

Nachtrag 21:00 Uhr
Vielleicht sollte bei den Berechnungen dazu durch CHDK auch bedacht werden, daß hierzu die größte anzunehmende Zahl in den Formeln den Wert +/- 180 hat (= Längengrad), wobei üblicherweise dazu nur maximal zwei Nachkommastellen kommen. Das ergibt einen Wert von max. 5 Digits (sprich 5 Stellen) für weitere Berechnungen.
Alle Ergebnisse sind dabei viel kleiner als +/- 180.
Das nur als Hinweis.

Liebe Grüße
Werner_O
Benutzeravatar
Werner_O
CHDK-Legende
CHDK-Legende
 
Beiträge: 1013
Registriert: 22.10.2010, 14:12
Wohnort: Köln
Kamera(s): SX20 1.02d
SX240 1.01a
S100 1.01a
S3 1.00a

Re: Sonnenauf- & Untergang, Blaue Stunde - Berechnungen

Beitragvon msl » 01.12.2012, 22:46

Hallo Werner_O,

die Annäherung an das richtige Ergebnis beim Sonnenaufgang ist bedingt durch die Vorgabewerte (Datum; Ort) purer Zufall. Rechnet man mit anderen Vorgaben, sieht das Ergebnis nicht so positiv aus.

Einen Fehler in den abschließenden Berechnungen schließe ich mal aus. Siehe dazu den Ausschnitt aus meiner Skript-Studie:
Syntax: [ Download ] [ Verstecken ]
Benutze Lua Syntax Highlighting
--Aufgang Ortszeit = 12 - Zeitdifferenz - Zeitgleichung
--Untergang Ortszeit = 12 + Zeitdifferenz - Zeitgleichung
-- 12 - 4.382 - -.216
-- 12000 - 4382 - -216
sunrise_local = (12*1000 - time_diff) - time_equation
sunset_local = (12*1000 + time_diff) - time_equation

--Aufgang = Aufgang Ortszeit - geographische Länge /15 + Zeitzone
--Untergang = Untergang Ortszeit - geographische Länge /15 + Zeitzone
sunrise = ((sunrise_local*10) - (L/150 +UTC)*10)/10
sunset = ((sunset_local*10) + (L/150 +UTC)*10)/10
Erstellt in 0.003 Sekunden, mit GeSHi 1.0.8.9

Deklination und Zeitgleichung bekomme ich ziemlich genau mit 3 Stellen hin.

rudis Winkelfunktionen sind unumstritten.

Die Berechnung der folgenden Gleichung muss im Skript einfach optimiert werden:
Code: Alles auswählen
Zeitdifferenz = 12*arccos((sin(h) - sin(B)*sin(Deklination)) / (cos(B)*cos(Deklination)))/Pi
Das Ergebnis dieser Gleichung bestimmt das Endergebnis entscheidend.

Nebenbei bemerkt handelt es sich bei dem Zahlenwert 17,58 aus der Beispielrechnung und Grad und nicht um Bogenmaß.

Gruß msl
■ "Hey you, don't tell me there's no hope at all. Together we stand, divided we fall."CHDK inside FAQCHDK-Neuigkeiten auf Twitter
Benutzeravatar
msl
Super-Mod
Super-Mod
 
Beiträge: 4512
Bilder: 271
Registriert: 22.02.2008, 12:47
Wohnort: Leipzig
Kamera(s): A720 1.00c
SX220 1.01a

Re: Sonnenauf- & Untergang, Blaue Stunde - Berechnungen

Beitragvon msl » 02.12.2012, 17:44

Hallo,

nach dem unser Chefanalytiker rudi meine erste Skriptstudie etwas näher untersucht und diverse Mängel beseitigt hat, kann ich nun ein erstes Skript veröffentlichen, mit dem man die die Leistungsfähigkeit der emulierten Winkelfunktionen testen kann.

Das Skript berechnet auf Basis dieser Formeln bürgerliche Dämmerungszeiten sowie Sonnenauf- und Untergangszeiten für Orte, die in einer externen Datei gelistet sind. Dabei kann eingestellt werden, ob das aktuelle oder ein frei wählbares Datum zur Berechnung benutzt wird. Außerdem kann man noch festlegen, ob die Sommerzeit berücksichtigt werden soll (Sydney hat gerade Sommerzeit :D .). Das alles lässt sich in den Skriptparametern einstellen.

Hauptfenster
- [hoch/runter] Ort wechseln, wenn mehrere Datensätze verfügbar sind.
- [SET] Untermenü Geo-Daten
- [MENU] beendet das Skript.

Geo-Daten
- [SET] Laden von externen Geo-Daten, die in einer Datei stehen. (*)
- [Rechts] Manuelle Eingabe von Geo-Daten: Breitengrad, Längengrad, Zeitzone als Eingabemaske
- [Links] Löschen einzelner Datensätze
- [DISP] GPS (geplante Funktion zum Abruf der Geo-Daten)
- [Menu] zurück zum Hauptfenster

(*) Eine solche Datendatei ist im Zip-Paket enthalten. Sie sollte vorzugsweise im Ordner CHDK/DATA platziert werden. Der CHDK-Datei-Browser wird zuerst in diesem Verzeichnis suchen. Es besteht die Möglichkeit, eigene Daten in eigenen Dateien anzulegen. Zeilen mit einer Raute (#) werden beim Auslesen ignoriert und können somit als Kommentarzeilen verwendet werden. Diese Reihenfolge ist einzuhalten: Ort;Breitengrad;Längengrad;Zeitzone. Die Koordinaten werden in Grad angegeben. Dabei wird eine Dezimalstelle benutzt. Diese muss aber als Ganzzahl eingegeben werden: 52,5 -> 525.

Das Skript setzt voraus, dass sich die Datei cordiclib.lua im Unterordner CHDK/LUALIB befindet. Diese gibt es hier.

Die Städte-Daten basieren auf Angaben folgender Links:

http://www.astrologon.com/positionen.htm
http://www.deine-berge.de/Rechner/Koordinaten
http://www.timeanddate.com/worldclock/

Gruß msl

Edit: 02.12.2012 - Sonnenhöchststand hinzugefügt, Berechnung vereinfacht.
Edit: 10.12.2012 - Skript neu strukturiert, Geo-Daten extern ladbar.
Edit: 13.12.2012 - Unternemü für GeoDaten, manuelle Eingabe von Geo-Daten, Löschen von Datensätzen
Edit: 06.01.2013 - Diese Skriptversion hier wird nicht weitergeführt. Mehr zur neuen Version hier: viewtopic.php?f=7&t=2976&p=27094#p27094
Dateianhänge
twilight.zip
v0.4
(4.15 KiB) 135-mal heruntergeladen
■ "Hey you, don't tell me there's no hope at all. Together we stand, divided we fall."CHDK inside FAQCHDK-Neuigkeiten auf Twitter
Benutzeravatar
msl
Super-Mod
Super-Mod
 
Beiträge: 4512
Bilder: 271
Registriert: 22.02.2008, 12:47
Wohnort: Leipzig
Kamera(s): A720 1.00c
SX220 1.01a

Re: Sonnenauf- & Untergang, Blaue Stunde - Berechnungen

Beitragvon Sinter » 03.12.2012, 17:22

Hallo Msl,

ich bin dein beachtliches Skript kurz durchgegangen.

Falls zusätzlich eine Differenzberechnung der Werte gegenüber der aktuellen Uhrzeit eingebaut wird (Blaue Stunde beginnt in x Stunden y Minuten etc. ), stellt sich vielleicht noch die Frage, ob man beim Auslesen der Uhrzeit der Kamera noch automatisch erkennen kann, ob in der Kamera die Sommerzeit gesetzt ist (Propcase?).

Ob aus den Daten bereits der Winkel der Sonne gegenüber dem Horizont einfach auslesbar ist, habe ich jetzt nicht geprüft. Es wäre ein möglicher Indikator für die Intensität der Dämmerung (evtl. in Prozent umrechnen).

Zudem vielleicht noch den Tiefststand (=Negativer Höchststand) der Sonne heranziehen, falls sich jemand nahe/jenseits des Polarkreises befindet und vorab wissen möchte, welche maximale Dunkelheit (anzeigen in Prozent) überhaupt zu erwarten ist, falls die Sonne je nach Jahreszeit auch weniger als 6 Grad unter den Horizont taucht und somit gar keine vollständige Dunkelheit erreichbar sein wird.

Man könnte die Dämmerung auch in verschiedene Phasen (vielleicht in Drittel oder Viertel) aufteilen und berechnen, wie lange dem Fotografen jede Phase zur Verfügung steht.

Eventuell könnte man auch noch überlegen, die Koordinaten der Städte in eine (oder mehrere) separate Datei auszulagern. Vielleicht je Land oder Kontinent. Ähnlich wie die Kartendaten bei Navigationsgeräten.

Viele Grüße,
Sinter
Zuletzt geändert von Sinter am 05.12.2012, 11:15, insgesamt 1-mal geändert.
Ixus 60 (SD600) Firmware 1.00a
CHDK-DE aktuelle Version
Benutzeravatar
Sinter
CHDK-Begeisterter
CHDK-Begeisterter
 
Beiträge: 416
Bilder: 2
Registriert: 14.08.2009, 14:16
Wohnort: München

Re: Sonnenauf- & Untergang, Blaue Stunde - Berechnungen

Beitragvon Sinter » 05.12.2012, 11:14

Hallo Msl,

noch ein paar Gedanken rund um das Thema:

An dieser Stelle wäre auch wieder das TagMe-Skript sehr interessant. Lässt sich dessen Funktionalität vielleicht mit angemessenem Aufwand in die Form einer Lua-Function bringen, wobei man an diese Function nach der Aufnahme denjenigen String übergibt, der dann in die Exif geschrieben werden soll? Oder wäre hier wieder die beeindruckende Fachkompetenz der Programmierer gefragt?

Jedenfalls könnte man dann in einem „Blaue-Stunde“-Skript den Höhenwinkel der Sonne zum Zeitpunkt der Aufnahme in den Exif-Daten der JPG hinterlegen. (Evtl. wäre das auch für die DNG-Exif noch leichter zu realisieren, da CHDK die DNG-Exif-Daten unmittelbar bestimmt.) Log-Files könnten zwar ebenfalls Sonnenstandsdaten der einzelnen Aufnahmen dokumentieren, jedoch halte ich es für sinnvoller, diese Daten besser gleich in die Exif-Daten der Fotos zu schreiben.

So könnte man bei besonders gelungenen Fotos ganz leicht herauslesen, unter welcher Dämmerungsintensität die Aufnahme entstand und man könnte mittels dieser Info versuchen, an anderen Tagen eine entsprechend identische Dämmerungsintensität abzuwarten (bzw. den zutreffenden Zeitpunkt angezeigt zu bekommen) um ähnlich gute gleichartige Ergebnisse zu reproduzieren (Z. B. harmonische Kombination aus kunstlichtbeleuchteten Fenstern und natürlicher Dämmerung).

Ich weiß nicht genau, welche konkreten Features du bereits geplant hast. Vielleicht könnte auch sinnvoll sein, Belichtungsprofile (Sonnenstand, Belichtungszeit, Blende, ISO, Brennweite bzw. bei anderer Brennweite passende Hochrechnung der Belichtung) von gelungenen „Blaue-Stunde“-Aufnahmen zu hinterlegen (Profil-Logfile) um diese einzelnen Profile bei Bedarf mittels eines „Blaue-Stunde-Timer“-Skript zu laden und somit konkrete Dämmerungs-Farb-Stimmungen reproduzieren zu können („Timer“-Auslösung bei Erreichen eines hinterlegten Sonnenstands, evtl. mit den Einstellungen eines hinterlegten Belichtungsprofils). „Timer“ hier also nicht im Sinne von „zeitgesteuert“, sondern im Sinne von „Dämmerungsintensität-gesteuert“. Auch hier vielleicht die Bestimmung des Sonnenstands in eine Lua-Function legen, die dann in einer Schleife ständig abgefragt wird bis der Sonnenstand einen hinterlegten Wert erreicht, um erst dann jeweils auszulösen.

Daneben vielleicht noch einen Intervall-Timer als weitere Option einprogrammieren, bei dem der gesamte Dämmerungsprozess in eine vom User gewählte Anzahl von x Intervallen (bzw. Aufnahmen) unterteilt wird, um den Dämmerungsprozess über x Aufnahmen zu dokumentieren. Die Intervalle auch hier nicht zeitgesteuert, sondern vom berechneten aktuellen Sonnenstand gesteuert.

Ich überlege gerade ob es einen Verwendungszwecke geben könnte, um vielleicht auch noch den Bewegungssensor/MotionDetection irgendwie sinnvoll zu integrieren, falls er in der Lage wäre, bei aufgehender Sonne den ersten direkten gleißenden Sonnenstrahl am Horizont zu detektieren. Oder auch beim Sonnenuntergang detektieren, wann plötzlich kein direkter Sonnenstrahl mehr vorliegt?

Nungut, viele Features sind denkbar, aber die Höhe des Sonnenstands ist auch im nachhinein für „Blaue-Stunde“-Fotos besonders erkenntnisreich und könnte daher zweckdienlich in den Exif-Daten hinterlegt werden. Für DNG-Exif könnte man das vielleicht sogar direkt in CHDK integrieren. Für JPG hingegen wäre nun sinnvoll, „TagMe“ in Form einer Lua-Function zu realisieren, sofern überhaupt möglich. Hier wäre TagMe jedenfalls eine sehr aufschlussreiche und sinnvolle Anwendung. Bei einem gelungenen Blaue-Stunde-Foto ist stets interessant, bei welcher exakten Dämmerungsintensität die Aufnahme entstand, bzw. in welchem Winkel die Sonne dabei zum Horizont stand.

Viele Grüße,
Sinter
Ixus 60 (SD600) Firmware 1.00a
CHDK-DE aktuelle Version
Benutzeravatar
Sinter
CHDK-Begeisterter
CHDK-Begeisterter
 
Beiträge: 416
Bilder: 2
Registriert: 14.08.2009, 14:16
Wohnort: München

Re: Sonnenauf- & Untergang, Blaue Stunde - Berechnungen

Beitragvon Werner_O » 10.12.2012, 03:27

Hallo zusammen,

ich habe es jetzt endlich hinbekommen ein Programm zu schreiben, welches auf einem HP48 S/SX/G/GX (auch emuliert via EMU48) die Sonnenstände für einen Tag sehr genau berechnen kann.
Dabei können nahezu beliebige Ortskoordinaten eingegeben werden (etwa Längengrad -180°W bis +180°O), bei den Breitengraden habe ich das Programm aber auf -65°S bis +65°N beschränkt, weil zu diesen Breitengraden hin die Genauigkeit der Berechnungen bei nur noch kleiner/gleich 9 Minuten liegt.
Auch bis zu 6 Presets für eigene Ortsvorgaben sind möglich, dazu später mehr.

Als Ergebnisse werden neben den geographischen Angaben und der Zeitzone dabei zunächst immer die Zeiten für den Sonnenaufgang, den Meridian (die Sonne ist genau im Süden) und den Sonnenuntergang ausgegeben.

Zusätzlich gibt das Programm (je nach eigener Auswahl) auch die Dämmerungszeiten (vor und nach Sonnenaufgang/-Untergang) aus - entweder für die "Bürgerliche Dämmerung" (h=-6°), die "Nautische Dämmerung" (h=-12°) oder die "Astronomische Dämmerung" (h=-18°).
Sind die errechneten Dämmerungszeiten je nach Breitengrad und gewähltem Tag ungültig, weil das Ergebnis der Formel für die "Zeitdifferenz" mit der arccos-Funktion eine komplexe (imaginäre) Zahl ergibt, wird dann "FEHLER" für die Dämmerungszeiten ausgegeben - die Sonne kann dann halt gar nicht so weit unter den Horizont gehen und eine Berechnung der gewählten Dämmerung ist dann definitiv nicht möglich.

Hinweise:
1. Für einen Photographen ist im Grunde nur die "bürgerliche Dämmerung" interessant. Selbst mit sehr lichtstarken Objektiven kann dann nur vom Stativ und mit extrem langen Belichtungszeiten ein Bild gemacht werden. Umgangssprachlich ausgedrückt wird der Himmel ab der "bürgerlichen Dämmerung" überhaupt erst so langsam hell (bezogen auf das Sehvermögen gesunder menschlicher Augen).
2. Die sogenannte "blaue Stunde" ist dabei als Faustregel in etwa morgens die letzten 2/3 der Zeit zwischen bürgerlicher Dämmerung und Sonnenaufgang. Abends sind es dagegen in etwa die ersten 2/3 der Zeit zwischen Sonnenuntergang und bürgerlicher Dämmerung.
Allerdings muß dafür auch das Wetter mitspielen - ist der Himmel etwa stark bewölkt kommt es gar nicht zu einer "blauen Stunde" .
Insofern macht es m.E. auch keinen Sinn, die "blauen Stunden" via CHDK-Skript genau berechnen zu wollen.
Neben den Wetterverhältnissen kommen ja auch die jeweiligen geografischen Bedingungen dazu, und die entsprechen in der Praxis so gut wie nie den theoretischen Vorgaben.
3. Die "nautische Dämmerung" und "astronomische Dämmerung" sind für Photographen dagegen in der Praxis m.E. völlig irrelevant.
Diese via CHDK-Skript berechnen zu wollen ist zudem sehr problematisch, worauf ich bereits hingewiesen hatte (mögliche komplexe/imaginäre Ergebnisse bei der Formel für die "Zeitdifferenz"). Es macht also m.E. keinen Sinn, dafür überhaupt Zeit zu investieren.

Zurück zu meinem neuen Programm:

Das erfordert einen realen HP48 S/SX/G/GX oder eine Emulation dieser Rechner durch "EMU48".
Ich habe heute auf meiner Homepage zwei Downloads bereitgestellt, mit welchen EMU48 entweder mit einem HP48GX (empfohlen) oder einem HP48SX mit nur zwei simplen Kopiervorgängen installiert werden kann.

Zunächst die Links:
EMU48 mit HP48GX
EMU48 mit HP48SX

Zusätzlich ist das Programm separat (als Verzeichnis) verfügbar für User, die etwa bereits EMU48 installiert haben. Der Link dazu ist sun.zip.

Die Installation ist wie gesagt denkbar einfach, hier Details dazu:
Installationshinweise:

1. Entweder das ZIP-Archiv "emu48_v1.47_hp48gx.zip" von meiner HP herunterladen (empfohlen) oder aber die HP48-Vorgängerversion "emu48_v1.47_hp48sx.zip".
2. Das gewählte Archiv entpacken.
3. Den Ordner "EMU48" in den Ordner C:\Programme\ kopieren.
4. Die Datei "Emu48.ini" in den Windwos-Ordner kopieren.
Das wars schon. Allerdings sind dafür Administratorrechte nötig.

Zum Starten von EMU48 die EMU48.exe ausführen.

Mein neues Programm "Sun" liegt dabei im Unterordner "Sun".

Hier eine Programmbeschreibung:
Zunächst fragt das Programm, ob einer der maximal 6 verfügbaren Presets für Ortsangaben verwendet werden soll:

1 Bejaht man dies, werden kurz die in der globalen Variable "PRES" gespeicherten Orte im Display eingeblendet und man kann anschließend den gewünschten Ort numerisch auswählen.
Das Programm überprüft dann die für diesen Ort gespeicherten Werte für den Längen- und Breitengrad sowie die Zeitzone auf Plausibilität und bricht bei Werten, welche nicht den VORGABEN entsprechen, mit einer Fehlermeldung ab.

2. Verneint man die Verwendung eines Presets, können anschließend Längen- und Breitengrad sowie die Zeitzone manuell eingegeben werden.
Auch dabei werden alle Eingaben überprüft, ob sie den VORGABEN entsprechen, wobei bei ungültigen Eingaben jeweils Fehlermeldungen ausgegeben werden und die Eingabe mit einem gültigen Wert wiederholt werden muß, damit das Programm weiterläuft.

Danach fragt das Programm nach dem Tag für die Berechnung, wobei jeweils das aktuelle Datum inklusive des Jahres vorgeschlagen wird.
Nur bei Schaltjahren kann dabei der 29. Februar eingegeben werden!
Fehlerhafte Eingaben führen zu einer Fehlermeldung und die Eingabe muß anschließend solange wiederholt werden, bis ein korrektes Datum eingegeben wurde.

Anschließend fragt das Programm, ob die Sommerzeit (aktuelle Zeitzone + 1h) verwendet werden soll.
Für die Monate April bis Oktober wird dabei die Sommerzeit bei der Eingabe vorgeschlagen, ansonsten nicht, und hier gilt es aufzupassen!
Die genauen Daten für die Umstellung von Winterzeit auf Sommerzeit und umgekehrt sind ja jahresabhängig und finden immer in einer Nacht von einem Samstag zu einem Sonntag statt.
Meine aktuelle Programmversion enthält jedenfalls noch keine zusätzliche nötige Programm-Routine, um die Zeitumstellungen auch korrekt tagesgenau vorzuschlagen.

Als letzte Eingabe wird gefragt, ob für die Dämmerungswerte die "bürgerliche", die "nautische" oder die "astronomische" Dämmerung verwendet werden soll.
Dazu ein wichtiger Hinweis:
Die "nautische" und die "astronomische" Dämmerung können abhängig vom Breitengrad und Jahreszeit oft gar nicht ermittelt werden, weil die Sonne dann in der Nacht real gesehen (das betrifft insbesondere Breitengrade bereits ab etwa +/- 50 Grad) gar nicht 12° (nautische Dämmerung) oder 18° (astronomische Dämmerung) unter den Horizont absinken kann.
Auch das wird von meinem Programm überprüft, und bei ungültigen Ergebnissen für die Zeit der gewählten Dämmerung wird dafür jeweils "FEHLER" anstelle einer Uhrzeit im Ergebnis angezeigt.

Ausgabe der Ergbnisse:

Alle Ergebnisse werden sowohl am Display ausgegeben als auch zusätzlich in der globalen Variablen 'RESU'gespeichert.
Die Variable 'RESU' ist dabei eine Liste, in welcher alle Ergebnisse in Form von 7 Unterobjekten (jeweils alphanumerische Zeichenketten) gespeichert werden.
Die Variable 'RESU' wird dabei nach jeder neuen Berechnung mit den neuen Ergebnissen überschrieben und enthält somit immer nur die Ergebnisse der letzten Berechnung.

Die angezeigten Ergebnisse im Detail:
Zeile 1: Tag und Zeitzone, bei Verwendung von Presets zusätzlich noch vorangestellt der Ort (gegebenfalls abgekürzt)
Zeile 2: verwendeter Längen- und Breitengrad, jeweils gerundet auf zwei Nachkommastellen
Zeile 3: Dämmerungszeit vor Sonnenaufgang (je nach vorheriger Auswahl bürgerlich, nautisch oder astronomisch)
Zeile 4: Sonnenaufgang
Zeile 5: Erst der maximal zu erwartende Fehler ("G...;") in Minuten; danach die Meridianzeit (sprich die Sonne ist genau im Süden)
Zeile 6: Sonnenuntergang
Zeile 7: Dämmerungszeit nach Sonnenuntergang (je nach vorheriger Auswahl bürgerlich, nautisch oder astronomisch)

Hier die Bereichsgrenzen der möglichen VORGABEN (entweder manuell oder via Preset):
Dieses Programm erwartet folgende Vorgaben für die Eingabewerte.
Wird auch nur eine einzige Vorgabe über- oder unterschritten, muß etwa eine Eingabe wiederholt werden oder aber das Programm bricht mit einer Fehlermeldung ab (etwa bei der Verwendung fehlerhafter Presets).

Erlaubte Vorgabewerte
1. Längengrad: -180,0 bis +180,0 Grad
2. Breitengrad: -65,0 bis +65,0 Grad
3. Zeitzone: maximal -1 bis +1 Stunde Differenz zu der mathematisch zum eingegebenen Längengrad passenden Zeitzone

Achtung:
Für Längen- und Breitengrade erwartet das Programm bei der Eingabe DEZIMALE GRADWERTE, und dabei für Nord oder Ost positive Zahlen und für Süd oder West negative Zahlen!
Angaben in der Form xx°yy' (sprich in Grad und Minuten) können nicht verarbeitet werden und müssen ggfs. vorher umgerechnet werden.
Dazu gibt im Sun-Ordner das kleine Unterprogramm "GM->D" (Grad/Minuten zu einem dezimalen Gradwert):
Nach Eingabe eines Längen-/Breitengrads mit den Grad als als Vorkommastellen und den Minuten als Nachkommastellen wandelt dieses Programm diese Werte in eine gültige dezimale Gradangabe um (gerundet auf drei Nachkommastellen), welche für die Presets oder auch für freie Eingbaben verwendet werden kann.
Beispiel Berlin:
Längengrad = 13° 22´ O = +13,367 Grad
Breitengrad = 52° 33´ N = +52,550 Grad
Beispiel Rio De Janeiro:
Längengrad = 43° 14´ W = -42,233 Grad
Breitengrad = 22° 54´ S = -22,900 Grad

Hinweis:
Auch die Preset-Werte aus der globalen Variable 'PRES' werden diesbezüglich überprüft und führen zu einem Programmabbruch mit einer Fehlermeldung, wenn die Vorgabewerte für einen Preset unter- oder überschritten wurden.

Hier einige Infos, um die globale Variable "PRES" mit den bis zu 6 möglichen Presets an eigene Vorlieben anzupassen:
Die globale Variable "PRES" ist sehr einfach gestrickt:
Sie besteht aus einer Liste (in geschweiften Klammern), welche wiederum bis zu 6 Unterlisten (ebenfalls in geschweiften Klammern) mit Presets für Orte enthalten kann.
Diese Unterlisten hmüssen jeweils 4 Einträge enthalten:
1. Den Namen des Ortes als Alphastring (mit " als Begrenzungszeichen)
2. Den Längengrad von -180 bis + 180 (als dezimale Gradzahl mit positiven Werten für Ost und negativen Werten für West)
3. Den Breitengrad von -65 bis + 65 (als dezimale Gradzahl mit positiven Werten für Nord und negativen Werten für Süd)
4. Die Zeitzone von -12 bis +12 Stunden bezogen auf GMT bzw. UTC, wobei die gewählte Zeitzone nur -1h bis +1h von der zum Längengrad (2. Listeneintrag) passenden Zeitzone differieren darf.

Per default enthält die globale Variable "PRES" folgende Einträge:

{
{ "Hamburg" 10 53,55 1 }
{ "Berlin" 13,367 52,55 1 }
{ "Köln" 6,95 50,933 1 }
{ "Stuttgart" 9,183 48,767 1 }
{ "München" 11,583 48,15 1 }
}

Diese Liste kann man sich natürlich nach Belieben abändern, um etwa seinen Wohnort und/oder ein Urlaubsziel einzugeben etc.

Dazu muß man sich diese Liste unter Windows mit den Tastenkombinationen "STRG" und "F3" zunächst in den Stack in Ebene 1 holen.
Das geht auch mit der Maus über "Right Shift" und danach Klick auf "PRES" oder "F3".
Mit der "Taste nach unten" kommt man in den EDIT-Modus für diese Liste.
Nun können die numerischen Werte für Breiten- und Längengrad sowie Zeitzone der Unterlisten leicht geändert werden.
Um Die Ortsnamen zu ändern muß der sogenannte "Alpha-Modus" aktiviert werden:
Unter Windows geht das mit der Taste "Tab", per Maus mit Klick auf die "Alpha-Taste" oberhalb "Left Shift".
Dabei ist zunächst immer der Großschreibemodus aktiviert, auf Kleinschreibung kann mann dann (solange der Alpha-Modus noch aktiv ist, was im Display übrigens über ein griechisches Alpha-Symbol angezeigt wird) unter Windows mit der Taste "°" (üoberhalb der Tabtaste) bzw. mit der Maus mit der Eingabekombination "Left Shift" und "Alpha" auf Kleinbuchstaben wechseln und umgekehrt.
Nach den gewünschten Änderungen im EDIT-Modus befördert "Enter" die Liste wieder auf Ebene 1 des Stack.
Die geänderte Liste muß nun gesichert werden:
Unter Windows geht das mit "Shift" und "F3", per Maus mit "Left Shift" und "F3".

Beim nächsten Programmstart sollten dann die geänderten Presetwerte verfügbar sein.

Aber wie gesagt Achtung:
Eingaben zu einem Preset, welche nicht den VORGABEN entsprechen, führen anschließend zu einem Programmabbruch mit einer Fehlermeldung.

Anschließend noch einige Screenshots von diesem Programm.

1. Zunächst das Ergebnis zur Beispielsrechnung für Berlin am 30. Januar bei Verwendung der "bürgerlichen Dämmerung":

Bild

Hier fällt auf, daß der Sonnenaufgang (im Vergleich zur Beispielsrechnung) 1 Minute später erfolgt (07h51m statt 07h50m).
Das ist aber sachlich richtig, weil bei der Beispielsrechnung der Längen- und Breitengrad von Berlin relativ ungenau auf (vermutlich gerundete) 13,5° Ost und und 52,5° Nord festgelegt wurde.
Mein Preset für Berlin verwendet dagegen die genaueren Werte 13,367° Ost und 52,550° Nord (entsprechend 13° 22´ O und 52° 33´ N laut http://www.astrologon.com).
Gibt man bei meinem Programm übrigens manuell 13,5° Ost und und 52,5° Nord ein, wird auch 07h50m als Sonnenaufgangszeit (wie in der Beispielsrechnung) errechnet.

Mein Programm rechnet also (im Rahmen des überhaupt möglichen) sehr genau und könnte als Referenz für CHDK-Skript-Berechnungen diesbezüglich verwendet werden.
Einfacher als mit diesem Programm können Fehler bei CHDK-Skript-Berechnungen momentan wohl kaum ermittelt werden.

2. Hier ein Screenshot mit "nautischer Dämmerung" (Köln, 01.07. mit MESZ):

Bild

Man beachte bitte die nahezu 2 Std. Differenz der "nautischen Dämmerung" zu Sonnenauf- und Untergang.

3. Hier ein Screenshot mit "astronomischer Dämmerung" (Köln, 01.07. mit MESZ):

Bild

Dort fallen die Meldungen "FEHLER" für die astronomischen Dämmerungen (morgens und abends) auf.
Das ist aber kein Fehler von meinem Programm - ganz im Gegenteil:
Die Sonne sinkt zu diesem Datum (bezogen auf diesen Ort) halt nicht so tief unter den Horizont (-18° für die astronomische Dämmerung), sodaß eine Berechnung der "astronomischen Dämmerung" dann schlichtweg unmöglich wird.

Soviel dazu zunächst von mir,
liebe Grüße
Werner_O
Zuletzt geändert von Werner_O am 12.12.2012, 01:16, insgesamt 6-mal geändert.
Benutzeravatar
Werner_O
CHDK-Legende
CHDK-Legende
 
Beiträge: 1013
Registriert: 22.10.2010, 14:12
Wohnort: Köln
Kamera(s): SX20 1.02d
SX240 1.01a
S100 1.01a
S3 1.00a

Nächste

Zurück zu Code-Ecke

Wer ist online?

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