Zum Inhalt springen

Klaus14

Mitglieder
  • Gesamte Inhalte

    41
  • Benutzer seit

  • Letzter Besuch

  • Tagessiege

    1

Alle erstellten Inhalte von Klaus14

  1. Da gebe ich dir natürlich vollkommen recht, mit dem geeigneten Projektor kann man sich das Leben schon deutlich einfacher machen, das ist klar 😉
  2. Das Thema passt doch recht gut hier her, denn mit Friedemanns Scan-Controller könnte man doch bei jeden Projektor mit DC Motor und einer kleinen Anpassung seiner Firmware auch den Gleichlauf eines Projektors sehr gut regeln. Sein Controller hat einen 8MHz Quarz als Taktgeber, läuft also sehr präzise und mit dem Sensor bekommt man immerhin einen Impuls pro Bild, der Rest ist Software. Und noch ein kleiner Hinweis. Wer das Projekt von Friedemann nachbauen möchte, verwendet ja ohnehin die Raspberry HQ Kamera und mit der kann man natürlich auch Videos Scannen (zugegeben nicht ganz in der Qualität wie Friedemann es mit seiner Einzelbildmethode schafft) aber dafür in Echtzeit. Und mit dieser Kamera braucht man dann keine 16,66 fps, denn man kann mit echten 18 fps "abfilmen" und könnte gleichzeitig so sogar eine vorhandene Tonspur synchron mit aufnehmen. Ich habe das gerade mit meinem Bauer T502 getestet und das funktioniert prima 😉
  3. Mach dir nichts daraus, ist bei mir nicht anders. Der Frühling steht vor der Türe und da stehen wieder viele Arbeiten im Haus & Garten an und die Radsaison hat auch wieder begonnen, also ich verstehe das sehr gut, dass es jetzt wieder nur sehr langsam weitergehen kann. Ich experimentiere übrigens mit der externen Triggerung der HQ Kamera, aber das ist im Moment eher ein Albtraum, weil es da scheinbar in der PiCamera2 API noch Fehler gibt! Dafür habe ich jetzt etwas Zeit um mich doch in das PICO SDK einzuarbeiten, denn ich möchte den PICO natürlich schon in C/C++ programmieren 😉
  4. Ja ich hab's gefunden, diesen Link hatte ich bisher völlig übersehen 😳 Vielen Dank
  5. Hallo Friedemann, ich wüsste bitte gerne WO und WIE man deinen Reflexsensor am optimalsten anbringt. Hast du das schon irgendwo beschrieben, ich hab es zumindest nicht gefunden? Und wie geht es deinen Korrekturen die du noch machen wolltest, kommst weiter damit? LG aus Wien, Klaus
  6. Naja, Eumig hat das bei ihren Projektoren damals etwas anders gelöst und da konnte man in gewissen Grenzen die Geschwindigkeit zwischen 18 und 24 FPS fast stufenlos verändern und das rein mechanisch! Blöd nur, dass man trotzdem kaum auf die 16,67 gekommen ist 😒hast dir deren Lösung schon mal angesehen?
  7. Ja klar, für die Entwickler war es damals so natürlich einfacher, sich an den sehr konstanten 50Hz des Stromnetzes zu orientieren, aber sie hätten schon daran denken können, dass rund ein halbes Jahrhundert später dann so verrückte Typen kommen könnten, die aus ihren Projektoren Filmabtaster bauen wollen und die tun sich nun mal mit Gleichstrommotoren leichter 😄😅😂
  8. Danke Andreas, das ist sehr nett. Ja du hast vollkommen recht, wirklich blöd! Ich wusste nicht wie viele Projektoren solche Motoren hatten/haben, ich dachte bisher eher, das war eine "Eumig Krankheit", aber ich habe jetzt z.B. einen Rollei P840T bekommen und der hat ebenso einen Wechselstrom Motor. Diese Antriebe sind zwar nicht umzubringen, aber die Regelung ist leider problematisch 😳Da lobe ich mir meine YELCO Projektoren, die haben alle einen Gleichstrommotor.
  9. Kannst du bitte den Schaltplan hier zeigen? Danke
  10. Der Bolex SM8 wird hier ja sehr gelobt, was hat der denn bitte für einen Motor drinnen, einen Gleichstrom oder Wechseltrom Motor? Diesen Projektor hatte ich bisher überhaupt nicht im Focus, der ist aber bei uns leicht zu bekommen 😉
  11. Hallo Nils, Willkommen im Club ... also ich würde mich sehr über deinen Baubericht freuen. Je mehr Möglichkeiten aufgezeigt werden, desto mehr neue Ideen können entstehen. Also BITTE beschreibe auch dein System genauer in einem eigenen Thread. Liebe Grüße aus Wien, Klaus
  12. Ich werde sicher versuchen das auf dem RP5 unter Picamera2 zum Laufen zu bringen, ob ich es schaffen werde, ist eine andere Frage 😉
  13. Deine Vorgehensweise finde ich vollkommen richtig und vernünftig. Später können die Anderen, die das brauchen oder wollen und die Zeit dafür haben, das Projekt ja weiterführen auf den RP5 portieren und vielleicht auch optimieren. Wichtig ist erst mal die Qualität und an der müssen sich alle "Optimierer" dann messen und werden sich vermutlich die Zähne ausbeissen. Da mein PICO jetzt das erledigt was mein RP4 bisher selbst mit den PIOs gemacht hat, konnte ich heute bei meinem Projekt auf den RP5 umsteigen. Ich habe jetzt also einen RP4 übrig, der nur noch auf deine Platine wartet 😉
  14. Danke Friedemann für diese Infos, ich habe sie mal versucht zu verstehen und ja die Jungs haben beim RP5 den Kamerazugriff verändert, aber man kann doch sehr wohl immer noch selbst bestimmen, dass man "uncompressed raw" haben möchte und das kann man dann sogar ca. 6 x so schnell abspeichern, wie das auf einem RP4 möglich wäre. There is a way to speed things up and improve the raw quality on the RP5. You need to force the RP5 to work with uncompressed raw. This can be done by explicitly requesting such a format. Here’s the appropriate code line to do so: capture_config = picam2.create_still_configuration(raw={'format':'SRGGB12','size':(4056, 3040)}) If the uncompressed raw format is selected with an RP5, you end up with about 160 msec for a .dng-save on a SSD drive, compared to about 980 msec when working with the “compressed” format. While 980 msec is too slow for my film scanner, the 160 msec when using the normal raw format is fine. Also ich kann da jetzt beim besten Willen nichts erkennen was den RP5 ausschließen würde, ganz im Gegenteil, er kann das sogar 6 x schneller wie der RP4. OK, es mag schon sein, dass man diese raw Files dann eben etwas anders in echtes Adobe DNG umwandeln muss, aber wäre das denn so schlimm, du konvertierst sie doch auch erst später in "echtes" DNG, wenn ich das richtig verstanden habe.
  15. Ich habe jetzt mal die PiCamera2 Doku nach raw durchsucht und bei den ca. 75 gefundenen Stellen aber auf die Schnelle keinerlei Hinweise gefunden, dass die RAW-Daten schon zwangsweise durch eine Objektiv/Vignettenkorrektur gepresst werden. Es ist zwar scheinbar auch ein komprimierter RAW Modus möglich, wohl um die Datenmenge zu reduzieren, aber den muss man ja nicht nutzen. Kannst du dich vielleicht noch erinnern, wo du das über Objektiv/Vignettenkorrektur gelesen hast? Echt spannend, darf ich fragen was du bei Adobe genau machst, klingt sehr interessant.
  16. OK danke, das sind sehr interessante Hinweise, von denen ich leider keine Ahnung habe, weil ich mich noch nie ernsthaft mit RAW beschäftigt habe und schon gar nicht auf dem Raspi. Da ist also noch gewaltig Recherche und Lernen bei mir angesagt ... aber Lernen kann ich bei deinem Projekt ja mehr als genug 😉
  17. Guten Morgen am Sonntag, Neugierig wie ich nun mal bin, habe ich mir eben dein Projekt auf github angesehen und natürlich ein wenig im Quellcode "geschnuppert" 😉 Dazu zuerst einmal ein großes Lob, du hast einen wirklich feinen Programmierstil, sehr übersichtlich mit sehr aussagekräftigen Namen und sogar Kommentaren ... RESPEKT ... es macht Freude deinen Quellcode zu betrachten und das sowohl im Python- als auch im C/C++ Code ... sehr, sehr lobenswert! Was mir aber sofort aufgefallen ist, wäre diese Zeile "from picamera import PiCamera" und daraus resultiert jetzt folgende Frage. Mit welcher OS Version arbeitest du am Raspi 4 eigentlich? Mit dem Raspi 4 wurde doch auf Debian version: 11 (bullseye) umgestellt und ein neues Kamera Interface PiCamera2 eingeführt. Ich hatte damals auf einem Raspi 3 meine ersten Experimente mit der Camera gemacht und war entsetzt, das alles plötzlich auf dem Raspi 4 unter BullsEye nicht mehr kompatibel war und PiCamera2 zu Beginn ja noch nicht einmal funktioniert hatte. Ich war so sauer, dass ich den Krempel erst mal für Monate weggelegt und auf eine funktionierende PiCamera2 Version gewartet habe. Und alles was ich jetzt mache basiert bei mir natürlich auf den neuen Standard PiCamera2 (der aber zugegeben etwas gewöhnungsbedürftig ist)! Ist dein Code auf github aktuell, oder hast du das einfach noch nicht aktualisiert? Oder bist du auch da einfach auf Nummer Sicher gegangen und bei einer älteren OS Version geblieben? schönen Sonntag LG Klaus
  18. Und wer hat den dann konstruiert ... EUMIG, Bauer oder haben die am Ende ohnehin zusammengearbeitet um Kosten zu sparen?
  19. Bei uns in Österreich sind natürlich die EUMIG Projektoren die "Üblichsten", aber da sind die älteren Modelle für dein System ungeeignet, weil sie einen Snychronmotor haben, da müsste man dann auch den Motor tauschen. Vielleicht kannst du mir ein paar Modelle nennen, die du als "üblich" sehen würdest und die für den Umbau geeignet sind.
  20. Friedemann gilt dieses Angebot allgemein ... also für eine Umbaudokumentation bekommnt man eine (voll funktionsfähige) Prototyp Platine 😀 Wenn dem so ist, schliesse ich mich da sehr gerne an und dokumentiere auch einen Umbau, wobei du dir vielleicht sogar den Projektor aussuchen kannst, hätte einige Modelle zur Auswahl 😉
  21. GUI am Raspberry Und zu guter letzt noch die GUI am Raspberry die ich zu 100% in Python programmiert habe und das Framework PyQt5 nutze Das ist aber noch in einem sehr frühen Entwicklungsstadium und da wird es wohl noch viele Änderungen geben. Ich gebe zu da nicht alles selbst implementiert zu haben, so Manches ist aus verschiedenen Projekten "zusammengeklaut" ... man muss ja das Rad nicht immer neu erfinden und in der Dokumentation der HQ Kamera gibt es ja ein wunderbares Beispiel, wo man sich was "abkupfern" kann. Also geklaut trifft die Sache nicht, habe Ausnahmslos auf Open Source Beispiele zurückgegriffen. Aber da bin ich schon sehr auf die Lösung von Friedemann gespannt, denn meine GUI ist viel zu überladen. Aber im Moment dient sie mir eben auch dazu, die Möglichkeiten der HQ kamera auszuloten. So das war's erst mal, damit habe ich in etwa gezeigt wie meine Experimente so aussehen. Wie der endgültige Scanner dann aussehen wird, kann ich noch nicht sagen, aber ich habe zumindest schon mal viel gelernt, seit ich mit diesem Projekt begonnen habe. Werde es weiter hier dokumentieren, wenn Interesse besteht.
  22. Frame Sensor fehlt eigentlich nur noch ein Sensor, der immer dann anspricht, wenn der Film nach dem Bildwechsel wieder zum Stillstand gekommen ist. Da habe ich wieder auf Technik aus dem 3D Druckerbereich zurückgegriffen und nutze Lichtschranken die als optische Endschalter verwendet werden. Lichtschranke Für die Montage (die ja sehr vom Projektor abhängt) habe ich mir mit Fusion 360 die entsprechenden Teile konstruiert und auf meinem 3D Drucker ausgedruckt. Mit etwas Übung klappt das echt gut und man findet wohl in jedem Projektor eine Stelle wo man das montieren kann. Diese Methode hat den Vorteil, dass man durch einfaches Drehen der Sensorscheibe, die den Lichtstrahl unterbricht, den richtigen Zeitpunkt perfekt justieren kann. Die Auswertung des Signals übernimmt der PICO und sendet den Abspeicherbefehl an den Raspberry Pi der dann im gewünschen Format (RAW ist leider noch nicht dabei) abspeichert.
  23. Kamera & Objektiv Als Kamera nutze ich natürlich die Raspberry HQ Kamera die ich vor dem Projektor auf einen 3-Achsen Lineartisch montiert habe. Das ist zwar zum Experimentieren recht nett, aber in der Praxis keine brauchbare Lösung, weil viel zu wackelig. Als Objektiv verwende ich ein simples C-Mount Objektiv mit 35mm 1:1,7 vor das ich noch entsprechend viele Distanzhülsen geschraubt habe. Das habe ich rein experimentell ermittelt, ich kenne mich mit Objektiven viel zu wenig aus um dazu was Schlaues sagen zu können. Die ganze Konstruktion möchte ich aber durch ein Objektiv ersetzen, wie es Friedemann in seinem Projekt beschrieben hat, das scheint mir doch eine deutlich bessere Lösung zu sein.
  24. Es steht zumindest Bauer drauf, aber wenn ich die Technik mit meinem Bauer T502 vergleiche, bin ich nicht sicher, ob da auch ein echter Bauer drinnen ist 🫣 Ich kenne mich mit den ganzen Modellen zugegeben zu wenig aus, aber am Ende der Schmalfilmzeit wurden von den verschiedensten Firmen noch Projektoren auf den Markt geworfen, die sich doch sehr, sehr geglichen haben, nur wer hat die wirklich gebaut. Vielleicht gibt es hier ja einen Experten der das aufklären könnte.
  25. Friedmann ich gebe dir grundsätzlich recht bei EE keine unnötigen Risiken einzugehen, aber ich bin kein Profi-Entwickler, sondern mache das aus Spaß an der Sache und da ist es doch irgendwie klar, dass ich mir immer wieder was Neues ansehen möchte. Bei meiner ersten Version habe ich ALLES über die GPIOs des Raspi 4 erledigt und das hat grundsätzlich funktioniert. Der Ärger ist ja erst entstanden wie das mit dem Raspi 5 eben nicht mehr geklappt hat und da hatte ich eben endlich die Gelegenheit mir den PICO genauer anzusehen. Der 328/168P würde da vollkommen reichen und sich wohl immer noch die meiste Zeit eher fadisieren, aber mein "Drang" Neues zu erforschen hat mich einfach überwältigt. Vor allem wollte ich ausloten, wie weit ich auf dem PICO mit Micro Python komme und das ist ja auch ein erhebliches Neuland und damit Risiko ... aber es macht Spaß ... und darauf kommt es mir bei meinem Hobby ja an 😀 Viele Wege führen ans Ziel und ich zeige hier einfach mal meine Experimente der letzten Wochen ... was da letzt endlich daraus wird ... mal sehen 😉 Freue mich schon sehr auf deine weiteren Fortschritte schönes Wochenende und LG aus Wien
×
×
  • Neu erstellen...

Filmvorführer.de mit Werbung, externen Inhalten und Cookies nutzen

  I accept

Filmvorfuehrer.de, die Forenmitglieder und Partner nutzen eingebettete Skripte und Cookies, um die Seite optimal zu gestalten und fortlaufend zu verbessern, sowie zur Ausspielung von externen Inhalten (z.B. youtube, Vimeo, Twitter,..) und Anzeigen.

Die Verarbeitungszwecke im Einzelnen sind:

  • Informationen auf einem Gerät speichern und/oder abrufen
  • Datenübermittlung an Partner, auch n Länder ausserhalb der EU (Drittstaatentransfer)
  • Personalisierte Anzeigen und Inhalte, Anzeigen- und Inhaltsmessungen, Erkenntnisse über Zielgruppen und Produktentwicklungen
Durch das Klicken des „Zustimmen“-Buttons stimmen Sie der Verarbeitung der auf Ihrem Gerät bzw. Ihrer Endeinrichtung gespeicherten Daten wie z.B. persönlichen Identifikatoren oder IP-Adressen für diese Verarbeitungszwecke gem. § 25 Abs. 1 TTDSG sowie Art. 6 Abs. 1 lit. a DSGVO zu. Darüber hinaus willigen Sie gem. Art. 49 Abs. 1 DSGVO ein, dass auch Anbieter in den USA Ihre Daten verarbeiten. In diesem Fall ist es möglich, dass die übermittelten Daten durch lokale Behörden verarbeitet werden. Weiterführende Details finden Sie in unserer  Datenschutzerklärung, die am Ende jeder Seite verlinkt sind. Die Zustimmung kann jederzeit durch Löschen des entsprechenden Cookies widerrufen werden.