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