cpixip

Es gibt ein paar Updates bei cineFlow. README und Handbuch wurden erweitert und präziser formuliert. Für Videodateien wird jetzt der FFV1 codec standardgemäß verwendet. Die Tooltips wurden verbessert, man kann jetzt mit Video-Eingangsmaterial als Ausgabe TIFF-Verzeichnisse wählen (das ging vorher nicht). Hier übrigens ein kurzer Beispielclip eines Negativscans, den mir Tony Truand netterweise zur Verfügung gestellt hat:

Bislang konnte ich cineFlow nur mit Umkehrmaterial testen. Ich habe nun erstmals auch Negativmaterial testen können. Hier ist das Ergebnis: (Testmaterial kindly provided by Tony Truand; Film stock: Orwo 54, Development: Rodinal) Wie man sieht, kann cineFlow auch dieses spezielle Filmkorn handhaben (das Filmkorn der Kombi Orwo 54 + Rodinal ist schon besonders...). Die Entwicklungsflecken des rechten Quellbildes sind im Ausgabebild übrigens auch verschwunden. Das ist das Result der cineFlow-Verarbeitung im dustA-Modus, bei dem fast alle Bildvariationen, die nur in einem einzigen Frame auftauchen, weggerechnet werden. Normalerweise gilt das halt für Staub oder Kratzer, aber für Entwicklungsflecken gilt es ebenso. Falls man diese Flecken aber erhalten möchte, wäre das auch möglich: anstatt dem dustA-Modus müsste man einfach den Standardmodus "best" benutzen. Ich sehe damit cineFlow als ein Werkzeug sowohl für Umkehrfilm als auch Negativfilm, mit dem man den Look des Materials verändern kann, je nach gewünschter Ästhetik.

Hallo - wer cineFlow und seine GUI austesten will: es gibt auf GitHub eine neuere Version. Kleinere Programmkosmetik, aber vor allem bessere Defaultwerte - die genommen werden, wenn der Nutzer nichts einstellt. Habe ich mit HDR/RAW, Kodak/Agfa/Fuji und mehreren sehr unterschiedlichen Szenen bzw. Filmabschnitten getestet. Die Defaults sollten jetzt einen besseren Startpunkt für eigene Optimierungen darstellen.

Nein, nicht wirklich. Der Aufwand wäre erheblich - und der Übergang vom bestehenden Pythoncode auf C++ wäre vermutlich die geringste Herausforderung. Schon in flowQt (der GUI) als auch in cineFlow selber (dem batch-Prg) sind jede Menge Optimierungen versteckt, welche unnötige Berechnungen und insbesondere Kopie-Operationen zwischen CPU und GPU vermeiden. Diese Optimierungen passen nicht wirklich auf das ofx-Konzept. Aber vielleicht findet sich ja jemand, der sich das zutraut - die Software ist ja open source.

Genau dafür wurde die Software entwickelt. Ich habe von jedem Film eine Archivkopie (4K Scan) und ggf. sogar mehrere Distributionskopien. Die letzteren können sich auch durchaus in der Ästhetik unterscheiden (Grain Anteil, Farbabstimmung, fps), je nach Zielpublikum. cineFlow soll soweit wie möglich die originalen Bildinformationen herausholen - dabei bleiben idealerweise alle Beschränkungen des Mediums auf der Strecke. Aber: man kann ja gezielt einen Arbeitspunkt zwischen Original und Restauration wählen, je nach Zielpublikum Ja - zunächst wird das Material raum-zeitlich analysiert (u.a durch optische Flussschätzer), anschließend mit dieser Information registriert (fusioniert) und dann an eine Schärfungsstufe übergeben, welche eine Schärfung auf der Basis der vorher berechneten Karten durchführt. Es ist eine adaptive Schärfung. Man kann diese Stufe auch abschalten, dann bekommt man das reine Fusionsergebnis. Naja, beide Programme haben einen Default-Parametersatz. Damit erzielt man bei einer relativ breiten Auswahl an Testmaterial (HDR/RAW, K25/Fuij/Agfa/noName, ruhige Landschaftsaufnahmen/schneller Vogelschwarm, unterbelichtete Szenen/überbelichtet, dünne Objekte (Äste) vs diffuse (Gischt, Wasserfälle) Ergebnisse - ob die ausreichen, muß man selber beurteilen. Ich hatte den Aufmerksamkeitsradius des Programm ("context") kürzlich auf +-1 Nachbarframe gestellt, einfach, um eine schnellere Vorschau zu haben. Das wird demnächst aber wieder auf +-2 Nachbarn zurückgestellt - dieses Setting funktioniert akzeptabel (ich werde demnächst die Defaults entsprechend anpassen). Die obigen Beispielrolle ist, da sollte ich nochmal darauf hinweisen, mit jeweils für den Abschnitt optimierten Settings gerendert worden. "Grand Canyon" arbeitet mit dem maximal möglichen context = 8, "Yellowstone" hingegen mit dem alten Standardcontext = 2. Im Allgemeinen reicht es aus, gleichartige Szenen in einem Rutsch zu bearbeiten. Beste Ergebnisse wird man aber erst dadurch erzielen, dass man einzelen Szenen einen eigenen Parametersatz beschert. Die Programme (flowQt und cineFlow) unterstützen das. wenn kein Parametersatz für eine Szene/Abschnitt gefunden wird, gilt der Standardsatz (oder, alternativ, ein Parametersatz, der direkt beim Aufruf übergeben worden ist) wenn im übergeordneten Ordner ein Parametersatz gefunden wird, gilt dieser für alle Unterordner, es sei denn, im Ordner selber gibt es eine entsprechende Parameterdatei - dann wird diese verwendet, aber natürlich nur für diese Bilder Ich mache das meistens so: ich starte damit, dass ich einzele Szenen aus DaVinci exportiere, alle in einen gemeinsamen Unterordner. Dann schaue ich mir die Szenen an - und zwar mit dem Standardsatz. Wenn das ok ist, mache ich garnichts, sondern gehe zur nächsten Szene über. Gleiches Spiel. Finde ich eine Szene, wo ich mit anderen Parametern bessere Ergebnisse bekomme, drücke ich die Taste "Save recipe" - das ist alles. Diese Taste färbt sich übrigens ein, wenn ein Parameter verändert wurde. Aber, das ist meine Arbeitsweise. Die GUI und das batch-Programm erlauben auch durchaus andere Vorgehensweisen. Nach dem Reimport in DaVinci kann man übrigens die bearbeitete und die Rohversion synchron übereinanderlegen - damit hat man die Möglichkeit, sehr variabel den Kornanteil für das finale Ausspielen einzupegeln.

Naja, was ist schon sicher? 😁 Aber, der Effekt wurde seinerzeit (ca. 2023) bei mehreren unterschiedlichen Scannersetups, die rund um den Planeten verteilt waren, reproduziert. Von mir auch mit einem Minimalsetup (nur RP5 + HQ-Kamera + offizielles RP-Netzteil). Also sind Störspannungen oder Einstrahlungen als Ursache eher unwahrscheinlich. Vermutlich ist das, was uns vom Sensor als "RAW" verkauft wird, nicht wirklich das rohe Sensorsignal, sondern intern mit Rauschunterdrückung. Der Effekt wurde aber, wenn ich mich recht erinnere, nie endgültig geklärt. Er taucht auch im normalen Gebrauch nicht auf, ist also eher akademisch. Wie gesagt, ich scanne mittlerweile auch nur noch DNGs. Übrigens, seinerzeit hat Jack Hogan den IMX477 gründlich untersucht. (Falls es jemanden interessiert)

Das ist im Wesentlichen auch meine Erfahrung - und HDR dauert, je nach Zahl der Einzelbelichtungen, vier bis fünfmal so lange, mit wenig Gewinn. Der kleine Gewinn des HDR-Verfahrens zeigt sich in sehr kontrastreichen Gegenlicht-Aufnahmen (wie der Grand Canyon-Sequenz im obigen Beispielclip). Dann können, wenn man die Schatten zu weit anhebt, insbesondere im Rotkanal des IMX477-Sensors (der in der HQ verbaut ist) rauschartige, horizontale Muster auftreten: Das scheint eine Eigenschaft des IMX477-Sensors zu sein; in der Regel zieht man aber die Belichtung in den Schatten nicht so hoch, dass die Streifen sichtbar werden. CineFlow kann das übrigens auch ein bisschen reduzieren, da die Streifen in jedem Frame anders liegen - also eher akademisch denn eine realistische Herausforderung. Alle neueren Scans mache ich nur noch in RAW.

Also bei mir liegt cineflow in folgendem workflow: 4k capture mit Selbstbauscanner auf der Basis des Raspberry Pi HQ Sensors. Ausgabe: 12 bit DNG -> Archivkopie Debayer via DaVinci, initiales color grading, downscale auf 1800 x 1350 px, Ausgabe rec.709. Entweder als Video oder als tif-Dir: ein Verzeichnis mit den durchnummerierten Frames der Szene/des Abschnitts Durch cineflow für's denoising. Ausgabe entweder als Video (ProRes) oder besser halt wieder als tif-Dir Einlesen in DaVinci, final crop (meistens mit ein bisschen Kamera-Stabilisierung), final grading. Ausgabe als Video -> Distributionskopie Es gibt Punkte, die gegen das direkte Einlesen von DNGs sprechen: 4k kostet gegenüber 1800 x 1350 px etwa die fünffache Rechenzeit. Bei 4k läuft der VRAM leicht voll. Der NVIDIA-Treiber wirft dann nicht etwa einen Fehler, sondern lagert stillschweigend in den Hauptspeicher aus — die Verarbeitung läuft weiter, nur um Größenordnungen langsamer. Das lineare Gamma der DNGs staucht genau den Bereich, in dem die interessanten Daten liegen — das Rauschen in den dunklen Partien. rec.709 akzentuiert sie hingegen. DNGs sind gebayert, jeder Farbkanal also unterabgetastet. Feine Strukturen erzeugen dabei Moiré, und das wandert bei kleinsten Bewegungen eigenständig durchs Bild — darauf optischen Fluss zu berechnen wird schwierig. Man könnte cineFlow um ein RAW-frontend erweitern. War mal angedacht, einschließlich interner Transformation auf einen optimalen Farbraum, ist aber dann verworfen worden zugunsten des obigen Workflows. Der Beispielclip oben nutzt übrigens ein anderes Aufnahmeverfahren. Mein Scanner kann auch im HDR-Modus arbeiten, bei dem vier bis sechs Einzelbelichtungen zu einem Bild zusammengefügt werden — genau dieses Material ist im Beispielclip verwendet worden. Ein Beispiel aus dem oben beschriebenen DNG-Workflow: Links der Rohscan, rechts das Ergebnis. Vermutlich ein Fujichrome; mein Material stammt hauptsächlich aus den Siebzigern und frühen Achtzigern.

Naja, hier wird's dann ein bisschen technisch... Vorab: kenne Neat Video nicht so gut, und naturgemäß ist das auch nicht Open Source, so dass ich nicht direkt im Code nachschauen kann. Tendenziell nimmt Neat Video vermutlich ein anderes Rauschmodell an, eher in Richtung digitaler Sensoren getrimmt. Daher auch der Schritt in der Anwendung, eine möglichst strukturlose Fläche im Bild zu wählen — daraus wird ein Rauschprofil gewonnen, nach dem dann im Einzelbild gefiltert wird. Der Temporalfilter scheint mir eher ein Zusatz dazu zu sein; nicht so ganz klar, ob hier wirklich dichte Flusskarten berechnet werden. Genau da liegt für mich der Knackpunkt: Im Einzelbild sind Korn und feines Detail schlicht nicht unterscheidbar. Beides sind kleine, kontrastreiche Strukturen. Wer primär räumlich filtert, muss also raten — und nimmt zwangsläufig Detail mit weg. Erst über die Zeit wird der Unterschied sichtbar: das Detail bleibt, wo es ist, das Korn springt. cineFlow setzt deshalb genau dort an. Über den optischen Fluss wird ermittelt, wohin sich jeder Bildpunkt von Frame zu Frame bewegt hat. Damit lässt sich ein Detail über mehrere Nachbarbilder hinweg verfolgen und aus mehreren Beobachtungen desselben Bildpunkts verrechnen. Das Korn, das ja in jedem Bild woanders sitzt, mittelt sich dabei weitgehend heraus, während das echte Detail stehenbleibt. Also, mit den wenigen Infos, die ich über Neat Video habe: Neat Video ist eher auf digitales Rauschen getrimmt, cineFlow definitiv auf analoges. Neat Video arbeitet vermutlich primär räumlich mit temporaler Ergänzung, cineFlow primär temporal — das Pferd wird also von der anderen Seite aufgezäumt, wobei es hier kein „Falschherum" gibt. Hier ein kurzer Clip mit ein paar Beispielen: „Grand Canyon" — sehr starkes Rauschen in den Schatten. Zwei Faktoren kommen zusammen: das über ein Jahr gelagerte Latentbild des K25 und der hohe Kontrast der Szene selbst. „Fast Birds" — viele kleine, schnell bewegte Objekte vor fast texturlosem Hintergrund. Notorisch schwieriges Material: wer über die Zeit mittelt, ohne die Bewegung sauber zu erfassen, produziert hier Schlieren oder Doppelkonturen. „Yellowstone" — schnell bewegte, diffuse Objekte (Wasserfall) und transparente Gischt. Also Bildinhalt, für den es streng genommen gar keine eindeutige Korrespondenz zwischen zwei Frames gibt. „Las Vegas" — hoher Kontrastumfang und sich schnell ändernde Lichter. Nicht so einfach. „Rooftops Seattle" — ein anderes Filmmaterial: Ektachrome, schön gefadet über die Jahre. Andere Emulsion, also anderes Korn. Links jeweils der Rohscan, rechts das Ergebnis.

Hi, bin neu hier. Befasse mich aber schon seit Jahren mit dem Digitalisieren von Super-8-Material. Meine größte Herausforderung bisher: ein etwa einstündiger Film auf Kodachrome 25, der erst über ein Jahr nach der Belichtung entwickelt wurde. Das Korn ist entsprechend ungewöhnlich für K25, und gerade in den dunklen Partien ist die Qualität unterirdisch. Die üblichen Entrauscher helfen da nur bedingt. Habe daraufhin eine eigene Software in Python entwickelt. Kernidee ist, dass reale Szenendetails über ein paar Frames stabil bleiben, während sich Bildstörungen — insbesondere das Filmkorn-Rauschen — mit jedem Frame ändern. Per optischem Fluss werden die Nachbarbilder auf das zentrale Bild ausgerichtet und verrechnet. Wo der Fluss nicht vertrauenswürdig ist, bleibt das Original unangetastet. Oberstes Ziel bei der Entwicklung war, weitestgehend nichts dazuzuerfinden — im Idealfall nur das Filmkorn zu beseitigen oder zu dämpfen. Es gibt zwei Programme: eine interaktive Oberfläche zum Einstellen und einen (schnelleren) Batch-Prozessor für ganze Szenen. Vorausgesetzt werden Python und ein paar Bibliotheken, die man installieren muss. Wenn eine NVIDIA-GPU mit CUDA-Support vorhanden ist, wird die Verarbeitung schneller, und man hat einen weiteren Flussalgorithmus zum Ausprobieren. Rein und raus gehen Bildsequenzen; bei mir sitzt DaVinci Resolve davor und dahinter. Zu finden ist die Software auf GitHub — vielleicht ist sie ja für den einen oder anderen auch nützlich. Das Bild unten zeigt die interaktive Programm-Oberfläche mit einem "K25 - nach einem Jahr entwickelt"-Beispiel: