[Lua] Ein Sonnen-Live-OSD als Add-on für Twilight

[Sinter]

EDIT 21.06.2013:
Sun-Live-OSD-Display. (Stand: 21.06.2013) Kontinuierlich aktualisierte Informationen über Elevation, Azimut und bevorstehende Ereigniszeitpunkte der Sonne, zur aktuellen und vorausblickenden Einschätzung der Entwicklung der natürlichen Lichtverhältnisse. (Aus technischen Gründen weicht diese Farbgebung vom Original geringfügig ab.)

Aktuellster Download unter folgendem Link: viewtopic.php?f=7&t=3025&start=60#p27609

/EDIT
____________________________________________________________________________________________


Hallo,

nach einigem Tüfteln, hier nun als Add-on ein Prototyp für ein Sonnen-Live-OSD zum vorbildlichen Twilight-Skript.

Das Live-OSD ist in dieser Demo vorerst nur behelfsmäßig in das Twilight-Skript von Msl (Danke!) eingeklinkt. Das Live-OSD verwendet in erheblichem Maße neue Winkelbefehle von Rudi, dem ich für seine vorausschauende Programmierung der Winkel-Befehle ebenfalls ein großes Dankeschön aussprechen möchte! Ohne Rudis neue Befehle und die Entwicklungen von Msl wäre das Live-OSD nicht realisierbar gewesen. Danke euch beiden!


Start des Live-OSD:
Im beigefügten abgewandelten Twilight-Skript startet das OSD nach dem Start des Skripts und halbem Drücken des Auslösers. Die Live-OSD-Anzeige wird im Abstand einiger Sekunden ständig aktualisiert.

Beenden des Live-OSD:
Exit erfolgt mittels Drücken der Menü-Taste.


Zum Live-OSD selbst:


Linksseitig befindet sich die Einblendung des Sonnenwinkels gegenüber dem Horizont im Skalenbereich der Goldenen und Blauen Stunde. Die gelbe Sonnenscheibe mit der angehängten gelben „Nadel“ zeigt somit den Fortschritt der Goldenen und Blauen Stunde an.


Ganz rechts oben befindet sich eine schriftliche Einblendung der aktuellen relativen Schattenlänge in Prozent. (bzw. bei ganz niedrigem Sonnenwinkel nur noch "very long")
Darunter schließt sich die Zeichnung Einblendung der Sonnen-Höhenwinkelanzeige an:

Waagrecht ein "simulierter" Horizont.
Senkrecht eine "simulierte" Wand.
Rote Linie zeigt den maximalen Sonnenhöhenwinkel des aktuellen Tages winkeltreu an. (zusätzl. digital)

Darin bildet die gelbe Sonnenscheibe mit gelbem Strahl den aktuellen Höhenwinkel der Sonne winkeltreu ab.


Rechts unten innerhalb einer Kompassrose:
Einblendung des aktuellen Azimut-Winkels (= aktueller Richtungswinkel der Sonne), jedoch derzeit noch mit einer festen Dummyvariable (konstant 190°) besetzt. Die Anzeige erfolgt sowohl dezimal (innerhalb der „Kompassrose“) und auch als winkeltreu an der Kompassrose angehängte Sonnenscheibe.


Mittig befindet sich das Hauptinstrument:
Eine runde Zifferblattanzeige mit einem langen und einem kurzen Zeiger: Beide Zeiger verbleiben grundsätzlich in der 12-Uhr-Stellung.
Die 12-Uhr-Position repräsentiert stets den aktuellen Zeitpunkt als Referenz für die weiteren enthaltenen Einblendungen.

Unterhalb des Zentrums des Zifferblatts wird die aktuelle Kamerazeit angezeigt.

In den Kränzen des Zifferblatts repräsentieren eingepasste Event-Scheiben einzelne Sonnenstands-Ereignisse. Die Eventscheiben werden entsprechend des Zeitpunkts des Eintretens der Ereignisse platziert. Die Eventscheiben im äußeren und inneren Kranz wandern mit voranschreitender Zeit daher GEGEN den Uhrzeigersinn jeweils in Richtung 12-Uhr-Position. Ein Kreisumlauf im äußeren Kranz dauert/repräsentiert eine Stunde. Ein Kreisumlauf im inneren Kranz dauert 12 Stunden. Genau wie auf einem normalen Zifferblatt einer Uhr.

Äußerer Kranz:
- bildet mittels Event-Farbscheiben die Zeitdauer bis zum Eintreten der Ereignisse innerhalb der nächsten Stunde ab.
- negative Höhenwinkel besitzen in den Eventscheiben rote Ziffern

Innerer Kranz:
- bildet auf seiner äußeren Bahn die Ereignisse der nächsten 12 Stunden ab.
- bildet auf seiner inneren Bahn die Ereignisse in 12 bis 24 Stunden ab.

Somit kann man wie auf einer Uhr stets "ablesen", wie lange es bis zum Eintreten der in den nächsten 24 Stunden kommenden eingeblendeten Ereignisse noch dauert. Sonnenaufgang/-untergang finden jeweils am Grenzpunkt zwischen rotem und blauem Bereich statt.


EVENTFARBSCHEIBEN:
Gelb: =Zenit-Zeitpunkt
Weiss: Die Winkelstufen tagsüber außerhalb der Goldenen Stunde
Rot: Einzelne Winkelstufen zur Goldenen Stunde
Blau: Einzelne Winkelstufen zur Blauen Stunde
Hellgrün: Nachts außerhalb der Blauen Stunde


ACHTUNG:
Derzeit eilt das Skript leider noch eine Stunde voraus (und zeigt somit alle Events eine Stunde zu früh an). Die Einbindung in das Zeitensystem von Twilight ist noch nicht vollständig gelöst.
Die Farben können je nach Kameramodell abweichen.


TODO:
Stabile Einbindung in das Twilight-Zeitensystem.
Negativen Zenit berechnen und als Variable hinterlegen => dann lassen sich ganz einfach auch sämtliche ganzzahligen Negativgradzahlen als Eventscheiben einblenden.
Kleine Abweichungen zwischen digitalem Höhenwinkel und Platzierung der Eventscheiben können evtl. mittels sekundengenauer Berechnung und/oder mathematischer Rundungen evtl. noch beseitigt werden. Sofern kein anderer Bug hinter dem Sachverhalt steckt.

Weitere TODOs im Code.


@Msl: Auf die Schnelle ging es leider nicht anders, um mein Live-OSD lauffähig anzubinden musste ich ein paar wenige Zeilen in Twilight verbiegen. Wenn du im Code nach „sinter“ suchst, findest du die Stellen. Ich habe versucht, im Code alle Veränderungen hinreichend zu kennzeichnen.

EDIT: alte Datei entfernt.
Aktuellster Download unter diesem Link viewtopic.php?f=7&t=3025&start=60#p27609


Viel Spaß beim Ausprobieren,
Sinter

[msl]

Hallo Sinter,

bei der Skriptgröße dachte ich im ersten Augenblick, das gibt bestimmt Probleme. Aber nein, es läuft. Allerdings muss man sich als Standort München o.ä. auswählen. Nördlicher gelegene Standorte wie z.B. Nürnberg liefern einen Skriptfehler.

Mit diesem Skript bekommt man sehr viele Informationen zum Sonnenstand, die wunderbar grafisch aufbereitet sind. Das ist ein völlig neuer Ansatz. Vielen Dank dafür.

Zum Skriptfehler: Die Funktion in Zeile 563 liefert unter bestimmten Umständen einen booleschen Wert (Polarnacht, Mittsommernacht). Das führt dann in Zeile 564 zum Abbruch, weil versucht wird, mit dem booleschen Wert eine arithmetische Operation auszuführen. Es müssten also die Argumente in Zeile 563 überprüft werden. Außerdem muss in Zeile 564 ff abgesichert werden, dass diese nur ausgeführt werden, wenn Zeile 563 einen numerischen Wert liefert.

Die Grafik ist sehr umfangreich und führt häufig bei Neuaufbau zu unvollständiger Darstellung. Das ist aber kein Skriptproblem, sondern eine Einschränkung durch das CHDK. Möglicherweise kann man die Anzeige durch Optimierung stabilisieren.

Sicherlich müssen wir uns auch Gedanken machen, wie man diese ganzen astronomischen Berechnungen miteinander verknüpft. Denn eins steht fest, alles können wir nicht zusammen in ein Skript packen.

Gruß msl

[rudi]

Hallo Sinter,

da hast du eine interessante Erweiterung hinzugefügt. Die optische Umsetzung kann sich sehen lassen.
Der von msl beschriebene Skriptfehler tritt bei mir auch auf. Die Ursache hat msl bereits beschrieben. Da in unseren Breitengraden Polarnacht oder Mitternachtssonne nicht auftreten sollten, solltest du die Argumente, die sun_times() übergeben werden, prüfen.

Derzeit eilt das Skript leider noch eine Stunde voraus (und zeigt somit alle Events eine Stunde zu früh an).

Den Versatz um eine Stunde führe ich auf die fehlende Berücksichtigung der Zeitzone zurück. Meiner Meinung nach wird die Uhrzeit zur Berechnung der Sonnenbahn auf die Zeit von Längengrad 0 (lokale Zeit minus Zeitzohne) bezogen. Von da aus ergibt sich die Zeit aus Längengrad durch 15.

In der Funktion sun_position() ist ein Fehler beim Rückgabewert azimut_tausend. Dieser bleibt immer nil, da dieser innerhalb des if-Blocks als local definiert ist und auch nur innerhalb gülig ist.

Syntax: [ Download ] [ Verstecken ]

Syntax: [ Download ] [ Zeigen ]

Benutze Lua Syntax Highlighting

local azimut_tausend
if (hour*1000+minute*1000/60) <= 12*1000+(15*1000-lng*1000/10/15)-(time_equation/60) then
    azimut_tausend=acosr(y)*1000/K
else
    azimut_tausend=360-acosr(y)*1000/K
end

Erstellt in 0.005 Sekunden, mit GeSHi 1.0.8.9

Bitte prüfe auch die Variable x in sun_position(), diese sollte im Wertebereich von -1000 bis 1000 liegen. Mehr hier
Einen Hinweis noch zu den Winkelfunktionen. Es ist nicht erforderlich, Winkel in Grad erst ins Bogenmaß umzuwandeln. In deiner Umsetzung mit dem Faktor K kommen noch Ungenauigkeiten hinzu.
Möglichkeiten zur Berechnung von sin(30°) im Vergleich:

Syntax: [ Download ] [ Verstecken ]

Syntax: [ Download ] [ Zeigen ]

Benutze Lua Syntax Highlighting

K = ((PI))/180   -- Faktor 1000
winkel_deg    = 30*imath.scale                                --30°
winkel_K      = K*winkel_deg/1000                             --0.510
winkel_muldiv = muldiv(imath.pi, winkel_deg, 180*imath.scale) --0.524
winkel_rad    = imath.rad(winkel_deg)                         --0.524
print(string.format("vom Bogenmass mit K     : sin(%d) = %d", winkel_K  , imath.sinr(winkel_K)))   --sinr(0.510) = 0.488
print(string.format("vom Bogenmass mit muldiv: sin(%d) = %d", winkel_rad, imath.sinr(winkel_rad))) --sinr(0.524) = 0.500
print(string.format("vom Bogenmass mit rad() : sin(%d) = %d", winkel_rad, imath.sinr(winkel_rad))) --sinr(0.524) = 0.500
print(string.format("vom Winkel in Grad      : sin(%d) = %d", winkel_deg, imath.sind(winkel_deg))) --sind(30°)   = 0.500

Erstellt in 0.007 Sekunden, mit GeSHi 1.0.8.9

Grüß rudi

[Sinter]

Hallo zusammen,

vielen Dank für die interessanten und aufschlussreichen Hinweise.

Bei der Zeitzone war ich davon ausgegangen, den OSD-Code an einer Stelle von Twilight eingeklinkt zu haben, an der die Zeitzone bereits ins Zeitsystem einberechnet ist. Hier muss ich mir den Code von Msl nochmals genauer ansehen um die konkrete Ursache zu finden, weshalb meine Daten eine Stunde vorlaufen. Ich hoffe, die notwendigen Änderungen sind nicht zu kompliziert.

Den Skriptabbruch bei der Verwendung von GeoDaten nördlich von München, hatte ich fast schon befürchtet. Hier hätte ich die manuelle gesetzten Grenzen einer bestimmten Programmschleife weniger ausreizen sollen. Mittlerweile plane ich einen Workaround, um diese Problematik mittels eines Automatismus zu lösen.

Unerwartet kommt für mich die Aussage, die Grafik würde bei Neuaufbau manchmal unvollständig sein. Diesen Sachverhalt konnte ich bei mir bislang nicht beobachten. Möglicherweise sind auch nur bestimmte Kameramodelle davon betroffen. Einzig Vergangenheitsdaten verschwinden natürlich wie geplant. Vergangenheitsdaten tauchen hierbei links von der 12-Uhr-Position jeweils weg und deren Eventscheiben sind dann nicht mehr zu sehen.


Das Gleichungssystem mit K hatte ich aus einer anderen Quelle einfach übernommen. Hier muss ich mir noch ansehen, ob ich hier zuerst versuche, die Gleichungen vorab bereits zu optimieren, oder zuerst einfach nur mal die suboptimale Version funktionsfähig zu bekommen.


Die Aussage, wir können nicht alles in ein einziges Skript packen, mag richtig sein. Aktuell ist es vielleicht auch eine Chance für uns, die Grenzen des Machbaren exakter auszuloten. Denkbar wäre durchaus, das Live-OSD auch als Stand-alone-Skript zu realisieren. Andererseits setzt das Skript ohnehin viel des Twilight-Skriptcodes voraus (Einstellmöglichkeiten der Geo-Daten etc.).
Vielleicht könnte man daneben auch mal probieren, den Skriptcode des OSD als separaten File zu hinterlegen und ihn mittels des Befehls dofile() aufzurufen. Ob das jedoch das Speichermanagement vereinfacht, oder vielleicht umgekehrt noch mehr fordert, ist mir unbekannt. Auch frage ich mich, wie hier eine Parameterübergabe programmtechnisch auszusehen hätte, und ob man dann aus dem separaten Sub-Skriptcode heraus auf die functions des Master-Skripts zugreifen könnte. Bisher kenne ich noch keine Anwendung, die auf Scriptcode eines separaten Files zugreift und was man bei der Umsetzung alles berücksichtigen müsste.


Nochmals zu Rudis Befehlen:
Es hat den Anschein, dass aktuell das Auflösungsvermögen von Rudis Winkelbefehlen bei der Berechnung des aktuellen Höhenwinkels im Skript für das OSD teilweise noch besser ausgeschöpft werden kann. Für das bisherige Twilight war das zweitrangig, für das OSD hingegen durchaus ein zu berücksichtigender Vorteil. Falls ich die Sache korrekt interpretiere, so können wir bei der aktuellen Auslegung des Twilight-Gleichungssystems bei der Berechnung des Höhenwinkels bis hinunter auf 3,6 Sekunden Input-Genauigkeit der Uhrzeitdaten auflösen. Ich werde versuchen, dies in einer weiteren Optimierung des OSD auszuschöpfen und umzusetzen.


Kann man eigentlich die bisherige normale Grafik auch noch mit der objektorientieren Grafik kombinieren? Das würde eventuell ermöglichen, die Darstellung ruhiger und flüssiger zu gestalten.

Ein paar andere Aspekte gilt es beim OSD ohnehin noch zu optimieren, bzw. hinzuzufügen.

Vielen Dank und viele Grüße,
Sinter

[msl]

Hallo Sinter,

Die Grafikprobleme solltest du erst mal vernachlässigen. Das ist in erster Linie ein Problem neuerer Kameras, was sich später durch geschickten Einsatz von sleep() weitestgehend abstellen lässt.

Wenn du mit objektorientierter Grafik die Lua-Bibliothek drawings.lua meinst, würde ich sagen, die hilft uns nicht weiter. Die basiert auf vielen speicherintensiven Tables. Ich hatte anfänglich bei Twilight damit experimentiert. Es gab aber laufend Skriptabbrüche wegen Speichermangels.

In der aktuellen Twilight-Version sind alle zum aktuellen Geo-Datensatz dazugehörigen Variablen global definiert (Lat, Lon, DoY, Tz), damit man sie ohne größere Umstände übernehmen kann. Das trifft auch für die Zeitzone zu. Diese wird in Minuten angeben. Du brauchst also nur die Variable Tz für die Zeitzone zu deiner Uhrzeit hinzuzufügen.

Achte bitte beim aktuellen Twilight-Skript darauf, dass die Funktionsparameter für Berechnungsfunktionen etwas umgestellt wurden. Wir wollten damit einer einheitliche logische Reihenfolge im gesamten Skript näher kommen.

Über die evt. Aufteilung in Skriptmodule können wir uns zu einem späteren Zeitpunkt verständigen. Wahrscheinlich ist dazu noch ein Konzept notwendig, wie die notwendigen Informationen von Modul zu Modul übergeben werden.

Gruß msl

[Sinter]

Hallo zusammen,

vielen Dank für die Info. Ein paar Dinge habe ich nun geändert:

Deutschland müsste jetzt mittels einer eingebauten Automatik für das Setzen der Schleifengrenze der Nachtevents funktionieren. Dadurch werden nun auch in der Regel sämtliche ganzzahlige Nachtevents als Eventscheiben angezeigt. Boolsche Ergebnisse werden aktuell aber noch nicht abgefangen. (Kopenhagen)

Die grafische Höhenwinkelanzeige rechts oben habe ich um den Sonnentiefststand ergänzt (untere rote Linie).

Rechts unten hatte ich für den Azimut einen Versuch mit dem neuen Gleichungssystem gewagt. Das läuft aber noch nicht rund. Ich habe wie von Rudi empfohlen, ohne K auszukommen versucht. Aktuell gibt es immerhin ein Ergebnis für den Azimut von 270, aber ich habe noch Zweifel....

Ungereimtheiten gibt es auch noch bei der Berechnung der Höhe mittels des alternativen Gleichungssystems. Über dem Kompass blende ich derzeit versuchsweise die alternativ berechnete Höhe als ungerundete Ganzzahl ein. Aber die alternative Berechnung der Höhe (und Azimut) gehört noch weiter geprüft. Da ist wohl mindestens noch ein Bug drin.

Zur Fehlersuche habe ich einige Konsolenausgaben eingefügt, welche die Grafik derzeit teilweise überlagern.

Alles ist noch im alten Twilight-Code platziert. Die Ãœbertragung in den neuen Twilight-Code steht noch aus.

Die Beseitigung des fehlerhaften Voreilens um eine Stunde habe ich noch kurz zurückgestellt. Ich denke, das verknüpft man am besten mit der Übertragung auf den neueren Code.


EDIT: alte Datei entfernt. Aktuelles Live-OSD in den aktuellen Beiträgen

Viele Grüße,
Sinter

[msl]

Hallo Sinter,

vielen Dank für die neue Skriptversion. Ich habe diese jetzt als Basis genommen, um deine Live-OSD-Funktion in das Twilight-Skript zu integrieren. Zwecks besserer Analyse ist diese Skriptversion unter neuem Namen zu finden: tw_l-osd.lua.

Wie immer bei diesem Projekt sind alle Dateien im Subversionskontrollsystem zu finden.

Projekt: http://trac.assembla.com/chdkde/browser ... s/twilight

tw_l-osd.lua: http://trac.assembla.com/chdkde/browser ... _l-osd.lua (Download ganz unten auf dieser Seite)

Beschreibung: http://trac.assembla.com/chdkde/browser ... /usage.txt

Was habe ich nun gemacht?

Programmiertechnische Informationen: Neustrukturierung der Hauptfunktion, indem die Funktion in lokale Variablen und Funktionen sowie den eigentlichen Routinen geordnet wurden. Alle Farbwerte beziehen sich jetzt auf globale Konstanten. Alle Variablenbezeichnungen wurden gekürzt und in englisch gehalten (mögliche internationale Vorstellung des Skripts). Viele Terme wurden zusammengefasst. Nicht notwendige "Zwischenberechnungsvariablen" habe ich entfernt. Die Winkelanzeige habe ich auf Grad, Minuten umgestellt, da wir dafür schon eine gute Funktion haben.

Die eigentlichen Berechnungen blieben mit Ausnahme der Berücksichtigung der booleschen Werte für Polar- und Mittsommernacht unangetastet.

Ich habe eine neue Bedienerfunktion eingeführt, mit der man zwischen Kamera- und lokaler Ortszeit umschalten kann.

Benutzerinformationen: Die Live-OSD-Anzeige lässt sich über das CHART-Menü erreichen. Also 2mal [DISP] nach dem Skriptstart drücken und das Live-OSD wird angezeigt. Mit [SET] kann man zwischen Kamera- und lokaler Ortszeit wechseln. [MENU] beendet diesen Programmteil.


Es scheint so, das wir uns vorläufig nicht damit beschäftigen müssen, was den Speicherbedarf angeht.Trotzdem sind noch einige Dinge zu tun. Allererste Aufgabe wäre die Verschmelzung von sun_pos() und sun_position(), um den Azimut-Wert effektiv zu ermitteln. Unklar ist für mich die doppelte numerische Höhenwinkelanzeige.

Wenn wir dann mit der Sonne fertig sind, können wir uns dem Mond widmen ...

Gruß msl

[Werner_O]

Hallo msl,

Es scheint so, das wir uns vorläufig nicht damit beschäftigen müssen, was den Speicherbedarf angeht.

An meiner SX20 startet das neue Skript tw_l-osd.lua erst gar nicht wegen not enough memory.

Das nur zur Info,
liebe Grüße
Werner_O

[Sinter]

Hallo Msl,

vielen Dank für das Einklinken des OSD in Twilight. Offline hatte ich am Wochenende ebenfalls daran gearbeitet und noch einige Sachverhalte weiter optimiert. Ich habe schnell versucht, auch meine Weiterentwicklungen in deinen neuen Code einzuarbeiten.

Auch bei meiner Weiterentwicklung war mir aufgefallen, allein die Automatik für die Nacht-Sonnenwinkel reichte doch noch nicht aus, um manche Skript-Abbrüche in den Griff zu bekommen. Inzwischen fing dann auch ich noch die Boolschen-Ergebnisse ab. Abbrüche sind bei mir nun bisher nicht weiter aufgetreten. Das dürfte bei deiner Lösung ebenfalls robust sein.

Eine kleine Sache fällt mir auf: Nach deinen Veränderungen am OSD-Code sind die FiveMinuteMarks im inneren Kranz kaum mehr sichtbar. Aktuell existiert bei mir im inneren Kranz nur noch eine einzige Markierung auf der 3-Uhr-Position. Ist das bei deiner Kamera auch so? Im Code von dir sehe ich auf den ersten Blick keinerlei Fehler. Die Programmschleife hast du korrekt übernommen. Merkwürdig, ich habe keine Erklärung weshalb dann ausschließlich die Markierung auf 3 Uhr erkennbar ist. Kannst du vielleicht einen Bug erkennen, der die Anzeige fehlmanipuliert? Wurde vielleicht die Reihenfolge der Einblendungen etwas verändert und die Markierungen werden von den Eventscheiben ( im inneren Kranz) übermalt?

Die Skalenwerte der Blaue-Stunde-Winkel hast du in der Fortschrittsanzeige auf der linken Seite erst mal weggelassen. Das ist eine optisch interessante Alternative für all jene, welche die Fortschrittsanzeige auch ohne Zahlen zu deuten wissen. Im Sinne der Bedienungsfreundlichkeit hatte ich ursprünglich geplant, dieses (klein zu haltende) Fortschrittsdiagramm jederzeit im Aufnahmemodus einblenden zu können, damit man während der blauen Stunde auf kürzestem Bedienungsweg über den Fortschritts-Status der Blauen Stunde informiert ist.
Das ist auch der Grund für die (vorerst) doppelte numerische Höhenwinkelanzeige. Der User könnte mittels Parameter vorab bestimmen, welche Anzeigeart er gerade benötigt. Die linke Fortschrittsanzeige benötigt wenig Platz auf dem Display und unterrichtet über den aktuellen Fortschrittsstatus der Blauen Stunde. Wer hingegen für seine Zeitplanung während eines Blaue-Stunde-Shootings auch eine Zeiteinschätzung benötigt/wünscht, wie lange es noch dauert, bis eine konkrete Blaue-Stunde-Intensität (bzw. Winkelstellung) erreicht wird, der erhält mit der Zifferblattanzeige der einzelnen Events die gewünschten Infos. So könnte man den User mittels Parameter wählen lassen, welche Anzeigegrafiken er eingeblendet haben möchte. Daher hatte ich bei beiden (!) Anzeigevariationen oben drüber jeweils eine numerische Winkelanzeige gesetzt.

Denkbar wäre noch, eine Anzeige in Grad und Minuten abzubilden, und die andere Anzeige in Dezimalform zu realisieren. Links in Dezimalform um möglichst kleinflächig zu sein, und mittig über dem Zifferblatt in Grad und Minuten. Du hast Recht, astronomisch korrekt sind natürlich Winkel-Angaben in Grad, Minuten etc. Andererseits lässt sich ein Fortschreiten eines Winkels gedanklich etwas leichter in Dezimalform verfolgen. Beides hat seine Vor- und Nachteile. Zur Not lassen sich auch beide Alternativen problemlos mittels Parameter optional wählbar gestalten. Nebenbei: Bei der Minutenanzeige würde ich befürworten, die Minuten hier im OSD grundsätzlich zweistellig anzugeben um beim Anwender gedankliche Irrungen zu vermeiden. Sonst verleitet eine einstellige Anzeige von bspw. 18°5' irrtümlich leicht zu der Annahme, der Winkel liegt eher mittig zwischen 18 und 19° oder auch ähnlich wie 18°50'. Wir können sicher sein, viele Anwender sind überhaupt nicht mit Winkelangaben in Grad und Minuten vertraut, sondern versuchen, jegliche numerische Anzeige als Dezimalform zu „lesen“.


Am Wochenende hatte ich die Auflösung der Input-Zeiten weiter optimiert und konnte daher meinen Workaround zur behelfsmäßigen Feinsteuerung auskommentieren. Rudis neue Befehle lassen in der Systematik von Twilight eine Auflösung der Input-Zeiten bis auf 3,6 Sekunden zu. Dies schöpfte ich nun voll aus. Das ist mit Rudis Befehlen klasse. Nun könnten wir das OSD sogar alle 4 Sekunden aktualisieren, und die Eventscheiben wandern präzise in kleinsten (Pixel-)Schritten. Gut zu beobachten auf dem äußeren Kranz des Zifferblatts, wie die Eventscheiben in winzigen Pixelschritten nach und nach die einzelnen Minutenmarkierungen überstreichen, auch wenn das OSD aktuell weiterhin in 10-Sekunden-Abständen aktualisiert wird.

Verbessert wäre damit zugleich auch ein anderer Sachverhalt: Vorher konnte man im Live-OSD bei der Werteinblendung des Höhenwinkels beobachten, dass es bei der kontinuierlichen Berechnung der Höhe des Sonnenstands in der ersten Nachkommastelle zu Dezimalübersprüngen kommt. Offenbar steigt/sinkt die Sonne teilweise innerhalb einer Minute um mehr als 0,1 Grad. In der Nachkommastelle hatten wir bei aufeinanderfolgenden Berechnungen kein Kontinuum gewährleistet. Mit Ausschöpfung der Auflösung von Rudis neuen Befehlen könnten Dezimalübersprünge nun der Vergangenheit angehören. Wenn ich das nun auch auf die Winkelminuten übertrage, ergibt sich natürlich ebenfalls eine bessere Fortschrittsgenauigkeit der Winkelanzeige im OSD. Noch dazu bilden die "Minuten" mehr Genauigkeit ab, als eine einzige erste Nachkommadezimale. Mal sehen, wie kleinteilig sich nun die numerischen Winkelangaben ändern. Aber jetzt scheint das Gleichungssystem die Grenzen zu setzen.


Nebenbei: Der Sonnentiefststand in der Nacht (im Diagramm rechts oben die untere rote Linie) ist Richtung Polarregionen interessant, um den dunkelsten Tageszeitpunkt zu erfahren wenn bspw. die Sonne im Sommer nachts nur noch knapp unter den Horizont taucht und der Himmel nicht mehr richtig dunkel wird. Insofern könnte sinnvoll sein, diesen Zeitpunkt auch im deinem normalen Twilight-Main-Bereich zu listen. Den Zeitpunkt des Sonnentiefststands in der Nacht habe ich nun auch als schwarze Eventscheibe in die Eventanzeige integriert, damit man nun zusätzlich diesen dunkelsten Tageszeitpunkt ablesen kann. Aktuell noch als einfache "Näherung", indem ich unterstelle, der Zeitpunkt liegt genau 12 Stunden zum Zenit versetzt. (Vielleicht ersetze ich dies demnächst noch durch eine präzisere, aber deutlich aufwendigere Näherungsberechnung.) Im Innenkranz des OSD berühren sich daher die gelbe und die schwarze Eventscheibe (und liegen naturgemäß auf verschiedenen Bahnen). Ich musste auch noch etwas Programmcode hinzufügen, denn ich sah gerade, da muss zusätzlich noch die schwarze Eventscheibe für einen weiteren Tag später berechnet und einfügt sein.
Vielleicht kannst du ja kurz prüfen, ob ich meinen Skriptcode mit der Eventscheibe des Tiefststands korrekt in dein Codesystem "übersetzt" habe.


Erleichtert bin ich über deine gelungene Ankettung des OSD an das Zeitensystem von Twilight, denn die Zeitensystematik innerhalb von Twilight scheint an manchen Stellen elegant tricky programmiert zu sein und für einen Dritten nicht so leicht zu durchschauen. Die Anbindung scheint dir perfekt gelungen zu sein. Danke!

Die Verschmelzung der beiden functions zur Berechnung der Sonnenposition muss gut überlegt werden, denn die zweite function (mit dem Azimut) verwendet ein anderes Gleichungsmodell und sollte eigentlich ausschließlich zur Berechnung des Azimut dienen, liefert aber nebenbei auch noch einen Höhenwinkelwert den man interessehalber mit unserem bisherigen Wert vergleichen könnte. Allerdings bin ich mit den Berechnungsergebnissen des alternativen Gleichungssystems beim Azimut noch nicht glücklich. Da gehört wohl noch die Zeitzone oder andere Zeitenvariablen aus Twilight zusätzlich berücksichtigt. Ich habe zwar aktuell wieder Bugs aus dieser function beseitigt, aber die Berechnung ist noch immer nicht in Ordnung. Vielleicht bewegt sich das Gleichungssystem außerhalb der Limits von Rudis neuen Winkel-Befehlen. Das schließe ich jedoch eher aus. Ich vermute hier eher noch kleine Bugs, entweder in der Übersetzung der Gleichungen in Rudis Befehle, oder/und in der Einbindung in das Twilight-Zeitensystem.

Aktuell dürfte Version "tw_l-osd_2.lua" die Basis für weitere Optimierungen sein. TODOs wären u. a. Azimut und Wiedererlangen der Markierungen im inneren Kranz.

Edit:
Ups, mit „tw_l-osd_2.lua“ bekomme ich gerade (gegen 16:00 Uhr) einen Fehler gemeldet, der vorhin noch nicht auftrat:
887: bad argument #1 to ‚abs‘ (number expected, got nil)
Scheint von der Uhrzeit abhängig zu sein.

Die Fehlermeldung tritt ebenfalls mit "tw_l-osd.lua" auf.
Keine Fehlermeldung mit "twiOSDdeg_5.lua".

EDIT: alte Dateien entfernt. Aktuelles Live-OSD in den aktuellen Beiträgen


Vielen Dank und viele Grüße,
Sinter

P.S.: Angesichts der Speicherprobleme des SX20-Modells kann Twilight demnächst ein Experimentierumfeld bieten, falls sich mittels dofile() ein Add-on-Code einbinden lässt.

[msl]

Hallo Sinter,

vielen Dank dass du dich gleich auf "meine" Version eingelassen hast. Aber jetzt haben wir eine einheitliche Basis und die zusätzliche Anpassungsarbeiten gehören der Vergangenheit an. Deine Änderungen und diverse Korrekturen sowie ein paar organisatorische Änderungen sind in der aktuellen Version eingearbeitet.

tw_l-osd.lua: http://trac.assembla.com/chdkde/browser ... _l-osd.lua (Download ganz unten auf dieser Seite)

Zur besseren Unterscheidung hat dieses Skript jetzt den Titel Twilight live. Außerdem habe eine Revisionsnummer für "Live OSD" eingeführt.

Eine kleine Sache fällt mir auf: Nach deinen Veränderungen am OSD-Code sind die FiveMinuteMarks im inneren Kranz kaum mehr sichtbar. Aktuell existiert bei mir im inneren Kranz nur noch eine einzige Markierung auf der 3-Uhr-Position. Ist das bei deiner Kamera auch so? Im Code von dir sehe ich auf den ersten Blick keinerlei Fehler. Die Programmschleife hast du korrekt übernommen.

Das ist bei mir auch so. Ich habe bewusst keine Änderungen an deinem berechnenden und darstellenden Code vorgenommen. Fehler sind aber trotzdem nicht ausgeschlossen.
Edit 29.1.13:00Uhr: Fehler lag bei mir. Ich hatte die Berechnung falsch zusammengefasst. Ist wieder hergestellt.

Die Skalenwerte der Blaue-Stunde-Winkel hast du in der Fortschrittsanzeige auf der linken Seite erst mal weggelassen. Das ist eine optisch interessante Alternative für all jene, welche die Fortschrittsanzeige auch ohne Zahlen zu deuten wissen.

Auch hier habe ich keine geplante Veränderung vorgenommen. Das Fehlen der Skalenwerte war mir garnicht aufgefallen. Jetzt stellt sich tatsächlich die Frage, welche Variante ist besser?
Edit 29.1.13:00Uhr: Fehler lag bei mir. Ich hatte die Schleife versehentlich gelöscht. Ist wieder hergestellt.

Ups, mit „tw_l-osd_2.lua“ bekomme ich gerade (gegen 16:00 Uhr) einen Fehler gemeldet, der vorhin noch nicht auftrat:
887: bad argument #1 to ‚abs‘ (number expected, got nil)
Scheint von der Uhrzeit abhängig zu sein.

Diesen Fehler hatte ich auch. Er trat das erste mal auf, als ich begann, die Funktion zur Auswahl von Orts- und Kamerazeit zu integrieren. Da er dann aber nicht mehr vorkam, nahm ich an, der Fehler ist behoben. Das ist wohl ein Trugschluss gewesen.

ToDo:

- Azimut
- Darstellung innerer Kranz 5-Minuten-Einteilung ist wieder hergestellt.
- Darstellung Skalenwerte (ja/nein?, optional?) Anzeige wieder hergestellt.
- Darstellung numerischer Wert Höhenwinkel (2fach?, dezimal?, 1x dezimal 1x °'?, Minuten 2stellig)
- Abfangen Skriptfehler
- Optimierung Speicherbedarf (not enough memory)

Gruß msl

[Sinter]

Hallo Msl,

die eingeklinkte "Version" hat sich inhaltlich nicht groß verändert. Entscheidender Meilenstein war zunächst, das Live-OSD korrekt an das Zeitensystem von twilight anzuhängen.

Offline habe ich mir ebenfalls nochmals in Ruhe das Skript angesehen, um den Tücken nachzugehen. Die beim Einbinden entstandenen Bugs waren dann tatsächlich zu identifizieren. Bei ganz genauem Hinsehen fiel mir auf:
Einerseits fehlte bei der Blauen Stunde der event_angle von 0 für die Berechnung bei Sonne am Horizont. Den Wert müssen wir als Argument einer Function übergeben. Ich vermute, das war der Auslöser für den Skriptabbruch. Bin mir aber noch nicht ganz sicher. Im Fehler wurde ja nil gemeldet. Müsste die Variable aber nicht noch immer den letzten Wert der for-to-Schleife besitzen? Aber es könnte sein, dass Lua nach so einer Schleife dann der Lauf-Variablen wieder nil zuweist.
Jedenfalls habe ich die Sache korrigiert und der Skriptabbruch trat nun bei mir nicht mehr auf. Dieses Problem dürfte nun bereinigt sein.

Zudem war ein ganz winziger Bug bei den fiveminutemarks des inneren Kranzes. Dort warst du der Verlockung erlegen,
/12*1000
durch
/NOON
zu ersetzen. Bei genauem Hinsehen fiel auf, dass dies mathematisch natürlich nicht der Reihenfolge der korrekten Rechnung entspricht (zuerst "geteilt durch 12", danach erst "mal 1000". Und nicht zusammengefasst "geteilt durch 12000"). Durch das Weglassen eines Klammerpaars hatte ich dich hier irrtümlich auf eine falsche Fährte gelockt. Auf den ersten Blick hatte ich bei deinem Code ebenfalls gedacht, ja das geht, clever, 12*1000 kann man ja durch NOON ersetzen. Erst bei genauem Hinsehen sagt einem dann das Unterbewusstsein: "Denkste".
Nebenbei habe ich noch die fiveminutemarks des inneren Kranzes verkleinert, damit nun auch die schwarze Eventscheibe des Tiefststands hinreichend erkennbar zur Geltung kommt.

Die Frage, wie weit das Einblenden der Skalenwerte für den User bedeutend ist, ist vom Wissensstand des einzelnen Users abhängig. Für unerfahrene User macht die Einblendung sicher Sinn. Wer hingegen die Grafik zu deuten weiß, für den reicht die optisch schön aufgeräumt wirkende Version ohne Skalenwerte aus. Ich denke, die Lösung ist ganz einfach: Wir lassen den User per Skript-Parameter einstellen, ob er die Skalenwerte eingeblendet haben möchte. Gleiches gilt aus meiner Sicht für die Auswahl der angezeigten Grafiken. Ich habe vier Grafiken und zusätzlich die Schatten-Info. Alles zusammen schenkt dem User so ziemlich die vollkommendste Information. Während eines Blaue-Stunde-Shooting sind hingegen fast ausschließlich die Zeitinformationen des Zifferblatts, sowie die aktuelle Intensität der Blauen Stunde (linke Grafik) bedeutend.
Das Live-OSD hatte ich auch mit dem Hintergedanken entworfen, falls programmtechnisch möglich, es evtl. auch nicht nur als Skript aufzurufen, sondern es als weiteres CHDK-Feature unmittelbar in CHDK zu integrieren und dort für den User optional anzeigen zu lassen. Ähnlich wie die Batterieanzeige, Speicherbelegungsbalken, Temperatur etc. Daher hatte ich links die erste Grafik möglichst platzsparend an den linken Rand angeschmiegt. Aber nachdem so eine schmale Grafik keine hinreichende Zeitenabbildung der Events bieten kann, musste zusätzlich eine aufwendige andere Lösung her und ich bin auf die Idee gekommen, die Ereigniszeitpunkte der einzelnen Höhenwinkel innerhalb eines Zifferblatts zu visualieren. So lassen sich visuell die Zeitpunkte sämtlicher Ereignisse der nächsten 24 Stunden ablesen. Zugleich gewährleistet das Zifferblatt, dass der User bereits gedanklich auch unterbewusst damit vertraut ist, je nach Platzierung innerhalb des Zifferblatts ein Gefühl für die Zeitdauer bis zum Eintreten der platziert angezeigten Events zu besitzen.

Angesichts einer möglichst perfekten Usability, hier noch eine kleine weitere Ergänzung als Todo: Während die ausführlichen Textanzeigen von Twilight insbesondere der Vorplanung eines Shootings dienen, so kommt das OSD insbesondere während (!) des Shootings zur Anwendung. Daher sollten wir per Parameter optional einstellen können, bei Start des Skripts auch direkt (!) zum OSD durchzuschalten. Denn während eines Shootings hat man sicher wichtigere Dinge zu tun, als sich nach jedem Skriptstart noch zweimalig über die Display-Taste zu klicken bis man an das Live-OSD gelangt. Nachdem wir noch nicht in der Lage sind, das Live-OSD ähnlich wie die Batterieanzeige etc. direkt in CHDK einzublenden, so sollte man zumindest mittels Skriptstart bereits optional direkt zum OSD durchstarten können, ohne weitere Tasten betätigen zu müssen.
z. B.:

@param z Skriptstart zu
@default z 0
@values z TwilightDaten LiveOSD

Ein Schnellausstieg aus dem OSD wäre ebenfalls nicht schlecht. Andererseits gibt es diesen bereits mittels Skriptabbruch durch ShootFull. Wie ist deine Meinung dazu?

Nachdem wir schon bei Parametern sind, möchte ich an dieser Stelle gerne erneut aufgreifen, dass ich mir wünschte, wir könnten in CHDK bei den Skript-Einstellungs-Parametern zusätzlich auch Textzeilen einblenden. Hier könnten uns die Programmierer einen großen Gefallen tun, damit wir den Usern mittels Zwischenüberschriften die einzelnen Parameter ordentlich zueinandergehörig gruppieren können:

akt. Datum verwenden
*****Falls anderes Datum:******
Jahr
Monat
Tag
****** Zeitbasis: ************
Sommerzeit
Zeitzone in Min?
**************************
Speicher-Anzeige?
**************************
****Live-OSD-Einstellungen:****
Skriptstart mit LIVE-OSD
Skalenwerte einblenden
Auswahl der Grafiken

Dies nur als theoretisch mögliches umfassendes Beispiel mehrerer zwischengeschalteter Zeilen. Alle Textzeilen mit Sternchen besitzen hier keine weitere Funktionalität, sondern dienen jeweils ausschließlich zur kostbaren Gruppierung und Erklärung der Parameter. Thematisch gruppierte Parameter wären für viele User sicher einfacher zuzuordnen um zu wissen, wo sie welche „Schraube“ suchen müssen, um daran zu drehen.
Unsere Skripte werden ohnehin zunehmend aufwendiger werden. Ich denke, wir brauchen daher so eine Textzeilen-Möglichkeit bei den Parametern zwingend, um die Usability weiter zu optimieren.


Die Schattenanzeige ganz rechts oben habe ich von Prozent auf eine "Faktor"-Anzeige umgestellt. Ich denke, es ist für den User gedanklich eingängiger, hier einfach bspw. von einem Wert "2" auf doppelte Länge zu schließen. Und bei flacher stehender Sonne würden Prozentwerte erst recht unübersichtlich hoch (und damit lang) werden. Mal sehen, ob ich hier nun einen Bug drin habe, oder ob das alles bereits korrekt programmiert ist.

Die numerischen Werte des Höhenwinkels habe ich nun gesplittet. Links verwende ich das Dezimalsystem, beim Zifferblatt hingegen Grad und Minuten. Dabei fiel mir auf, dir ist der gleiche kleine Bug unterlaufen wie mir, als ich die Dezimalanzeige programmierte. Anfangs wurde bei meiner Dezimalanzeige bei Werten zwischen kleiner 0 und größer -1 das Minus-Vorzeichen weggelassen. Diesen Bug hatte ich bei mir dieser Tage gelöst. Aktuell habe ich gesehen, auch deine Twilight-function zur Darstellung von Grad und Minuten leidet unter diesem Bug, sowohl bei der Verwendung über dem Zifferblatt, und auch in der Seite "Informationen". Bei meiner Dezimalanzeige hatte ich zur Lösung eine weitere Programmzeile vorgeschaltet. Falls man mit tonumber() auch Boolsche Werte in rechenbare 0/1-Werte umwandeln könnte, so wäre auch noch eine elegante Lösung ohne Zusatzzeile denkbar.

Den Horizont der Höhenwinkelanzeige in der Grafik rechts oben habe ich in der Farbgebung der Wand angepasst.

Zusätzlich habe ich noch das Ereignis des visuellen Sonnenaufgangs/-untergangs eingefügt, welches die Lichtbrechung berücksichtigt. Sonst wäre verwirrend, dass bei den Eventscheiben der Zeitpunkt für 0° ein anderer ist, als der Sonnenaufgangs-/-untergangszeitpunkt in deiner angezeigten Zeitenliste, welche bei diesem Ereignis die Lichtbrechung einkalkuliert.

Ansonsten habe ich noch ein paar Kleinigkeiten weiter optimiert.

Der Azimut steht weiter auf der TODO-Liste, und ein paar weitere kleine Optimierungen sind mir auch noch eingefallen.

Anbei die aktuellste Skriptversion des Twilight-Live-OSD. EDIT: Alte Datei entfernt

Viele Grüße,
Sinter

[msl]

Hallo Sinter,

deine neueste Version ist gespeichert. Vielen dank dafür. Vielleicht kannst du die alten Versionen heraus nehmen.

Sehr gut hast du die Sache mit event_angle analysiert und korrigiert. Die Umstellung der Schattenangabe von Prozent auf Faktor ist eine gute Idee.

Einen Schnellzugriff auf die Live-OSD-Anzeige können wir besprechen, wenn die Funktion in Sachen Darstellung und Berechnung fertig optimiert ist. Ein optionaler Direktzugriff ist einfach zu realisieren. Ich sehe eher Probleme bei der Darstellung im Aufnahmemodus. Gerade neuere Kameras haben sehr viele Einstellmöglichkeiten über das FUNC.SET-Menü, was dann links eingeblendet wird. Schauen wir mal, was sich in der praktischen Anwendung ergibt.

Ich habe die Ausgabe der numerischen Werte noch einmal überarbeitet und sun_position() vollständig auf Grad-Berechnung umgestellt. Die restlichen Änderungen dienen ausschließlich der Platzeinsparung bei den Kommentierungen, damit die Skriptdatei nicht zu groß wird.

aktuelle Version:

tw_l-osd.lua: http://trac.assembla.com/chdkde/browser ... _l-osd.lua (Download ganz unten auf dieser Seite)


ToDo:

-Azimut
- Optimierung Speicherbedarf

Gruß msl

[Sinter]

Hallo Msl,

ja, vielen Dank, das Zusammenfassen des Codes zur Speichereinsparung ist vernünftig umgesetzt.

Anbei nun eine weiter optimierte Version des Live-OSD.

Im linken Instrument habe ich nun die Wertanzeige mobil schleppend an die gelbe Anzeigenadel programmiert. Hier reicht eine Nachkommastelle. Diese Formatierung lässt sich sicher auch mittels deines neuen Formatierungstools identisch darstellen.

Zudem habe ich im linken Instrument das unterste Anzeigefeld für die Nacht grün eingefärbt, analog der grünen Eventscheiben für die Nachtevents. Es gewährleistet die leichtere gedankliche Zuordnung des nächtlichen Sonnenhöhenstatus' zu den Nachtevents.

Beim Schattenwert dürfte nun für den User mittels der Einblendung
h*
intuitiv erfassbar sein, dass die Anzeige (mit zwei Nachkommastellen) die Länge des Schattens als Faktor einer Höhe eines Gegenstands darstellt. Die Anzeige wechselt bei Überschreiten des Faktors über den Wert 999 hinaus zur Meldung, dass der Schatten gegen unendlich geht.

Neben kleinen optischen Retuschen habe ich noch die Einblendung des Tiefststands des Vortags als Eventscheibe einprogrammiert. Sonst könnte kurz nach Mitternacht der Fall eintreten, dass in der aktuellen Nacht kein Tiefststandsevent angezeigt wird.

Über dem "Azimutkompass" sind nun während der „Baustelle“ vorübergehend Zwischenwerte des alternativen Gleichungssystems eingeblendet, welche mittels Dummyvariablen der Zeit errechnet werden. Die Werte kann man mit dem Excel-Sheet aus der Quelle vergleichen, bzw. im Skriptcode bei der function sun_position() eigene Dummyvariablen setzen.

Für die aktuellen Dummyvariablen (und München als Location) würde Excel berechnen für
Höhe= 20.9
y_= -0.9159
Azimut= 203.7

Mit den Gleichungen und Rudis Befehlen liegen wir mit der Höhe 21345 (scaled) recht nahe am Excel-Wert.
y_ und Azimut sind noch offen.

In die Gleichung von y könnten wir auch den Sinus der Höhe unseres bisherigen Gleichungssystems einsetzen. Deklination eventuell ebenfalls. Ob wir jedoch mit den einzelnen Zwischenergebnissen in den Gleichungen noch immer innerhalb des Gültigkeitsbereichs von Rudis Winkelbefehlen liegen, ist offen.


EDIT: Alte Skriptversion entfernt. Die neueste Version findet sich in den laufenden Beiträgen weiter unten.

Viele Grüße,
Sinter

[msl]

Hallo Sinter,

deine aktuelle Version ist ins SVN eingelesen. Vielen Dank dafür.

Ich habe mich wiederum der Formatierungen angenommen und versucht, die Azimut-Berechnung gangbar zu machen. Scheinbar bin ich der Lösung nun etwas näher gekommen. Jedenfalls zeigt der Azimut-Kompass nun schlüssige Ergebnisse.

Edit 3.2.2013:
Optionale 16:9-LCD-Darstellung für Live-OSD integriert. Routinen und Kommentierungen im Sinne einer kleineren Skriptdatei zusammengefasst.

tw_l-osd.lua: http://trac.assembla.com/chdkde/browser ... _l-osd.lua (Download ganz unten auf dieser Seite)

ToDo:

- Azimutberechnung verifizieren und vereinfachen (evt. Höhe aus vorhandener Funktion).
- Speicherbedarf
- statische Skriptgröße verkleinern

Gruß msl

[Sinter]

Hallo Msl,

vielen Dank für die Umsetzung der Azimut-Gleichung in Rudis Befehle. Die berechneten Werte sehen nun plausibel aus. Jetzt kommt zur Geltung, wie sich die Sonnenscheibe im Tagesverlauf winkeltreu um den Kompass bewegt.

Anbei die neueste Version des Live-OSD. Das Live-OSD habe ich in einigen Punkten nochmals weiter optimiert:

String-Anzeigen habe ich in ein gefälligeres Form-Design gekleidet und teilweise etwas umplatziert.

Eine Anzeige der eingestellten Standorts (Location) wurde hinzugefügt, denn der User muss unterwegs bei spontaner Anwendung erkennen können, ob das Live-OSD für die Berechnungen die Daten den gewünschten Ort als Berechnungsgrundlage heranzieht, oder ob er einen neuen Standort als Bezugspunkt einstellen möchte. Diese mögliche Fehlerquelle in der Anwendung wäre damit vermieden.
Zu klären: Koordinaten aus dem GPS könnte man ebenfalls in einen Location-String umwandeln und dann die GPS-Koordinaten als Location einblenden.

Die Anzeige des Höhenwinkels über dem Zentralinstrument habe ich optisch an das Zifferblatt „geschmiegt“. Vorher schwebte der Höhenwinkel als Klötzchen über dem Zifferblatt.

Die Skalenwerte des linken Blaue-Stunde-Instruments sind nun in Analogie zur Blauen Stunde entsprechend blau hinterlegt. In der Skala habe ich knapp über der „-1“-Marke eine kleine rote Markierung für den Höhenwinkel des „Visual Sunrise/Sunset“ eingefügt. Sie verdeutlicht dem User den Punkt des in deinem Twilight-Skript berechneten optischen Sonnenauf-/-untergangs, welcher die Lichtbrechung der tiefstehenden Sonne berücksichtigt.

Im Zentralinstrument sind (vorerst zur Abklärung eventueller Bugs) die Eventscheiben der nächtlichen Events jenseits der Blauen Stunde verschieden eingefärbt:
Hellgrün sind die Ereignisse der heutigen Nacht(-hälfte).
Ereignisse der morgigen Nacht (im Sinne von: zeitlich nach einer bevorstehenden Mitternacht) sind dunkelgrün.
Ereignisse der gestrigen Nacht werden ebenfalls in einem dunkleren Grün angezeigt.

Im endgültigen Live-OSD könnte sinnvoll sein, diese Unterscheidung wieder rückgängig zu machen und sämtliche nächtlichen Ereignisse wie bisher hellgrün einzufärben.

Die Anzeige von Daten auf den Eventscheiben im äußeren Kranz habe ich auf Strings umgestellt. Der Sonnen-Tiefststand wird nun mit „Lo“, und der Zenit mit „Ze“ gekennzeichnet.


Eine Sache ist mir bei der Zeiteneinbindung noch etwas unklar: Du hattest beim Einbinden des OSD in das Zeitensystem von Twilight zwischen Kamerazeit und Lokaler Ortszeit (Umschaltung mittels „Set“) unterschieden. Was bewirkt das im OSD? Bei mir sehe ich keinen Unterschied, außer dass die Uhrzeitmeldung zwischen „K“ und „L“ umschaltet?


EDIT: Alte Skriptversion entfernt. Die neueste Version findet sich in den laufenden Beiträgen weiter unten.

Viele Grüße,
Sinter