Friedemann Wachsmuth

Oh, das wäre ja schön! Davon gibt's doch einige. Muss ich den Abschnitt noch mal überarbeiten. Falls jemand Gewissheit hat: bitte melden. 🙂 Und: wo hast du die Schaltpläne gefunden? Habenwill

Ich hätte nicht gedacht dass das jemand will, aber ja, das sollte sich machen lassen. Danke für Dein Hilfsangebot, darauf komme ich sicher zurück.

Punkt 3 hab ich geschafft, Punkt 2 auch. Punkt 1 nicht — dafür habe ich noch ein paar üble Bugs gefunden, die ich noch beheben muss, und eine möglicherweise konstruktive Verbesserung/Vereinfachung, die ich noch ausprobieren will.

Danke, Simon. Genauso ist es. (Ich habe gestern gedacht, ein Visalux sei von Braun... wir sind eben alle nicht unfehlbar.)

Nur zu, kann gut sein, dass das mit dem Raspi 5 und neuen APIs schneller geht. Mir war das noch zu sehr in Flux und zu intransparent, als ich es mir zuletzt anguckte. Ich brauche mit dem Rpi 4 etwa 450 ms zum Speichern eines Einzelbildes, keine 960 ms. Die alte API die ich verwende erzeugt eh kein DNG, sondern hängt das Raw als EXIF Blob an das (dann) Preview-JPEG an. DNG mache ich erst später per Python draus, wenn ich das CinemaDNG erzeuge. Kurz: Tempo ist bei meinem Scanner nie eine Prämisse gewesen. Der Focus liegt auf Qualität. Alles andere kommt nachgelagert. Und wenn da andere noch Geschwindigkeit optimieren: super! Dazu ist es ja open source. Edit: in obigem Post ist ja auch zu lesen, das "consistent exposure" für Raw erst seit ca. 8 Tagen wieder funktioniert! Da lass ich Software lieber noch bisschen reifen, bis ich da aufspringe. Meine Zeit für solche Projekte ist endlich. 🙂

Hier sind die Details ganz gut zusammengefasst: https://forums.kinograph.cc/t/raspberry-pi-5-hq-sensor-new-stuff/2695 Bin u.a. Product Manager für Lightroom.

Raw ist eigentlich keine Abkürzung, sondern bedeutet einfach "roh". Eben rohe Messdaten ohne jegliche Weiterverabeitung. Damit kann man prima Sachen wie Objektivkorrekturen machen, aber bitte an Hand der Rohdaten, nicht in die Rohdaten eingebacken. Raw-Daten sind proprietär und Herstellerspezifisch, oft ist deren Format nicht mal offengelegt, sondern muss reverse engineered werden. DNG ist ein von Adobe erfundenes, offenes Dateiformat, dass Raw -Daten in eine einheitliche, strukturierte Form bringt, ohne die Sensordaten selbst in irgendeiner Weise zu verändern. (Disclaimer: ich arbeite bei Adobe, und in genau der Abteilung. Der Scanner ist aber völlig frei von Adobe-Software und nicht an sie gebunden.)

Ich würde fast behaupten: Bei Einzelbildschaltung ist der Vorwicklet noch wichtiger als im kontinuierlichen Betrieb, weil die gebende Filmrolle nie in Schwung kommt sondern bei jedem Bild neu beschleunigt werden muss. Das ist auch einer der großen Fehler des Wolverine.

Der Code auf GitHub ist mein aktuellster, und verwendet die alte API auf altem Raspbian. PiCamera2 ist zumindest für unsere Zwecke m.E. Mist. Neu ist ja nicht immer besser. (Wenn ich mich recht erinnere, sind sogar die angeblichen RAW-Daten schon durch eine Objektiv/Vignettenkorrektur geiaufen, das ist schon im Ansatz ein Fehler. RAW muss Rohdaten heißen.

Gern, ja, ich muss gucken wie viele funktionierende Prototypen ich noch habe. Drei müsste es wohl auf jeden Fall noch sein. Je "üblicher" der Projektor, desto besser, denn umso mehr Leute können dann nachbauen.

Stimmt. Dann doch lieber beim aufgefeilten N8 Gate bleiben 🙂 Ich hab mittlerweile schon einen P8 bekommen. Aber wenn Du den t610 Umbau dokumentierst, kriegst Du dafür gern eine der (voll funktionsfähigen) Prototyp-Platinen überlassen.

Eigentlich ist er Visalux doch von Braun. Oder hast Du da ein seltenes Modell was ich noch nicht kenne? 🙂 Und Ja: der Spaß an der Sache, in unserem Fall Forscher- und Entdeckergeist, die sind das wichtigste!

Nein, das ist egal.

Ja, der Pico ist ne schöne Brücke zu den größeren Arms (STM32 und so). Ich kenne ihn schon recht gut, hab schon einiges mit dem gemacht, auch state machines per PIO. Sehr feine Sache. Ich finde aber keineswegs, dass der die 8-Bit AVRs einfach ersetzen sollte, nur weil er neuer ist. Ich bin bei EE ein Freund der Philosophie, das zu nehmen, was wirklich benötigt wird — überflüssiges bringt nur unliebsame Überraschungen. Der 328P (oder 168P) kommt beim Scannen mitnichten an irgendwelche Grenzen, reicht also vollkommen. (Im Grunde hätten die GPIO des Raspi allein wohl auch zum Steuern gereicht, mit ist der Raspi aber für sowas zu zickig, zu kompliziert, und Linux zu wenig RTOS.) Viele Wege führen zum Ziel. 🙂

Ich wär dann bereit. 🙂

VSCode. Und mach mal einen eigenen Thread für Dein Picodings, klingt sehr spannend! (Ich hab den 328P vor allem auch deshalb verwendet, weil hier noch 120 Stück davon rumflogen... und als ich mit dem Scanner begann, gabs quasi überhaupt keine uC, nirgendwo.)

Doch, vermutlich. Habe ich unterwegs oft auch gedacht. Nur: der 328P hat ja nur eine serielle, und die brauchte ich halt für mein printf debugging. 🙂 Eigentlich mag ich i2c aber, nur habe ich erst spät begriffen, dass der Raspi ja nur smbus kann. Das war oft etwas anstrengend. Aber es funktioniert jetzt gut, das ist die Hauptsache. 🙂 Ich hoffe ja, dass der OpenSource da Optimierungen, Verbesserungen und Erweiterungen von anderen bringen wird. Auf dem Interfaceboard sind neben UART auch einige GPIO und Pins des 328P an Testpunkte geführt. Es darf und soll gelötet und gehackt werden!

Sehr cool, Andreas. Bin gespannt. Und gerade wird mir klar, dass man N8 doch auch mit dem S8 Gate scannen kann... ist halt nur noch dollerer Overscan. Manch mal sieht man echt den Wald vor lauter Bäumen nicht... 🙂 Na klar! dieses Wochenende steht an: 1. Das generieren eines Raspi-Images zu automatisieren. Das ist eng mit dem "bootstrapping" verbunden, also der Erstkonfiguration... soll ja auch für nicht-Linux-Experten gut laufen. 2. Die 25 Boards zu flashen. Das Pogopin-Rig dafür ist schon fertig. 3. Einen neuen Holzunterstand im Garten zu bauen. Dieser Punkt wird sogar der erste sein... erst die Arbeit, dann das Vergnügen. 🙂

Oh ja, mach gern mal einen Thread zu deiner Lösung auf, finde ich sehr spannend! Echtzeitlösungen gibt es ja schon viele, auch daher habe ich was neues gesucht. Und mir ist's völlig egal, ob ich auf ein entwickeltes Röllchen 3 Minuten oder 30 Minuten warten muss, bis der Scan da ist. Dann eben lieber 30 Minuten und garantiert kein zweites Mal scannen müssen. 🙂

https://www.elektronik-kompendium.de/sites/com/1809251.htm Aber wenn es mit Deinem kleinen Netzteil tut, tuts auch mit dem Akku. Die theoretischen 16,x Volt sollten für einen DC-Motor völlig unkritisch sein. (Persönlich kenne ich den Motor aber nicht)

Oder USB-C PD nehmen. Da gehen ja auch 100W... allerdings wohl kaum mit ner Powerbank. Ein 14.4V Makita-Akku müsste doch passen. (Aber bitte kein Plagiat)

Danke für die Blumen! Am Wochenende jetzt geht's auch wieder weiter. Ob 4K lohnen, ist eine Glaubensfrage. Viele sagen Nein, ich sage klar Ja. Warum? 1. Um Korn sauber und unverfremdet abzubilden brauchst du möglichst viele Pixel pro Korn. Korn ist wichtig für Beibehalt des Filmlooks. 2. Für den Effekt der Superresolution brauchst Du neben temporaler auch spatiale Informationsredundanz. Ein Filmbild hat eben kein festes Raster, das übersehen viele. Alt, aber noch gültig: https://www.filmkorn.org/zwischen-den-zeilen-wie-wir-film-sehen/ 3.: Der Raspi schafft das locker. Und Kleinrechnen kann man ja immer noch. Aber eben am Ende der Bearbeitung. 🙂 Ob "sRaw" mit der HQ-cam geht, weiß ich gerade nicht aus dem Kopf. Ich vermute fast nicht, denn das Zusammenfassen von je 4 RGBG-Zellen wäre nicht unerhebliche Rechenarbeit... 16 Additionen und 4 Divisionen pro Pixel, und das mit 12-Bit (also praktisch 16)-Bit Werten. Aber Versuch macht kluch. 🙂

Cool. Über Geo Kraemer? 🙂

Ist das Rost da am Andruckstück des oberen Teils!? "Gut erhalten" wäre dann sehr relativ.

Die Connectoren sind jetzt, genau 1000 Lötstellen später (25x40), alle dran. Ich habe mir zudem heute noch ein "Testjig" mit Pogo-Pins gebaut, mit dem ich jeden Controller recht schnell und zuverlässig flashen und testen kann. Hoffentlich ist bald wieder Wochenende 🙂