[Lua] Projekt „Verlaufsfilter“? (evtl. mit Automatik)

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

Re: Projekt „Verlaufsfilter“? (evtl. mit Automatik)

Beitragvon msl » 04.05.2012, 21:37

Hallo,

eine in den Datei-Browser integrierte Funktion, so wie sie schon für die Merge-Funktionen Addition und Durchschnitt verfügbar sind, kann ich mir gut vorstellen. Dennoch halte ich gerade bei diesem Thema Skriptlösungen für den besseren und mittlerweile auch einfacheren Weg.

Auch wenn die gegenwärtige Exif-Eintragslöung geschickt durchgeführt wird, finde ich sie bedenklich. Viele Anzeigeprogramme erzeugen anhand der Herstellerangabe spezifische Anzeigefelder. Wenn der Hersteller-Tag nun manipuliert wird, kann das zu Problemen führen. Deshalb hatte ich auch den benutzerdefinierten Eintrag vorgeschlagen.

Für xnView habe ich mal getestet, in wieweit der Benutzerkommentar nutzbar ist. Per Option ist dieser Exif-Eintrag anzeig- und als Suchfilter verwendbar.

Aber in erster Linie sollten wir hier über den Verlaufsfilter sprechen. Fototechnisch gesehen, ist das seit langer Zeit wieder mal ein richtiger Quantensprung in der CHDK-Entwicklung. Verfolgt das Projekt unbedingt weiter und macht es für die breite Masse anwendbar.

Gerade überbelichtete Wolkenstrukturen stellen immer noch ein typisches Canon-Problem dar. Hier wird immer wieder empfohlen, die Belichtungskorrektur um ein bis zwei drittel zurückzudrehen. So werden dann aber auch dunkle Bildanteile noch dunkler. Ein Verlaufsfilter wäre hier hilfreicher.

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: Projekt „Verlaufsfilter“? (evtl. mit Automatik)

Beitragvon naddel » 07.05.2012, 00:11

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
S2 1.00f mit aktueller DE Version
Benutzeravatar
naddel
CHDK-Begeisterter
CHDK-Begeisterter
 
Beiträge: 156
Registriert: 26.01.2009, 19:42
Kamera(s): G3 s2 ixusii

Re: Projekt „Verlaufsfilter“? (evtl. mit Automatik)

Beitragvon Sinter » 07.05.2012, 12:09

Hallo,

übers Wochenende habe ich ein paar Überlegungen mit Automatik und Konstantanteil geprobt. Mittlerweile reichen die Skriptparameter bei mir gerade noch so aus. Für die Erprobung habe ich nun erstmalig sämtliche Buchstaben des Alphabets als Skript-Parameter in Verwendung.

Eine halbwegs praktikable moderate Automatik dürfte kein Problem sein, sobald ich die zugehörigen Entscheidungs-Parameter angemessen bestimme/einrichte. Das ist eigentlich nur noch eine Frage des Tüftelns. Indes stellt sich die Frage, ob man das auf 12-Bit-Cams übertragen kann.


Die Schwarzwertbestimmung ist auch mir noch rätselhaft. Ich habe bei den Curves öfter bemerkt, dass der Wert 32 offenbar nicht stets korrekt sein kann. Werte unterhalb von 32 werden offenbar durchaus noch in JPG-Zeichnung umgesetzt, ohne sie mittels Curve-Editor bei den CVF "anfassen" zu können. Möglicherweise ist 32 nur als „guter Mittelwert“ verwendet worden.

Neben dem Verlaufsfilter halte ich CHDKLovers "Curves for all" ebenfalls weiterhin für äußerst sinnvoll, denn es eröffnet neue Möglichkeiten. CHDKLover ist hier schon weit vorangeschritten. Er hat die schwierige Spline-Interpolation bereits drin. Fehlt vielleicht nur noch die lineare Interpolation, die ich für ein neues Projekt benötigen würde, da Spline selbst bei ansteigenden Stützpunkten keine Monotonie gewährleisten kann. Ideal wäre noch eine dritte Interpolation, welche ähnlich wie Spline gerundete (!) Kurven liefert, die aber (bei ansteigenden Stützpunkten) zugleich an keiner Stelle der Kurve fallend sein dürfte. Ob es solch ein Interpolationsverfahren in möglichst einfacher Form gibt, und ob es dann umsetzbar wäre, weiß ich nicht.


Curves und Filter sind in der Entwicklung natürlich komplex und schwierig. Indes wird der „Normal-User“ beim Start von Skripten gar nicht bemerken oder sich nicht bewusst sein, dass da im Hintergrund Curves oder Filter angewendet werden. Einzig die Bearbeitungszeit ist halt etwas länger. Die Frage wäre halt noch, ob man solche Funktionalitäten irgendwie noch „einfacher zugänglich“ starten könnte. Manch Normaluser würde ein CHDK-Feature öfter/eher nutzen, wenn er dazu nicht erst das passende Skript auf der SD-Karte suchen und laden müsste. Das tolle Handbuch von Msl hat doch in den Lua-Programmierbefehlen einen dofile(file)-Befehl. Da liegt der Gedanke nahe, vielleicht könnte man innerhalb von CHDK ein Auswahl-Menü für solche Features realisieren, die ja ohnehin als Lua-Skript hinterlegt sind und nur noch auf irgendeine Weise gestartet werden müssen. Dann würde es reichen, der User sucht nicht erst aufwändig das passende Skript, sondern wählt irgendwo einfach nur sein aktuell gewünschtes Feature. Aber so eine Auswahlmöglichkeit von Features müsste halt am besten schnell und mit nur ein oder zwei Tastendrücken zugänglich sein.


@Naddel:
Das mit den CurvesEditor-Eckpunkten ist wohl nur ein kleines Missverständnis. Ich denke, ich hatte nie festgelegte Endpunkte im Diagramm (!) beklagt. Einzig halte ich die Definition (bzw. Auswahl) von Schwarzwert (vielleicht auch Weißwert?), für fragwürdig unbekannt. Denn mindestens der Schwarzwert wird vom CurvesEditor bei den CVF genutzt. Falls dieser Schwarzwert fehlerhaft ist, so wirkt sich das teilweise dann auch auf die Curveanwendungen aus, weil man die mit dem Schwarzwert belegten Pixel dann mittels Curve leider gar nicht "greifen" kann. Solche Pixel entziehen sich damit leider der Beeinflussung.

Zu 1: Ein direkter Verlaufsfilter lässt sich mit Curves leider nicht realisieren.
Zu 2: Curves, welche nicht durch Eckpunkte gehen, sind machbar. Aber hier kann dann ein falscher Schwarzwert ein Problem sein. Die Gelbfehler sind offenbar darauf zurückzuführen. Vielleicht sind Schwarzwerte sogar kanalabhängig.
Zu 3: Die Horizontalachse steht bei CV-Curves für die RAW-Kanal-Werte. Indes fehlen mir die Infos, wie genau die CVF vom Curves-Editor gehandhabt werden, denn bei CVF wird der (möglicherweise ungenaue oder fehlerhafte) Schwarzwert berücksichtigt. Möglicherweise werden bei CVF die Kanäle irgendwie mit der Helligkeit des Grünkanals gewichtet. CHDKLover hat da mal Vermutungen angedeutet. Dazu müsste man vielleicht nochmals den C-Code von Toinech lesen/interpretieren (können). Darin taucht der Schwarzwert bei den CVF wohl auf, aber ich bin kein Programmierer und kann den Rest des Listings leider nicht genau deuten/nachvollziehen.


Zum Verlaufsfilter:
Einen Konstantanteil in den Verlaufsfilter einzupflegen, halte ich weiterhin für sehr sinnvoll. Indes wäre schön, wenn man die Konstantbereiche in der Fläche des Filterbereichs nicht einzig anteilig fifty-fifty, sondern ganz flexibel festlegen könnte, also frei justieren könnte, ob man genau 50 % der Filterfläche (!) konstant haben mag, oder nur 49%, 48%, 47%,... oder 20%, 15%, 5% oder 70% der Filterfläche etc.
Deine weiteren Alternativüberlegungen klingen auch interessant: 1/3 auf der ersten Hälfte, 2/3 auf der zweiten Hälfte, aber das müsste man sich dann erst als Ergebnis ansehen. Schwierig abzuschätzen.
Eher kann ich mir noch die runde Viertel-Sinusfunktion vorstellen, wobei hier wohl dann auch der obere Rand lange dunkel blieb. Allerdings könnte Dein Sinus-Vorschlag auch ein tolles Ergebnis zusammen mit dem Konstantbereich bringen. Also dass man zunächst einen vom User bestimmten Bereich konstant verdunkelt, und daran angrenzend den Übergangsbereich in der Tönungsintensität sinusförmig gefiltert gestaltet.

Ich habe am WE schon probiert, wie sich vielleicht mit bestehenden Mitteln ein Verlaufsfilter mit Konstantanteil realisieren lässt. Daher habe ich überlegt, wie sich angesichts Deiner Überlegung, mittels Filter1 zuerst abzudunkeln und dann mittels Filter2 einen Teilbereich des ersten Verlaufsfilter wieder heller zu machen, wie man damit einen Konstantbereich basteln könnte. Das habe ich nun auch probiert. Prinzipiell ist das wohl auch tatsächlich machbar. Einzig stoße ich dabei zu schnell an Grenzen, so dass sich leider genau die klassischen Fälle nicht mehr mittels dieses Vorgehens berechnen lassen (sondern nur schwache langgestreckte Übergangsverläufe und kurze schwache Konstant-Tönungen).

Falls ich beispielsweise über die ersten 40% Bildbereich eine Verdunkelung um -80% als Konstantbereich haben möchte, und daran anschließend einen Übergangsbereich von 40% Bildbereich bis 60% Bildbereich will, dann gerate ich mit der Kennlinie von Filter1 beim oberen Bildrand unter Null, sofern ich zunächst mit Verdunkelung, und dann mit Aufhellung arbeite.
Ein Workaround könnte vielleicht sein, zuerst als Filter1 den Aufhellungsfilter anzuwenden, und dann erst die Verdunkelung. Damit würde ich mit Filter1 aber wohl leicht über den Weißwert hinausschießen. Sollten uns hier aber 16 Bit zur Verfügung stehen, dann könnte das vielleicht nutzbar sein, sofern man den Weißwert erst nach Berechnung des zweiten Filters (diesmal Verdunkelung als Filter2) als oberen zulässigen Grenzwert berücksichtigt. So dass man aus Filter1 erzeugte Werte auch oberhalb (!) des Weißwerts als Input an Filter2 übergeben kann. Ich glaube, dann würde man etwas mehr Spielraum für die Berechnung eines Konstantanteils haben. Dennoch würde man auch hier noch immer an Grenzen stoßen, sofern überhaupt machbar.

Aber ich denke es ist vielleicht in der Tat wesentlich leichter und sinnvoller, deiner C-Programmierung des Filters doch noch eine echte Konstantoption hinzuzufügen. Den nötigen Aufwand dazu kann ich jedoch nicht abschätzen.

Auch weiß ich nicht, wie groß der Programmieraufwand für zwei (!) Filter ist. Ob wir zwingend zwei (!) Filter brauchen, bin ich mir nicht sicher. Ich persönlich wäre schon mit einem Filter mit Konstantanteil glücklich:

raw_merge_set_filter( Filterwert, Bereichswert, Konstantanteil )
Die Frage ist noch, wie wir den Konstantanteil am besten „bemessen“. Ob als ProzentPUNKTE des gesamten vom Filter bestrichenen Bildbereichs, oder als Prozentwert (also den Prozentwert als „relativ“ interpretiert) der horizontalen Abgrenzung analog des Bereichswerts.

Ich könnte mir beispielsweise vorstellen, ein neuer Filterbefehl mit Konstantanteil:

raw_merge_set_filter( -60, 75, 40 )
bedeutet interpretiert:
Konstante Tönung (Abdunkelung) in Höhe von 60% innerhalb der gesamten oberen 40% des Bildbereichs.
Und der eigentliche VERLAUFS-Übergang erstreckt sich erst anschließend ab 40% des Bildbereichs bis 75% des Bildbereichs (jeweils von oben gemessen).


Transparente Rechtecke im Display lassen sich wohl nicht realisieren. Dann bleiben wir vorerst bei Zickzack-Linien, vielleicht nochmals weiter optimiert. Wobei so eine Anzeige dann bei einer Automatik wohl gar nicht mehr nötig wäre weil dann der User keinen vorgegebenen Filterbereich mehr berücksichtigen muss.

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: Projekt „Verlaufsfilter“? (evtl. mit Automatik)

Beitragvon msl » 07.05.2012, 13:00

Hallo naddel,

ich beziehe mich mal nur auf ein paar Punkte deiner Ausführungen. Da, wie schon öfters von mir bemerkt, ich kein Programmierer bin, kann ich dir, wenn es in die tiefen der CHDK-Programmierung geht, nur wenig helfen. Ich bin froh, so einigermaßen den Überblick zu behalten, was an den diversen Fronten passiert.

naddel hat geschrieben:Handbuch lua ... der Befehl raw_merge_add_file wird dort als raw_merge_add beschrieben
Danke für den Hinweis, ist korrigiert und kommt mit der nächsten Ausgabe. Im Zweifelsfall hat immer der Quellcode recht.

naddel hat geschrieben:der Befehl table.setn ist ab lua 5.1 abgeschafft und liefert "is obsolete"
Welche LUA Version verwendet eigentlich CHDK?
Bist du dir sicher mit table.setn? In den Dokumentationen, die ich kenne, ist es noch aktuell. Aber sei es drum, CHDK benutzt Lua 5.1.3 mit Stand 2008, was Standardfunktionen und Bibliotheken betrifft.

naddel hat geschrieben:... 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.
1. Kann ich nicht sagen. Ich finde im Quellcode auch keine Hinweise dazu. 2. Vermutlich. 3. Nein. ich kann dir ein 12-Bit-RAW zukommen lassen, allerdings als CMOS-Abbild, was seit 2011 aktuell ist.

naddel hat geschrieben:Wie wird der Schwarzwert für die Kammeras bestimmt? Für 10/12-Bit gilt allgemein 32/128.
Alle kameraspezifischen Definitionen sind in platform_camera.h im jeweiligen Plattform-Verzeichnis zu finden. Grundsätzlich ist alles in camera.h in core/include vordefiniert.

naddel hat geschrieben: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.
Gut hier im speziellen konnte keine Rückmeldung erwartet werden, da kein nur sehr eingeschränktes Testmaterial verfügbar ist. Generell ist aber die Bereitschaft, bei der Entwicklungsarbeit aktiv mitzuwirken, sehr gering. Ein Großteil der Nutzer hier erwarten ein fertiges funktionierendes Produkt. Das Interesse an CHDK ist schon relativ groß. Viele treffen ihre Kaufentscheidung zu Gunsten von Canon, weil es CHDK gibt. Wenige haben aber Lust, aktiv zu werden. Wenn überhaupt, dann nur zu Themen, die selbst interessieren.

Hinsichtlich Veränderungen, die Core-Bereich betreffen, muss man sehr vorsichtig agieren. Da wären stufenweise Änderungen ratsam.


naddel hat geschrieben: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.
Das mit dem Kopieren hatte ich schon bemerkt. Leider haben sich die Funktionen zum Auslesen der Dateien als nicht unbedingt effektiv erwiesen, was das Speicherverhalten betrifft. Da sind schon einige Kameras in die Knie gegangen. Ein Dateifilter ist kein Problem. Da der File-Browser, den vollständigen Pfad als String an das Skript zurück gibt, braucht man nur diesen String auszuwerten.

naddel hat geschrieben: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.
Für solche generellen neuen Funktionen sollte in jedem Fall die Modul-Version verwendet werden. Das Proxy-Problem ist aber ein lokales Problem. Da wird hier kaum jemand helfen können.


Generell sollte auch mal geklärt werden, ob die Integration der 12-Bit-Kurven-Funktion noch ein Thema ist. Leider ist CHDKLover wohl so eingespannt, dass er keine Zeit findet, sich hier zu diesem Thema zu äußern. CHDK sollte eine Möglichkeit anbieten, auch 12-Bit-RAWs zu manipulieren. Und da würde die Verlaufsfilterfunktion sehr hilfreich sein.

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

CHDKLovers Curve-Konzept

Beitragvon Sinter » 07.05.2012, 13:27

Hallo,

ja, mag sein, CHDKLover ist wohl aktuell zeitlich sehr eingespannt. Angesichts der Möglichkeiten seines Konzepts, bleibt sein Curves-for-all weiterhin ein bedeutsames Ziel, für welches es sich auch lohnt, Wochen oder auch Monate Verzögerung zu akzeptieren. Bei meiner 10-Bit-Cam scheint seine Spline-Interpolation zu klappen. Der Rohbau steht damit vermutlich bereits. Möglicherweise fehlt nur noch die lineare Interpolation und ein wenig Feintuning.

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: Projekt „Verlaufsfilter“? (evtl. mit Automatik)

Beitragvon CHDKLover » 07.05.2012, 18:19

Hallo,
wenn ich das richtig sehe, dann wurde damals die lineare Interpolation realisiert.
Um diese zu aktivieren muss entweder im Dateinamen oder irgendwo in der Stützpunktdatei die Zeichenkette "lin" für linear stehen. Wenn nicht im Dateinamen (zum Beispiel: "test.lin"), dann sollte der Schalter am Ende des Datenbereiches stehen, um die Kompatibilität im dem curve editor zu erhalten.

Gleiches Verfahren wird zur Umschaltung von RGB und Luminaz-Kurven verwendet.

Standartwerte falls keine Schalter im Dateinamen oder in der Stützpunktdatei gefunden wurden: kubische Splineinterpolation im Luminanz-Modus.

Marker zum aktivieren der kubische Splineinterpolation: "spline", "cub", "kub"
Marker zum aktivieren der linearen Interpolation: "lin"
Marker zum aktivieren der RGB-Kuven: "rgb"
Marker zum aktivieren der Luminaz-Kuven: "lum", "lcurve"

Die Marker sind nur zu Testzwecken eingebaut und können beliebig angepasst werden.

CHDKLover
A610 100e CHDK-DE: aktuelle Version
Benutzeravatar
CHDKLover
Super-Mod
Super-Mod
 
Beiträge: 878
Bilder: 8
Registriert: 12.09.2007, 18:25
Wohnort: Dresden
Kamera(s): a610 100e

Re: Projekt „Verlaufsfilter“? (evtl. mit Automatik)

Beitragvon Sinter » 09.05.2012, 11:54

Hallo zusammen,

schön, wie sich nach und nach spannende Fortschritte ergeben.


@CHDKLover:
Vielen Dank für Deine zuversichtliche Info zu Curves-for-all hinsichtlich Linear. Irgendwo hattest Du gemeint, Du hattest zunächst ausschließlich Spline eingebaut. Indes hattest Du in einem späteren Auswahlmenü dann auch bereits Linear mit eingefügt. Das hatte ich mittels Aktivierung im Menü getestet, hatte aber im CTC-File keinen zusätzlichen Marker gesetzt. Irgendwas lief damals bei mir noch schief, so dass ich (wohl irrtümlich) annahm, Linear sei zwar bereits ins Menü integriert, aber noch nicht wirklich funktionsfähig.

Eine andere Sache war mir noch aufgefallen, bei der ich mir aber bezüglich meiner Beobachtungen und der Interpretation nicht mehr ganz sicher bin. Du hattest ursprünglich geplant gehabt, die kamerainterne Berechnung ausschließlich dann ausführen zu lassen, wenn eine CTC-Datei noch nicht in eine Curve umgerechnet wurde. Und Du wolltest auf die („zeitintensive“) Neuberechnung verzichten, falls die Curve bereits berechnet in der Kamera vorliegt. Die Spline hatte ja bei mir funktioniert, dauerte aber in der Anwendung wohl jeweils gleich lang, unabhängig ob ich die CTC-Curve erstmalig aufgerufen habe, oder ein zweites Mal anwendete. Sollte diese Überprüfung, ob die Curve bereits in der Cam berechnet vorliegt, bereits vor Dir integriert sein, dann liegt die Vermutung nahe, die Berechnung der Curve aus den CTC-Daten geht unauffällig schnell. Aber ich denke, das muss ich bei Gelegenheit ausführlicher austesten.

Nachdem Du sagst, Du glaubst Linear bereits einprogrammiert zu haben, habe ich jetzt nur mal kurz nochmals die Linear-Funktionalität ausprobiert. Dein aktuellster Curve-for-all Build scheint tatsächlich auch Linear integriert zu haben. Irgendwas hatte mit Linear bei mir vor einigen Wochen noch nicht geklappt und ich hatte dann weiterhin geglaubt, nur Spline ist bereits integriert, aber ich bin mir nicht mehr sicher ob ich damals bereits den aktuellsten Build auf der SD-Karte hatte. Oder aber ich hatte in Deinem neuen vielfältigen Auswahlmenü irrtümlich eine falsche Einstellung.

Deine Idee, Marker in die File-Inhalte oder auch in den Filenamen einzubauen, ist äußerst clever und sehr hilfreich. Ich überlege gerade, wie man dann mittels Lua in Deinem Menü Richtung Automatik-Version händelt, falls ein User sein CHDK-Curve-Menü nicht auf AUTOMATIK, sondern auf RGB oder LUMI, bzw. LIN oder SPLINE gestellt hat, ich aber mittels Lua-Skript unbedingt die AUTOMATIK aktiviert benötige, bzw. eine Zwangseinstellung auf LINEAR/LUM realisieren muss. Entweder wäre in der Folge später noch zwei zusätzliche Lua-Befehle sinnvoll, um Curves jeweils auf AUTO stellen zu können, oder aber wir bestimmen (und programmieren) die Konvention, dass man mittels Markern die Gültigkeit der Menüeinstellung over-riden kann. Letztlich benötigen wir eine Möglichkeit, mittels Skript die Menü-Einstellung Linear oder Spline (und auch RGB/LUMI) overriden zu können, falls der User „vergessen“ hat, das Curve-Menü für beide Parameter jeweils auf AUTOMATIK geschaltet zu haben. Dies nur so als Gedanke für später.

Gut, nachdem Linear nun vermutlich tatsächlich schon funktioniert, kann ich meine weiteren Planungen wieder aufnehmen. Und sofern man manuell auf Automatik schalten kann, komme ich aktuell auch noch ohne zusätzliche Auto-Schaltbefehle aus. Die lassen lässt sich in Lua auch später noch hinzufügen. Ich bin zuversichtlich, vorerst mit den gegebenen Mitteln passabel auszukommen. Die Schaltbefehle benötigen wir erst wenn wir Curves-for-all allgemein verfügbar machen.

Sollte hier jemand beiläufig noch eine Idee für ein drittes Interpolationsverfahren haben, welches bei steigenden Stützpunkten gewährleistet, eine abgerundete und an keiner Stelle fallende Kurve zu generieren, dann wäre das eine weitere hilfreiche Perspektive, um mit Curves noch optimaler agieren zu können.
Diese Diskussion gehört nun eigentlich nicht mehr zum Verlaufsfilter. Mod darf gerne entscheiden, entsprechende Passagen eventuell nach Curves-for-all zu schieben.

Curves mindern die Bedeutung der Verlaufsfilter jedenfalls keineswegs.



@ Naddel:
Vielen Dank für Deine weiteren Verbesserungen, die ich nun weiter getestet habe. Den Überlauf beim Schwarzwert hast Du perfekt aufgefangen, und vor allem hast Du mit Deinem neuen Divisor viele entscheidende Sekunden Berechnungszeit gewonnen. Klasse!

Deinen Vorschlag, meine Zickzackeinblendung zusätzlich in kleinerer Form auch noch im stärker getönten Bereich zur Kennzeichnung (und weiteren „Verdunkelung“) des Filterbereichs einzufügen, habe ich eingebaut. Ja, ich denke, das ist ein praktikabler Weg, um dem User die Fläche des Filterbereichs und die Tönungsintensität zu signalisieren.

Meine Versuche, mit den bisherigen zwei Filtern auch eine Fläche mit einer Konstant-Tönung zu realisieren., stoßen mit den bisherigen Mitteln zu schnell an Grenzen weil die Kennlinie des Verlaufsbereichs dann gerne die prozentuale y-Achse der Filterintensität unterhalb vom Wert Null schneidet (wobei ich hier im Gegensatz zur Filterkonvention die Tönung als Positivwerte gehändelt habe). Neben diesem Problem schränkt auch der bisherige maximale Aufhellungsfaktor in Höhe von 300% die Möglichkeiten der nachträglichen Aufhellung eines Teilbereichs zusätzlich ein. Falls der Rand um 90% getönt ist, so stehen mir maximal noch 30 Prozentpunkte an Aufhellungspotential zur Verfügung. Bei 95% nur noch 15 Prozentpunkte, und schnell liegt man mit der Kennlinie sogar bei einem Tönungsüberlauf. Dann fehlt jegliche Aufhellungsmöglichkeit. Daher ist es mittels des bisherigen Doppelfilters mathematisch wohl nicht möglich, die wünschenswerten Konstantfilterwerte stets zu erreichen, sondern einzig sehr moderate Filterlösungen mit Tönungswerten von nur geringer Intensität. Sofern wir einen Filter mit Konstantanteil realisieren wollen, so geht dies in der Tat vermutlich genau wie von Dir geplant, ausschließlich mittels Deiner leistungsstarken C-Programmierung unmittelbar beim Filterbefehl.


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: Projekt „Verlaufsfilter“? (evtl. mit Automatik)

Beitragvon naddel » 09.05.2012, 12:15

Hallo Sinter,

Wenn der Verlaufsfilter mit Curves nicht zu erreichen ist verschieben wir die Curves auf später.

Sinter hat geschrieben:Sollte hier jemand beiläufig noch eine Idee für ein drittes Interpolationsverfahren haben, welches bei steigenden Stützpunkten gewährleistet, eine abgerundete und an keiner Stelle fallende Kurve zu generieren, dann wäre das eine weitere hilfreiche Perspektive, um mit Curves noch optimaler agieren zu können.

Ich habe mit gewichteten Mittelwerten gute Erfahrungen gemacht. Die Berechnung war einfach, ist aber schon lange her und ich muß das Verfahren nochmal raussuchen.

Der Verlaufsfilter zieht sich. Wie Du bekomme ich schwach abweichende aber dennoch unreproduzierbare Ergebnisse.
Mit den Tests bin ich noch nicht durch.

Gruß naddel
S2 1.00f mit aktueller DE Version
Benutzeravatar
naddel
CHDK-Begeisterter
CHDK-Begeisterter
 
Beiträge: 156
Registriert: 26.01.2009, 19:42
Kamera(s): G3 s2 ixusii

Re: Projekt „Verlaufsfilter“? (evtl. mit Automatik)

Beitragvon Sinter » 09.05.2012, 15:52

Hallo zusammen,

kein Problem wenn sich der Verlaufsfilter noch hinauszögert. Naddel, Du kannst Dir ruhig Zeit lassen. Auch bei mir ist freie Zeit aktuell knapp und ich bin froh wenn es derzeit nicht ganz so schnell vorangeht. Meine Veränderungen von Display-Anzeige und Automatikansätzen für Dein Skript, habe ich nun weitgehend in functions gepackt, die sich dann später auch leicht in ein von Dir überarbeitetes Skript mit überarbeiteten Verlaufsfiltern einfügen lassen. Gut wäre jedenfalls, wenn wir die Filterfläche bitte nicht starr in Konstantbereich und Verlaufsbereich halbieren, sondern wenn man die Flächenanteile von Konstantbereich sowie Verlaufsbereich frei wählen kann. Vorerst würde wohl eine lineare Kennlinie des Übergangsbereichs ausreichen. Die Viertel-Sinuskennlinie und andere Überlegungen kann man dann vielleicht erst bei Bedarf hineinprogrammieren, wenn man sieht, wie die Ergebnisse bei linearer Kennlinie konkret ausfallen. Ich vermute, es könnte sinnvoll werden, die Viertel-Sinuskennline noch ein wenig asymmetrisch zu verzerren.


Ob man auf die Ursache der verschieden dunklen Entwicklungen kommt, bin ich mir nicht sicher. Vielleicht liest Msl hier mit und hat zwischendurch sogar eine Idee oder Vermutung, weshalb bei nachträglicher (!) Entwicklung die Fotos zwar nicht immer, aber oft (!) einen Hauch dunkler werden als das Original. Dieses Phänomen hatte ich bereits bei Curves festgestellt, und wir beide jetzt auch bei unseren beiden Kameras beim Verlaufsfilter. Bei Curves hatte ich mal gemeint zu beobachten, es hinge davon ab, ob ich bei nachträglicher Entwicklung die Cam Richtung Licht oder Dunkelheit richte, aber ich konnte das jetzt nicht mehr reproduzieren. Das Tele ist es ebenfalls nicht. Ich habe dieser Tage noch die Exif-Daten einiger Doppel-Fotos des Verlaufsfilters verglichen, ob ich irgendwelche möglichen Hinweise finde. Dabei fand ich aber ein Pärchen Fotos mit exakt übereinstimmenden Belichtungs- und Brennweitendaten, und dennoch ist das nachträglich entwickelte Bild auch im vom Filter nicht behandelten Bereich einen deutlich erkennbaren Hauch dunkler. Ob da irgendwie ein von CHDK bestimmter/gewählter Schwarzwert hineinspielt?


Das andere Thema:
Vielleicht bin ich bezüglich Curves-for-all schon wieder einen kleinen hochinteressanten Schritt weiter: Ich habe vorhin zur Monotonie gegoogelt und bin auf die sogenannte
„monoton kubische Interpolation“
gestoßen. Dabei wird auf den englischen Wikipedia-Eintrag verwiesen. Als ich den Kurvenverlauf gesehen habe, dachte ich sofort „DAS IST ES“. Denn dessen Kurvenverlauf scheint zumindest auf den ersten Blick der Zielsetzung von Monotonie und Rundung der Kurvenecken sehr gut zu entsprechen. Ich glaube, das wäre als bedeutendes drittes Interpolationsverfahren zwischen den Curve-Stützpunkten genau richtig für CHDK.
Falls diese Interpolation gleichbedeutend mit Hermite-Interpolation ist, so gerate ich in der deutschen Algorithmensammlung von Wikibooks sogar zu einem Verweis mit c-Code. Vielleicht könnte man von diesem dann sogar die Struktur einfach in CHDK übernehmen. Eventuell auch sogar in den Curves-Editor einbauen, um einen besseren Einblick in die „optische“ Kurvengestaltung dieser Interpolation zu erhalten. Aber falls ich den c-Code von toinech inhaltlich korrekt deute, dann beschreibt unser vorhandenes c-Listing von toinech einzig die CHDK-Curve-Programmierung, während wir vom CurvesEditor leider keinen Quellcode besitzen, in den man dann noch die monoton kubische Interpolation hinzufügen könnte...?

Falls sich auch gewichtete Mittelwerte als Interpolation gut programmieren lassen, so wäre ein Vergleich der beiden Kurvenführungen spannend.

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: Projekt „Verlaufsfilter“? (evtl. mit Automatik)

Beitragvon naddel » 09.05.2012, 16:19

Sinter hat geschrieben:während wir vom CurvesEditor leider keinen Quellcode besitzen, in den man dann noch die monoton kubische Interpolation hinzufügen könnte...?


Doch haben wir. Nachdem Toinech seinen zusammengebrochen Rechner wieder am laufen hatte hat er doch noch auf meine damalige Anfrage geantwortet. Fe50 hat den Anhang mit in sein Archiv übernommen. Leider geht es mir wie toinech und mir ist mein VB 4?? abhanden gekommen.
Er schreibt es ist VB 6 im Programm steht aber Version 5. Wenn diese Baustelle weg ist könnte man mal
versuchen ihn mit vba zum laufen zu bringen. Das wäre dann vielen zugänglich.

btw
@Fe50
Wäre Dein Archiv nicht auch der Platz für ein paar Beispiele von Originalraws.
Platz ist das entscheidende. Hast Du den?

Ein paar Beispiele wären z.B. zur Untersuchung der kanalabhängigkeit des Schwarzwertes hilfreich, den ich wie CHDKLover auch schon vermutet hatte.

@msl
Deine Raw nehme ich natürlich gerne. Lieber wäre mir aber die 16-Bit Version bei der man auch mit blosem Auge schon was erkennt.
Dazu Raw_merge nach dem 1. add_file abbrechen. Der File A/raw16.tmp ist die 16-Bit Version. Natürlich größer als die 10/12 Bit.

@Sinter
Nein das ist der Quellcode, eigentlich nicht viel und auch anders nachzubilden. Steht auch noch auf Setepontos?

Gruß naddel
Zuletzt geändert von naddel am 09.05.2012, 17:39, insgesamt 4-mal geändert.
S2 1.00f mit aktueller DE Version
Benutzeravatar
naddel
CHDK-Begeisterter
CHDK-Begeisterter
 
Beiträge: 156
Registriert: 26.01.2009, 19:42
Kamera(s): G3 s2 ixusii

Re: Projekt „Verlaufsfilter“? (evtl. mit Automatik)

Beitragvon Sinter » 09.05.2012, 16:27

Hallo Naddel,

ja, ich weiß noch, Toinech hatte Dir nach einer Weile geantwortet.

Ich habe die Files
curves.c
curves.h
curves.txt
noch aus dem CurveUpdate.zip Juli 2008. Soll das der Code des Editors sein, oder sind das andere Files?

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: Projekt „Verlaufsfilter“? (evtl. mit Automatik)

Beitragvon Sinter » 09.05.2012, 18:00

Hallo Naddel,

Beispiele für die vermutete Kanalabhängigkeit des Schwarzwerts muss ich in den nächsten Tagen in meinen alten Archiven suchen. Ich vermute das stets bei den Gelbfehlern bei manchen Curves, die sich anders kaum erklären lassen. Auch bei den Italy-Curves kam es teilweise zu einer ansonsten ebenfalls nicht durch die Curves erklärbaren kleinen Farbveränderung. Ich hoffe, bis nächste Woche kann ich paar betroffene Fotos finden.

Der Gelbfehler besagt vielleicht, ich konnte in original-gelben Bereichen teilweise kein Blau hinzusteuern. Also dass der Schwarzwert für Blau niedriger liegt, als man mittels CurvesEditor anfassen kann. Gelber Originalbereich = ganz geringer Blaukanalwert. So gering, dass er unterhalb des im CurveEditor normierten Schwarzwerts liegt und somit auch keine Curve diesen niedrigen Blauwert greifen konnte. Das könnte die Erklärung sein.

Allerdings erklärt dies wohl noch immer nicht, weshalb eine nachträgliche Entwicklung eines RAW oft einen Hauch dunkler als im Original ausfällt.

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: Projekt „Verlaufsfilter“? (evtl. mit Automatik)

Beitragvon msl » 11.05.2012, 10:50

Hallo naddel,

naddel hat geschrieben:Deine Raw nehme ich natürlich gerne. Lieber wäre mir aber die 16-Bit Version bei der man auch mit blosem Auge schon was erkennt.
Dazu Raw_merge nach dem 1. add_file abbrechen. Der File A/raw16.tmp ist die 16-Bit Version. Natürlich größer als die 10/12 Bit.


sx220 12bit RAW
sx220 16bit RAW

Die 16-Bit-Datei habe ich mit folgendem Skript-Schnipsel erzeugt:
Syntax: [ Download ] [ Verstecken ]
Benutze Lua Syntax Highlighting
--[[
@title raw merge
]]


raw_merge_start(0)
img_file = file_browser("A/DCIM")
raw_merge_add_file(img_file)
wait_click(0)
Erstellt in 0.004 Sekunden, mit GeSHi 1.0.8.9


Allerdings funktioniert das nur mit der einfachen stabilen CHDK-Version. Bei der Modul-Version stürzt die Kamera beim Laden der Datei (raw_merge_add_file) ab. Der Vorgang beginnt (LED leuchtet). Es wird aber kein grafischer Ladebalken angezeigt. Nach einiger Zeit (entspricht ungefähr der eigentlichen Ladezeit) stürzt die Kamera ab. Die verwendete Modul-Version enthält deine beiden RAW-Merge-Patches. Ich kann dir leider bisher nicht sagen, ob es vor den Änderungen funktioniert hat.

Edit: der Fehler tritt auch mit älteren Modulversionen auf, die deine Änderungen nicht enthalten. Die Fehlerquelle liegt also wo anders.

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: Projekt „Verlaufsfilter“? (evtl. mit Automatik)

Beitragvon naddel » 11.05.2012, 14:43

Hallo msl,

msl hat geschrieben:Es wird aber kein grafischer Ladebalken angezeigt. Nach einiger Zeit (entspricht ungefähr der eigentlichen Ladezeit) stürzt die Kamera ab. Die verwendete Modul-Version enthält deine beiden RAW-Merge-Patches. Ich kann dir leider bisher nicht sagen, ob es vor den Änderungen funktioniert hat.

Edit: der Fehler tritt auch mit älteren Modulversionen auf, die deine Änderungen nicht enthalten. Die Fehlerquelle liegt also wo anders.


Der Ladebalken sollte schon kommen bis dahin ist ja noch nichts verbotenes gemacht worden.
Der Letztendliche Absturz kommt wohl daher, daß die GUI (der Ladealken) nicht beendet wird.
Beim letzten Pach hab ich zwar die Variablen freigegeben die GUI aber nicht beendet. Das muß also noch rein. Danke.
Ich habe in meiner Testversion das löschen der tmp in der raw_merge_end ausgeklammert und damit keinen Fehler bekommen.
Ein Fehlen der tmp Datei in raw_merge_end wird soweit ich das im Kopf habe abgefangen.
Ein umbennen der tmp an der Stelle des waitklick und ein reguläres beenden über raw_merge_end sollte also keinen Fehler bringen.
Ich werds ausprobieren.

Gruß naddel
S2 1.00f mit aktueller DE Version
Benutzeravatar
naddel
CHDK-Begeisterter
CHDK-Begeisterter
 
Beiträge: 156
Registriert: 26.01.2009, 19:42
Kamera(s): G3 s2 ixusii

Re: Projekt „Verlaufsfilter“? (evtl. mit Automatik)

Beitragvon naddel » 12.05.2012, 04:27

Hallo msl,

Zunächst danke für die Raw.
Eine 3 am Zeilenanfang gibts da nicht.
Dafür ein paar Byte Schrott am Zeilenende. Wahrscheinlich muß die Zeilenlänge auf Wortlänge gebracht werden.

Deinen obigen Sachverhalt muß ich voll und ganz bestätigen.
Wegen des vermuteten Zusammenhangs mit der Gui habe ich ein Skript in 2 Versionen benutzt.

Syntax: [ Download ] [ Verstecken ]
Benutze Lua Syntax Highlighting
--[[
@title getraw16
@param   a Bildnummer
@default a 1

]]

nr=string.sub("000"..a,-4,-1)
print ("raw_start: ",raw_merge_start(0))
print ("raw_add  : ",raw_merge_add_file(file_browser("A/DCIM")))
print ("os.rename: ",os.rename("A/raw16.tmp","A/Img_"..nr..".r16"))
Erstellt in 0.004 Sekunden, mit GeSHi 1.0.8.9


und

Syntax: [ Download ] [ Verstecken ]
Benutze Lua Syntax Highlighting
--[[
@title getraw16 mit merge_end
@param   a Bildnummer
@default a 1

]]

nr=string.sub("000"..a,-4,-1)
print ("raw_start:",raw_merge_start(0))
print ("raw_add  :",raw_merge_add_file(file_browser("A/DCIM")))
print ("os.rename:",os.rename("A/raw16.tmp","A/Img_"..nr..".r16"))
print ("raw_end  :",raw_merge_end())
Erstellt in 0.004 Sekunden, mit GeSHi 1.0.8.9


Beide laufen auf CHDK_de trunk 935-993, ich arbeite immer noch auf 988.
Der Fehler beim umbenennen, wenn die Datei schon vorhanden ist ist Absicht.

Mit der testweise heruntergeladen neuesten ModularenDE Version geht es ebensowenig wie mit chdk versionen 1840 - 1847.
Mehr hab ich nicht.

Ein testweises auskommentieren aller gui-Funktionen in raw_merge_c #1847 hat nichts gebracht.
Aus dem Dateibrowser scheint alles zu funktionieren, der c-Kern ist also in Ordnung.
Nur die messagebox wird nicht beendet.

Nach den ausgedruckten Rückgabewerten kommt raw_merge_start noch durch liefert aber
immer das mitgelieferte argument 0/1 (average/sum) zurück egal was in raw_merge_c als returnwert gesetzt wird.
= stacktop ? jedenfalls kommt der richtige Wert wenn der Rückgabewert noch gepusht wird

Raw merge add habe ich von void auf int gesetzt aber auch in #1840 ohne diese Änderung tut es nicht.

Als eheste Fehlerquelle scheint mir der Funktionscast der Modularen Version in luascritp.c in Frage zu kommen.
Aber davon verstehe ich zu wenig.

Jetzt habe ich mal diese beiden prozeduren in luascript.c ersetzt

Syntax: [ Download ] [ Verstecken ]
Benutze C Syntax Highlighting
static int luaCB_raw_merge_start( lua_State* L )
{
  int op = luaL_checknumber(L,1);
  if (!module_rawop_load())
    return luaL_argerror(L,1,"fail to load raw merge module");

  if ( API_VERSION_MATCH_REQUIREMENT( librawop->version, 1, 0 ) &&
       (op == RAW_OPERATION_SUM || op == RAW_OPERATION_AVERAGE) ) {
    lua_pushnumber( L, librawop->raw_merge_start(op));  
  }
  else {
    return luaL_argerror(L,1,"invalid raw merge op");
  }
  return 1;
}

// TODO sanity check file ? Get it from C
static int luaCB_raw_merge_add_file( lua_State* L )
{
  if (!module_rawop_load())
    return luaL_argerror(L,1,"fail to load raw merge module");
  lua_pushnumber( L, librawop->raw_merge_add_file(luaL_checkstring( L, 1 )));
  return 1;
}
Erstellt in 0.005 Sekunden, mit GeSHi 1.0.8.9


(dann bekomme ich die richtigen Rückgabewerte). Will LUA immer 4Byte und c liefert da int 2? Falls das so ist unten die diff.
alle gui Aufrufe in raw_merge.c auskommentiert
und das script im Aufnahmemodus gestartet.
Dann bekomme ich bei raw_merge_add_file einen Abbruch mit der Meldung
"fail to load mdetect.flt action reloc", der Bildschirm bleibt aktiv aber die Tasten sind tot,
Im Wiedergabemodus weiterhin einen schwarzen Bildschirm.
Edit:
Jetzt kommt die Meldung schon bei Raw_merge_start. Ich fürchte durch das Geschiebe geht meine
Karte hops. Ich mach mal Pause.

Wenn ein Könner wie Rudi einen Blick drauf wirft wird er den Fehler wohl schnell finden.

Gruß naddel
Dateianhänge
patch.diff
(1.11 KiB) 362-mal heruntergeladen
S2 1.00f mit aktueller DE Version
Benutzeravatar
naddel
CHDK-Begeisterter
CHDK-Begeisterter
 
Beiträge: 156
Registriert: 26.01.2009, 19:42
Kamera(s): G3 s2 ixusii

Vorherige

Zurück zu Code-Ecke

Wer ist online?

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