Diskussion DOF-Rechner

[gehtnix]

moin moin,

die Visus-Thematik zieht einen Riesenrattenschwanz an Erklärungen mit sich. Z.b. wieso stimmt er Hyperfokale Fokus nicht mit dem DoFmaster überein?

Wir Stacken um mehr Details im Bild zu haben!

Ein Visus unter 50% ergibt ein schlechteres Bild, diese Version fällt wohl unter den Tisch.

Bei einem Visus von 100% passiert nun folgendes, der Hyperfokale Fokus verdoppelt sich, die GET_MIN_STACK_DIST wird nun verschoben von 27 auf 37mm, Bildzahl erhöht sich von 27 auf 38 Stück. Die DoF-Werte halbieren sich bei den entsprechenden Distanzen fast. Das kann man auch im Skript erledigen! Und ist viel einfacher zu handeln (50 Kameras > Pflege)

Und nicht zu vergessen, unter einem DoF von 10mm wird da wegen Integer wohl nix passieren, ab ca. 500mm wegen mangelnden Fokuspositionen wird das dann gestückelt.

Wegen meiner Einer braucht es das nicht.

gehtnix

[Sinter]

Hallo,

wenn man alle bislang gewonnenen Erkenntnisse bezüglich Visus betrachtet, so halte ich es ebenfalls für notwendig, genau zu überlegen, wie weit, bzw. in welcher Form das Visusthema in der Praxis eine Umsetzung lohnt.

Gehtnix Aussage über das 50%-Limit ist völlig korrekt. Weniger als ein 50%-Visus machen das Bild schlechter, was nur dann in der Praxis einen Sinn macht, wenn das Bild nur als"kleinerer" Abzug oder Internetbild betrachtet wird. Aber allein für diesen Fall macht es kaum Sinn, hier etwas umzusetzen, es sei denn, man zielt auf eine möglichst geringe Rechenenzeit ab.

Es bleibt die Frage, wie weit wir die Beobachtung umsetzen sollen, dass eine Visussteigerung durchaus noch eine Bildverbesserung ermöglicht. Dies ist vorwiegend für große Abzüge interessant. Insofern würde in der Tat die Low-Budget-Lösung darin liegen können, einfach im Skript die Möglichkeit zu haben, die Bildanzahl zu erhöhen indem die Fokusabstufung ein wenig verdichtet wird. Anhand der wunderbar ausgearbeiteten Exel-Tabellen von Gehtnix könnte bei Bedarf jeder User für seine individuellen Verhältnisse berechnen und vergleichen, welche Anzahl von Aufnahmen für seine Ansprüche Sinn machen. Auch für Postergrößen etc.

Sofern mit geringem Aufwand tatsächlich realisierbar, wäre Rudis Vorschlag mit ein oder zwei korrigierten pauschalen CoC-Werten anhand des Visusanspruchsniveaus (normal, hoch, niedrig) ein sehr guter Kompromiss. Genaugenommen würde wohl nach bisherigen Erkenntnissen auch ausschließlich ein zusätzlicher "Hoch"-Wert ausreichen, falls jemand ein Bild in Postergröße entwickeln möchte. Hoch- sowie evtl. Niedrig-Wert könnten womöglich einfach per Multiplikator aus dem bereits in CHDK hintelegten bisherigen CoC berechnet werden.

Gehtnix´ Tabellen und Praxisversuche haben uns jedenfalls schon eine Menge Erkenntnisse bezüglich Grenzen und evtl. ausschöpfbaren Reserven gebracht.

Versuchsweise habe ich nun noch probiert wie sich in Gehtnix´ v6-Exeltabellen-Version in beiden Tabellen eine andere Fokusfortschreibung auswirkt (Download in diesem Beitrag). (Eine sehr genau Approximation innerhalb der CoC-Berechnung ohne Tangens, sondern ersatzweise mittels simpler Multiplikation ist ebenfalls eingetragen, in Zelle P6):

Ich habe versuchweise den Fokus jeweils auf Grundlage des vorherigen Far-Wertes kalkuliert um zu sehen wie es sich darstellen würde, wenn man auch kameraseitig Überlappungen vermeiden, bzw. minimieren würde. Der Ansatz bestand darin, jeweils den Far1-Wert als Zielwert des Near2 zu nehmen und zu diesem Near2 den notwendigen/passenden Fokus2 auszurechen, aus dem sich wiederum der Far2-Wert ergibt, der dann weiter für Near3 übernommen wird usw.
Wobei Fokus2 aufgrund der Kamerastufen jeweils nur als Ganzzahl übernommen werden kann und somit manchmal den Near2-Wert doch noch ein wenig kleiner als den Far1-Wert ausfallen lässt. Dadurch entsteht zwar manchmal doch noch eine kleine Überlappung, aber sie bleibt deutlich minimiert, so dass wir mit weniger Aufnahemn auskommen könnten.

Bei 80% Visus müssen beispielsweise insgesamt nur noch 29 statt 34 Fotos gemacht werden.
Bei kurzen Motivdistanzen ändert sich in der Tabelle recht wenig. Der Bildanzahlgewinn wird vorwiegend ab den mittleren Entfernungen realisiert.

Indes gilt zu überlegen:
Deine bisherige Fokusfortschreibung beinhaltet durch die größeren Überschneidungen zugleich größere Sicherheitsreserven wenn sich der Fokus bei den Kameras ausschließlich in teilweise groben Stufen einstellen lässt. In obiger überlappungsminimierender Fokusfortschreibung sind dagegen so gut wie keine Sicherheitsreserven vorhanden und würde ein Visusanspruchsniveau nur dann korrekt einhalten können, wenn sich Fokusstufen fein genug einstellen ließen.

Mittlerweile frage ich mich ob es die Datenlage zulassen würde, in der linken Tabelle die in den Kameras real verfügbaren Fokusstufen zu berücksichtigen bzw. zumindest die Feinsteuerung auszureizen. Die Kameras setzen uns hier offenbar schon ziemlich harte Grenzen. Und vermutlich sind die verfügbaren Fokusstufen auch noch je nach Kameramodell äußerst verschieden.

Viele Grüße,
Sinter

[msl]

Hallo DOF-Entwickler-Team,

Eure Entwicklungs- und Forschungsarbeit ist bemerkenswert. Hier werden wirklich alle Grenzbereiche dieser Thematik ausgelotet.

Jetzt kommt aber das große ABER:

Diese Visus-Geschichte ist gegenwärtig einfach nicht umsetzbar. Damit würden wir das System CHDK gefährden. Wie Ihr wisst, haben wir mit vielen innovativen Entwicklungen, riesige Probleme, diese international durchzusetzen. Nicht zuletzt wegen dieser Tatsache wurde CHDK-DE ins Leben gerufen. Trotzdem wollen wir aber möglichst ein einheitliches System aufrecht erhalten. Änderungen, die sich auch die einzelnen Plattformen beziehen, sind nur machbar, wenn sie überall einheitlich übernommen werden. Sonst bekommen wir zukünftig riesige Probleme, neue Kameras überall zu integrieren.

Und Visus ist nun mal nicht so einfach international einführbar. Da müsstet Ihr die gesamte Diskussion noch einmal im internationalen Forum führen, damit es evt. begreifbar wird. Das Thema ist auch zu speziell.

Solange sich die Änderungen auf den Core-Bereich beziehen, sehe ich keine Probleme, diese auch abweichend vom Ursprung einzuführen. Das haben wir ja schon mehrfach gemacht. Einiges wurde dann auch international übernommen.

Deshalb sollten jetzt erst mal die Korrekturen am DOF-Rechner eingeführt werden, die sich auf vorhandene Plattform-abhängige Daten wie CoC und Brennweiten-Tabellen beziehen.

Wenn sich das bewährt (davon gehe ich aus) und zukünftig auch in die internationale Version einfließt, könnte man sich evt. um die Verfeinerung und Neuordnung der Plattform-abhängigen Daten kümmern.

Das sind nun eben auch die Nachteile eines weltweiten Open-Source-Projektes. Nicht alles ist zu jedem Zeitpunkt machbar.

Gruß msl

[gehtnix]

Hallo,

nicht vergessen, rudis Aussage zu seiner A590. Er hat nur 146 Distanz-Positionen, meine A610 wir wohl auch um diesen Dreh kreisen.
Zwischen 50 und 500mm fehlen dem rudi (und sicherlich nicht nur dem rudi ) also 75% der "notwendigen" Positionen um einwandfrei zu Stacken!

Sinter, Du lieferst eigentlich das schlagend Argument, die Excel-Tabelle. Mit 50% Visus sind wohl alle erstmal gut bedient. Und will nun einer ein Poster machen so gibt er in Excel 90x60cmm und einen Betrachtungsabstand von 150cm ein und stellt fest da ändert sich nicht viel. Bei 50mm Distanz die gleichen DoF-Werte, die gleichen Anzahl der Bilder.
Die Excel-Tabelle hat den Vorteil dass ich was "sehe", wenn ich in CHDK einen DOF_min aktiviere, so sehe ich zunächst mal nicht was das zur Folge hat.
Den DoF-Wert über das Skript (DoF*0,7 etc.) zu verkleinern halt ich für völlig ausreichend.

Ob ich nun 20 oder 27 Bilder durch CombinZP verwurste finde ich mittlerweile nebensächlich.

Die Fokusstufen nun auch noch mit zu berücksichtigen halte ich für überflüssig, siehe meine Notlösung mit dem "Digitalen Holzhammer". Wird aber auch nicht so schlimm werden da letztes Foto maximal mit Hyperfokalem geschossen wird.

Bei höheren Brennweiten da schaut es anders aus, da ist die Überlappung vielfach 0mm. Dass aber einer von von 250mm bis 50m bei Blende 2.8 und 29.2 Brennweite 100 Bilder stackt halt ich für die absolute Ausnahme. Wenn der noch den DoF halbiert......

Irgendwo muss aber auch mal eine Grenze gezogen werden! ....hat gerade auch msl gesagt

gehtnix

[Sinter]

Hallo,

kein Problem wenn wir die Visus-Geschichte ausklammern.

Inzwischen besitzen wir die Erkenntnis, dass der voreingestellte CoC einen Visus von etwa 50% erreicht. Es war mir ein wichtiges Anliegen dass wir diese Visuseinordnung ermitteln konnten um eine Vorstellung zu besitzen, wie wir derzeit liegen und in welcher Größenordnung bei seltenem Bedarf noch weitere Reserven ausreizbar wären.

Wer für eventuelle Poster die noch weiteren bestehenden Visus-Reserven benötigt und ausreizen mag, hat weiterhin die Möglichkeit, einfach die Fokus-Werte per Skript enger zu staffeln und auf diese Weise einen besseren Visus (soweit möglich) zu realisieren. Wie schon gesagt steht mit Gehtnix´ vorbildlichen Tabellen die Informationsgrundlage für alle eventuell anspruchsvolleren Bedürfnisse jedem User zur Verfügung.

In der Theorie haben wir in dieser Hinsicht nun viel ausgelotet, neben den Chancen, auch die Hürden. Dem großen ABER von msl kann man daher noch die Realität der festen Fokusstufen hinzufügen, die uns ohnehin die Umsetzung der Theorie deutlich erschwert. Nachdem es solche festen Fokusstufen gibt (bei meiner Ixus vermutlich noch weniger Stufen als bei Euren leistungsfähigeren Kameras) könnte man sogar ausrechnen, welcher Visus jeweils zwischen zwei Fokusstufen überhaupt realisierbar wäre. Damit würden sich die Grenzen unmittelbar aufzeigen.

Insofern ist bei Betrachtung unserer Erkenntnisse in der Tat sinnvoll, vorerst den Visus auszuklammern und nur bei Bedarf eventuelle Visus-Einflüsse allein in den Skriptbereich zu legen.


Msl bringt mich für ein Randthema bereits wieder auf eine andere Frage:
Falls die Plattform-abhängigen Daten wie CoC und Brennweiten-Tabellen in den CHDK-Daten für den DOF-Rechner enthalten sind, könnte ich denn unter Lua mit vertretbarem Aufwand auf diese Brennweiten-Tabellen zurückgreifen, sprich, über den Umweg Zoomstufe dann per Skript auslesen, welche Brennweite (in Millimeter) eingestellt ist?

Viele Grüße,
Sinter

[gehtnix]

könnte ich denn unter Lua mit vertretbarem Aufwand auf diese Brennweiten-Tabellen zurückgreifen, sprich, über den Umweg Zoomstufe dann per Skript auslesen, welche Brennweite (in Millimeter) eingestellt ist?

Nicht nur in LUA! Diesen Wunsch hatte ich schon mal formuliert. Glaube das war bei HDR-Hyper. Da wird über die Zoomstufen-ID die Brennweite rausgesucht. Direkt ein Funktion wie

get_focal_Length a
a = 27200

das wäre nicht schlecht. Wobei durch die neue Arbeitsweise, rudi sei Dank, werden wir bei HDR-Hyper diese Lookup-Tabelle nicht mehr brauchen. Insofern wüsste ich jetzt auf Anhieb nicht wo mir Funktion get_focal_Length fehlen würde.

In Zukunft wird ein HDR-Hyper-Skript für alle Kameras funktionieren. Die IXUS wird das wohl dann auch können. Nur mal so, aus dem Fenster lehnend, nebenbei gesagt.

gruß gehtnix

[msl]

Hallo Sinter,

zum Rand-Thema:

Man müsste eine Funktion bauen, die die Brennweite ausgibt. Die Formeln sind ja für die Zoom-Anzeige schon vorhanden. Diese greifen auf die Brennweiten-Tabellen zurück. Hier hätten wir dann aber ein Integer-Problem. Man müsste für Anwendungen aufwendige Lua-Funktionen schreiben.

Grundsätzlich gibt es in diesem Bereich noch einen Nachholbedarf. Bisher sind CoC und Brennweiten-Tabellen noch unterschiedlich in den Plattform-abhängigen Dateien verfügbar. Bisher habe ich 3 verschiedene Möglichkeiten entdeckt. Übrigens kann man das jetzt mit der Doxygen-Dokumentation schön verfolgen.

Deshalb habe ich auch von einer Neuordnung geschrieben. Wenn ich richtig informiert bin, sind CoC- und Brennweiten-Informationen schon in der Kamera-Firmware verfügbar. Ein direkter einheitlicher Zugriff auf diese Daten würde vieles vereinfachen.

Gruß msl

[Sinter]

Hallo,

nicht nur für HDR-Hyper wäre das interessant. Konkret fehlt mir eine Funktion/Skriptbestandteil der Art get_focal_Length zum Vergleich der aktuellen Verschlusszeit mit derjenigen Verschlusszeit, bei der man ohne Stativ gerade noch nicht verwackelt.

Faustregel ist ja der Kehrwert der Brennweite (auf das alte analoge Format berechnet). Je nachdem welche Zoomstufe gerade eingestellt ist, muss ja ein anderer Grenzwert eingehalten werden. Für eine einzelne Kamera könnte man noch die Daten für jede einzelne Zoomstufe im Skript hinterlegen, aber mir fehlt noch eine Lösung/Idee wenn das Skript auf allen CHDK-Kameras gültig sein soll.

Falls ich Euch richtig verstehe ist dieser automatische Vergleich mittels Skript auf absehbare Zeit leider nicht realisierbar und ich müsste zur Not den User aktiv in seine Skripteinstellung einbinden.

Viele Grüße,
Sinter

[gehtnix]

Hi Sinter,

für das zukünftige HDR-Hyper ist die get_focal_Length Funktion nicht mehr notwendig.
Mit einem shoot_half bekommt man nun nicht nur den richtigen Hyp geliefert, er verändert sich auch sofort beim Zoomen(!!!)

Mit ein bisschen Irxenschmalz kannst Du aber im Skript aus dem Hperfokalen doch die Brennweite zurückrechnen

zur Not den User aktiv in seine Skripteinstellung einbinden

Dazu sag ich mal nix.

gruss gehtnix

[Sinter]

Hallo Gehtnix,

Deine Idee gefällt mir, aus dem Hyperfokalwert die Brennweite zu berechnen. Ob das mit Integer geht weiß ich noch nicht. Das Resultat wäre dann die reale Brennweite der Digitalkamera, die ich dann noch auf das alte Analogformat umrechnen müsste. Dann kämen wieder die unterschiedlichen Sensorformate ins Spiel.

Viele Grüße,
Sinter

[gehtnix]

Dann kämen wieder die unterschiedlichen Sensorformate ins Spiel

CoC von 4, 5 und 6 mehr ist da nicht. Das kann man noch mit Optionen im Skript handeln. Aber Integer, das wird komplizierter.

Aber, an den Aufgaben wächst man, respektive Du

servus gehtnix

[Sinter]

Hallo Gehtnix,

Du meinst, der CoC-Wert repräsentiert genau drei bestimmte verschiedene Sensorgrößen? Falls ja, wie bekomme ich den hinterlegten CoC-Wert per Skript heraus?

Integer könnte ich vielleicht auf Umwegen lösen.

Viele Grüße,
Sinter

[gehtnix]

Ihr IXUS-Leichmatrosen ,

könnte im Skript so aussehen.

Syntax: [ Download ] [ Verstecken ]

Syntax: [ Download ] [ Zeigen ]

Benutze uBasic Syntax Highlighting

@param h CoC 4 5 6

@default h 5

 

Erstellt in 0.005 Sekunden, mit GeSHi 1.0.8.9

Schaust Du Anlage an. Das habe ich mal für HDR-Hyper gesammelt.
IXUS fehlt bisher. Einmal den DOFmaster durchforsten oder den Trunk, da stehen ja alle Daten.

shoting.c im Trunk \Plattform
int circle_of_confusion = 5;

Insgesamt 50 Kameras, 37 mit einem CoC von 5 und 13 mit einem Coc von 6.

PowerShot A450 & 460 haben einen CoC von 4 und nicht wie hinterlegt 5 ! > DOFmaster


servus gehtnix

[Sinter]

Hallo Gehtnix,

ich glaube ich hatte mein Problem missverständlich formuliert.

Die CoC der einzelnen Kameras sind natürlich bekannt und man kann sie so wie in deinem Skriptbaustein in einem Skript angeben. Indes ist das nicht das zu lösende Problem.

Vielmehr geht es darum mittels eines Skriptes herauszufinden (!), auf welchem Kameratyp (respektive Sensortyp) das Skript gerade läuft. CHDK speist ja irgendwo den entsprechenden CoC-Wert in die Kamera ein um Hyper und DOF berechnen zu können. Analog zu dieser Einspeisung suche ich nach einer Möglichkeit, diesen zuvor eingespeisten Wert mittels Skript herauszulesen. Ähnlich einem Basis-Peek oder get_prop.

Viele Grüße,
Sinter

[gehtnix]

Hi Sinter,

ist das zu viel, den User abzuverlangen den CoC seiner Kamera auszuwählen?

gehtnix