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... 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?

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?

Die druckt aber keine Sofortbilder. Genauso wenig wie das Handy.

Problematisch an Selenbelis ist auch ihre geringe Empfindlichkeit. Wenn die mit 100 ASA klar kommen, hat man ja schon Glück. Heute wird aber auch viel mit 200 und 500 ASA gedreht.

Schreiben ist seine Sache nicht. Aber er kann anderes. 🙂

Das stimmt so nicht (ich war bei der Sache beteiligt). Der Aufeickeldorn hatte zu viel Spiel, dadurch dass er v.a. für Backloader oft zu tief. Meine Theorie ist, dass der Wickel dadurch u.U. Unsauber wird und effektiv mehr als 8mm Breite haben kann, was dan zu Klemmern führen kann. Das unsägliche Kassette klopfen ist und erhöhter Filmzug machen die Sache dann natürlich nicht besser. Hoffen wir, dass es hilft. Gut ist, dass Kodak auf PV letztlich gehört hat.

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.

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...

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 🙂

Das ist ja mal RICHTIG geil. Habe will.

"Abschluss" ist relativ... Die Todo-Liste ist schon wieder lang 🙂 Ich kämpfe gerade noch mit einer weiteren kleinen Hardware-Unschärfe, die ich nicht so recht verstehe... und ein bisschen Doku fehlt auch noch. Aber es macht solchen Spaß 🙂

Fertig. Heute Abend gibt's ein Video.

Kadrieren oder 1,1-fach Reinzoomen in einem Group Post-Clip Node sollte helfen, also auf der Color Page. Ist zwei Clicks versteckt:

Der Kommentar ist verirrend, zu dem Zeitpunkt habe ich das DNG noch aus dem raw-stream selber erzeugt (auf dem host-computer). Mit libcamera2 übernimmt das jetzt der image signal processor (ISP) auf dem Pi. Das ist ungleich schneller und braucht eben keinen weiteren Konvertierungsprozess mehr.

Das Binning macht direkt der ISP!