von Sinter » 02.01.2013, 14:56
Hallo zusammen,
ich bin erst jetzt gerade dazu gekommen, die neue Version von Twilight korrekt runterzuladen. Die neue Version von twilight.lua ist beeindruckend. Klasse gemacht! Ein dickes Dankeschön an Msl und Rudi! So kann das gerne in den Kalender integriert werden.
An dieser Stelle vielleicht noch zum Vergleich der verschiedenen Kameragenerationen: Die Berechnung der grafischen Kurve im Diagramm dauert mit meiner Ixus60 16,97 Sekunden. Etwa Mitte März sind zweimals Ausreißerpunkte zwischen den roten und grünen Linien platziert. Ebenfalls ein Ausreißer etwa bei 20. September. Die drei Ausreißer können wir aber locker ignorieren.
Ich weiß nicht ob mir beim Einrichten der Dateien ein Fehler unterlaufen ist, beim Ladeversuch mittels Twilight.lua (mittels Set, Set) der GeoData1.txt kam bei mir die Fehlermeldung:
:163: attempt to get length of local 'description' (a nil value)
Auch TW_imath.lua habe ich probiert. Läuft bei mir (noch) nicht. Offenbar ist das die angekündigte Parallel-Version für die noch zu realisierenden Befehle von Rudi.
Mittlerweile von eurer Blauen-Stunde "infiziert" und auf den Geschmack gekommen, habe ich parallel dazu in den vergangenen Tagen ebenfalls schon gescriptet, um meinen eigenen Wunschvorstellungen eine Gestalt zu geben. Gerade musste ich noch mein Skript an die neue Erkenntnis anpassen, dass Msl für eine goldene Stunde bis +6° rechnet. Ich hatte bei meinem Skript zwar ebenfalls eine rötliche Sonnenauf-/untergangszeit berücksichtigt, allerdings nur bis +5°. Jetzt habe ich in Twilight.lua nachgesehen, eine goldene Stunde berechnet sich darin bis +6°. Daher habe ich gerade noch versucht, auch mein Skript an +6° statt ursprünglich +5° anzupassen. Ich hoffe, ich habe nichts übersehen.
Grundsätzlich geht es mir um eine Function für eine Art "Rund-um-Twilight-Live-OSD", mit der sich einige Live-Daten rund um die Blaue Stunde visualisieren lassen. Eine zu lösende Voraussetzung wäre noch, dass wir den Stand der Sonne gegenüber dem Horizont, also die Variable h, anhand der aktuellen Kamera-Uhrzeit (und den üblichen anderen Rahmendaten) berechnen. Da dies noch nicht vollständig gelöst ist, habe ich im Skript einen abnehmenden Sonnenstand erst mal nur simuliert um euch einen Eindruck über das Verhalten der live-OSD-Einblendungen je nach Sonnenstand zu geben. In dieser Simulation reduziert sich der Winkel der Sonne gegenüber dem Horizont pro Sekunde um ein halbes Grad. Die Sonne taucht in dieser Simulation vom Tageslicht bis zur Nacht.
Die Visualisierung erfolgt hauptsächlich in einem "Balken" am linken Bildrand.
Features:
Die Sonne wird von einer gelben Scheibe mit schwarzer Umrandung repräsentiert. Sie wird in einer Art "OSD-Balken" je nach Status platziert/verschoben.
Links über dem "OSD-Balken" steht die Ziffernanzeige des "aktuellen Sonnenwinkels gegenüber dem Horizont". Derzeit noch als Ganzzahl. (TODO: eine Dezimale müsste noch hinzugefügt werden.)
Der "OSD-Balken" repräsentiert im oberen Teil den Tageslichtzustand. Ganz oben rastet die Sonnenscheibe in eine oberste Position ein falls die Sonne mehr als +5° über dem Horizont steht.
Bei tiefstehender Sonne im Bereich 0° bis +5° wandert die Sonnenscheibe runter in den roten (analog Sonnenrot) Keilbereich mit kleinteiliger Skala. Jeder schwarze Querstrich entspricht einem Grad. (6 Pixel je Grad)
Wenn die Sonne den Horizont erreicht, taucht die Sonnenscheibe bei dem Skalenwert „0“ (=Horizont) in den Blaue-Stunde-Bereich ein, der deutlich gespreizter (20 Pixel je Grad) skaliert ist um den Intensitäts-Status der Blauen Stunde deutlich differenziert erkennbar anzuzeigen. Hier geht ein blauer Keil in einen grauen Keil nach unten über. Rechts von den Skalierungsstrichen kann man jeweils die zugehörige "Gradzahl unterhalb des Horizonts" ablesen. Auf ein Minuszeichen jeweils davor, habe ich zugunsten der Übersichtlichkeit verzichtet.
Die Platzierung der Sonnenscheibe erfolgt noch bis -6,5° in diesem weit gespreizten Maßstab und taucht unterhalb von -6° bereits in den untersten schwarzen Nacht-Bereich ein. Somit ist zugleich bei aufgehender Sonne gewährleistet, dass sich die Sonnenscheibe im Display bereits knapp vor Beginn der Bürgerlichen Blauen Stunde nach oben zu bewegen beginnt.
Steht die Sonne (nachts) noch tiefer als -6,5°, so rastet die Sonnenscheibe am unteren Ende des unteren schwarzen (Nacht-)Bereichs ein. Der OSD-Balken allein liefert dann jedoch keine Visualisierung des Sonnenwinkels. Hierfür dient dann das nun folgende Feature.
Eine aus der Sonnenscheibe "herausstrahlende" gelbe Linie (SunBeam) visualisiert generell (auch noch in der oberen und unteren Raststellung) in Verbindung mit einer zusätzlichen waagrecht eingeblendeten kurzen schwarzweißen Linie (die einen waagrechten Horizont repräsentiert), den Sonnenwinkel gegenüber dem Horizont. Das ist evtl. nützlich für all diejenigen Fälle, in denen die Sonne tiefer als -6,5° oder höher als 6° gegenüber dem Horizont steht, und der Winkel nicht aus der OSD-Balkenskala optisch ermittelbar ist.
Die korrekte Berechnung der Neigung des gelben Strahls ist noch nicht realisiert. Diese Simulation verwendet daher hilfsweise eine ähnlich anmutende Dummy-Berechnung, um den Sachverhalt mittels SunBeam erst mal ungefähr zu verdeutlichen.
Als Zahlenwerte werden zusätzlich die sieben Countdown-Zeiten und sieben absolute Ereigniszeiten für das Erreichen der vollen sieben Gradzahlen innerhalb der Blauen Stunde eingeblendet. In der Simulation nur schematisch jeweils mit identischen Dummywerten.
Eigentlich hätte ich diese Zeitwerte gerne ohne den etwas störenden massiven Blockhintergrund anzeigen wollen. Um die Zahlenwerte dennoch vom Bildhintergrund besser abzuheben, dachte ich, man könnte vielleicht für die Zeichen auch Schatten setzen indem man die Zeichen unmittelbar vorher um ein oder zwei Pixel versetzt in Schwarz (mit transparentem Hintergrund geschrieben hätte und danach die Zeichen überlappend drüberlegt. Allerdings scheinen die schwarzen Zeichen dabei mit jeder Pixelmatrix automatisch überschrieben/gelöscht zu werden. Insofern bleibt wohl doch nur die weniger elegante Lösung mit einem für jedes Zeichen kompletten Hintergrund in Form der etwas arg massiven rechteckigen Hintergrund-Pixelmatrix.
Vielleicht sollte ich den gelben Beam aus der Sonnenscheibe ebenfalls noch mit angelegten
schwarzen Linien vom Hintergrund deutlicher abheben.
Den gelben Strahl und auch die Zeitenwerte könnte man auch als zuschaltbare Optionen programmieren, welche der User bei Bedarf einer möglichst "vollkommenen Information" zuschalten kann. Denkbar wäre auch, den SunBeam ausschließlich erst außerhalb (!) der goldenen und blauen Stunde automatisch zuzuschalten. Vielleicht wäre dies die ansprechendste Lösung, um die eingeblendeten Zeitdaten nicht zu stören/übermalen.
Noch eine kurze technische Bemerkung: Das Skript verwendet die Variable h aktuell intern in Hundertstel-Grad. Also um den Faktor 100 skaliert. Eine RAD-Umrechnung ist aktuell nicht integriert.
TODOs:
Berechnung von h in Grad (DEG) anhand der aktuellen Uhrzeit der Kamera.
Berechnung des Countdown bis jeweilige Ereignisse (Erreichen einer bestimmten Gradzahl) in der Blauen Stunde.
Berechnung der Ereignisuhrzeit der jeweiligen Ereignisse (Erreichen einer bestimmten Gradzahl) in der Blauen Stunde.
Evtl. Färbung der Ereignis-Zeiten je nachdem ob schon vorbei (rot) oder erst künftig stattfindend (grün).
Bei den Zeiteinblendungen gelingen leider keine Schatten mittels vorherigem schwarzen Offset um ein oder zwei Pixel. Offenbar muss man daher mit leider stärker bildverdeckenden Kastenhintergründen arbeiten.
Es fehlt uns ja noch die Berechnung von h anhand der Kamerauhrzeit:
Falls ich mich nicht täusche, so lässt sich unser Gleichungssystem auflösen in die Gleichung:
sin (h)=((Zeitdifferenz*PI*cos(B)*cos(Deklination))/12+(sin(B)*sin(Deklination))
Vielleicht kann jemand dieses Ergebnis bei Gelegenheit bestätigen oder korrigieren.
Damit sind wir der Auflösung nach h hoffentlich näher. Jedoch muss die "Zeitdifferenz" noch unabhängig von h eingesetzt werden:
Hier wird es dann etwas undurchsichtig: Evtl. muss man noch zwischen Vormittag und Nachmittag unterscheiden? Vormittags müsste wohl gelten:
Zeitdifferenz=12-WOZ
Somit könnte man diese Zeitdifferenzformel oben in die Gleichung einsetzen.
Aber es müssten wohl auch noch MOZ und Zeitzone und Sommerzeit berücksichtigt werden, sowie ein Korrekturfaktor bezüglich des Längengrads. Wenn das gelöst wäre, dann könnten Rudis neue Winkelbefehle die Lösung für die Berechnung von h anhand der Uhrzeit in der Kamera zaubern.
Nebenbei: Wer die Einblendungen schön groß aus der Nähe betrachten mag, statt Lupe, eine normale Lesehilfebrille mit 2 oder 3 Dioptrien vereinfacht das genaue Verfolgen der Einblendungen aus der Nähe deutlich.
Kritik, Anmerkungen und weitere Gedanken sind gerne willkommen.
Viel Spaß beim Testen des simulierten "Rund-um-Twilight-Live-OSD",
Sinter
- Dateianhänge
-
- Visu_07.lua
- Blaue-Stunde-OSD
- (8.4 KiB) 406-mal heruntergeladen
Ixus 60 (SD600) Firmware 1.00a
CHDK-DE aktuelle Version