Hallo,
ich hab mich in meinem kleinen Winkel im CHDK-Gärtchen wieder einmal total verlaufen. Deshalb ein Zwischenstand um einige Fragen zu klären
und auf den rechten Weg zurück zu kommen.
Das Einfachste zuerst.
@msl
Handbuch lua
der Befehl raw_merge_add_file wird dort als raw_merge_add beschrieben
der Befehl table.setn ist ab lua 5.1 abgeschafft und liefert "is obsolete"
Welche LUA Version verwendet eigentlich CHDK?
Als ich einige meiner Raw-Dateien mit dem Text-Editor (liest binär mit einstellbarer Zeilenlänge) angesehen habe ist mir aufgefallen, daß
alle Zeilen in der Raw mit <eof> (asci(3)) beginnen. Das wurde früher oft gemacht um das lesen durch Textprogramme zu verhindern.
1. Ist das gewollt.
2. Ist das auch bei den 12-Bit raws so
3. Gibt es irgendwo eine Sammlung von CHDK-Raws verschiedener Kammeras.
Die Raw-Merge Funktionen behandeln den 1.Punkt einer Zeile mit, er sollte also auf Schwarzwert gesetzt werden wird aber auf 0 gesetzt.
Bei den gemergeden Dateien (.wav) wird also die Zeilenkennung gelöscht. Ansonsten könnte man durch die Suche nach der 1. 3 die Zeilenlänge
und somit das Bildformat der Raw bestimmen.
Xnview liest ja die crw und cr2 seit jeher und benutzt anscheinend die 3 nicht zur Formatfindung, da auch umbenannte WAvs angezeigt werden.
Benutzen andere Bildviewer die 3? D.h. Zeigen zwar crw aber umbenannte wav, die crw enthalten nicht an.
Wie wird der Schwarzwert für die Kammeras bestimmt? Für 10/12-Bit gilt allgemein 32/128.
Bei mir erscheinen in den unbelichteten Rändern links 11Pixel +1.=3 oben 8 Zeilen, rechts 42 Pixel
Werte zwischen 27 und 36. Ist 32 ein aus Erfahrung "guter Mittelwert".
Da das Interesse nach den Rückmeldeungen quasi 0 ist und ich zur Zeit etwas eingespannt bin habe ich zum ausprobieren die Funktion auf die schnelle
als Erweiterung in die Raw_merge_end gepackt deshalb wäre mir auch die (optionale) Parameterübergabe an die Raw_merge_end am liebsten gewesen.
Das hätte aber Änderungen an der PTP und GUI erfordert.
Jetzt würde ich eine eigenstänige Prozedur bevorzugen wozu allerdings die Prozeduren in raw_merge etwas zerpflückt werden müssten.
Die etwas längere Laufzeit durch zeilenweise Funktionsaufrufe liesen sich durch die Oben angesprochene Nichtbeahndlung des 1.Pixels mehr als kompensieren.
Am liebsten wäre mir nur ein Parameter als Table variabler Größe aber wie wird das in C auf dem Stack addressiert.
Die Eigenständige Prozedur wäre wesentlich schneller da man sich das lesen und schreiben von ~3 Rawfiles spart.
Zu den Beispielen von Sinter
JA, das sieht besser aus als ich gedacht hätte.
Meistens kommt durch die Überbehandlung des oberen Randes eine gewisse Gewitterstimmung auf, was aber in manchen Deiner Beispiele der Wahrheit wohl näher kommt als das Original. Wie Du das an deinem winzigen Bildschirm beurteilen kannst ist mir schleierhaft.
Deinen Vorschlag den Filter auf der 1. Hälfte konstant zu lassen und den Übergang auf der 2. Hälfte zu machen werde ich umsetzen.
Alternativ wär noch
1. 1/3 des Filters auf der 1. Hälfte 2/3 auf der 2. Hälfte
2. 1/4 der Sinus-Funktion mit langsamer Angleichung die Randbereiche und stärker Änderung des Filterwertes um die Mitte herum.
Dein Beispiel mit der Zickzack-Linie ist auch gut eine weitere Abdunklung nach oben könnte durch zusätzliche Zacken in den sich nach oben öffnenden Dreiecken erfolgen.
Eine an sich schöne Lösung durch überlagerte transparente Rechtecke scheitert schon daran daß nur eine Transparentfarbe über die allgemeingültige Farbmap ansprechbar ist. Außerdem weckt es die Erwartung, daß man auch bekommt was man sieht. Wie das auch zu erreichen wäre ist mir nicht klar.
Eine Automatik durch Auswertung der Blauwerte in einem z.B. 50x50 Raster vom oberen Bildrand her mit Festlegung eines Mindestblauwertes erscheint mir möglich ist mir aber wesentlich zu aufwendig zumal die Daten in der Bayermatrix vorliegen und auf den verschiedenen Modellen unterschiedlich ausgewertet werden. Bezieht man sich bei der Auswertung nur auf den Bildschirm kommen auch unschöne Effekte zum tragen (z.B. Weißabgleich, Farbtemperaturverstellung
hellere Anzeige bei dunklem Bild), die das Ergebnis sehr zweifelhaft erscheinen lassen.
@msl
Es ist sehr schade, daß die wirklich hervorragende exiflib von stift so ein Schattendasein führt und plädiere sehr für deren Verwendung.
Im Editor hatte ich auch schon die Möglichkeit der Kommentierung des Bildes direkt in der Kammera eingebaut. Leider keine einzige Rückmeldung.
Die Verwendung des Hersteller exif möchte ich keienesfalls empfehlen. Nur das Benutzer-kommentarfeld war vor 2 Jahren noch nicht leicht zugänglich,
und ist auch heute nach sehr weit unten in den Exifdaten angesiedelt. Wegen der prominenten Stellung in der Anzeige benutze ich es auch heute noch
bei Testreihen, .z.B. Sensortemperatur bei der Aufnahme. Das muß bei einer "public version" nicht so bleiben.
msl hat geschrieben:Das Skript lässt sich aus meiner Sicht drastisch vereinfachen. Eine Unterscheidung zwischen CHDK-DE und CHDK bezüglich der Konsolenbefehle ist nicht mehr notwendig. Die für die Filteranwendung benötigte CRW-Datei lässt sich interaktiv über den CHDK-Datei-Browser (Datei_inlc_Pfad = file_browser(<Pfad>)) aufrufen. Damit entfallen die aufwendigen Dateisuchfunktionen.
Das ist sicher so ich habs in einer Viertelstunde zusammengeguttenbergt. datei_browser ist auch eine gute Idee aber er hat noch keine
Dateifilterfunktion. --> eine andere Baustelle.
Bezüglich des diffs:
Ja das wäre wünschenswert um an mehr Tester zu kommen. Aber auf welche Version\Trunk soll ich mich beziehen. Ich hab noch keine Zeit gefunden
auf die Modularversion umzusteigen zumal mich der Proxy an der Stelle wo ich mich meistens aufhalte vom svn aussperrt.
Der Verlaufsfilter wäre ja für 10 un 12 Bit anwendbar dennoch fände ich es wie einige meiner Vorredner besser das
Curves for all voranzutreiben, das anscheinend hauptsächlich an an belastbaren Kurvendaten
wie sie seinerzeit Sinter geliefert hat gestockt hat. Diese enorme Arbeit von CHDKLover verkommen zu lassen wäre mehr als Schade.
@Sinter wie tajchigong beklagst du, daß im Curveeditor die Endpunkte Fixiert sind.
Bei mir sind sie nur in der Horizontalen fixiert in der Vertikalen lassen sie sich verschieben.
1. liese sich durch diese Möglichkeit ein Verlaufsfilter erzeugen.
2. Hast du je einen Filter konstruiert, der nicht durch die Eckpunkte geht?
3. Was brächte es den Eckpunkt auf einer der Horizontalachsen zu platziern.
- Ist das sinnvoll?
- Was besagt die Horiontalachse?
Na da wäre noch einiges aber genug für Heute
Edit:
Jetzt muß ich doch noch was dazusetzen.
Canon verkauft jährlich eine runde Million Kleinbildkammeras in Deutschland. Die allermeisten sind mit dem was sie da bekommen wunschlos glücklich.
Geschätzt jeder tausendste oder auch ein paar mehr davon (ich kenne die Downloadzahlen nicht und wieviele davon sind Updates)
landet irgendwann bei CHDK. 90% davon lassen es oder bekommen durch die gute Dokumentation alles problemlos installiert und das was sie vermisst hatten.
Reihen, Bewegungserkennung, Batterieanzeige, stacking usw.
Bleiben 100 übrig, die etwas besonderes wollen und sich anmelden, die meisten haben ein Verstädnisproblem, das sich leicht beheben lässt.
Bleiben also noch ein paar Dutzend mit einem speziellen Wunsch, die eine Weile aktiv bleiben (bis das Problem gelöst ist). Die handvoll wirlich aktive, zu denen ich mich nicht zähle, sind vollauf mit Organisation, Anpassungen un Portierung beschäftigt. Das ist eine schwache Diskussionsgrundlage.
Das Problem mit Kurven und Filtern ist, daß dafür bei diesem verbleibenden Personenkreis wenig Interesse besteht, PS wirds schon richten.
Ich kenne einige Leute, die Ihre Fotos machen und auf den Karten lassen. Allenfalls werden sie noch auf dem Fernseher angesehen oder per direktdruck
oder mit dem Automat im Supermarkt gedruck. Einige dieser Bekannten haben keinen PC und somit auch keinen Zugang zum CHDK.
Genau diese Leute, die mit der Aufnahme das Bild bekommen wollen, das sie haben wollen und keinen Spaß dabei haben ein Bild eine halbe Stunde am PC zu optimieren wären das Potenzial für Funktionen mit denen das Bild schon in der Kammera zu dem gemacht wird was man haben will.
Da kommt nicht zusammen was zusammen gehört.
Gruß naddel