[Lua] Fotos bei schwachem Licht (Für 10-Bit-CHDK-Cams)

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

Beitragvon msl » 18.03.2010, 13:16

Hallo Sinter,

in der Tat hatte ich bei meinen Formatierungsgeplänkel negative nicht in Betracht gezogen. Das könnte man mit einer Absolut-Funktion und Einplanung des Minus-Zeichens lösen. Aber Du hast ja mittlerweile eine gute Lösung gefunden.

Einen Hinweis im Handbuch zur blauen LED möchte ich nicht machen. Es handelt sich hier um eine spezielle Anwendung, die man nicht verallgemeinern kann. Wir würden sonst seitenweise Ausnahmeregeln dokumentieren müssen. Und ein paar Geheimnisse brauchen wir doch noch. ;)

Und hier gibt es eine Lösung für das Entfernen der Kommentare.

Wir bräuchten jetzt langsam mal mehr Tester insbesondere für die S-Serie, die SX-Serie, die G-Serie, die neueren Ixen, und für die A4xx Serie.

Ich möchte das Skript gerne in das Komplett-Download-Paket hinein packen. Dazu muss es aber auf vielen Kameras laufen. Deshalb sollte auch mit LED- und Sound-Steuerung vorsichtig umgegangen werden. Hier gibt es doch die eine oder andere Differenz zwischen den Kameras.

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

Getestet

Beitragvon Sinter » 18.03.2010, 14:16

Hallo CHDKLover,

die alleinige Anwendung der Mehrdeutigkeitsvermeidungsrechnung ist im Zusammenhang mit einer on-the-fly-Messung offenbar eine Sackgasse: Bilder sind oft viel zu hell. Ohne on-the-fly-Messung, also mit bisherigem Shooting, scheint die Sache nach einem ersten Test wohl zu funktionieren. Beide Downloads unten.

Ich war nach meiner zusätzlichen Integration der Mehrdeutigkeitsvermeidungsrechnung weiterhin zweigleisig verfahren, da ich mir nicht ganz sicher bin ob ein Get_tv96() und eine Bestimmung über die Mehrdeutligkeitsvermeidungsrechnung zum absolut identischen (!) Ergebnis führt. Theoretisch sollte es zwar so sein, aber es gibt ganz ohne Skript manchmal auch eine kleine Differenz zwischen der originalen Belichtungszeitanzeige der Cam, und der Belichtungszeitanzeige von CHDK, deren Grund ich nicht kenne aber auch nicht weiß, ob es hier überhaupt Parallelen zu unserer Belichtungsbestimmung gibt.

Ein Shooting mit einer Messung on-the-fly ist vermutlich nicht möglich. Dein angeschlossener Shooting-Prozess erschent mir gewagt und ich habe das in dieser kompakten Reihenfolge auch noch nirgends realisiert gesehen, aber falls Du doch noch einen anderen Weg findest, gerne.


@msl:
Ja, an der leidigen Formatierung habe ich mich ein wenig abgequält nachdem es keinen Lua-Befehl dafür gibt. Ich war erleichtert, als mir dann diese funktionierende quick-and-dirty-Function einfiel nachdem ich eine Weile die verfügbaren Lua-Befehle gesichtet hatte.

Deine Handbuchüberlegung kann ich nachvollziehen, das geht okay nachdem die Sache in der Tat sehr speziell ist.

Die blaue LED ist mir persönlich gar nicht so wichtig, nachdem ich ohnehin gerne den Akku schone. Aber prinzipiell ist korrekt, dass viele User verunsichert sein könnten, wenn sich kurze Zeit nur ein schwarzer Bildschirm zeigt, ohne laufende Prozesse wahrnehmen zu können. Da fällt mir noch ein, man könnte einen Stromsparparameter integrieren, der in diesem Skript sowohl LED und Sounds deaktiviert. Andererseits wäre so ein zusätzlicher Parameter eher Ballast.
Ob die Soundsteuerung genauso problematisch wie die LED-Steuerung ist, das weiß ich nicht. Ich hoffe, bzgl. Sounds sind die Cams weniger anfällig.
Sind Dir denn Probleme mit der orangen Focus-LED bekannt, wegen meinem eingebauten CustomTimer?

Ins Download-Paket kannst Du das Skript gerne hineinnehmen. Es war mir mit dem Skript ein Anliegen, die alte Schwäche der viel zu langen Belichtungszeiten unter schwachen Lichtverhältnissen auszumerzen. Gerade mit meiner Ixus60, die über keine ImageStabi verfügt. Zur Not kommentieren wir vorerst Sounds und LED aus.


@alle Tester: Derzeit sollte Version 0.9.5.0
download/file.php?id=1140
stabil und robust laufen. Mögliche Probleme könnten darin vielleicht bei LEDs (vorne orange bei Custom-Timer, Rückseite blau bei Bildentwicklung) und Sounds (während CustomTimer und bei eventueller Warnmeldung nach Shooting-Abschluss) auftreten.

Viele Grüße,
Sinter
Dateianhänge
LowLight_alleine_MehrdeutVerm_ohne_on_the_fly.lua
OHNE get_tv96, OHNE on-the-fly.
Funktioniert vermutlich/offenbar. Kann ich aber noch nicht endgültig bestätigen.
(33.28 KiB) 327-mal heruntergeladen
LowLight_alleine_MehrdeutVerm_mit_on_the_fly.lua
OHNE get_tv96, MIT on-the-fly.
Funktioniert falsch. Bilder oft zu hell da eine on-the-fly-Messung vermutlich grundsätzlich nicht möglich ist.
(33.17 KiB) 317-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

Beitragvon CHDKLover » 18.03.2010, 14:59

Hallo Sinter,
du hast recht, das ist mir zunächst gar nicht aufgefallen. :oops:
Schade, denn das hätte den Erstellungsprozess erheblich beschleunigt. Nagut, mehr fällt mir dazu gerade auch nicht ein.

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

CHDKLovers Schachzüge

Beitragvon Sinter » 18.03.2010, 16:42

Hallo,

doch doch, CHDKLover ist noch etwa eingefallen. Ein genialer Schachzug von CHDKLover macht ein "on-the-fly"-Shooting incl. Messung nun vielleicht doch möglich. =D>

Hier ein Download.


EDIT: Diese Version 0.9.5.4 scheint bei mir tatsächlich tadellos zu laufen. Ich glaube das ist eine solide Version für die weitere Entwicklung. CHDKLovers Schachzug stellt hier womöglich eine äußerst nützliche und angenehme Revolution für unsere Shooting-Möglichkeiten dar.

Viele Grüße,
Sinter
Dateianhänge
A954LowLight.lua
LowLight.lua mittels Mehrdeutigkeitsvermeidungsrechnung und Shooting/Messung on-the-fly! Die Kommentare im Skript sind noch nicht aktualisiert.
(33.23 KiB) 337-mal heruntergeladen
Zuletzt geändert von Sinter am 18.03.2010, 18:24, insgesamt 4-mal geändert.
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

Beitragvon CHDKLover » 18.03.2010, 16:53

Und da gibt es doch noch eine Lösung:
statt:
Syntax: [ Download ] [ Verstecken ]
Benutze Lua Syntax Highlighting
set_tv96_direct(wert)
Erstellt in 0.004 Sekunden, mit GeSHi 1.0.8.9

dies hier:
Syntax: [ Download ] [ Verstecken ]
Benutze Lua Syntax Highlighting
proptable=require "propcase"

set_prop(proptable.TV,wert)
Erstellt in 0.004 Sekunden, mit GeSHi 1.0.8.9

Warum ist das so?
Ãœblicher Ablauf der Overwirtes:
  1. Override Werte zum setzten merken
  2. shoot_half
  3. Kamera Fokussiert und ermittelt ihre Werte, sie ist bereit zum knipsen
  4. CHDK überschreibt schnell noch mit den zuvor eingestellten Overrides die von der Kamera ermittelten Werte
  5. shoot_full
  6. fertiges Foto

Was macht jetzt set_tv96[_direct]()?
Der Befehl sorgt dafür das sich das CHDK die Override Werte zum ersetzen merkt für 1.

Warum geht das in dem Fall nicht?
Da wir schon shoot_half ausgelöst haben und die Kamera daraufhin bis einschließlich Schritt 4 (CHDK hat keine Werte verändert, da keine Overrides vor shoot_half eingestellt waren) abgearbeitet hat, müssen wir jetzt "manuell" den Override ausführen. Dies machen wir mit dem setzten des Propertys TV. Nun macht die Kamera das Bild mit der gewollten Belichtungszeit.

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

Flüssiges Shooting

Beitragvon Sinter » 18.03.2010, 17:45

Hallo CHDKLover,

ich habe das jetzt noch weiter getestet und muss sagen, der Ablauf des Shootings ist spürbar flüssiger wenn nicht mehr doppelt fokussiert werden muss. Deine geniale Idee macht sich richtig angenehm bemerkbar und ist auch für andere Skripte sehr interessant. Diese Lösung werde ich zukünftig gerne auch noch in andere Skripte einbauen. DANKE!

Ãœbers Wochenende werde ich die Version 0.9.5.4 nochmal genau unter die Lupe nehmen. Ich glaube, diese Version ist inzwischen sehr solide.

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

Beitragvon Hamster.78 » 21.03.2010, 22:11

Hallo,

möchte einmal ein kurzes Testergebnis abliefern ;)
Die Sound und LED Steuerung funktioniert mit der SX100.

Die blaue LED leuchtet jedoch die komplette Zeit (Erstellung Foto & Tonwertkorrektur) - wenn es möglich wäre diese LED nur für die Belichtungszeit anzusteuern wäre es hilfreich.

LowLight_alleine_MehrdeutVerm_ohne_on_the_fly.lua liefert super Ergebnisse. Jedoch habe ich soeben bei starker Dunkelheit festgestellt das die Belichtungszeit über 1/40s möglich ist. Leider fehlte mir die letzten Tage die Zeit mich näher damit zu beschäftigen.

gruß Hamster Bild
◄ SX100 v100c ◄ Samsung NX10

CHDK DEThe Canon Camera Hackers Manual schon gelesen?
Benutzeravatar
Hamster.78
CHDK-Begeisterter
CHDK-Begeisterter
 
Beiträge: 318
Registriert: 24.01.2009, 11:21
Wohnort: Sachsen / Chemnitz

Beitragvon msl » 21.03.2010, 23:23

Hallo Hamster.78,

die blaue LED leuchtet erst mit Beginn der Einrechnung der Kurve. Sinter möchte damit signalisieren, dass die Kamera trotz des schwarzen Bildschirms arbeitet. Als Alternative könnte man evt. auch einen Text einblenden.

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

Version 0.9.5.5

Beitragvon Sinter » 22.03.2010, 07:50

Hallo,

zunächst als Download ein weiteres Update 0.9.5.5 , in welchem die realisierte Belichtungszeit nicht nurals Apex-Wert, sondern zusätzlich in Sekunden angegeben wird. Vorübergehend habe ich daher nun die Konsolenzeilen auf Anzahl 13 ausgedehnt, was allerdings keine Dauerlösung sein soll. Auf Dauer würde ich gerne höchstens 12 Zeilen zulassen um eine Kollision mit Anzeigen im oberen Displayteil zu vermeiden.

Die Anwendung der alleinigen Mehrdeutigkeitsvermeidungsrechnung scheint mir inzwischen problematisch. Erste Test ergeben den Eindruck, dass die Cam dabei geneigt ist, etwas zu hell zu belichten. Vielleicht muss ich hier wieder zurückrudern und im Normalfall wieder auf das präzise get_tv96() zurückgreifen.



@Hamster:
Vielen Dank für Deine Rückmeldung.

Die (blaue) LED war eine gute Idee von CHDKLover, damit ein unerfahrener User von dem schwarzen Display während der Entwicklungsdauer nicht verunsichert wird, sondern signalisiert bekommt, die Kamera arbeitet noch. Auch wenn ich sehr gerne mit dem Akkuverbrauch geize, für unvertraute User macht die LED durchaus Sinn.

Wann die LED leuchtet, bzw. wo die Steuerungsbefehle (ein/aus) im Skriptcode platziert sind, das scheint ein wenig heikel. Beim ersten Versuch hatten manche Cams gestreikt. Die derzeitige, offenbar nun kameraübergreifend funktionierende Platzierung im Code, hatte msl gefunden. Die endgültige Anzeige des Arbeitszustands können wir gerne noch in einem Feintuning weiter versuchen zu optimieren.

Deine Beobachtung von Belichtungszeiten größer als 1/40 Sekunde ist korrekt, sofern es derart dunkel ist, dass diese Dunkelheit selbst mit höchster ISOBoost-Stufe 4 nicht kompensiert werden kann. In solchen Fällen wird dennoch eine Aufnahme gemacht, jedoch mit entsprechend längerer Belichtungszeit, und zugleich erfolgt eine akustische und schriftliche Warnmeldung, um wieviel EV das Anspruchniveau verfehlt wurde. Die akustische Warnmeldung piepst Dir mittlerweile sogar genau die Anzahl der verfehlten EV. Nach der Aufnahme braucht man daher nicht mehr unbedingt auf das Display zu schauen, sondern kann der Kamera auch nur zuhören. Wenn es piepst, dann wurde das Anspruchniveau (oft 1/40 Sekunde) um die Anzahl der Beeps verfehlt. Voraussetzung natürlich: Der Ton ist an. Bei sehr ruhiger Hand kann man beispielsweise eine Verfehlung um eine EV oft noch verschmerzen. Sofern die Cam angelehnt war vielleicht auch noch eine Verfehlnug von 2 EV. Bei größerer Verfehlung wird das Verwackeln aber schon sehr kritisch.


Ich versuche derzeit noch eine optionale, bedarfsgerechte zusätzliche ISO-Anhebung zu integrieren. Ich musste aber über das Wochende feststellen, dass die ISO-Steuerung etwas heikel ist. Zunächst muss ich noch klären, auf welche Weise die Cam zuverlässig ISO-Steuerungsbefehle annimmt. Erste Tests zeigten mir unerklärliche, sehr verwirrende Ergebnisse. Wenn diese Steuerung geklärt ist, werde ich das Skript nochmals verbessern. Dazu wäre interessant, ob man auch die camspezifische ISO-Obergrenze mittels Skript ermitteln könnte. Ich vermute, das ist kaum möglich. So bliebe entweder eine manuelle Parameter-Einstellung, oder aber eine Annahmebeschränkung von ISO 800.

Viele Grüße,
Sinter
Dateianhänge
A955LowLight.lua
LowLight Version 0.9.5.5
(33.41 KiB) 342-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

Anwendung von ISO-Steuerungsbefehlen?

Beitragvon Sinter » 22.03.2010, 14:52

Hallo,

ich finde derzeit keinen Weg um eine zuverlässig ISO-Steuerung zu realisieren.

Bevor ich die Sache in LowLight anwende, müsste zuerst grundsätzlich geklärt sein, wie die ISO-Steuerungsbefehle in einem Skript eingesetzt werden können. Momentan kämpfe ich mit der korrekten Platzierung und Anwendung der Befehle.

Irritiert bin ich über folgenden Sachverhalt:
Zunächst das Skript in Lua:

Syntax: [ Download ] [ Verstecken ]
Benutze Lua Syntax Highlighting

--[[

************************************

@title IsoCheck/ISOShooting

@param q Kein Parameter

@default q 0

--]]




-- start main



sleep(2000)

print_screen(1)



set_console_layout(0,0,25,12)



print("Bei Start: ",get_sv96())



print"i IApex IMode IMarket IReal"

for i=400,850,50 do



set_sv96(i)

   

press("shoot_half")

  repeat

    sleep(1)

  until get_shooting() == true

   

--set_sv96(i)

   

print(i,get_sv96(),get_iso_mode(),get_iso_market(),get_iso_real())

        sleep(300)

   

        press("shoot_full")

        release("shoot_full")

        release("shoot_half")

       

  repeat

    sleep(1)

  until get_shooting() ~= true

end

 



print_screen(false)

 
Erstellt in 0.005 Sekunden, mit GeSHi 1.0.8.9


Nun das Ergebnis, als ich das Skript in ISO-Einstellung ISO100 startete:

Code: Alles auswählen
Bei Start:  0
i IApex IMode IMarket IReal
400 400 0 85 60
450 450 0 66 86
500 500 0 95 124
550 550 0 136 178
600 600 0 196 256
650 650 0 282 367
700 700 0 405 527
750 750 0 581 756
800 800 0 833 1084
850 850 0 1196 1556



Wobei das erste Foto heller ist als das Zweite. (ISOMarket spiegelt das offenbar wider, hier ist der zweite Wert am geringsten.) Das zweite Foto ist insgesamt am dunkelsten.
Foto 1 ist etwa so hell wie Foto 5.
Von Foto 2 bis 7 nimmt die Helligkeit zu.
Fotos 7 bis 10 sind gleich hell. Offenbar ist das die IsoGrenze meiner Ixus60, die jedoch offiziell bis ISO800 geht. Kann es sein, dass ISOMarket von 405 der nächsten ISOStufe angerechnet wird?

Seltsam dass ISOReal (Minimum bei Foto 1) einen anderen Verlauf hat als ISO Market (Minimum bei Foto 2)

Und den Nullwert des Befehls get_iso_mode kann ich mir hier auch nicht erklären. Die gesamte Serie wurde mit Einstellung ISO 100 gestartet.

Am liebsten wäre mir das set_sv96 nach dem Halfshoot, aber auch das funktioniert nicht wie gewünscht. Hat denn jemand Erfahrung, auf welche Weise die ISO-Steuerung korrekt funktioniert?

Seltsam auch, dass beim Start der Wert 0 geliefert wird.

Falls ich richtig beobachtet habe, so ist ISO nicht nur in den wenigen festen Stufen der Cam, sondern mittels CHDK ziemlich fein einstellbar. Oder täusche ich mich?

Viele Grüße,
Sinter
Zuletzt geändert von Sinter am 22.03.2010, 18:19, insgesamt 1-mal geändert.
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: Version 0.9.5.5

Beitragvon Hamster.78 » 22.03.2010, 17:48

Sinter hat geschrieben:Auch wenn ich sehr gerne mit dem Akkuverbrauch geize, für unvertraute User macht die LED durchaus Sinn.
unter den Voraussetzungen findet diese Anzeige natürlich Ihre Berechtigung.
Ich habe auch festgestellt das man die gelbe LED für die Überprüfung der Belichtungszeit nehmen kann, da diese ja auch noch blinkt ;)

schade das sich nicht mehr User für einen Test entscheiden können. :-k

gruß Hamster
◄ SX100 v100c ◄ Samsung NX10

CHDK DEThe Canon Camera Hackers Manual schon gelesen?
Benutzeravatar
Hamster.78
CHDK-Begeisterter
CHDK-Begeisterter
 
Beiträge: 318
Registriert: 24.01.2009, 11:21
Wohnort: Sachsen / Chemnitz

Das sehe ich locker

Beitragvon Sinter » 22.03.2010, 18:16

Hallo Hamster,

laut Handbuch sind die anderen farbigen LED noch tückischer. Daher ist die blaue LED vermutlich die Erste Wahl um dem User den Busy-Status zu signalisieren.

Dass es derzeit noch kaum Tester gibt, sehe ich recht locker. Kritisch sind im Skript wohl allenfalls die LED-Signale und das Piepsen. Zur Not kann man beides auch einfach weglassen falls sich tatsächlich Probs zeigen. Das wäre schnell gemacht. Von daher ist das Skript eigentlich noch nicht wirklich fertig. Andererseits könnte man ein Skript mit den derzeitigen Features vielleicht demnächst schon als eine Version 1.0 freigeben, und dann später mit Folgeversionen nachlegen.

Derzeit sind auch noch wenige andere Fragen offen, für deren ausgiebige Tests ich teilweise selbst noch nicht genügend Gelegenheit fand. Einerseits könnte es sein, dass ich aus Präzisionsgründen einfach wieder zweigleisig fahren muss und die Abfrage mit get_tv96 wieder einbauen muss. Das wäre kein Problem.

Ich würde jedoch gerne noch eine optionale bedarfgesteuerte automatische ISO-Anhebung programmieren. Dafür fehlen mir eigentlich nur noch die Erkenntnisse, unter welche Umständen die ISO-Steuerungsbefehle auch die beabsichtigte Wirkung erzielen. Daher auch mein heutiger Beitrag zum ISO-Steuerungsproblem allgemein. Ich habe in den letzten Tagen dafür jede Menge Zeit investiert und Möglichkeiten ausprobiert, habe aber noch keine Lösung gefunden, welche robuste Ergebnisse geliefert hätte. Ich hoffe, ich habe nur eine winzige wichtige Regel übersehen. Sobald ich eine solche Methode kenne, ist der Einbau nur noch eine Zeitfrage. Hoffentlich kennt jemand den entscheidenden Tipp für mich.

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

Beitragvon msl » 22.03.2010, 20:39

Hallo Sinter,

ich habe in diesem Skript etwas mit dem Setzen von ISO-Werten experimentiert. Das waren meine ersten Ansätze, zu lange Verschlusszeiten mit Erhöhung der Empfindlichkeit zu kompensieren. Vielleicht hilft dir das etwas weiter. Zumindest kannst Du mit diesem Skript das Verhalten beobachten.

Bedenke aber, sobald du dich außerhalb der von Canon vorgesehenen Werte befindest, können die Ergebnis stark verfälscht werden. Deshalb wäre es auch im Interesse des Rauschverhaltens empfehlenswert, den ISO-Market-Wert zwischen 80 und 400 einzugrenzen.

Das für den ISO-Mode 0 ausgeben wird, kann ich im Augenblick auch nicht erklären. Da muss ich selbst erst mal experimentieren.

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

Bewährtes herausgreifen

Beitragvon Sinter » 25.03.2010, 11:35

Hallo,

nach meinen weiteren Tests scheint die Mehrdeutigkeitsvermeidungsrechnung teilweise von der präzisen get_tv96()-Messung abzuweichen. Daher würde ich vorschlagen, zunächst ein wenig zurückzurudern und eine erste "offizielle" Version von LowLight 1.0 noch mit den bewährten Algorithmen und dem doppelten Fokussieren laufen zu lassen. Alle tv96-Apex von >0 werden damit präzise eingelesen und das Skript wendet nur im Mehrdeutigkeitsfall (tv96-Apex=0) die vielleicht etwas ungenauere, aber dennoch hilfreiche Mehrdeutigkeitsvermeidungsrechnung an.

Das hoffentlich realisierbare Shooting-on-the-fly, wie von CHDKLover vorgeschlagen, möchte ich sehr gerne weiterverfolgen für demnächst optimierte Versionen. Die Realisierbarkeitstests brauchen noch eine Weile. Das weitere angedachte Feature einer bedarfgerechten automatischen ISO-Anhebung lassen wir in Version 1.0 ebenfalls noch weg und können damit vielleicht später nachlegen.

Version 0.9.6.1 schlage ich als Kandidat für Version 1.0 vor. Den Abschluss des Skriptes würde ich gerne noch kurz diskutieren. Einerseits habe ich das sleep(5000) auskommentiert um dem User eine schnellere Abfolge der Aufnahmen zu ermöglichen. Etwas unklar ist mir noch, weshalb die Konsole 4 bis 5 Sekunden nach Skriptbeendigung gelöscht wird (welcher Befehl ist dafür verantwortlich?), und welche Überlegung dahintersteckt?

Es wäre noch zu bedenken, wie viele Zeilen die Konsole für Normaluser haben soll. Bislang bekommt der User noch die vollständige Information über sämtliche Werte. Im Alltag könnte jedoch reichen, sich auf

Anspruchniveaukorrekturumfang (wird ohnehin nur bei Bedarf eingeblendet)
Angewandte ISOBoost-Stufe
Realisierte Belichtungszeit und evtl.
Verfehlungsumfang/ISO-Erhöhungsaufforderung

zu beschränken. Was meint Ihr, welche Infos für den User im Alltag Sinn machen? Ich könnte dann per Parameter schaltbar gestalten, ob der User die vollständigen oder nur die eingeschränkten Infos angezeigt bekommen möchte.

Sofern all diese Punkte geklärt sind kann ich gerne für eine Version 1.0 die Kommentare entfernen um das Skript schlanker zu machen.



@msl:
Vielen Dank für Deinen Hinweis auf Dein ISO-Skript. Das werde ich mir gerne noch genauer ansehen.

Ich habe parallel dazu experimentiert, wie weit die beiden Verfahren (get_tv96 sowie Mehrdeutigkeitsvermeidungsrechnung) voneinander abweichen. Die Abweichungen schwanken bei mir bislang in einem Streuungsintervall von bis zu 1EV, vorwiegend bei sehr schwachem Licht. Bei besserer Helligkeit liegen beide Methoden tendenziell näher beisammen. Da muss ich wohl noch einige Erkenntnis gewinnen, ob/wie sich das vielleicht doch noch verlässlicher betreiben lässt.

Eine Eingrenzung von ISO-Market hatte ich auch schon angedacht, vor allem allein schon weil je nach Cam unterschiedliche ISO-Obergrenzen existieren, die sich nicht so einfach im Skript abfragen lassen. Ich hatte als Grenze mit Market 800 spekuliert, was man aber erst noch experimentell untersuchen müsste. Mit Deinen vorgeschlagenen 400 liegt man auf jeden Fall auf der sicheren Seite.

Die Tücke steckt nun in den Details und lässt die weitere Optimierung jetzt langsamer voranschreiten. Daher halte ich es für sinnvoll, eine Version 1.0 zunächst auf die erprobten funktionierenden Features und Algorithmen zu beschränken und die eventuell realisierbaren weiteren Optimierungen in späteren Versionen einzupflegen.

Viele Grüße,
Sinter
Dateianhänge
A961LowLight.lua
Version 0.9.6.1 evtl. als Basis für Version 1.0
(24.54 KiB) 332-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

Verwackelungsschutz-LowLight-Skript mit PDF-Anleitung

Beitragvon Sinter » 01.04.2010, 11:49

Hallo,

diese Version könnte vielleicht als RC für LowLight 1.0 geeignet sein.
Der Code ist um viele Kommentare eingekürzt.

Hier für Euch zum Download die ausführliche PDF-Anleitung sowie das aktuelle LowLight-Skript, welches vielleicht die finale Fassung für LowLight 1.0 darstellen kann.

Viele Grüße,
Sinter
Dateianhänge
LowLight963.pdf
Ausführliche PDF-Anleitung zu LowLight 0.9.6.3
(78.89 KiB) 343-mal heruntergeladen
A963LowLight.lua
LowLight 0.9.6.3
als RC für LowLight 1.0
(13.69 KiB) 340-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

VorherigeNächste

Zurück zu Code-Ecke

Wer ist online?

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