Sonnenauf- & Untergang, Blaue Stunde - Berechnungen

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

Re: Sonnenauf- & Untergang, Blaue Stunde - Berechnungen

Beitragvon msl » 07.01.2013, 17:43

Hallo Sinter,

der von dir genannte Fehler tritt auf, weil du die beiden Geo-Daten-Dateien nicht aktualisiert hast. Da das System auf Minuten umgestellt wurde, kommt das aktuelle Skript nicht mehr mit den alten Dateien klar, weil dort die Angaben in Stunden bereitgestellt werden.

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

Re: Sonnenauf- & Untergang, Blaue Stunde - Berechnungen

Beitragvon Sinter » 09.01.2013, 12:56

Hallo Msl,

vielen Dank für den Hinweis. Ja, das war die Ursache. Jetzt wird das Diagramm bei mir sogar nochmals schneller gezeichnet: Dein Skript schafft das jetzt mit der Ixus60 in 0,99 Sekunden.

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, 13:16
Wohnort: München

Re: Sonnenauf- & Untergang, Blaue Stunde - Berechnungen

Beitragvon Belichter » 09.01.2013, 19:52

Allen noch ein gesundes Neues.

@msl
Danke für das perfekt gestaltete Skript.

Meine Ixus zeigt die Grafik jetzt in 1140ms, vorher 14790ms, was für eine grandiose Beschleunigung.

bis dann
IXUS 970 IS 100b
Belichter
CHDK-Begeisterter
CHDK-Begeisterter
 
Beiträge: 170
Bilder: 11
Registriert: 21.05.2009, 09:21
Wohnort: Solingen
Kamera(s): ixus 970 IS 100b

Re: Sonnenauf- & Untergang, Blaue Stunde - Berechnungen

Beitragvon Werner_O » 12.01.2013, 15:29

Hallo msl,

vielen lieben Dank für dieses tolle Skript, was ich heute unter v0.8.101 an meiner SX20 unter CHDK DE 1.2.0 2476 getestet habe.
Klasse Arbeit von Dir!

Positiv:
1) Die Rechengenauigkeit - bei deutschen Breitengraden max. 1 min Differenz zu meinem noch etwas genauer arbeitenden Programm "SUN" für die HP48/49 Taschenrechnerserie.
Angesichts der erschwerten Rechenverhältnisse unter CHDK (etwa nur Ganzzahlen etc.) ist das eine sehr hohe Genauigkeit und für die Praxis auch völlig ausreichend.
Man darf ja nicht vergessen, daß wegen der vereinfachten Rechengrundlagen sowieso noch +/- 3,5 bis 4 min Fehlertoleranz (für deutsche Breitengrade) dazugerechnet werden müssen.
2) Die Bedienführung ist so gut gelungen, daß eine zusätzliche Hilfedatei dazu m.E. gar nicht nötig ist.
3) Die Dateien "GeoUserD.txt" und "GeoData1.txt" lassen sich durch das einfach zu verstehende Format schnell an eigene Bedürfnisse anpassen.
Die Datei "GeoUserD.txt" habe ich etwa gleich auf meinen Heimatort Köln umgeändert und das funktioniert auch prima.
4) Auch die Kurven werden selbst mit meiner SX20 bereits innerhalb etwa 1 sec gezeichnet, wobei ich diese Funktion aber eher als "Gimmick" sehe ohne echte Praxisrelevanz.

Negativ (bitte als Verbesserungsvorschläge ansehen):
1) Die verwendete Lua-Zeichenfunktion führt bei meiner SX20 reproduzierbar zu keiner Anzeige beim ersten Skriptaufruf.
Bei Deinem Skript "AV-Plus" hatte ich ähnliche Probleme, welche dort durch einen größeren Wert für die Anzeigeverzögerung behoben werden konnten.
Auch bei diesem Skript sollte das auf ähnliche Weise behoben werden können - einige wenige Zehntel-sec mehr könnten eine stabile Anzeige auch bei älteren Kameras sicherstellen, wobei dieses wenige mehr an Zeit für den Displayaufbau für die Praxis m.E. irrelevant wäre.
2) Die Vorgabe für Köln in der "GeoData1.txt" ist nicht perfekt:
Bei BG 50,94° Nord und LG 6,96° Ost müßte die Wertevorgabe korrekt gerundet so aussehen: "Köln;509;70;60"
3) Bei manuellen Vorgabewerten für LG, BG und Zeitzone stört mich die zu lange Display-Anzeige für den Ort (dann "Benutzerdaten"), sodaß die Anzeige für die UTC +/- xyz dann bei mir nicht mehr sichtbar ist.
Dieser Bildschirmbereich links neben den Displaysymbolen für AV, TV, P oder M ist bei mir traditionell für den verbleibenden Speicherplatz in GB bzw. MB sowie darunter die Akkurestlaufzeit in Prozent reserviert, und ich kann diese Anzeigen auch nicht so einfach mal ausblenden. Das geht noch nicht mal mit "OSD Aus" im CHDK-Menü.
Eine Verkürzung der Bezeichnung "Benutzerdaten" auf "Benutzer" würde da bereits Abhilfe bieten.
4) Ansonsten fehlt m.E. in den Skript-Voreinstellungen noch die Möglichkeit, eine vorhandene "GeoData1.txt" automatisch bereits beim Skriptaufruf laden zu können.
Eine zukünftige zusätzliche Skriptoption diesbezüglich würde ich sehr begrüßen.
5) Der Zugriff auf die Kalenderfunktion führt bei mir reproduzierbar zu Programmabbrüchen mit der Fehlermeldung "not enough memory", sobald ich ca. 4 mal nach links oder rechts gedrückt habe für die Anwahl eines anderen Tages für die Berechnung.

Liebe Grüße
Werner_O
Zuletzt geändert von Werner_O am 12.01.2013, 18:19, insgesamt 1-mal geändert.
Benutzeravatar
Werner_O
CHDK-Legende
CHDK-Legende
 
Beiträge: 1027
Registriert: 22.10.2010, 13: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 » 12.01.2013, 17:06

Hallo Werner_O,

auf deine Analyse habe ich schon lange gewartet. Endlich Fakten, mit denen man etwas anfangen kann. Vielen Dank dafür.

Nun aber zu den angesprochenen Punkten (P=positiv, N=negativ):

P1:
Die Genauigkeit hat sich seit dem Themenstart deutlich verbessert. Was aber auch wichtig ist, bei unserem Skript werden mittlerweile Bereiche berücksichtigt, die bei der ursprünglichen Berechnungsgrundlage fehlerhaft sind, Stichwort Polarnacht, Mittsommernacht. Hier hat rudi ganze Arbeit geleistet.

P2:
Danke, die Hilfsdatei dient auch eher dem Ãœberblick.

P4:
Stimmt, das Diagramm ist eher ein Gimmik, aber trotzdem wichtig. Sie ist bei der Fehleranalyse (siehe P1) sehr hilfreich. Teste beispielsweise mal Breitengrade > 65°.

N1:
Das Skript ist generell für die Benutzung im Wiedergabemodus ausgelegt, da es bis auf 20 Pixel Breite ganz unten den gesamten Bildschirm nutzt. Es ist sozusagen eine Vollbildanwendung. Man sollte auch die CHDK-OSD-Elemente im Wiedergabemodus deaktivieren. Das ist aber eigentlich auch die Standardvorgabeeinstellung (CHDK_Einstellungen => OSD-Einstellungen => OSD-Anzeige [an], Ausnahme [in Play]).

Sollte bei Skriptstart dann nichts zu sehen sein, weil mal wieder irgendeine Kamerafunktion zugeschlagen hat, einfach eine Taste klicken und der Bildaufbau wird erneuert. Eine Verzögerung ist nicht vorgesehen.

In einer nächsten Version werde das Skript auch zwangsweise im Wiedergabemodus starten lassen.

N2:
Gut, das kann geändert werden. Sicherlich könnte man sich auch trefflich über die Werte streiten, je nach dem, welche Quelle als Basis genommen wird. ;)

N3:
Siehe dazu N1. Die Formatierung erfolgt immer auf Basis der Vollbildanwendung und der damit verbundenen Dimensionen.

N4:
Muss das wirklich sein? Abhilfe würde schaffen, wenn du einfach die Daten der Datei GeoData1.txt in die Datei GeoUserD.txt kopierst. Diese Datei wird automatisch geladen, wie du ja schon bemerkt hast. Eigentlich hatte ich mal vor, die Geo-Daten in verschiedene Dateien, sortiert nach Regionen, aufzuteilen.

N5:
Das ist schlecht und zeigt uns, das wir an die Grenze des Machbaren gestoßen sind. Die SX20 gehört zu den Kameras mit dem geringsten zur Verfügung stehenden Arbeitsspeicher. Wir müssen uns also vorrangig mit der Optimierung auseinandersetzen. Erweiterungen sind dann erst mal zweitrangig. Ich war gerade dabei, eine kleine Zeitraffer-Funktion einzubauen. Das kann ich mir nun schenken. :(

Was mich dabei interessiert: Tritt der Fehler erst nach dem Laden der Geo-Datensätze aus der Datei GeoData1.txt oder sofort nach Skriptstart, wenn nur ein Datensatz verfügbar ist, auf?

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

Re: Sonnenauf- & Untergang, Blaue Stunde - Berechnungen

Beitragvon Werner_O » 12.01.2013, 19:08

Hallo msl,

dieser Kalender-Fehler tritt bei mir bereits nach einem einfachen Skriptaufruf auf (nur ein Ort aus der "GeoUserD.txt") ohne zusätzlich geladene Geo-Datensätze.

Liebe Grüße
Werner_O
Benutzeravatar
Werner_O
CHDK-Legende
CHDK-Legende
 
Beiträge: 1027
Registriert: 22.10.2010, 13: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 Werner_O » 13.01.2013, 19:57

Hallo msl,

heute habe ich die Zeit gefunden, weiter zu testen (inzwischen mit CHDK DE 1.2 2483).

zu N5:

Lade ich die Datei "GeoData1.txt" und gebe zusätzlich noch manuell eine weitere Koordinate ein stürzt der Kalender übrigens gleich beim Aufruf mit "not enough memory" ab.

Bezüglich Speicher an meiner SX20 gibt CHDK 1.2 2483 übrigens folgendes aus:
Freier Speicher: 414.904 Bytes
CHDK Größe: 150.548 Bytes

Zu N1 und N3:

Bei deaktivierten OSD-Anzeigen im Wiedergabemodus funktioniert es nun. Auch die vorangegangen Tests hatte ich dabei bereits im Wiedergabemodus ausgeführt.

Zu N4:

Danke für den Hinweis, daß man bereits die Datei "Datei GeoUserD.txt" mit mehreren Datensätzen füttern darf.
Das sollte in der Praxis ausreichen, da so auch etwa die Koordinaten eines Urlaubsortes schnell mit eingebunden werden können.

Hinweis:
Bei der Datei "GeoData1.txt" fällt das einzelne Binärzeichen in Zeile 25 auf und könnte zu unnötigen Irritationen führen.
Ich habe diese Zeile darum mal gelöscht und das Binärzeichen am Ende in Zeile 49 wieder eingefügt.
In der Praxis funktionieren bei mir dabei beide Dateien ohne einen merklichen Unterschied.

Verbesserungsvorschlag 1:
Die verwendeten Koordinaten für LG und BG werden bisher kommentarlos in Grad angezeigt und es ist bisher nicht offensichtlich, welcher Wert welche Koordinate repräsentiert.
Würde zukünftig zusätzlich dem BG noch N oder S (für Nord bzw. Süd) und dem LG noch W oder O (für West bzw. Ost) angehängt wäre die Anzeige bereits auf den ersten Blick eindeutig.
Die entsprechende Zeile bietet auch noch genug Raum für diese zusätzlichen Angaben.

Verbesserungsvorschlag 2:
Die dezente blau/gräuliche Farbgebung für die jeweils verfügbaren Bedientasten ist am Display meiner SX20 bereits ab einem Winkel von 45° von oben oder unten nicht mehr lesbar.
Insofern wäre mir da ein Farbe lieber, die auch bei größeren Betrachtungswinkeln noch lesbar bleibt.

Zu N2:
Die drei mir bekannten Quellen sind sich bzgl. der geographischen Lage von Köln einig.
Vermutlich wird jeweils der zentral gelegene Kölner Dom als Zentrum betrachtet, und der wandert wohl kaum herum ;-)

Was aber auch wichtig ist, bei unserem Skript werden mittlerweile Bereiche berücksichtigt, die bei der ursprünglichen Berechnungsgrundlage fehlerhaft sind, Stichwort Polarnacht, Mittsommernacht. Hier hat rudi ganze Arbeit geleistet.

Sorry, aber hier muß ich jetzt mal nachfragen. Laut der Seite http://lexikon.astronomie.info/zeitgleichung/ mit den Berechnungsgrundlagen für die vereinfachte Formel addieren sich die beiden Fehlerquellen "Einfache Formel vs. CalSky" und "Max. jaehrliche Abweichung vom Aufgangszeit-Mittelwert".
Bereits bei 65° Nord oder Süd liegt der kumulierte Fehler bereits bei +/- 9 min, weshalb ich bei meinem Programm für den HP48/49 auch keine größere Werteeingaben zugelassen habe.

Da beide Fehlerkurven ab 65° aber extrem steil nach oben gehen und sich wie gesagt ja auch noch addieren würde mich schon interessieren, inwieweit die beim Twilight-Skript möglichen Eingabewerte für den Breitengrad von bis zu +/- 90° überhaut noch realistisch sind.
Es geht ja um noch sinnvolle Ergebnisse, und daran habe ich ehrlich gesagt starke Zweifel beim Skript bei Breitengraden größer +/- 65°.

Insofern würde mich dringend interessieren, auf welchen mathematischen Grundlagen Berechnungen mit etwa +/- 90 BG überhaupt noch beruhen sollen, was das Twilight Skript ja erlaubt.
Ich kann mir jedenfalls nicht vorstellen, daß ihr das wesentlich genauere Programm "CalSky" im Skript Twilight nachbilden konntet.

Liebe Grüße
Werner_O
Benutzeravatar
Werner_O
CHDK-Legende
CHDK-Legende
 
Beiträge: 1027
Registriert: 22.10.2010, 13: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 » 13.01.2013, 21:46

Hallo Werner_O,

vielen Dank für die hilfreichen Anmerkungen.

zu N5:
den hohen Speicherverbrauch beim Kalender kann auch nachvollziehen. Allerdings geht er bei meinen Kameras nicht so weit in den Keller, dass ein Speicherfehler kommt. Mal sehen, was sich da optimieren lässt.

zu N1 & N3:
Es gibt eine neue Skriptversion, die zwangsweise in den Wiedergabemodus schaltet und am Anfang eine Sekunde mit dem Bildaufbau wartet.

Der Datensatz für Köln ist auch geändert.

Das Binärzeichen (#) ist als Kommentierungszeichen gedacht. Alle Zeilen, die mit # beginnen, werden vom Skript beim Einlesen ignoriert. Man kann sich also Notizen zu den Datensätzen machen. Im Fall Zeile 25 habe deutsche und internationale Städte getrennt.

V1:
Im Skript wird immer zuerst Breitengrad und dann Längengrad genannt. Man könnte da noch ein B und L in die Anzeige einbauen. Im Augenblick ist das aber zurückgestellt, weil ich den Platz in der Zeile für andere Analysezwecke brauche (Speicheranzeige). Ost/West und Nord/Süd ist eigentlich durch Vorzeichen eindeutig zu unterscheiden.

V2:
Das liegt nicht am Skript, sondern an den Farbdefinitionen für die SX20 im CHDK. Wie du in meinen Screenshots siest, wird bei mir blau vernünftig dargestellt. Schau dir mal die Farbpalette an (CHDK-Einstellungen => CHDK-OSD-Farben => Farbpalette anzeigen). Für deine Kamera ist als blau 0x3b definiert (4. Reihe, 11. Spalte).
CHDK-Skripte haben aber die wunderbare Eigenschaft, dass jeder individuelle Anpassungen durchführen kann. Suche dir in der Palette eine Farbe nach deinem Geschmack aus. Wähle sie mit den Steuertasten an. dann siehst du ganz oben den HEX-Wert für diese Farbe. Diesen merkst du dir und trägst in im Skript in Zeile 46 (BLUE = 265) statt der 265 ein. Dabei kannst du entweder die HEX-Schreibform oder den Wert umgerechnet in das dezimale Format eintragen.

zur Berechnung:
Wahrscheinlich habe ich mich nicht ganz verständlich ausgedrückt. Die ursprüngliche Formel berücksichtigt weder Polar- noch Mittsommernacht. Tritt dieser Fall ein, wird das Ergebnis in unserem Skript gesondert dargestellt. (Polarnacht "--.--", Mittsommernacht "++.++"). Die Diagrammkurve läuft sauber aus.

+/- 90 Grad lassen wir im Augenblick mal außen vor. Da arbeitet rudi gerade dran.

Ansonsten ist die gesamte Berechnung im Skript recht gut dokumentiert. Die gesamte mathematische Berechnung befindet sich im Skript zwischen Zeile 137 und 170 (function sun_times). Alle Zeilen mit "--" sind Kommentierungen Formelgrundlagen zur eigentlichen Berechnung. Die Gleichung für die Zeitdifferenz ist in 3 Teile gesplittet.

Ich finde die Ergebnisse z.B. für Lahti im Vergleich zu http://www.timeanddate.com schon ziemlich überzeugend.

Aufgang: 9.16 Uhr Skript: 9.14 Uhr
Untergang: 15.37 Uhr Skript: 15.37 Uhr
Höchststand: 12.26 Uhr Skript: 12.26 Uhr

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

Re: Sonnenauf- & Untergang, Blaue Stunde - Berechnungen

Beitragvon rudi » 13.01.2013, 22:48

Hallo,

ich habe der Skriptgröße etwa 1kByte abgetrotzt. Dabei hat sich auch der Speicherbedarf der Kalenderfunktion verringert und die Anzeige wird seltener aktualisiert (http://trac.assembla.com/chdkde/changeset/1054).

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

Re: Sonnenauf- & Untergang, Blaue Stunde - Berechnungen

Beitragvon Werner_O » 13.01.2013, 22:53

Hallo msl,

jetzt nur noch auf die Schnelle (weiteres dazu erst ab morgen):

Seit kurzem verwenden die neuesten CHDK DE 1.2 Versionen anscheinend die neu eingeführte Datei "CCHDK3.CFG" (vormals "CCHDK2.CFG").
Ich mußte darum sämtliche persönliche CHDK-Einstellungen neu konfigurieren inkl. dem Benutzermenü.

So richtig scheint das alles aber noch nicht zu laufen, weil etwa das Twilight-Skript (aber nur manchmal) für die Tasten auch das vorgesehene satte Blau anzeigt, die im Playback-Mode deaktivierten OSD-Anzeigen manchmal trotzdem aber noch "blinde Flecken" am Display erzeugen uam.
So macht CHDK keinen Spass mehr :-(

Trauriges Fazit:
Ich werde CHDK wohl downgraden müssen, weil diese unerklärlichen Fehler einfach nur noch nerven.
Bitte nenne mir die minimal nötige CHDK DE 1.2 Version damit das Twilight-Skript noch laufen kann ohne die zusätzlich eingebundene nötige LUA-Bibliothek.
Darauf werde ich dann downgraden - ich habe fast alle Vorgängerversionen von CHDK 1.1 und 1.2 für die SX20 bei mir lokal gespeichert.
Notfalls verzichte ich sogar ganz auf das Twilight-Skript zugunsten einer stabil laufenden älteren CHDK-Version.

Liebe Grüße
Werner_O
Benutzeravatar
Werner_O
CHDK-Legende
CHDK-Legende
 
Beiträge: 1027
Registriert: 22.10.2010, 13: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 » 13.01.2013, 23:12

Hallo Werner_O,

die internen neuen mathematischen Funktionen sind seit Revision 2453 verfügbar.

Bist du dir sicher, dass CHDK aktuell nicht mehr richtig funktioniert? Das klingt mir alles nach Datenverlusten durch fehlerhafte Dateien, was leider beim vielen Probieren nicht auszuschließen ist. Die Konfiguration wurde doch schon vor einiger Zeit auf cchdk3.cfg umgestellt.

Ich empfehle, mal eine komplette Neueinrichtung inkl. frisch formatierter Karte vorzunehmen.

Gruß msl

Edit 14.01. 10.00Uhr

cchdk3.cfg gibt es seit Revision 2284 (17.11.2012).
Benutzeravatar
msl
Super-Mod
Super-Mod
 
Beiträge: 4567
Bilder: 271
Registriert: 22.02.2008, 11:47
Wohnort: Leipzig
Kamera(s): A720 1.00c
SX220 1.01a

Speicherbedarf, Farbpalette, Einblendungen

Beitragvon Sinter » 14.01.2013, 13:13

Hallo zusammen,

ich bin gerade bei eigenen weiteren Programmierungen ebenfalls auf Schwierigkeiten bei der Farbpalette gestoßen:

Verstehe ich richtig, dass die Farben 256 bis 273 von uns für jede Kamera ausgewählt und in CHDK hinterlegt wurden (damit abseits der kameraindividuellen Paletten bei jeder Kamera zumindest ähnliche Farbgestaltungen möglich sind)? Für meine Ixus 60 weichen im Bereich 256 bis 273 einige dargestellte Farben von der "Soll"-Beschreibung ab:

Bei Grau sind dunkelgrau und grau "vertauscht".

Alle drei Blau sind im Wiedergabemodus blautransparent und ausschließlich im Aufnahmemodus deckend. Zudem sind alle drei Blautöne identisch gleich hell; ohne eine dunklere oder hellere Variante.

Gelb und Dunkelgelb unterscheiden sich ebenfalls nicht voneinander.


Falls sich die Zuweisung von möglichen Farben zu den einzelnen Farbnummern 256 bis 273 ändern lässt, kann ich gerne mal Vorschläge suchen, welche Farbkoordinaten aus den Farbpaletten sowohl im Wiedergabe- und auch Aufnahmemodus zu gewünschteren Ergebnissen führen. Ich vermute, man kann für die Farbnummern 256 bis 273 jeweils nur eine einzige Farbkoordinate hinterlegen. Oder lassen sich für einzelne Farbnummern jeweils eine Farbkoordinate für Wiedergabe und eine andere (!) Farbkoordinate für Aufnahme zuweisen?

Zur Ãœbersicht hier die aktuelle Situation:
Farben bei Ixus60, teilweise um die Abweichungen ergänzt:
Soll * abweichend davon im Wiedergabemodus * im Aufnahmemodus

256 - transparent
257 - schwarz
258 - weiß
259 - rot
260 - dunkelrot
261 - hellrot * (wirkt orange)
262 - grün * dunkelgrün (tannengrün)
263 - dunkelgrün * grün (olivgrün)
264 - hellgrün
265 - blau * transparentblau * blau deckend
266 - dunkelblau * transparentblau * blau deckend
267 - hellblau * transparentblau * blau deckend
268 - grau * dunkelgrau
269 - dunkelgrau * grau
270 - hellgrau * hellgrau
271 - gelb * braun
272 - dunkelgelb * braun
273 - hellgelb



Anderes Thema:
Es wurde auch noch der Speicherbedarf des Skripts diskutiert. Auf welche Aspekte muss man denn konkret achten, um ein Skript möglichst speicherfreundlich zu halten? Wie weit spielt der Umfang des Codes eine Rolle? (Anzahl der Programmzeilen, Länge der verwendeten Variablennamen)
Oder geht es eher um Ãœberlegungen des Speichermanagements, z. B. bei Tables, Arrays?


Nicht zwingend bei Twilight, sondern allgemein:
Kann man in einem laufenden Skript im "draw-Modus" eigentlich auch noch ganz unten links den Skriptnamen ausblenden, und evtl. auch unten in der Mitte das rote "<ALT>"-Symbol?
Die Konsole bekommt man ja mittels
set_console_layout(0, 0, 0, 0)
bereits weg.

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, 13:16
Wohnort: München

Re: Sonnenauf- & Untergang, Blaue Stunde - Berechnungen

Beitragvon msl » 14.01.2013, 14:19

Hallo Sinter,

oha, Fragen über Fragen.

Die CHDK-Farben - eine unendliche Geschichte.

Mit Einführung der Zeichenfunktionen wurde auch versucht, ein einheitlich Farbsystem zu etablieren - wenigsten für ein paar Grundfarben. Als Basis nutzte man die Farbdefinitionen für das Histogramm und die Icons. Dabei muss man sich aber darauf verlassen, welche Farben bei der jeweiligen Kameraportierung definiert wurden.

Schon früher hatten wir festgestellt, dass es gerade bei den frühen CHDK-Kameras Unterschiede bei der Farbdefinition gibt. Diese Kameras benutzen alle eine Palettendefinition.

Wenn du jetzt in der für die Ixus60 zutreffenden Palette 1 etwas änderst, wirkt sich das auf sehr viele Kameras, die ebenfalls diese Palette benutzen, aus. Deshalb ist das nicht machbar. Man müsste für die Ixus60 eine separate Palettendefinition einführen.

Du kannst dir den Quellcode mal anschauen, der die Palettendefinitionen betrifft: http://trac.assembla.com/chdk/browser/t ... gui_draw.h

In den einzelnen Paletten sind auch schon diverse Ausnahmen definiert.

Welche Palette für welche Kamera zutrifft, ist in der jeweiligen Datei platform_camera.h definiert. Das gilt aber nur, wenn eine andere als Palette 1 verwendet wird, da diese die Vorgabe ist.

Wenn die Farben in einem Skript nicht passen, ist es einfacher, die Werte einfach im Skript anzupassen, wie ich es weiter oben schon beschrieben hatte.

Zum Speichermanagement:

Die Länge von Namen und die Anzahl der Zeilen sowie die Menge der Kommentierung ist zweitrangig. Sicherlich wird eine sehr große Datei irgendwann auch zu Speicherproblemen führen. Das ist aber noch genügend Luft nach oben.

Vielmehr die Art und der Inhalt von Variablen ist entscheidend. rudi und ich haben gestern im Twilight-Skript eine Menge geändert, um den Speicherverbrauch zu optimieren. Zu diesem Thema gibt es ganze Abhandlungen. Es ist also nicht in zwei bis drei Sätzen beschrieben, was man beachten sollte.

Wichtig ist beispielweise, möglichst viele Variablen als "local" zu definieren. Tables sparsam einsetzen. Formeln vereinfachen. Wiederkehrende Routinen als (lokale) Funktionen definieren.

In der Literatur findet man auch Hinweise, dass das "local-Machen" von globalen Funktionen hilft. Wir haben das mal im Twilight-Skript für ein paar Funktionen wie string.format, tonumber und os.date eingeführt.

Zum Draw-Problem:

Prinzipiell ist es möglich, die untere Zeile mit Draw zu überschreiben. CHDK merkt aber das Überschreiben und wird bei nächster Gelegenheit Skripttitel und <ALT> wieder in den Vordergrund bringen. Im Interesse eines ruhigen Bildaufbaus würde ich den unteren Randbereich nicht verwenden.

Und das wichtigste: Es gibt eine neue Twilight-Version mit verbessertem Speichermanagement: viewtopic.php?f=7&t=2976&start=15#p27094

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

Re: Sonnenauf- & Untergang, Blaue Stunde - Berechnungen

Beitragvon Sinter » 14.01.2013, 16:31

Hallo Msl,

vielen Dank für die hilfreichen Erläuterungen. Ja, die neue Version habe ich gesehen, und wenn ich jetzt in Code blicke, mit Winkelfunktionen als local werden die Berechnungsformeln auch übersichtlicher.

Mit der Farbpalette werde ich mich nun erst mal arrangieren. Bei Bedarf kann man bei Gelegenheit einen Workaround mittels Look-up-Table überlegen, um das Problem detaillierter zu lösen. Oder doch noch mühsam separate Paletten erstellen, sofern es den CHDK-Programmcode nicht sprengt.

Ebenfalls werde ich die unterste Zeile im Display nun als gegeben einkalkulieren.

Mal sehen wie weit ich all die Erkenntnisse noch in meinen bereits bestehenden etwa 400 weiteren Zeilen berücksichtigen kann. Es ist zumindest schon eine gute Nachricht, dass Kommentarzeilen und lange Variablennamen den Speicher nicht so sehr belasten. Einige Variablen habe ich bereits als local definiert.

Aktuell muss ich bei mir noch ein paar Kleinigkeiten optimieren und ergänzen. Dann kann ich auch von meinen bisherigen Dummyvariablen wegkommen und konkrete Twilight-Berechnungen einspeisen. Nach den vielen einzelnen Änderungen deines Skripts durch dich und Rudi, ist dein Twilight inzwischen wohl so weit bereinigt, dass ich auf dessen berechnete Eventdaten für meine Zwecke zurückgreifen kann? Oder wird bezüglich Eventdaten noch etwas umgestellt? (Einheiten oder Formate etc.)

Vermutlich werde ich für meine Zwecke die Eventdaten (Eventgattung, dessen Zeitpunkt, sowie dessen aktuelle Countdownzeit) zunächst in Arrays schreiben, um sie danach einzeln auszulesen. Ich hoffe, ich brauche keine Arrays sortieren.


Die eventuelle Berechnung von h mittels Rudis neuen Befehlen muss ich mir auch nochmals anschauen. In den vergangenen Tagen habe ich glücklicherweise mit Rudis neuen Befehlen etwas Übung erhalten.

Vielen Dank und 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, 13:16
Wohnort: München

Re: Sonnenauf- & Untergang, Blaue Stunde - Berechnungen

Beitragvon Werner_O » 14.01.2013, 22:34

Hallo msl und rudi,

Vollständige Downgrades auf CHDK DE 1.2 Version 2476, 2473 und 2463 haben keinerlei Änderung gebracht.
Momentan ist darum bei mir wieder 2483 drauf.

Auch das Ändern der dezimalen Farbangabe für Blau im Twilight-Skript (in der aktuellsten Skriptversion in Zeile 50) ändert bei mir leider rein gar nichts.
Für die vierte (blaue) Zeile und Spalte 11 wird bei mir in der Farbpalette 0x3Bh angezeigt, was dezimal 59d entspricht.

Dabei sind mir auch folgende Sachen aufgefallen:
1) In der Farbpalette bei meiner SX20 tauchen nur Werte von 0x00h bis 0xFFh auf (dezimal 0-255), wie das etwa auch bei GIF-Dateien üblich ist.
2) Schaue ich in diese Farbpalette nach einem Neustart werden in Reihe 4 in den Spalten 1-12 auch unterschiedliche Blautöne angezeigt -
schaue ich da aber nach einem Skriptaufruf von Twilight rein werden dort ganz andere Farben dargestellt die viel dunkler sind.
3) Die dezimalen Farbangaben im aktuellsten Twilight-Skript (Zeilen 46-53) sind dezimal allesamt größer als 255. Anscheinend kann meine Kamera damit aber nicht korrekt umgehen.

Die neueste Twilight-Skriptversion habe ich heute auch mal kurz angetestet und mir dabei auch die Speicheranzeige anzeigen lassen.

Der Speicherverlauf ist dabei wie folgt:

1) Nach dem Einschalten der Kamera werden 387.632 Bytes freier Speicher angezeigt.
2) Nach dem Twilight-Skriptstart im Wiedergabemodus mit nur einem Datensatz in der "GeoUserD.txt" wird folgendes angezeigt: M=162872
3) Lade ich zusätzlich die "GeoData1.txt" sinkt M auf 132200
4) Gebe ich nun manuell eine zusätzliche Koordinate ein sinkt M auf 128592
5) Starte ich den Kalender sinkt M auf 123440
6) Skippe ich nun im Kalender über "Zoom" auf zukünftige Monate veringert sich M sukzessive um etwa 3000 bis 6000 Bytes pro Monat, wobei dann aber im Monat Oktober 2015 der Wert für M wieder sprunghaft auf 131720 ansteigt.

Fazit:
1) Eure Codeoptimierungen bzgl. Speicherbedarf haben sich bereits jetzt sehr ausgezahlt - Danke für Eure Mühen! Die damit erreichte Verbesserung ist jedenfalls enorm.
2) Ich vermute allerdings, daß bzgl. des Kalenders noch weitere Optimierungen möglich sein könnten.
Von meinem HP48 weiß ich, daß auch lokale Variablen vom Programm überschrieben werden können und durch eine optimierte Programmstruktur auch relativ klein gehalten werden können.
Für die lokale Variable für den gewählten Monat inkl. der jeweils verfügbaren Tage (28-31) reichen ja die Angaben für den aktuell gewählten Monat aus ohne daß darin gleich viele Monate unterschiedlicher Jahre gespeichert werden müssen.
Das nur als Anregung von mir, wobei ich von LUA aber defintiv keine Ahnung habe.

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

VorherigeNächste

Zurück zu Code-Ecke

Wer ist online?

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