Frage von roki100:Hat es jemand versucht? Hier ein Tipp (nicht perfekt aber immerhin) :)
https://youtu.be/Zq5mVnDZR24
Antwort von mash_gh4:
ja -- natürlich funktioniert diese sehr einfache methode, um das chroma rauschen zu vermindern. wie all diese seher einfachen eingriffe, die jeweils nur ein aktuelles bild heranziehen bzw. die räumlich benachbarten pixel, geht es aber leider mit einer deutlichen verschlechterung der bildqualität bzw- schärfe einher.
einigermaßen brauchbares denoising sollte also unbedingt auch in der temporalen ebene einbeziehen -- also die benachbarten bilder davor und danach --, um mit weniger qualitätsabstrichen auszukommen. z.b. das ffmpeg filter
'hqdn3d' macht das ganz passabel. allerdings gibt's hier das problem, dass in guten lösungen auch unbedingt eine kompensation der bewegungen im bild hinzukommen sollte, damit keine unerwünschten geisterbilder an den wandernden konturen entstehen. derartiges ist leider im genannten ffmpeg-filter nicht vorhanden.
die einbeziehung derartiger temporaler vergleiche ist meines wissens nach mit resolve color nodes ohne rückgriff auf openFX plugins nicht möglich. im übrigen gibt's hier auch das problem, dass man zur möglichst raschen berechnung auf der GPU natürlich gleich einige bilder gleichzeitig im dortigen speicher unterbringen muss, was beim resolve regelmäßig dazu führt, das man wieder mit irgendwelchen out of memory fehlern zu kämpfen hat, so fern man nicht über sehr teure luxus-grafikkarten verfügt.
aber eigentlich sind auch diese einfachen temporalen vergleiche mittlerweile wieder schnee von gestern. denoising kann man nämlich auch mit sgn. autoencodern, einer grundform von neuronalen netzwerken, wie man sie im machine learning umfeld nutzt, ausgesprochen toll umsetzten. wobei auch hier wieder die temporale ebene bzw. das einbeziehen der benachbarter video frames wieder eine ziemlich komplizierte zusatzaufgabe darstellt, die man einbeziehen muss, um wirklich gute ergebnisse in der videoverabeitung ohne störendes flackern zu erzielen. das ist wohl eher die herangehensweise, die man heute als state of the art ansehen kann.
Antwort von roki100:
Danke für den Tipp mit ffmpeg Filter!
Funktioniert wunderbar, jedoch nur mir ProRes Aufnahmen.
Hier der ffmpeg Befehl unter MacOS oder Linux für ProRes Aufnahmen:
./ffmpeg -i <INPUT>.mov -c:v prores_ks -profile:v 4 -pix_fmt yuv422p10le -filter:v hqdn3d=4.0:3.0:6.0:4.5 -c:a pcm_s16le -ar 48000 -y <OUTPUT>.mov
Sieht auf jeden Fall nicht schlecht aus... ist aber 10bit und bei Bewegung im Video sieht man eine Art MotionBlur. Naja immerhin.
Antwort von mash_gh4:
roki100 hat geschrieben:
Sieht auf jeden Fall nicht schlecht aus... ist aber 10bit und bei Bewegung im Video sieht man eine Art MotionBlur. Naja immerhin.
wenn du eine etwas besser qualität haben willst, könnstest evtl. auch einen blick auf die diversen
vapoursynth denoiser werfen. vieles davon halte ich zwar techn. auf zieliemlich verstaubt, aber z.b. die MVTools basierenden ansätze, die eben auch motion compensation einbeziehen, funktionieren schon deutlich besser als hqdn3d.
siehe:
http://www.vapoursynth.com/doc/pluginlist.html
Antwort von cantsin:
Man kann auch OFX-Filter wie Neat Video in der kostenlosen Version von Resolve nutzen.
Antwort von roki100:
also mit ffmpeg sieht es wirklich gut aus. Und das mit MotionBlur scheint etwas normales zu sein in der Noise Reducer Technik. Ich habe nämlich Red Giant Denoiser III ausprobiert (was sehr gut sein soll) und da ist es auch zu sehen. Man sieht es auch nur dann, wenn man das Video langsam abspielt und nicht in der eigentliche Geschwindigkeit.
Man beachte die Parameter:
luma_spatial
A non-negative floating point number which specifies spatial luma strength. It defaults to 4.0.
chroma_spatial
A non-negative floating point number which specifies spatial chroma strength. It defaults to 3.0*luma_spatial/4.0.
luma_tmp
A floating point number which specifies luma temporal strength. It defaults to 6.0*luma_spatial/4.0.
chroma_tmp
A floating point number which specifies chroma temporal strength. It defaults to luma_tmp*chroma_spatial/luma_spatial.
https://ffmpeg.org/ffmpeg-filters.html#hqdn3d-1
Es ist die selbe angewendete Technik wie die beiden Slider/Steuerung in Davinci Resolve.
Vorteil von ffmpeg ist, dass man einfach per #!/bin/bash (Script) z.B. alle in einem Ordner hinterlegten *.mov Dateien hintereinander automatisch denoisen lassen kann. :) Oder einfach eine GUI/Grafischeoberfläche basteln (siehe
https://de.wikipedia.org/wiki/Zenity) mit Dateiauswahl Möglichkeit und passende Einstellungen.
Vapoursynth benutzt auch nur ffmpeg libavcodec usw. Daher vermute ich, dass auch hier die selbe Denoise Technik verwendet wird.
Antwort von mash_gh4:
ich galube, da bringst du einiges ein bisschen durcheinander.
roki100 hat geschrieben:
also mit ffmpeg sieht es wirklich gut aus. Und das mit MotionBlur scheint etwas normales zu sein in der Noise Reducer Technik.
ffmpegs hqdn3d ist für alltägliche anwendungen durchaus brauchbar. viel besser machen das jedenfalls die meisten kameras auch nicht. man kann es allerdings schon sauberer lösen, wenn man eben auch motion compensation einbezieht. damit wird es wesentlich komplizierter, aber dafür zeigen sich die genannten begleiterscheinungen nicht mehr in dieser weise.
roki100 hat geschrieben:
Ich habe nämlich Red Giant Denoiser III ausprobiert (was sehr gut sein soll) und da ist es auch zu sehen. Man sieht es auch nur dann, wenn man das Video langsam abspielt und nicht in der eigentliche Geschwindigkeit.
ja -- das problem gibt's leider immer, dass sich oft auch in teuer kommerzsoftware relativ unbefriedigende einfache lösungen verstecken. in der hinsicht profitiert man im freien umfeld oft schneller davon, dass irgendwelche akademischen forschungen und verbesserungsbemühungen einbezogen werden können.
roki100 hat geschrieben:
Man beachte die Parameter:
luma_spatial
...
chroma_spatial
...
Es ist die selbe angewendete Technik wie die beiden Slider/Steuerung in Davinci Resolve.
nur weil die ganz elementaren einstellungsparameter bei den meisten denoisern ähnlich wirken, sagt das noch lange nichts über deren tatsächliche interne umsetzung aus. gut, man kann daraus evtl. erschließen, dass eine lösung bspw. auch die temporale ebene mitberücksichtigt, was ja schon einen deutlichen unterschied ausmacht, aber wie gut sie das dann tatsächlich umsetzt, also z.b. im hinblick auf die bewegungskompensation, kann man aus diesem indkator noch lange nicht erschließen. da gibt's schon riesige unterschiede in der komplexität der verwendeten techniken.
roki100 hat geschrieben:
Vorteil von ffmpeg ist, dass man einfach per #!/bin/bash (Script) z.B. alle in einem Ordner hinterlegten *.mov Dateien hintereinander automatisch denoisen lassen kann. :) Oder einfach eine GUI/Grafischeoberfläche basteln (siehe https://de.wikipedia.org/wiki/Zenity) mit Dateiauswahl Möglichkeit und passende Einstellungen.
ja, genau diese vorteile schätze ich daran natürlich auch, nur würde ich sie gerade im zusammenhang mit diesem feature nicht überbewerten. der grund dafür liegt darin, dass man in der praxis die optimalen rauschunterdrückungseinstellungen leider fast für jeden shot individuell herausfinden muss, wenn man gute qualität erzielen will.
generell sollte man beim denoisen von fertig gebackenem video material aber möglichst zurückhaltend sein bzw. nur im ausnahmefall als notlösung darauf zurückgreifen. (!)
das ist im falle vom resolve und der bearbeitung von RAW material etwas völlig anderes. dort muss man es ja quasi fast zwingend für jede aufnahme im zuge des entwicklungsprozesses durchführen, aber bei gewöhnlichem material sollte das eigentlich bereits die kamera erledigt haben.
es macht leider auch einen ziemlichen unterschied, in welchem farbraum das denoisen vorgenommen wird. in der einfachen form, wie es das ffmpeg macht, können daher leider auch die farben bzw. die zeichnung der konturen stark darunter leiden, weil ein einfaches mischen von farbigen pixeln bspw. im rec.709 bezugsraum ganz ungute nebeneffekte mit sich bringt.
roki100 hat geschrieben:
Vapoursynth benutzt auch nur ffmpeg libavcodec usw. Daher vermute ich, dass auch hier die selbe Denoise Technik verwendet wird.
vapoursynth verwendet ffmpeg hauptsächlich für die ein- und ausgabe der daten, aber die verabeitung selbst geschieht durchwegs in unabhängigen modulen, die mit ffmpeg überhaupt nichts zu tun haben. am ehesten würde ich noch dahingehend ähnlichkeiten sehen, dass das meiste davon sich auch an broadcast verarbeitungskonventionen orientiert, die heute in viele punkten als technisch überholt gelten -- also z.b. in hinblick auf einen befriedigenden umsetzung von farbeingriffen...
Antwort von roki100:
Danke für die viele Informationen!
Übrigens, es gibt noch "Handbrake" (leider only mp4 und mkv )
https://handbrake.fr/downloads.php mit einem sehr guten Denoiser Namens "NLMeans" :)
Antwort von cantsin:
Handbrake ist ein (vereinfachtes) grafisches Interface für ffmpeg...
Antwort von mash_gh4:
dieser "non-local means" denoiser stammt wieder aus dem ffmpeg.
siehe:
https://dirk-farin.net/projects/nlmeans/index.html
derartige denoiser, die sich nur auf die spatiale ebene beschränken, sind jenen techniken, die eben auch die temprale information bzw. zusätzliche anhalspunkte einbeziehen, fast immer unterlegen.
