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

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

Projekt „Verlaufsfilter“? (evtl. mit Automatik)

Beitragvon Sinter » 13.04.2012, 11:11

Hallo,

nachdem in letzter Zeit viele neue CHDK-DE-Entwicklungen tendenziell oft technische Schwerpunkte hatten und der Wunsch nach Weiterentwicklung vorhanden ist, macht es nun Sinn, die neueren Entwicklungen vermehrt auch in konkrete Anwendungen einzubringen. CHDK-DE steht durchaus noch immer vor technischen Herausforderungen, und es sind sicher noch nicht „alle Skripte geschrieben“.

An dieser Stelle möchte ich einige Überlegungen anstellen, ob es machbar sein kann, CHDK-DE mit (verschiedenen) Verlaufsfiltern ausstatten zu können. Für den Anfang vielleicht auch erst nur eine einfache Verlaufs-Tönung für den oberen Bildbereich/Himmel.

Msl, als hiesige höchst-engagierte CHDK-DE-Ikone, hatte bereits vor längerer Zeit das vorbildliche br_dev.lua-Skript eingebracht, mit welchem es möglich ist, Bilder übereinanderzulagern. In seinem Skript werden Prozesse/Befehle (raw_merge_start(Operation)) verwendet, bei denen Pixelwerte addiert, bzw. auch Durchschnitte gebildet werden können. Davon ausgehend funktionieren bereits Additionen und Divisionen bei der Manipulation von Bilddaten. Das durchdachte Skript von Msl inspiriert zu der Überlegung, falls es uns auch noch gelingt, zusätzlich Multiplikations-Operationen mit Bilddaten zu realisieren, dann könnte man vielleicht einen entscheidenden Schritt weiterkommen, um nun auch Verlaufsfilter für einzelne Fotos zu ermöglichen. In diesem Fall muss man nicht zwei komplette Bilder übereinanderlagern, sondern man könnte vielleicht die RAW-Daten einer Aufnahme beispielsweise zeilenweise mit zeilenabhängig interpolierten Faktoren (=Tönungswerten) multiplizieren:

Angenommen, wir möchten gegen einen zu hellen Sommerhimmel einen Verlaufsfilter ins Bild einbringen, der z. B. nur das obere Bildfünftel manipuliert, indem der Filter ausschließlich das obere Bildfünftel nach unten hin nachlassend abdunkelt. Beispielsweise auf einer Aufnahme ganz oben den Himmel um 30 Prozent abdunkeln, während dann im oberen Bildfünftel Zeile für Zeile die Tönung immer schwächer wird.
Angenommen ein Bild besteht aus 100 Zeilen. Die oberen 20 Zeilen sollen verlaufsartig getönt werden; oben am stärksten getönt, und nach unten hin immer schwächer getönt. Die oberste erste Zeile wird nun mit dem Wert 0.7 multipliziert (=100-70=30 % Tönung) um den Himmel dunkler abzubilden. Die zehnte Zeile wird demnach interpolierend mit dem Wert 0.85 multipliziert (100-85= nur noch 15 % Tönung). Und ab der 21. Zeile nach unten hin werden alle Zeilen belassen (=sozusagen mit 1 multipliziert = keine Tönung mehr). Also das obere Fünftel der 100 Zeilen, nämlich alle Zeilen zwischen der ersten und der 21. Zeile mit interpolierenden Faktoren multiplizieren, abhängig von der gewünschten maximalen Tönungsintensität und dem gewünschten Bildbereich des Verlaufsfilters.

Ich gehe davon aus, wir benötigen hierfür einen neuen CHDK-DE-Befehl. Vermutlich muss die Division angesichts von Integer mittels einer Kombination aus Multiplikation und Division ausgeführt werden, z. B. ein RAW-Wert 589 in einer obersten Zeile für 70%-Tönung:
589*700/1000=412

Ob ein Verlaufsfilter mittels zeilenweiser Multiplikation mit interpolierten Faktoren zu einem hinreichend guten optischen Ergebnis führt, lässt sich derzeit nicht exakt abschätzen. Bei Bedarf kann man die Transformation natürlich auch abwandeln.
(Eventuell kann man auch einfach beim Skript von MSL ansetzen und (als Filter) ein zweites RAW-Bild generieren, welches die notwendigen Filterdaten repräsentiert und einfach mittels Multiplikation mit dem Foto-RAW verknüpft/verschmilzt.)

Die Anzeige im Display:
Für den User könnten wir die Aktivierung des Verlaufsfilter im Display mittels Verwendung der neuen Zeichen Befehle (z. B. draw_line( x1, y1, x2, y2, cl) oder draw_rec signalisieren. Interessant wären hier transparente „Farben“ in verschiedenen Tönungsstufen, die wir stufenweise bildbreit als Rechtecke/Linien auf das Displaybild überlagern könnten. Der Tönungsverlauf wäre dann zwar vermutlich etwas stufig abgebildet, aber für den User hinreichend erkennbar. Alternativ könnte man sich vorerst auch einfach mit einem Sägezahnmuster aus Linien oder mit einer Sinuskurve behelfen, die denjenigen Bildbereich abdeckt/überstreicht, in welchem der Verlaufsfilter wirken würde. So würde der User zumindest sehen, in welchem Bildbereich der Verlaufsfilter aktiv ist.

Für die Berechnung der korrekten Displayanzeige des Verlaufsfilters wäre hilfreich, wenn wir mittels eines Lua-Befehls die Sensorbreite und Sensorhöhe (jeweils in Pixeln gemessen) auslesen könnten. Alternativ können wir uns auch vorerst mittels Skriptparameter behelfen, indem der User selbst eingeben muss, wie viele Pixel der Sensor in Höhe und Breite aufweist. Gleiches gilt für die Diaplaydimensionen der jeweiligen Cam.


Zudem stellt sich noch die Frage, wie wir eventuelle hell ausgefressene Bereiche des Originalfotos händeln. Entweder bekommen diese dann (je Zeile) eine „konstante maximale“ Helligkeit, oder aber es gelingt uns ein Workaround, um vermutete Helligkeitsverläufe innerhalb eines ausgefressenen Bereichs zu „(re-)konstruieren“. Hierzu wäre interessant, wenn wir die Anwendung des Befehls get_histo_range () auch auf einen definierten Bild-Bereich einschränken könnten. Aber das wäre schon wieder eine weitere offenes Herausforderung, welche wir aber auch nutzen könnten, um einen automatischen Verlaufsfilter zu realisieren, der automatisch erkennt, wo der (zu) helle Himmel beginnt, und der automatisch sowohl den notwendigen Bildbereich und auch den Tönungsgrad eines Verlaufsfilters einstellt. Mittels CHDK-DE könnte das vielleicht realisierbar werden.
So könnten wir ein Skript realisieren, bei dem der User entweder auf Verlaufsfilter-Automatik stellt, oder aber selbst per Skriptparameter sowohl Typ, Bildbereich, und Tönungsintensität des Verlaufsfilters definiert. Denkbar wäre vielleicht auch noch, die Himmelsfarbe zu croppen, und diese selbst als Tönungsfarbe zu verwenden.


Gerne könnt Ihr hier nun auf eventuelle Denkfehler, Irrtümer, unüberwindbaren Hürden oder noch unbedachte Herausforderungen hinweisen, und all Eure Gedanken, Überlegungen und Vorschläge anfügen. Stehen uns die Ressourcen zur Verfügung, um zumindest einen ganz einfachen Verlaufsfilter zu realisieren, oder welche neuen Vor-Entwicklungen wären noch zu vollbringen?

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 Panobert » 14.04.2012, 19:30

Hallo Sinter,
was ich noch nicht verstanden habe :
Welchen Vorteil hat man, wenn die Filterung in der Kamera passiert ?
Jedes halbwegs brauchbare Bildbearbeitungsprogramm kann das.
Ich sehe nur einige Nachteile gegenüber der Bearbeitung am Computer.
- Festlegung der Parameter/Verlaufsgrenzen umständlich am kleinen Display der Kamera.
- Beurteilung des Ergebnisses auch schwierig am kleinen Display der Kamera und evtl. bei heller Umgebung.

Die Automatik finde ich schon interessanter, die muß aber dann wirklich intelligent sein, sonst kommt nichts Vernünftiges dabei raus.
Allerdings bleibt immer noch das Problem mit der Beurteilung, ob das Ergebnis so ist wie gewünscht, d.h man muß dann doch wieder am Computer nachbearbeiten.

Ich will Dir den Spaß am Projekt nicht verderben, vielleicht habe ich es ja nur noch nicht ganz durchschaut.

Grüße Norbert
Canon A620 + SX220 + Nikon D80
Benutzeravatar
Panobert
CHDK-Einsteiger
CHDK-Einsteiger
 
Beiträge: 25
Bilder: 8
Registriert: 22.05.2010, 14:04

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

Beitragvon naddel » 15.04.2012, 02:33

Hallo Sinter

Das sehe ich ähnlich wie Panobert. Angesichts vieler hervorragender Bildbearbeitungsprogramme ist es den Meisten recht gleichgültig was die Kammera liefert.
Interessant ist dann das DNG-Format für die Weiterverarbeitung. Das steht im Widerspruch zu den primitiven Bearbeitungsmöglichkeiten in der Kammera, die das Raw-Format, also ein schlichtes Abbild des Sensors, das sich auch wieder in den Bildbearbeitungsspeicher zurückkopieren lässt voraussetzt.
EInige interessieren sich für die technischen Möglichkeiten der Knipse und versuchen die gewünschten Effekte gleich ohne Nachbearbeitung zu bekommen.
Bei deinen Tonwertkurven hast du gesehen, daß das eine kleine Minderheit ist.
Deine Vorschläge bedeuten einen tiefen Eingriff in den Kern des Chdk, und müssten mit c umgsetzt werden.
Die Bilderstellung würde für die Meisten unangebracht lange brauchen.

Eine Erweiterung der Raw-Funktionen um ein sub wäre aber einfach. Dann könnte man mit vorbereiteten Raws Bereiche auch abdunkeln und nicht nur aufhellen wie mit add. Die Doppelbelichtung sollte dann als dunklerer Schatten erscheinen. Diese Löung wäre aber wegen der verschiedenen Rawgrößen modell- wenn nicht wegen der Hotpixel kammeraabhängig.

Auf die Raw zu verzichten und den Sensorspeicher geziehlt mit zu subtrahierenden Werten zu beschreiben wäre dann der nächste Schritt.
Mit 2 Forschleifen wären das wohl auch keine 20 Zeilen Code.

Lg 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 msl » 15.04.2012, 13:39

Hallo Sinter,

wie immer sind deine Ideen und Gedanken sehr komplex aber auch inspirierend.

Bei diesem Thema muss ich meinen Vorrednern in der Richtung zustimmen, dass deine vorgeschlagenen Funktionen eher eine Sache für die Bildverarbeitung am Rechner sind.

Eine Erweiterung der RAW-Merge-Funktionen hinsichtlich weiterer Operationen neben vorhandener Durchschnittsbildung und Addition kann ich mir noch vorstellen. Die Integration von Verlaufsfiltern ist dagegen sehr anspruchsvoll. Wenn es dann noch partiell erfolgen soll, wird es richtig kompliziert. Man denke nur an die unterschiedlichen Sensorgrößen und Sensorarten.

Außerdem kommt noch ein anderer Aspekt hinzu. Neuere Kameras haben mittlerweile eine Unmenge an sogenannten künstlerischen Einstellmöglichkeiten. Man kann gezielt Farben verändern oder austauschen, deren Intensität beeinflussen. Diverse Effekte wie Fisheye- oder Miniatur-Optik können eingerechnet werden. Eine Funktion wie iContrast kann die gesamte Bildkomposition beeinflussen. Mit diesen Funktionspaketen wird vieles abgedeckt.

Was ich mir wünsche, sind die Tonwertkurven-Funktionen für die 12Bit-Kameras. Gerade bei den Kurven für die 10Bit-Kameras hast du Pionierarbeit geleistet. Wenn man deine genialen Kurven auch bei 12Bit-Kameras nutzen könnte, das wäre großartig.

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 Knarf » 15.04.2012, 17:56

MSL:
Was ich mir wünsche, sind die Tonwertkurven-Funktionen für die 12Bit-Kameras. Gerade bei den Kurven für die 10Bit-Kameras hast du Pionierarbeit geleistet. Wenn man deine genialen Kurven auch bei 12Bit-Kameras nutzen könnte, das wäre großartig.

Schliesse mich an in der Hoffnung.

Gruss Knarf
Knarf
CHDK-Begeisterter
CHDK-Begeisterter
 
Beiträge: 472
Bilder: 2
Registriert: 28.12.2011, 17:42
Kamera(s): SX130IS 101c
CHDK-DE-Modulversion

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

Beitragvon TobiMarg » 16.04.2012, 10:16

Hallo

Zu den Verlaufsfiltern kann ich eigentlich (noch) nichts sagen, aber zu den zwei letzten posts:
Hier gibt es bereits einen ansatz, der villeicht weiterzuführen währe (ich kam nur bisher nicht dazu). Es scheinen sich aber nicht so viele dafür interessiert zu haben wie man an den nur 23 downloads des diffs sieht.

Gruss
TobiMarg
TobiMarg
CHDK-Begeisterter
CHDK-Begeisterter
 
Beiträge: 102
Registriert: 24.09.2011, 15:17
Kamera(s): SX230HS 1.01c

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

Beitragvon Knarf » 16.04.2012, 11:07

Wie mache ich aus dem .diff ein Script? Kenne .diff von Linux.

Gruss Knarf
Knarf
CHDK-Begeisterter
CHDK-Begeisterter
 
Beiträge: 472
Bilder: 2
Registriert: 28.12.2011, 17:42
Kamera(s): SX130IS 101c
CHDK-DE-Modulversion

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

Beitragvon msl » 16.04.2012, 11:37

@TobiMag
Die wenigen Downloads der Diff-Datei haben ihre Ursache. Die wenigsten können hier mit dem CHDK-Quellcode umgehen. ganz zu Schweigen vom Einlesen einer Diff-Datei. Das Projekt an sich ist genau das, was ich ich mit meinem Wunsch angesprochen hatte.

@Knarf
Die Diff-Datei hat im engeren Sinn nichts mit einem Skript zu tun. Sie beschreibt die Unterschiede zwischen Vorgabe und und geänderter Vorgabe. In unserem Fall stellt sie den Unterschied dar, wenn jemand den CHDK-Quelltext in bestimmten Bereichen geändert hat, um Korrekturen oder neue Funktionen einzuführen.

Programme, die mit Diff-Dateien (oder auch Patch-Dateien) umgehen können, fügen die Änderungen automatisiert in den bestehenden Quellcode ein.

Im vorliegendem Fall enthält die Diff-Datei von CHDKLover alle Quellcode-Änderungen, die für die Realisierung der 12Bit-Tonwertkurven-Funktion notwendig sind (ausgehend vom damaligen aktuellen Quellcode).

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 Sinter » 16.04.2012, 12:08

Hallo zusammen,

vielen Dank für all Eure Gedanken und Einschätzungen zu meinen Überlegungen.

Ich bin kein professioneller Programmierer und bin daher froh, wenn Hürden und Sinn äußerst kritisch hinterfragt werden. Es ist mir wichtig, einen Einblick zu erhalten, in welchem Verhältnis der Aufwand zum Nutzen stehen würde, und welche verschiedenen Sichtweisen vorherrschen.

Sicher kann man Verlaufsfilter auch mittels Bildbearbeitung machen. Andererseits möchten viele User gar nicht erst diesen Umweg beschreiten, sondern einfach „knipsen“ und das Ergebnis schon in der Kamera vorliegen haben. Wobei auch ich der Meinung bin, eine Verlaufsfilter-Automatik (!) wäre natürlich ein besseres Argument für einen CHDK-Verlaufsfilter, während einfache (!) Verlaufsfilter ganz stark mit einer PC-Bildbearbeitung konkurrieren würden.

Ob es möglich wäre, allein schon mittels Einführung einer Multiplikation zu einem guten Ergebnis zu kommen, kann ich aktuell noch nicht abschätzen.
Auch kann ich nicht abschätzen, wie lange eine Multiplikation mit Filterdaten dauern würde. Falls man dafür 30 Sekunden opfern müsste, wäre es recht uninteressant.

Naddel, ich freue mich immer zu sehen, wie Du Dich stets bei komplizierten Themen und Herausforderungen einbringst. Neben Deinen tollen Curve-Lösungen habe ich auch immer Deinen Lua-Taschenrechner in Gedanken, dessen Berechnungsalgorithmen vielleicht noch anderweitig nützlich werden können. Kann sein, dass Du damals der Zeit voraus warst. Dein aktueller Vorschlag mit der sub-Einführung ist leicht nachvollziehbar noch einfach und ich hatte daran auch schon gedacht, aber zumindest für Verlaufsfilter ein sub schnell wieder verworfen.
Denn wenn man genau überlegt, dann lässt sich ein sub angesichts der Sensorcharakteristik bei den Tonwerten hier kaum zielgerecht justieren. Wie weit ein sub anderen Zielen sinnvoll dienlich sein könnte, habe ich noch nicht überlegt. Ich gehe zwar stets gerne die von Euch Programmierern zur Verfügung gestellten Lua-Befehle durch und überlege, was man mit den Befehlen alles Schönes machen könnte, aber zum sub fällt mir auf die Schnelle noch kein richtig spannender Verwendungszweck ein. Ein Abdunkeln wäre damit natürlich durchaus möglich, allerdings müsste man für ein gezieltes gutes Ergebnis auch noch die Sensorcharakteristik ganz kompliziert berücksichtigen. Mit einer Multiplikation wären wir für einen Verlaufsfilter hingegen wohl näher am Filter dran.

Bilddaten im RAW-Format zu manipulieren und wieder in den Bildspeicher zurückzukopieren, das ist ein äußerst verfolgenswertes Ziel. Ich gehe davon aus, das wird zukünftig noch ein Thema für uns. Ich habe das durchaus bereits vermisst um nicht nur eine, sondern auch zwei oder mehrere Curves nacheinander auf eine Aufnahme anzuwenden.
Alternativ fällt mir ein, es könnte vielleicht noch einen zweiten Weg geben, um zwei Curves gleichzeitig anzuwenden: Nämlich nicht RAW-Bilddaten zwischenzuspeichern und zurückzukopieren, sondern stattdessen eine Möglichkeit zu schaffen, zwei bestehende Curves miteinander in eine neue zusammenfassende einzige Transformations-Curve zu „verschmelzen“. Ich könnte mir vorstellen, dies wäre für Programmierer simpel umzusetzen, statt RAW-Bilddaten zwischenzuspeichern und manipuliert zurückzukopieren.

Falls ich mich nicht täusche, müsste man mittels Curve-Verschmelzung die gleiche Transformation erreichen, und vielleicht würde der Prozess sogar noch schneller sein. Auch wenn ich kein Programierer bin, ich hatte mal versucht genauer in die c-Programmfiles von toinech für die Curves zu blicken. Ich sehe da zwar nicht komplett durch, aber habe zumindest Einblicke gefunden, wie es derzeit ungefähr programmiert ist. Einerseits sehe ich dort noch viel Spielraum für hilfreiche Weiterentwicklungen, die vielleicht auch gar nicht besonders aufwendig wären. Vielleicht erklärt sich anhand der in den Files gewählten Algorithmen auch bereits der teilweise auftretende Gelbfehler bei manchen Curves. (>Könnte sein, dass der Schwarzwert bei einzelnen Farbkanälen noch nicht perfekt gewählt ist. Auch andere Indizien könnten dies vermuten lassen.)
Wie tricky nun aber auch noch ein Verschmelzungsprozess zweier Curves in c zu programmieren wäre, kann ich nicht abschätzen. Aber ihr Programmierer lasst mich oft erstaunen, wie schnell und elegant ihr manche Hürden überwindet. Im Prinzip müsste es gedanklich zwar recht simpel sein, aber als Hürde wäre dabei zu meistern, CF- (keine Schwarzwertberücksichtigung) mit CVF-Curves (Schwarzwertberücksichtigung) zu verschmelzen.

Den Einwand mit den Hotpixeln hatte ich noch nicht bedacht. Aber die Möglichkeit der Curve-Verschmelzung würde dieses Problem wohl umgehen.

Richtig spannend, zu welchen Perspektiven Eure Anmerkungen verleiten.

Msl, die Überlegung der Erweiterung der RAW-Merge-Funktionen hinsichtlich weiterer Operationen möchte ich gerne im Auge behalten, auch wenn man konkrete Umsetzungszwecke dafür erst noch finden muss. Bei konkretem Bedarf greife ich das gerne wieder auf.
Teilweise ärgert mich beispielsweise manche originale Vignettierung meiner Kamera. Zumindest bei meiner Ixus 60 scheint die Vignettierung kameraseitig nicht hinreichend herausgerechnet zu werden. Man könnte hier zwar neue denkbare Merge-Befehle anwenden, aber die Befehle allein würden sicher nicht ausreichen, um Vignettierungen zu eliminieren.


Angesichts Eures wertvollen Feedbacks belassen wir es zunächst bei der prüfenden Überlegung zu Verlaufsfiltern. Vielleicht wird der nötige Aufwand für Verlaufsfilter irgendwann später auch niedriger sein, sobald zugehörige Teillösungen zukünftig bereits zu anderen Zwecken realisiert sind.

Auch ich würde es begrüßen, wenn sich vielleicht auch für 12-Bit-Kameras eine Tonwertkurvenfunktion realisieren ließe. CHDKLovers Ansätze in „Curves for all“ halte ich für äußerst durchdacht und vielversprechend. Das „geringe“ Interesse am Patch lässt sich leicht erklären, weil es sich hier um Entwicklungsarbeit handelt und insbesondere Nichtprogrammierer teilweise auch überfordert sind, sich daraus ein Test-CHDK für ihre Kamera zu generieren. Das ändert jedoch nichts an der Notwendigkeit von „Curves for all“. Sofern es realisierbar ist, habe ich dafür auch eine Verwendung.

Euch allen vielen herzlichen 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 » 21.04.2012, 18:21

Hallo Sinter,

Ausgefressene Stellen:
Überbelichtet ist überbelichtet, da ist nichts mehr was zu rekonstruieren wäre. Dann eher Standardverfahren. Mittels Zebra die
Belichtung auf die hellen Stellen einstellen und die Tiefen anheben. Die werden dann zwar gröber aber da ist wenigstens etwas was man verarbeiten kann. Das müsste doch prinzipell mit einer deiner isobust-Kurven gehen. I-contrast wird das auch nicht viel anders wenn auch intelligenter machen. Die Auto-Kurve aus std versucht das vermutlich auch.

Kurven mehrfach anwenden:
Geht nur über die Raw-Entwicklung, die ohne Umrechnungen aber relativ schnell ist.

Ich hab mir die raw_merge Funktionen nochmal angesehen. Eine sub ist dort schon vorhanden (wegen der Darkframekorrektur).
Ebenso eine mul bzw. div wegen der Durchschnittsbildung. Eine Erweiterung schien mir einfach allerdings bin ich wieder an der Einführung optionaler Parameter für raw_merge_end gescheitert obwohl ich das einmal konnte.

Deshalb extra für dich zum testen eine neue Luafunktion
raw_merge_set_filter(f1,b1,f2,b2) anzuwenden zwischen raw_merge_start und raw_merge_end.
damit können 2 vertikale Verlaufsfilter definiert werden.
die Werte müssen zwischen -200 und 200 liegen und <> 0 sein.

ein Filterwert(f1,f2) < 0 bedeutet % Abdunklung. Mehr als 100% sind hier natürlich nur bedingt nützlich.
entsprechend bewirken Werte > 0 eine Aufhellung.

Positive Bereichswerte(b1,B2) bedeuten % vom oberen Rand her, negative % der Bildhöhe vom unteren and her.

Anbei ein Beispiel

Bild
Die dabei verwendeten Werte sind in die Bilder eingeblendet.

von oben nach unten Filterwert 33 66 100 133 166 %
Die Mitte ist Referenz
nach links heller nach rechts dunkler immer 30% vom unteren Rand
in den Außenreihen der gleiche Filterwertauch vom oberen Rand.
Die Fehlfarben sind vermutlich Überläufe aus der Berechnung.

Nun liegts an dir zu zeigen was man damit anfangen kann.

Mit dem Skript Verlauf kannst du Testen ob es sinnvolle Werte gibt.
Die dort einstellbare Gruppe von 25 Bildern entsprechend obigem Cluster
braucht bei mir 824 Sekunden.

Da ein Großteil der Berechnung auf der Karte stattfindet, die Karten immer schneller werden
und die Prozessorgeschwindigkeit schneller als die Rawgröße ansteigt sollte es bei den Meisten
deutlich schneller gehen.

Die obigen Einwände bleiben natürlich bestehen.
wie
- Beurteilbarkeit am Kammerabildschirm
- Geschwindigkeit
- Ist die Rawentwicklung überhaupt der richtige Ort für deinen Ansatz
- Wird es wirklich benötigt. usw.

Zur leichteren Nachkontrolle überschreibt das Skript im Exif den Kammeramodellnamen mit den verwendeten Filterwerten.
Bitte Weißabgleich fixieren, da er sich bei Automatik verstellt.
Bei der Rawentwicklung auf eine kurze Verschlusszeit achten, da sie eh nicht angewendet aber ausgeführt wird.

Gruß naddel

Edit: Anhänge ausgetauscht Überlaufkorrektur

sx220hs-101a-1.1.0-r988.zip
chdk sx220 mit raw_merge_set_filter
(218.71 KiB) 464-mal heruntergeladen
Dateianhänge
ixus60_sd600-100a-1.1.0-r988.zip
chdk ixus 60 mit raw_merge_set_filter und Ãœberlaufkorrektur 27.04
(399.62 KiB) 472-mal heruntergeladen
verlauf.lua
Testskript Verlaufsfilter für vorhandene und neue Raw Dateien
(12.06 KiB) 480-mal heruntergeladen
Zuletzt geändert von naddel am 02.05.2012, 12:57, insgesamt 3-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 » 27.04.2012, 11:43

Hallo,

zunächst vielen Dank an Naddel für den Entwurf des faszinierenden neuen Befehls und das Skript!

Inzwischen habe ich glücklicherweise Gelegenheit gefunden, um Naddels Umsetzung zu testen. Bitte sorry für die leichte Klötzchenbildung, ich habe die JPGs vielleicht etwas stark komprimiert.

Hier ein Originalbild mit langsam aufkommenden Gewitterwolken, welche hier auf dem Original noch zu einem (unbefriedigend) arg weißen Himmel führen, also der klassische Anwendungszweck eines Verlaufsfilters:
Bild

Mit Naddels Verlaufsfilter kommt der Himmel nun besser zur Geltung:
Bild

Noch extremer:
Bild



Ein anderes Beispiel, ein aktuelles Bild von heute früh, bei klarerem blauem Himmel Richtung Berge (ganz rechts die Zugspitze):

Original:
Bild

Mittels Naddels Verlaufsfilter verändert, wobei ich hier die Intensität des Filters vielleicht etwas zu übertrieben gewählt habe:
Bild


Man sieht, vor allem beim klassischen Anwendungsfall eines recht weißen Himmels kann ein Verlaufsfilter dem Bild mehr Ausdruck verleihen. Wie elegant man mit Naddels Verlaufsfilter den im Original (zu) hellen Himmel hier zurück in den Zeichnungsbereich der Helligkeitswerte hineinziehen kann, da fühle ich mich fast schon an HDR erinnert. Eine tolle Leistung von Naddel!

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 » 02.05.2012, 11:41

Hallo,

hier ein weiteres Beispiel zur Anwendung von Naddels Verlaufsfilter. Das Originalfoto:
Bild

Und nun mittels Naddels Verlaufsfilter verändert:
Bild

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

Anwendung der neuen CHDK-DE-Grafik-Befehle

Beitragvon Sinter » 02.05.2012, 14:14

Hallo Naddel,

Dein Skript und der Filter laufen ja bereits prima. Nachdem Du nun in Dein tolles Skript sogar noch die Möglichkeit einer Einzelaufnahme hinzugefügt hast, hier nun probehalber eine knapp erweiterte (eine function und wenige Zeilen) Version des Verlauf-Skripts mit zusätzlich eingefügter Display-Anzeige des ersten Verlaufsbereichs in Gestalt einer schwarzen Zickzack-Linie über den gesamten Filterbereich, die im Falle einer Einzelaufnahme (Parameter h=0 =Bild neu) mit angeschlossener Filterberechnung vor dem Auslösen des Fotos im Display eingeblendet wird. Hier lassen sich nun die neuen Grafikbefehle von CHDK-DE wunderbar einsetzen.

In diesem einfachen Beispiel bleibt vor dem Shooting diese Zickzack-Linien-Anzeige zum Testen 10 Sekunden eingeblendet um Zeit zu haben, die Kamera gemäß des vorgewählten Filterbereichs auf das Motiv auszurichten.

Dies ist im Skript als Function bei „Start in 2 Sekunden“ als function display_insert_filter() eingefügt, sowie noch ein draw_clear() nach Deinem sleep(2000).

Optisch idealer wären sicherlich verschiedene transparente Grauabstufungen die man nacheinander als abgestuft heller werdende Querbalken (=gefüllte Rechtecke) über die gesamte Displaybreite wirft, aber ich glaube hier sind die Farb-Paletten zu kameraspezifisch. Ob die Möglichkeit besteht, die zusätzlich vordefinierte Skript-Palette noch um wenige grautransparente Farben zu ergänzen, weiß ich nicht. Beispielsweise mit bereits fünf oder vier verschieden grautransparenten „Farben“ (80%, 60%, 40%, 20%-Tönung) könnte man einen Filterbereich wohl hinreichend schlüssig im Display erkennbar machen/einblenden.

Ich halte es zumindest als per Parameter zuschaltbare Option für sinnvoll, dem User vor Auslösen einer Einzelaufnahme irgendeine optische Orientierung im Display zu geben, welchen Bildbereich der Filter bestreichen wird. Statt Zickzacklinie am liebsten mittels abgestufter transparenter Balken quer über das Display.


EDIT: Nachdem hier das Skript schon mehrfach heruntergeladen wurde möchte ich sicherheitshalber betonen, das Skript funktioniert nur bei denjenigen Usern komplett, welche die obige Befehlserweiterung von Naddel installiert haben.

Viele Grüße,
Sinter
Dateianhänge
verlaufD.lua
Beispiel des Verlaufsfilter-Skripts mit Displayanzeige des (hier nur ersten) Filterbereichs bei Einzelaufnahme
(12.28 KiB) 486-mal heruntergeladen
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 » 04.05.2012, 13:09

Hallo naddel, hallo Sinter,

die Ergebnisse sind beeindruckend. Ich denke, dass wäre eine Sache, die für alle zugänglich gemacht werden sollte. Schade, dass es (noch) keine Patch-Datei gibt. Bei diesen Ergebnissen sehe ich keine größeren Probleme, die CHDK-Modulversion mit den erweiterten RAW-Merge-Funktionen auszustatten.

@naddel
Danke, dass du extra eine SX220-Version bereitgestellt hast. Ich kann aber nicht so einfach testen, da das Skript wahrscheinlich nicht (richtig) laufen wird. Das liegt u.a. an der geänderten Datenstruktur im DCIM-Ordner und an begrenztem Speicher. Die ganzen Prozeduren zum Auslesen der CRW-Datei sind durch die Arrays speicherintensiv.

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.

Für Informationen in den Exif-Daten ist aus meiner Sicht das verfügbare Exif-Modul hervorragend geeignet. Mit diesem Modul kann man den Exif-Tag User Comment schreiben.

Mit einem vereinfachtem Skript würden sich solche neuen Funktion besser "verkaufen" lassen.

@Sinter
Danke für die sehr anschauliche Ergebnis-Demonstration. Das hat mich, auch ohne es selbst zu testen, total überzeugt.


Es ist schon erstaunlich, was ihr mit euren schon etwas betagten Kameras bewegt. =D>

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 Sinter » 04.05.2012, 14:06

Hallo Msl,

vielen Dank für Deine interessanten Hinweise und Überlegungen.

Betagte Kameras besitzen den "Vorteil", dass man sich vielleicht öfters über manche nicht ganz optimalen Ergebnisse Gedanken macht, um für kleinere oder größere Defizite bessere Lösungen zu finden. Zu hell abgebildete Himmel waren da schon öfter auffällig. Wurde also Zeit, dagegen etwas machen zu können und (zu) helle Wolken mehr in den Zeichnungsbereich zu lenken. Dein Merge in br_def.lua schenkte hier glücklicherweise interessante Gedanken, um einen Lösungsansatz zu gewinnen. Zunächst wurden hier im Forum meine Hoffnungen zwar eingedampft, aber dann kam Naddels beeindruckender Einfallsreichtum in Fahrt.

Auch Naddels Exif-Lösung ist geschickt durchtrieben und nutzt auf äußerst elegante Weise den Dateneintrag. Dies ist vor allem in der Entwicklungsphase äußerst hilfreich um sich bei der Bildanzeige die zugehörigen Daten einzublenden. Ob man sich auch den User Comment als Datenfeld einfach einblenden lassen kann, bin ich mir nicht so sicher. Ich glaube in IrfanV geht das mittels placeholder $E37510, für XnV habe ich noch nicht nachgesehen.

Ja, mir ist schon klar dass man hier am besten zunächst hinreichend überzeugende Ergebnisse anschaulich aufzeigen muss, um eine Übernahme neuer Features ins offizielle CHDK zu erreichen. Ich wusste, hier müssen Beispiel-Fotos her, denn mittels Worten ist solche Überzeugungsarbeit stets schwierig.
Soweit es hier bei CHDK-DE die zeitlich begrenzten Programmierkapazitäten der Profis nach und nach zulassen, Wünsche für zukünftige neue Lua-Befehle hätte ich noch genug.

Naddels toller neuer Befehl und das komplexe Skript sind bereits weit gediehen. Indes haben wir auch noch ein paar Überlegungen, den Verlaufsfilter weiter zu optimieren und um weitere Funktionalität zu ergänzen. In der Tat ist nun Feintuning angesagt, um eine möglichst optimale Lösung zu erarbeiten.

Tja, und das mit dem "verkaufen" lassen, ist eine eigenes Thema. Wenn sich ein Verlaufsfilter mittels neuem Befehl und Skript umsetzen lässt, dann müsste sich doch eigentlich der Verlaufsfilter auch direkt in CHDK integrieren/hineinprogrammieren lassen? Denn ich bezweifle dass sich User hier all ihre eventuell nützlichen Skripte aufwändig zusammensammeln. Allerdings wäre das eine langfristige Überlegung und es ist vielleicht auch noch gar nicht sicher, ob sich der Verlaufsfilter auf sämtlichen Plattformen realisieren lässt.

Die ursprüngliche Skepsis hinsichtlich der Bearbeitungsdauer einer Filterberechnung ist zwar durchaus überlegenswert, indes steht der Filterberechnungszeit gegenüber, dass Naddels Filter höher auflösende RAW-Daten anwendet, und damit gleich aus der Kamera heraus ein ansehnliches Ergebnis liefert. Wenn man bedenkt, wie viel Zeit man aufwenden müsste um eine Bildbearbeitung am PC zu starten, nach dem RAW-File zu suchen, und dann auch erst noch einen passenden Verlaufsfilter einzustellen, dann besitzt Naddels CHDK-Verlaufsfilterbefehl noch immer deutliche Zeitvorteile. So kann ich durchaus mit einer Filterberechnungsdauer leben. Die wirkungsvollen Ergebnisse sprechen jedenfalls FÜR Naddels Filter.

Und keine Sorge bitte falls hier ein paar Tage lang in diesem Thread keine neuen Beiträge eingestellt werden. Zeitliche Kapazitäten sind begrenzt, aber die Sache bewegt sich auch im Hintergrund weiter.

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

Nächste

Zurück zu Code-Ecke

Wer ist online?

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

cron