Friedemann Wachsmuth

Der ist jetzt im Github-Projektwiki: https://github.com/fwachsmuth/Filmkorn-Raw-Scanner/wiki Kapitel 3 und 4 fehlen noch, die anderen sind soweit komplett.

Du musst Dich doch nicht für einen Kommentar nicht entschuldigen! Der belebt das Forum, immer her damit! Und: Alles richtig, aber ich fürchte, Du bist nicht Zielgruppe. Der durchschnittliche Tiktok-User verbringt im Schnitt (!) über eine Stunde pro Tag dort, bei Instagram sind es etwa 30 Minuten (Quelle). Dort gibt es zu 99% Hochkantinhalte. So ändern sich die Dinge eben. Und genauso sind die 15 Sekunden ja auch Absicht, die meisten Reels werden eher 3-4 Sekunden angesehen, wenn nicht SOFORT action kommt... und die Inhalte dort verschwinden in der Regel nach 24 Stunden. Das ist keine Einschränkung sondern ein bewusstes Feature. Es senkt die Hemmschwelle beim Teilen. Und konnte der Hi8-Camcorder auch QR-Codes? 🙂

Gut zu wissen! 🙂

Sehr gut gemacht! Sowas gibt's übrigens auch sehr günstig beim Chinamann, sogar in 2D mit Einstellschrauben: https://de.aliexpress.com/item/1005001804948944.html Vermutlich baut das dann aber zu hoch, so müsste man den Kartenhalter des Title-Writers eben erhöhen. Oder auf so einen 3D-Schlitten (https://de.aliexpress.com/item/32882330249.html) schrauben. 🙂

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!

Ha, endlich ein T510-Besitzer! Rainer, darf ich Dich mal auf diesen Beitrag schubsen? und, genauer fragend, diesen:

Tja, und so ist sie die Realität: Hab einen ganzen Tag verloren, weil ich noch einen fiesen Schaltungsfehler entdeckt habe und v.a. finden musste. So muss ich bei allen 25 Boards noch ein SMD-Teil tauschen und ein weiteres drauf-bodgen. Machbar, aber kostet Zeit 🙂 Falls die Details jemanden interessieren: Bei einem der Boards (verwendet beim Schreiben der Doku) blieb der Atmega beim Einschalten einer Projektor-Lampeplötzlich hängen, wenn die Betriebsspannung > 20 Volt lag. Kein Reset, kein Brownout... er hing einfach. Das hatte ich so auch noch nie in 25 Jahren uC-Hacking... Der Grund dafür ist nicht fehlende Entkopplung, sondern ein Masse-Bounce. Q1 schaltet als Lowside-Switch die System-Masse an die Masse des LED-Treibers. Da ich den nicht direkt vom Atmega ("Lamp" Pin) treiben wollte (der LED-Treiber schafft bis zu 150W), bekam er mit U11 einen Gate-Driver. Tja, und dieser ist leider extrem schnell, Nanosekundenbereich. C2 und C14 (eigentlich ja Entkopplung) ziehen (kurz) richtig Strom (der Spike vorne) und damit "glitched" der Program-Counter des AVR ins Nirvana. R8 durch 1K ersetzen und 100n zwischen Gate und Source weichen den Einschaltvorgang schön auf, so ist der böse Burst weg. Die nächste Platinenrevision wird das natürlich berücksichtigen, die jetzige kriegt die Tage noch mal Handarbeit zu spüren. 🙂

Sorry, ja, was Dent-Jo schrieb. Eigentlich muss man Elkos zum Testen auf korrekte Funktion immer ausbauen. Und wenn man sie schon ausgebaut hat, kann man eben auch gleich einen guten neuen einlöten. Die ESR-Messung gibt keine 100% Gewissheit über die Qualität eines Elkos, aber einen deutlichen Indikator. Geräte, die den ESR im eingebauten Zustand korrekt messen können, sind meist sehr teuer und speziell. Das MESR-100 ist ein (wirklich bewährtes) China-Gerät, dass das überraschend gut für 30€ schafft. Natürlich kein Fluke, aber für den Hobby-Bastler ne gute Sache. Faustregel: Ist der ESR niedrig, ist der Kondenstaor vermutlich gesund. Ist er zu hoch (auf dem Gerät ist eine Tabelle), ist er "verschlissen" bzw. schon fehlerhaft. 100% alles erwischt Du damit aber auch nicht. Elkos können einen normal niedrigen ESR zeigen, aber trotzdem durch Leckstrom oder Kapazitätsverlust nicht mehr recht funktionieren. Das kann ein ESR-Messgerät beides nicht feststellen.

Auf https://github.com/fwachsmuth/Filmkorn-Raw-Scanner/ liegt unter Releases auch ein Disk-Image von gestern. (Dem fehlt stand heute nur das Feature, Debug-Logs zu generieren). Ohne den Controller wird das aber nicht viel tun. 🙂 Sitze jetzt erstmal an der Doku. Wenn die steht, kriegen meine 25 Boards hier noch die Fuses gesetzt und es geht los...

Wenn du das Board schon draußen hast, tausch sie lieber gleich alle. Oder Du kaufst Dir ein MESR-100, damit kannst Du den ESR auch im eingebauten Zustand beurteilen.

Was verleitet Dich zu dieser Annahme? Ich verwende schon Trixie mit 6.12er Kernel, da sollte eigentlich alles nötige an Bord sein. Die DTBs sind auch alle da. Ich vermute am ehesten kleine Unterschiede bei der HDMI-Konfiguration. Und GPIO läuft beim 5er ja über PCIe, aber ich bin voll auf libgpiod umgestiegen, das sollte auch passen — und das bisschen bitbanging beim Flashen eines Updates ist nicht kritisch schnell. Wie gesagt, es muss probiert werden. Wenn mir jemand einen Pi5 sponsern will, kann ich das gerne machen. 🙂 Im Moment steht es aber nicht ganz oben auf der Liste. Der 5 könnte allerdings theoretisch noch höhere Framerates erreichen, insofern nicht uninteressant.