Challenge: Framescanner für < 350€ bauen

[Nils Jacobsen]

Frage an die Runde.

 

Scanner ist bei mir auch fast fertig. Bilder folgen. Habe auch ein Gehäuse im 3D Druck erstellt- Auch das folgt, wenn es final ist. Muss noch ein wenig testen, ob das mit den Tastern gut funktioniert.

 

Ich habe seit ca 2 Wochen das Problem, dass die aufgenommenen Frames fehlerhaft sind. Schaut aus wie Teil des Bildes der sich bewegt. Habe mit allem schon rumprobiert. Belichtung, Belichtungszeit und auch die Auslöseposition. Von 5 Frames sind 3 oder 4 fehlerhaft. Den Fehler kann ich nicht finden.

 

Vielleicht habt ihr einen Rat.

 

 

Im ersten Bild Februar war der Fehler noch nicht vorhanden. Zweites Bild ist vom März.

 

Danke.

 

 

[Friedemann Wachsmuth]

Du musst die Capture-Latency in den Settings erhöhen. 

[Steffen Hauser]

@Nils Jacobsen Die in den Bildern sichtbaren pilzartigen Flecken kannst du, falls gewünscht, vor dem Scannen relativ einfach mit einem Tuch und destilliertem Wasser reduzieren bzw. entfernen.

[Nils Jacobsen]

vor 3 Stunden schrieb Friedemann Wachsmuth:

Du musst die Capture-Latency in den Settings erhöhen. 

Danke Friedemann. Das hatte ich bereits auch probiert.  Ohne wirklichen Unterschied. Der Fehler ist bereits beim Vorschaubild sichtbar. Probiere heute Abend noch mal. 

[Nils Jacobsen]

vor 47 Minuten schrieb Steffen Hauser:

@Nils Jacobsen Die in den Bildern sichtbaren pilzartigen Flecken kannst du, falls gewünscht, vor dem Scannen relativ einfach mit einem Tuch und destilliertem Wasser reduzieren bzw. entfernen.

Danke, ja das ist mir bekannt beim Agfa Material. Dies ist aber nur ein Testfilm der nicht wichtig ist.  Aber das mit dem destilierten Wasser funktioniert sonst sehr gut. 

[Friedemann Wachsmuth]

vor 3 Minuten schrieb Nils Jacobsen:

Der Fehler ist bereits beim Vorschaubild sichtbar

Das Vorachaubild ist ein 30 fps Videofeed. Da gibt es während des Transports immer ein Artefakt (die Unlaufblenxe fehlt ja oder würde asynchron abschatten.  
Intern werden parallel ständig Raws ins RAM aufgenommen (bei 2K mit ca. 10 fps und bei 4K mit etwas 4 fps).  Sobald der Film still steht sollte da immer eines ohne Bewegungsartefakte dabei sein (welches du nimmst, bestimmt die Capture Latenz). 
 

("ad hoc" ein Raw zu captured würde viel zu lange dauern, die Kamera braucht fast 1 Sekunde bis sie mit den korrekten Einstellungen startbereit ist)

[superkowski]

Falls jemand so gar nicht weiter kommt, ein Blick hier hin, könnte helfen 👀

Es ist ein Noris 2000, die Riemenwelle schleift an einem Versteifungs-/Begrenzungs Stück, was sich störend auf den Scanvorgang auswirkt. 
-
 

[Friedemann Wachsmuth]

Ich habe jetzt endlich etwas Zeit gefunden, um die Dokumentation weiter zu verbessern. Es gibt nun zwei neue Kapitel:

1. Umbau eines Bauer P8 zum 16mm Scanner
2. DaVinci Resolve Color Grading Howto für Farbnegativmaterial

Feedback dazu ist gerne willkommen. Wenn Interesse besteht, kann ich zum Thema Davinci auch noch eine kleine Reihe an Trainingsvideos machen, das Thema ist in Prosa und mit Screenshot doch recht schwer zu beschreiben...

Bearbeitet 14. Juni von Friedemann Wachsmuth (Änderungen anzeigen)

[Sebastian Bock]

Super, vielen Dank!

Hat es einen Grund, weshalb Du das ColorNegInvert Plugin nicht mehr nutzt?

Ich habe mittlerweile auch den gekapselten Motor bei meinem Noris eingebaut und der funktioniert wirklich Welten besser als der Universalmotor.
Allerdings schaffe ich nicht wirklich mehr als 2 Bilder / Sek bei 4K. Hast Du das bei Dir mal nachgemessen, wieviele fps Dein Setup reell schafft? 
 

Bearbeitet 14. Juni von Sebastian Bock (Änderungen anzeigen)

[Friedemann Wachsmuth]

ColorNegInvert ist so hakelig zu installieren und es gibt es nicht für Windows. Zudem ist die Bedienung grauenhaft, gerade beim Feineinstellen. Das Kurve flippen macht exakt das gleiche, allerdings mit besserer Gamma-Korrektur und ohne die clippenden Pixel bei extremen Korrekturen. Kurz: es ist besser. 🙂

 

FPS müsste ich bei mir jetzt noch mal messen, hab gerade nur 16 mm aufgebaut. Die neueste Firmware misst FPS jetzt aber richtig. 

[Friedemann Wachsmuth]

vor 9 Stunden schrieb Sebastian Bock:

Allerdings schaffe ich nicht wirklich mehr als 2 Bilder / Sek bei 4K

Ich meine, das ist das theoretische Maximum, das verarbeiten eines 4K Raws dauert im Schnitt ca. 500 ms. Im Scanner-Log müsstest Du diese Zeiten auch ausgewiesen sehen. 

[Sebastian Bock]

Für die Feinbearbeitung des Bildfensters eignet sich übrigens das Maniküre Set von Rossmann hervorragend…

 

[Bugs Bunny]

Hallo,

 

erstmal einen riesigen Respekt für das Projekt! Dies über die lange Zeit immer wieder fortzusetzen und dann auch noch als OpenSource inkl. einer niedrigschwelligen Einstiegslösung finde ich echt toll. Gerade auch, wenn man es mit einer recht ähnlichen Lösung von z.B. https://www.film-digital.com/ vergleicht.

 

Habe schon seit einiger Zeit nach einer geeigneten Möglichkeit zur Digitalisierung alter Familienfilme gesucht und bin von der Lösung echt begeistert. Insbesondere auf Grund des frame-by-frame grabbing, der Wiederverwendung eines Projektors (was meinem handwerklichen Geschick / Ausdauer sehr entgegenkommt), der Steuerung usw.

 

Nach Durchsicht des Git-Repositories hätte ich ein paar Fragen, die hoffentlich beantwortet werden können und auch hierher passen? Oder wären solche Diskussionen / Fragen besser auf Github aufgehoben?

- da ich noch einen Odroid N2 rumliegen habe und kein Raspberry Pi bestellen möchte (habe nur ältere rumliegen) habe ich mir die Schematics des 40-Pin connectors angeschaut. Am Raspi GPIO Pin37 liegt dort _GPIO26, was auf Basis der restlichen Schaltung den Power-Taster einliest, aber auch gleichzeitig mit SCL verbunden ist. Ist das so korrekt? (Pin 37 ist am Odroid leider kein GPIO sondern ein ADC, müsste mir daher einen Adapter bauen)

- die Lösung basiert ja auf der Raspberry Pi HQ Camera. Ich würde lieber (weil sowieso vorhanden) meine Sony Alpha verwenden. Wenn ich es im Code richtig gesehen habe, sollte es ja egal sein, welche Kamera ausgelöst wird. Oder gibt es weitere Abhängigkeiten zur Raspi Camera, die ich übersehen habe? (Dass ich das Image so nicht verwenden kann ist klar). @Friedemann Wachsmuth akzeptierst Du grundsätzlich Pull-Request auf Github?

- hat schon mal jemand versucht für den Scanner einen Eumig Mark 610D zu verwenden? Gibt es da vielleicht Tipps?

- Last but not least: andere ähnliche Scanner nutzen für die Bildstabilisierung OpenCV und um z.B. Kratzer/Staub/flickern zu entfernen weitere OpenSource Tools wie z.B. https://github.com/vapoursynth/vapoursynth um Kratzer/Staub zu entfernen. Was haltet Ihr von einer entsprechenden Verarbeitung? Oder ist die Mechanik schon so gut, dass gerade eine Bildstabilisierung gar nicht notwendig ist.

 

Ich hoffe ich bin mit den Fragen nicht komplett falsch hier.

 

Vielen Dank für sämtliche Tipps/Hinweise/Ergänzungen.

[Friedemann Wachsmuth]

vor 23 Minuten schrieb Bugs Bunny:

Am Raspi GPIO Pin37 liegt dort _GPIO26, was auf Basis der restlichen Schaltung den Power-Taster einliest, aber auch gleichzeitig mit SCL verbunden ist. Ist das so korrekt?

Ja, so ist es. Bis Debian Buster konnte man so einen "Soft Power" Button implementieren, was allerdings nie offiziell dokumentiert war und mit Bullseye verschwand. Daher hab ich den Powertaster zu einem "Sleep" Taster umfunktioniert, was eh deutlich sinnvoller und praktischer ist. Daher die komische Pin-Wahl.

 

Den Odroid kenne ich nicht, ich vermute, es könnte allgemein da doch ein bisschen Portierungsarbeit anfallen.

 

Sicher geht es auch mit einer Sony Alpha umsetzbar, nur sprengt das halt den anvisierten Kostenrahmen, und nennenswert besser wirds damit auch nicht (ich hab zu Beginn Einzelbildaufnahmen mit meiner a7Riii verglichen). Arbeit fällt da aber sicherlich an, denn das System ist eben voll auf die Raspi HQ-Cam abgestimmt. Da die nur ca. 50€ kostet und Du Deine Alpha sicherlich nicht ständig ab. und wieder aufbauen willst, rate ich da eher zur Raspi HQ Cam. 

Man sollte nicht unterschätzen wie gering die Hemmschwelle zum Scannen ist, wenn der Scanner 30 Sekunden nach dem man den Film aus dem Regal genommen hat schon los tickert und die Bilder umgehend auf dem Mac auftauchen. Ich hab bei mir oft gemerkt, dass jegliches "Vorbereiten müssen" (Verkabeln, Kamera ausrichten, Scharfstellen, Belichtung regeln, Speicherkarte suchen etc.) die Hemmschwelle hochsetzt und den Spaß nimmt. (Ja, das ist subjektiv...)

 

vor 33 Minuten schrieb Bugs Bunny:

akzeptierst Du grundsätzlich Pull-Request auf Github?

Na klar, so lange sie nicht AI Slop sind und ich genug Zeit finde, sie zu reviewen. Der Test-Harness ist im Moment sehr rudimentär, ich muss da fast alles manuell testen. Ich bin noh cnicht mal dazu gekommen, das ganze auf dem Raspi 5 zu testen, der hier schon lange liegt...

 

vor 35 Minuten schrieb Bugs Bunny:

hat schon mal jemand versucht für den Scanner einen Eumig Mark 610D zu verwenden? Gibt es da vielleicht Tipps?

Der hat iirc einen AC-Motor und ist damit ungeeignet. Du müsstest also einen DC-Motor einbauen (da würde ich eher einen passenden Noris suchen). Aber wenn Du den gelungenen Umbau eines Mark 610D schön dokumentierst und ich das Howto mit ins wiki nehmen darf, geht die Controller-Platine auf mich. 🙂

 

vor 37 Minuten schrieb Bugs Bunny:

andere ähnliche Scanner nutzen für die Bildstabilisierung OpenCV und um z.B. Kratzer/Staub/flickern zu entfernen weitere OpenSource Tools

Kann man machen, aber das ist m.E. nicht Aufgabe eines Scanners. Ein Scanner soll Scannen, fertig. Alle ableitende Weiterverarbeitung der Scannerdaten gehört in die Pipeline des Users, also auf dessen Computer. Zumindest ist das meine Philosophie — ich mache aber auch mit mienen digitalen Fotokameras nur Raw. Gleicher Grund.

Die Transportmechanik des Noris ist schon sehr präzis und v.a. auch gut einstellbar, falls mal nötig. Stabilisieren muss man da eigentlich nur, wenn der Kameramann wackelte. Und dann musst Du halt croppen, behältst die ggf. zugehörigen Bewegungsunschärfen und Dein Ergebnis ist nicht mehr das, was der Film zeigte.

Ich stabilisiere gelegentlich auch, Szenenweise, mit zwei Klicks in Davinci Resolve. Da ist alles erlaubt was gefällt.

 

Zu Kratzern: Das weiche Lichte macht schon eine Menge weg. Bunte Laufstreifen bleiben natürlich Laufstreifen. Staub hats nicht, wenn man am Filmeinlauf eine Plattenbürste montiert, durch die der Film läuft.

 

Flickern gibts bei Einzelbildscans eigentlich nicht.

 

Kurz: An Nachverarbeitung ist alles möglich und alles erlaubt, gerade die Raws bieten ja enorme Luft. Das aber ist nicht Sache des Scanners, finde ich.

 

[Friedemann Wachsmuth]

Ich hab übrigens gerade ein kleines Davinci Resolve Howto fertig geschrieben, am Beispiel "Farbnegativfilm nachbearbeiten":

https://github.com/fwachsmuth/Filmkorn-Raw-Scanner/wiki/4.-Davinci-Resolve