Challenge: Framescanner für < 350€ bauen

[jacquestati]

vor 36 Minuten schrieb Klaus14:

Hallo jacquestati,

 

Deine G6 mit einer Fotoauflösung von 4.608 x3.456(4:3), RAW und einem deutlich größeren Sensor als wir ihn verwenden, ist doch optimal. Wenn du jetzt noch eine gute Linse verbaut hast und eine gute Lichtquelle, hast du vermutlich eine sogar bessere Bildqualität beim Scannen. 

 

Friedemann will mit seinem Projekt ja zeigen, was man mit 350.- erreichen kann und das was er da geschafft hat finde ich mehr als erstaunlich.

 

Bei mir ist das überhaupt anders, mir macht das Basteln einfach Spaß und das ist einfach ein nettes Projekt für mich, an dem ich seit Jahren immerwieder "herumbastel", weiter nichts. Im Moment macht es mir wieder Spaß, aber trotzdem bin ich mir nicht sicher, ob es jemals fertig wird.

Na ja, die Kosten für den 16mm Scanner und die beiden anderen waren sehr überschaubar, der Siemens war kaputt und hat, wenn ich mich recht erinnere, so um die 50 Euro gekostet, die beiden anderen sogar noch weniger. Die Lumix gab es für ca 100, das Vergrößerungsobjektiv von Nikon war im Bestand, genauso wie das Balgengerät… Die teuerste Anschaffung war das 50er Lupenobjektiv mit 150 Euro für den N8 Scanner…

[Steffen Hauser]

Da kann ich dir nur zustimmen, Klaus, was Friedemann da an Lösungen erarbeitet und vorgestellt hat, finde ich wirklich auch ganz große Klasse!

 

Aufgrund eher bescheidener Elektronikkenntnisse habe ich momentan den Ansatz von jacquestati mit einer Panasonic G6 verfolgt, die per Reedkontakt vom Projektor ausgelöst wird. Das klappt auch sehr gut! Wenn man allerdings Raw-Dateien für DaVinci Resolve haben möchte, ist nach der Aufnahme noch ein Konvertierungsschritt auf dem PC erforderlich. Zumindest bei mir dauert dieser trotz Multithreading länger als die Aufnahme selbst. Deswegen experimentiere ich momentan mit einer Nikon Z5, deren Raw-Dateien direkt von Resolve gelesen werden können. Preislich übersteigt das dann natürlich den eigentlichen Rahmen. Ich bin mir auch nicht ganz sicher, ob ein größerer Sensor unbedingt von Vorteil ist, da dadurch die Schärfentiefe sinkt, was in diesen Abbildungsmaßstäben vielleicht kritisch werden könnte.

 

Nichtsdestotrotz verfolge ich mit Spannung den Fortschritt des Projekts auf Basis der Pi HQ Kamera. Die Option, neben Bildern in 4K auch solche in 2K bei entsprechend höherer Geschwindigkeit zu erzeugen, finde ich sehr spannend. Super auch, dass am Ende gleich fertige DNGs herauskommen, die man direkt in Resolve verwenden kann.

 

Zum 2K-Modus hätte ich allerdings eine Frage: Wie sieht es da mit der Qualität aus? Im Forum von Kinograph wird empfohlen, die kleineren Auflösungen generell nicht zu verwenden und stattdessen ein Bild in voller Auflösung zu skalieren (siehe Abschnitt "The HQ Sensor"). Bei dieser Methode wäre natürlich der schöne Geschwindigkeitsvorteil dahin.

https://forums.kinograph.cc/t/pi-hq-camera-vs-dslr-image-fidelity/2810/32

[Klaus14]

Aber irgend eine einfache Steuerung deiner Projektoren hast ja auch gebraucht, wie machst du das? Nur ein Reed-Kontakt und den Motor mit wieviel FPS laufen lassen?

Bearbeitet Gestern um 10:47 von Klaus14 (Änderungen anzeigen)

[Friedemann Wachsmuth]

Was ich bisher gesehen habe, ist die Qualität auch in 2K hervorragend. Ich hab hier ein paar Meter SMPTE-Testfilim (sündhaft teuer von Wittner), die werde ich noch mal durchziehen und präsentieren.
Der Arbeitsalltag hat wieder angefangen, aber ich mache (abends & nachts) trotzdem weiter.

Ich hatte noch Probleme beim "Bootstrapping", also dem "Auspacken & Anschliessen" für eine neuen Benutzer. Die sind jetztendlich auch gelöst, und auch meine Image-Generierung ist jetzt automatisiert und schnell. Der Raspi ist ja ein vollwertige Computer, wenn der im LAN hängt (optional) muss er auch maximal sicher sein. Das ist jetzt erreicht.
 

Es dauert nicht mehr lang 🙂

[Klaus14]

vor 24 Minuten schrieb Steffen Hauser:

Zum 2K-Modus hätte ich allerdings eine Frage: Wie sieht es da mit der Qualität aus? Im Forum von Kinograph wird empfohlen, die kleineren Auflösungen generell nicht zu verwenden und stattdessen ein Bild in voller Auflösung zu skalieren (siehe Abschnitt "The HQ Sensor"). Bei dieser Methode wäre natürlich der schöne Geschwindigkeitsvorteil dahin.

https://forums.kinograph.cc/t/pi-hq-camera-vs-dslr-image-fidelity/2810/32

Da ich selbst im Moment nur ein sehr durchschnittliches Objektiv verwende, kann ich diese Frage leider nicht beantworten. Friedemann hat sich damit sicher intensiver beschäftigt. Ich muss auch gestehen, dass meine 8 und S8 Filme teileweise so eine schlechte Qualität haben (wurden wohl zu lange falsch gelagert), dass es wohl völlig egal ist ob ich mit 2K oder 4K scanne, das Ergebnis ist traurig.

 

Mich würde in diesem Zusammenhang eher interessieren, ob es in der Zwischenzeit gute KI gestützte Programme gibt, die aus schlechten Material was Brauchbares "zaubern" können. Hat da hier Jemand Erfahrung damit?

[Friedemann Wachsmuth]

Ein spannender Post ist das da bei Kinograph. Vieles davon habe ich parallel auch entdeckt 🙂
Und es zeigt, dass der RPI5 halt doch nicht so ideal ist. Hab mir jetzt zum Testen (irgendwann) aber doch einen bestellt. Mein Focus ist aber eh auf Qualität, nicht auf maximal Geschwindigkeit...

[Friedemann Wachsmuth]

vor 4 Minuten schrieb Klaus14:

gute KI gestützte Programme gibt, die aus schlechten Material was Brauchbares "zaubern" können

Für dieses Un-Thema mach bitte einen eigenen Thread auf.
Das wird niemals Teil meines €350-Scanner-Projektes sein. Und zwar nicht aus Kostengründen.

[Steffen Hauser]

vor 54 Minuten schrieb Klaus14:

Aber irgend eine einfache Steuerung deiner Projektoren hast ja auch gebraucht, wie machst du das? Nur ein Reed-Kontakt und den Motor mit wieviel FPS laufen lassen?

 

Als Grundlage dient wie von Friedemann empfohlen ein Noris D100, bei dem ich den Motor ausgebaut und gegen einen langsamer laufenden ersetzt habe. Mit einem PWM-Modul an einem 12V-Trafo kann ich den Projektor dann im Vor- und Rücklauf steuern (schneller beim Filmeinlegen, langsamer beim Scannen). Der Reedschalter, der über ein Fernauslösekabel mit der Kamera verbunden ist, wird von einem Magneten an der (verkleinerten) Umlaufblende ausgelöst. Die Verkabelung ist also recht überschaubar. Da anders als bei Friedemann der Projektor die Kamera steuert, muss man natürlich schauen, bis zu welcher Geschwindigkeit keine Bilder verloren gehen. Je nach Kamera und Schreibgeschwindigkeit der Speicherkarte ist das anders, bei meiner G6 mit einer eher langsamen Speicherkarte komme ich momentan auf knapp ein Bild pro Sekunde.

 

vor 51 Minuten schrieb Friedemann Wachsmuth:

Was ich bisher gesehen habe, ist die Qualität auch in 2K hervorragend. Ich hab hier ein paar Meter SMPTE-Testfilim (sündhaft teuer von Wittner), die werde ich noch mal durchziehen und präsentieren.
Der Arbeitsalltag hat wieder angefangen, aber ich mache (abends & nachts) trotzdem weiter.

Ich hatte noch Probleme beim "Bootstrapping", also dem "Auspacken & Anschliessen" für eine neuen Benutzer. Die sind jetztendlich auch gelöst, und auch meine Image-Generierung ist jetzt automatisiert und schnell. Der Raspi ist ja ein vollwertige Computer, wenn der im LAN hängt (optional) muss er auch maximal sicher sein. Das ist jetzt erreicht.
 

Es dauert nicht mehr lang 🙂

 

Super, ich bin gespannt!

Bearbeitet Gestern um 11:43 von Steffen Hauser (Änderungen anzeigen)

[Klaus14]

vor 10 Stunden schrieb Friedemann Wachsmuth:

Ein spannender Post ist das da bei Kinograph. Vieles davon habe ich parallel auch entdeckt 🙂
Und es zeigt, dass der RPI5 halt doch nicht so ideal ist. Hab mir jetzt zum Testen (irgendwann) aber doch einen bestellt. Mein Focus ist aber eh auf Qualität, nicht auf maximal Geschwindigkeit...

Bestelle dir aber gleich ein M.2 HAT und eine entsprechende SSD dazu, du wirst beim Entwickeln deine Freude damit haben 😉

[Friedemann Wachsmuth]

Nee, das brauch ich nicht. Fotos kommen eh in eine ramdisk und uSD ist mehr als genug für das bisschen System. Nichts IO-kritisches schreibt auf uSD. Was sollte eine m2 da schneller machen?

[Steffen Hauser]

Ich bin gerade bezüglich der Ramdisk etwas tiefer in den Quelltext eingetaucht. Wenn ich es richtig sehe, legt der Scanprozess die fertigen DNGs in einer Ramdisk ab, also einem Teil des Hauptspeichers, was natürlich super schnell gehen sollte. Ein anderer Prozess verschiebt mittels lsyncd bzw. rsync alle bereits erstellten DNGs von der Ramdisk auf eine externe Festplatte oder SSD, was je nach Geschwindigkeit des Speichermediums mehr oder weniger lang dauert. Der Scanprozess kann derweil bereits mit anderen Aufgaben weitermachen. Falls die Ramdisk nicht schnell genug abgeräumt werden kann, hält der Scanprozess an.

 

Nun könnte es ja sein, dass save_dng im Scanprozess noch Daten in die Ramdisk schreibt, während der Synchronisationsprozess parallel dazu zuschlägt und diese unvollständigen Daten verschiebt. Vermutlich ist die Implementierung von save_dng aber so robust, dass dieses Problem nicht auftritt? Im Zweifelsfall empfiehlt es sich ansonsten, Dateiausgaben zuerst in eine temporäre Datei schreiben zu lassen (z.B. frame0001.dng.tmp) und am Ende diese temporäre Datei umzubenennen (z.B. in frame0001.dng). Das Umbenennen innerhalb eines Dateisystems ist eine atomare Operation, die nicht von anderen Prozessen unterbrochen werden kann. Alternativ könnte man die zu erstellende Datei auf Betriebssystemebene mit fcntl.flock während des Schreibens gegen parallele Zugriffe sperren.

[Klaus14]

Mich würde interessieren, was die Ramdisk in diesem Fall überhaupt bringen soll? Der Schreibprozess dauert am längsten und bremst den Scanprozess spätestens dann aus, wenn die Ramdisk voll ist. Also warum nicht gleich auf das endgültige Medium schreiben, das würde doch den kompletten Prozess vereinfachen und Lockprozesse oder dergleichen sind dann überhaupt nicht notwendig und das genutze Speichermedium gibt die mögliche Scangeschwindigkeit automatisch vor.

[Friedemann Wachsmuth]

Steffen hat's richtig analysiert. Halbe Dateien sind kein Problem: Der lsyncd lauscht über inotify auf die Ramdisk, und erst frühestens 15 Sekunden nach dem letzten event schaufelt der rsync die aggregierte Liste auf die platte. Ein DNG write dauert keine 100 ms, da sind 14.9 s Reifezeit allemal genug. 🙂
Durch die Asynchronität brauche ich weder lock-file noch temp-datei und atomic mv, das ist robust. Es führen viele Wege nach Rom, und 15 sek implizite Latenz waren bisher keine Prio...

 

vor 27 Minuten schrieb Klaus14:

Mich würde interessieren, was die Ramdisk in diesem Fall überhaupt bringen soll? Der Schreibprozess dauert am längsten und bremst den Scanprozess spätestens dann aus, wenn die Ramdisk voll ist. Also warum nicht gleich auf das endgültige Medium schreiben, das würde doch den kompletten Prozess vereinfachen

 

Du vergisst den scan-to-host Modus. Verfügbare Bandbreite auf eth0 ist kaum vorhersehbar. Und warum sollte der Scanner langsamer werden, nur weil ich gerade was downloade der im LAN eine Datei verschiebe? Die Ramdisk ist nichts anderen als ein write cache. Die haben sich generell durchaus bewährt. 🙂

(Am längsten dauert übrigens auch nicht der Schreibprozess, sondern dass Debayering.)

Ich frage gerade mich ein bisschen, wie relevant dieses Sezieren für dieses Forum ist. 

Mich stört's ja nicht, aber hier geht es ja eigentlich mehr um Film & Co als um Softwarearchitektur und ich denke 95% hier langweilt es. Vielleicht verlagern wir derlei lieber in PMs? 

[Gizmo]

Auch wenn ich selber von µC-Technik keine Ahnung habe. Es geht hier ja um einen Scanner, dass ist nun mal Digitaltechnik. Solche Threads sind relativ selten zu finden. Zumindest verdeutlicht es allen, wie komplex das Thema ist. Die Diskussionstiefe langweilt mich nicht. Letztendlich werden solche Beiträge auch über die Suchmaschinen gefunden und führen vielleicht noch den einen oder anderen Interessierten in dieses Forum.

[Klaus14]

vor 1 Stunde schrieb Friedemann Wachsmuth:

Ich frage gerade mich ein bisschen, wie relevant dieses Sezieren für dieses Forum ist. 

Mich stört's ja nicht, aber hier geht es ja eigentlich mehr um Film & Co als um Softwarearchitektur und ich denke 95% hier langweilt es. Vielleicht verlagern wir derlei lieber in PMs? 

Ist OK, soll mir recht sein 😉

 

Kannst du nur bitte nochmals den Link zu deiner bisherigen Doku veröffentlichen, ich würde mir gerne deine Hardware nochmals anschauen, finde den Link aber nicht mehr. 

 

Vielen Dank Klaus