Diskussion DOF-Rechner

[gehtnix]

Hi rudi,

Danke. Und das kann dann irgendwann mit "get_min_focus" (o.ähnlich) ausgelesen werden? Sehe ich das so richtig?

Den kl-Fokus mit der Brennweite dann über set_focus 1 /get_focus, Vergleich beider Zahlen und schon haben wir die minimale Startposition mit DOF=1 fürs Susi2Stack.
Das wäre ein Schritt in die richtige Richtung. Somit fallen alle Bilder mit einem DOF<1 weg.

@rudi, in Deinem minFokZo-Log, war da "Motiventfernung von Linse" aktiviert? - Nach Handbuch geht es bei der A590 erst bei 50mm los, dann wäre das doch OK.

gruß gehtnix

[rudi]

Hallo gehtnix,

den kleinsten Fokus kann ich auch in eine neue Funktion packen. Ich habe angenommen, dass die Formel auch in deine Exceltabelle Einzug hällt und die Hilfstabelle ersetzt.
Da die Funktion sich ausschließlich auf den DOF-Rechner bezieht, sollte man sie eher GET_DOF_FOCUS nennen. Aber Achtung, auch dafür ist dann SHOOT_HALF wegen der Blende nötig.

Den kleinsten Fokus der Zoomstufe kann man dann z.B. so anfahren:

Syntax: [ Download ] [ Verstecken ]

Syntax: [ Download ] [ Zeigen ]

Benutze uBasic Syntax Highlighting

set_focus get_dof_focus

Erstellt in 0.007 Sekunden, mit GeSHi 1.0.8.9

@rudi, in Deinem minFokZo-Log, war da "Motiventfernung von Linse" aktiviert?

Ja, denn ein anderer Wert macht ja keinen Sinn.

Da kann ich mal ein neues Testbuild für den DOF-Rechner machen.
Dabei nehme ich den Bezug der Funktionen zu "Motiventfernung von Linse" raus, damit wird immer von Linse gemessen (identisch zu Canon-MF-Balken).

Ich werde die originalen DOF-Funktionen jetzt ändern.

Habt ihr Ideen für einen kurzen und aussagekräftigen Funktionsnamen der neuen Funktion zum Ermitteln des kleinsten DOF-Fokus?

Gruß rudi

[gehtnix]

Hi rudi,

in Excel wollte ich das anders lösen.

set_focus get_dof_focus

Höchst elegant!
shoot_half wird im Skript ja eh schon gemacht. Perfekt!

Der Name "get_dof_focus", führt der nicht in die Irre?

Dabei nehme ich den Bezug der Funktionen zu "Motiventfernung von Linse" raus

Jupp, und mal ketzerisch gefragt, was könnte denn noch aus diesem Menü verschwinden?

Ich werde die originalen DOF-Funktionen jetzt ändern

Das klingt ein bisschen wie, ich ziehe jetzt den Stöpsel raus, in einer Stunde ist hier alles überflutet. So dramatisch ist das doch nicht Odrrrrr?

gruß gehtnix

[rudi]

Hallo gehtnix,

Der Name "get_dof_focus", führt der nicht in die Irre?

Daher gern weitere Vorschläge, nur GET_FIRST_FOCUS_BY_ZOOMSTEP_FROM_DOF_CALCULATOR ist mir einfach zu unhandlich. Dann evtl. GET_DOF_MINFOCUS ?

was könnte denn noch aus diesem Menü verschwinden?

Den Menüeintrag wollte ich noch nicht entfernen, da diese Einstellung noch an anderen Stellen verarbeitet wird. Das sollte erst geprüft werden. Die anderen Einstellungen würde ich mit implementieren - wer diese auch immer braucht. Ich gehe davon aus, dass sie nicht nur als langer Weile entstanden sind.

Ich werde die originalen DOF-Funktionen jetzt ändern

Die von mir im letzten Testbuild eingefürten Funktionen werden wieder entfallen.

Gruß rudi

[Hamster.78]

Hallöchen,

Habt ihr Ideen für einen kurzen und aussagekräftigen Funktionsnamen der neuen Funktion zum Ermitteln des kleinsten DOF-Fokus?

Der Name "get_dof_focus", führt der nicht in die Irre?

was haltet Ihr von

Syntax: [ Download ] [ Verstecken ]

Syntax: [ Download ] [ Zeigen ]

Benutze uBasic Syntax Highlighting

get_dof_min_focus

get_dof_minfocus  => wäre auch eindeutig

Erstellt in 0.004 Sekunden, mit GeSHi 1.0.8.9

gruß Hamster

[gehtnix]

@rudi, das mit Excel und der Formel hab ich jetzt erst überrissen. Mei, das alles da rein pfriemeln Nachfolgende Version hat die Formel noch nicht.

Anbei aber die erste Version bei der die Brennweite berücksichtigt wird. Mal stufenweise die Brennweite verändern und die Bildanzahl beobachten So haben wir dass auch noch nicht gesehen, oderrr? Der online DOFmaster zeigt aber die gleiche Daten an. Also sollte es wohl stimmen.

Ein weitere Merkwürdigkeit in der Log-Datei. Ohne "Moitventfernung ab Linse" wirft mir die Kamera konstant 314mm bei veränderter Brennweite aus. Mit dieser Option jedoch variieren die Werte von 265-250mm

GET_DOF_MINFOCUS
get_dof_min_focus
get_dof_minfocus => wäre auch eindeutig

Focus hätte ich gern draußen gesehen

get_dof_one - erster nutzbarer DOF-Wert
get_first_dof - ganz einfach
get_dof_value - solala
get_first_d - um vom DOF wegzukommen.

gruß gehtnix

[rudi]

Hallo gehtnix,

die LOG-Datei ist schon richtig. Wie du beim Zoomen beobachten kannst verschiebt es die Linse dabei. Daher sollte sich der Entfernungswert auch ändern. Der kleinste Fokus ab CCD ist offensichtlich nur bei Zoomstufe 0 nur so klein sonst gleich. Aber der Abstand der Linse zum CCD wird ja verändert.

Wie wird denn in der Tabelle die Diff-Grenze verarbeitet?
Ich hätte sonst die einfache plus 0,5 Variante genommen - Nachkommawerte <0,5 werden abgerundet und alles >=0,5 wird aufgerundet.

Und hier noch ein Namensvorschlag:

Syntax: [ Download ] [ Verstecken ]

Syntax: [ Download ] [ Zeigen ]

Benutze uBasic Syntax Highlighting

GET_MIN_STACK_DIST (kleinste Entfernung zum Stacken)

Erstellt in 0.003 Sekunden, mit GeSHi 1.0.8.9

Gruß rudi

[Sinter]

Hallo,

den DOF-Rechner sehe ich mir noch genauer an. Ich habe gesehen, es gibt sogar ein PDF dazu. Vielen Dank für den Hinweis. Ich bin gespannt wie weit dort die Annahmen zum CoC erklärt sind.



Gehtnix hatte letztens folgende Frage in den Raum gestellt:

Überlappung von Bild 1 "Far" zu Bild 2 "Near". Gerechnet wird für Fokus Bild2 = Fokus Bild1 + DOF Bild1. Frage: Sind wir dadurch noch genauer?

Ja, theoretisch sind wir damit einen Hauch genauer als es das Anspruchniveau vorschreibt. Denn für das Stacking liegt dann mehr scharfe Bildfläche zur Verfügung. Daher ist die Überlappungsfrage von Gehtnix absolut berechtigt und ich denke, mittels Gehtnix´ wunderbaren Tabellen kann auch dies anschaulich gelöst werden: Eine versuchsweise geänderte Tabelle (leider noch auf Grundlage der alten Tabellenversion 1 vom Montag) habe ich hier zum Download beigefügt:

Eine neue Berechnungsart für die blaue Tabelle: (download von "DOF min-Fokus__ohne Überschneidung.xls"):
Ausreichen würde (ohne Überschneidungen) wenn man den Fokus(Bild2) herleitet aus

Near2=Far1

und dann danach aus

Fokus(Bild2)= Funktion(Near2) = (hyperfok2*near2)/(hyperfok2-near2)

wobei ich mir nicht sicher bin ob near2 auch noch korrigierend die Brennweite enthält. Damit habe ich mich nicht beschäftigt. In der Far-Spaltenformel scheint die Brennweite jedenfalls eine (Korrektur-)Rolle zu spielen. Könnte also sein, dass dies auch noch in der Near-Spalte zu korrigieren ist.

Also Rudis F3-Funktion umgewandelt und nach s aufgelöst:

s=(h*near)/(h-near)

wobei s die Entfernung zu welcher Basis misst? zu CCD oder zu Linse?

Jedenfalls gehört dann diese s-Formel in der rechten blauen Tabelle in die Fokus-Spalte und die blaue Near-Spalte bekommt jeweils den Zellbezug zur vorigen Far-Zelle. Dadurch errechnen wir den Fokus2 anhand des Near2-Wertes, der sich wiederum aus dem Far1-Wert der Vorzeile ableitet (exakt identisch ist). Nun folgt noch die Bestimmung des Far2-Wertes, dessen Spaltenformel ich nicht verändert habe, (und ich glaube auch nicht verändert werden muss). Ich bin mir daher nicht sicher ob die Spalten konsistent sind, (ich vermute sie sind weiterhin konsistent), aber grundsätzlich dürfte erkennbar sein, wie man in der Theorie statt Überschneidungen gleich auf Angrenzungen kalkulieren kann.
Die Formeln hatte ich außerdem noch nicht durch alle Zeilen abwärts gezogen.

Offen wäre alledings dabei noch die Frage, mit welchen Werten wir die erste (!) Zeilenberechnung starten: Entweder legen wir auf die kleinste Motivdistanz exakt den Fokus, oder aber wir beginnen bei der kleinsten Motivdistanz bereits als (innerhalb des Anspruchsniveaus unschärfetolerierenden) Near-Wert. Im zweiten Fall müsste sich in Gehtnix´ theoretischer Idealberechnung (rechte blaue Tabelle) die absolut geringstmögliche (!) Anzahl an notwendigen Aufnahmen ergeben.


Ein ganz anderer Aspekt:
Bei den Ixen gibt es doch nur eine einzige Blende sofern ich mich nicht täusche. Alle in Ziffern größeren Blendenwerte (physikalisch kleinere Blendenöffnung) werden nur mittels ND-Filter simuliert. Da frage ich mich, was wohl die AV-Messung anzeigt und ob da irrtümlich mit Blenden-Werten gearbeitet wird, die in den ND-Filter-Kameras physikalisch nicht korrekt sind. Für die Bestimmung der Hyperfokaldistanz müsste allein die physikalische Blendenöffnung zählen. Alles andere liefert sonst falsche Werte.

Viele Grüße,
Sinter

[gehtnix]

Aber der Abstand der Linse zum CCD wird ja verändert.

rudi, wenn wir Dich nicht hätten, alles klar.... hätte ich jetzt für einen kurzen Moment schreiben können. Der Lichtblitz ist aber wieder weg.
Der Abstand Linse zu CCD wird doch immer verändert, das kann doch nicht von der Option Motiventfernung abhängen?

Nachkommawerte <0,5

einfach die 0,7 auf 0,5 ändern. Dazu habe ich das schon so rausgezogen. Wusste ich doch schon, da kommt noch was.

Syntax: [ Download ] [ Verstecken ]

Syntax: [ Download ] [ Zeigen ]

Benutze uBasic Syntax Highlighting

GET_MIN_STACK_DIST

Erstellt in 0.004 Sekunden, mit GeSHi 1.0.8.9

OK

S DOF=1, bei der Formel kommen mir ca. 4mm zuwenig heraus.
Das kannst Du in v3 so einfügen.
=WURZEL((D3*(D3-O5-1)/(2*(O5-D3))+1)^2-(O5*(2*D3-O5)/(2*(O5-D3)+1))-(D3*(D3-O5-1)/(2*(O5-D3)+1)))

@Sinter, nur kurz Dein Beitrag überflogen, Tabelle nicht angesehen. Ich würde bei der bestehenden Überlappung bleiben. Nicht das wir uns neue Bildlücken wegen der 1mm Verstellungsgrenze aufreissen.
Wichtiger erscheint mir die verschiedenen Sensorgrössen. Sind Deine kleineren Masse vielleicht um den nutzbaren Bereich eingeschränkt.

Und... ich möchte das Susi2Stack so einfach bleibt! Hinstellen auslösen, stacken. Den Visusfaktor noch als Variable, OK.

gruß gehtnix

[Sinter]

Hallo Gehtnix,

bei der realen Überlappung der linken Spalte können wir ohnehin nicht viel rausholen. Die Überlappungsvermeidung hatte ich nur in der rechten rein theoretischen Berechnung probiert, um noch einen weiteren Vergleich zu haben.

Links kann daher genau wie Du sagst, alles beim alten bleiben.


Die Sensorgrößen sind in der Tat noch abzuklären. Irgendwo hatte ich vor einigen Jahren paar Details gelesen, wie es sich mit Gesamtgröße und nutzbarem Bereich verhält. Diese Infos liegen mir leider nicht mehr vor. Meine in einer Tabelle gefundenen Sensormaße scheinen nicht unbedingt zuverlässig zu sein. Nur eine Dezimalstelle hinter dem Komma sieht eher nach Rundung aus. Vielleicht finde ich noch irgendwo exaktere Infos.

Optional ein variables Anspruchsniveau in Dein Susi2Stack zu integrieren, das könnte möglich sein. Die Option wird auch dann ihre Wirkung erzielen können, wenn wir die Option möglichst klein und einfach halten. Bei Gelegenheit mache ich demnächst auch paar Praxistests um zu sehen, was überhaupt in der Realität für dein Skript Sinn machen könnte. Denn die Praxis der CoC-Variation habe ich ja noch gar nicht untersucht. Dass Dein Skript weiterhin möglichst einfach bedient werden kann, halte ich ebenfalls für sinnvoll.

Viele Grüße,
Sinter

[gehtnix]

Die Option wird auch dann ihre Wirkung erzielen können, wenn wir die Option möglichst klein und einfach halten.

....Da rudere ich auch schon gleich wieder zurück Das wird, man wegen Integer, erst bei einem DOF>10(?), sehen.

gruß gehtnix

[Sinter]

Okay Gehtnix, schon möglich dass die Theorie nicht eins zu eins umsetzbar ist. Integer könnte tatsächlich ein schwieriges Hindernis sein.

Ich muss wie gesagt auch selbst erst noch erkunden, wie weit wir hier die Theorie in die Praxis einarbeiten könnten. Wobei das variable Anspruchniveau ohnehin erst auf die präzise DOF-Berechnung aufsetzt. Von daher gilt es, zunächst die präzise DOF-Berechnung zu klären. Alles andere wäre dann ein weiterer zusätzlicher Schritt, der nicht so sehr eilt.

Viele Grüße,
Sinter

[gehtnix]

Hi Sinter,

die Sache mit dem Visus die muß, wenn schon denn schon, ins CHDK rein, nicht ins Skript.
Im alten Skript gibt es "Überlappung %, da könntest Du mit rumprobieren. Ist letztlich ein veränderte Visus doch nur ein veränderter Fokus?
Vielleicht kann man das ja dann so lösen, %Überlappung ~ %Visus

@rudi, nach unnützem Starren ins hin und her fahrende Obejktiv, die Dusche hat es nun gebracht. Es bleibt dabei,
rudi, wenn wir Dich nicht hätten, alles klar. Werde nachher sogar den Messschieber schwingen und mal nachmessen.


gruß gehtnix

[rudi]

Hallo gehtnix,

na sooo viele Klammern, da kann man schon mal die Ãœbersicht verlieren.

bei der Formel kommen mir ca. 4mm zuwenig heraus.

=WURZEL((D3*(D3-O5-1)/(2*(O5-D3))+1)^2-(O5*(2*D3-O5)/(2*(O5-D3)+1)))-(D3*(D3-O5-1)/(2*(O5-D3)+1))

Jetzt sollte es stimmen.

Gruß rudi

[gehtnix]

@rudi, aahhh, jetzt ist bei mir der Groschen gefallen, Wurzel zu lang, passt.

servus gehtnix