4K UHD Denoising mit FFT3DGPU,FFT3DFilter,neo_fft3d (Performance,Bugs,VapourSynth-Umsetzung,...)

  • Okay, das war zu erwarten, da sich die Arbeitsweise der Bibliothek ja nicht ändert, wenn sie von Vapoursynth anstatt Avisynth aufgerufen wird.

    Cu Selur

    Das merkwürdige ist, dass die Fehler bei 4K Material bei mir im mode 2 unabhängig von der verwendeten precision auftreten, wenn man bw/bh < 64 einstellt.

    Sonst scheint es da in allen modes so so zu sein, dass wenn man bw/bh erhöht man irgendwann auch die precision erhöhen muss (also 32 bit floats statt 16 bit floats verwendet) um Bildfehler zu vermeiden.

    Kommt einem fast so vor, als ob das ein bug ist und intern bei mode 2 mit bw/bh < 64 versehentlich immer precision 0, also nur 16 bit floats verwendet werden.

    Kann das was ich hier niedergeschrieben habe eigentlich jemand reproduzieren? Vielleicht interessiert das ja pinterf?

  • Besonders das Problem mit mode 2 und bw/bh < 64 meinte ich (das schlägt nämlich aus der Reihe)

    Das wäre nur ein Versuch :)

    EDIT: Sorry, weiß gerade nicht, wo ich das sonst posten soll...

  • Vielleicht ist es ja wirklich nur so, dass Rundungsfehler die wegen 16 bit floats auftreten zu diesen seltsamen Bildfehlern führen, dann besteht vielleicht Hoffnung, dass er es fixed. Jedenfalls hoffe ich das irgendwie.

    Wenn du in dem Video, dass bei dir black frames mit Gittermuster ausgegeben hat, weiter nach vorne spulst, wirst du möglicherweise feststellen, dass nach wenigen Bildern das Bild nicht mehr komplett schwarz mit diesen Mustern ist, sondern dass sich die Muster dann durchs normale Video ziehen.

    Jedenfalls war das bei mir so, dass das nur in den ersten paar dunklen frames so war.

  • Ich hatte BlankClip verwendet :) Der ist immer schwarz, zeigt aber einfach, dass es ein Problem unabhängig von der Quelle ist.

    Rundungsfehler glaub ich auch nicht, sieht eher aus als ob da die Blockstruktur nicht passt und da irgendwo ein Überlauf passiert.

    Vermute Assmblercodefehler oder etwas in die Richtung.

  • Okay, wenn man FFT3DGPU mit 10+bit Material füttert wird intern immter 32bit verwendet und precision macht dann nix mehr.

    -> Werde in der nächsten Hybrid version wohl erstmal precision=0 rauswerfen oder die precision hoch setzen wenn with > 1920 oder height > 1080.

    Cu Selur

    Ps.: pinterf steckt auf jeden Fall einiges seiner Freizeit in die Suche nach der Ursache des FFT3DGPU Problems.

  • Nebenbei: Mal drüber nach gedacht KNLMeansCL anstatt FFT3D... zu nutzen

    Hab ich schon das ein oder andere Mal ausprobiert. Kommt aber für mich bzw. den Verwendungszweck den ich hauptsächlich mit Rauschfiltern verfolge nicht an FFT3DGPU ran.

    Ich versuche in erster Linie mit möglichst viel Leistung/Watt zu encoden und dabei 10-35% Bitrate einzusparen ohne dabei das Bildmaterial signifikant zu verhunzen / weichzuzeichnen.

    Das gelingt imho mit temporal Denoising ziemlich gut, besonders wenn man es z.B. mit X264 10bit kombiniert, da dadurch das Risiko von Banding, welches dabei entstehen könnte, massiv sinkt.

    3-4 Frames einzubeziehen bringt (jedenfalls bei fft3dgpu) einen guten Vorteil bei der Komprimierbarkeit, ohne bei Sigma-Werten so zwischen 1.2 und 1.8 je das Material signifikant entstellt zu haben.

    Wenn man mehr Wert auf "Original Look" legt, sind 4 Frames imho empfehlenswerter, ich nehme meistens 3 frames wegen der besseren Komprimierbarkeit + Performance und senke Sigma, je nach Material, wie oben erwähnt meist etwas unter 2.0 ab.

    Um (zumindest beim allermeisten Bildmaterial) ähnliche Bitrateneinsparungen bei vergleichbarer Qualität mit x264 veryslow o.ä. zu erreichen muss ich ein vielfaches an Rechenzeit inverstieren, mit x265 bestenfalls die 1,5fache Zeit.

    -> Das ist alles nicht gerade effizient und passt irgendwie nicht mehr in die Zeit.

    FFT3DGPU kostet mich in den meisten Szenarien 1-5% Rechenzeit und erhöht den Gesamtverbrauch meines Systems um maximal 10% bzw. etwa 30W.

    Old but gold, man merkt halt, dass es mal für deutlich lahmere Karten entwickelt wurde, als heute üblich sind :)

    KNLMeansCL bringt meine 75W Grafikkarte (irgendwann war die auch mal die damals modernste GPU Generation, aber davon halt eine der low power/ low budget Karten :) ) schon bei FHD/1080p ans Limit und bremst, wenn ich da distance von 0 auf 1 erhöhe und damit mehr als 1 Frame (genauer 3 frames), also temporal filtere.

    Um damit Einsparungen in der Größenordung von 25-30% zu erreichen musste ich die strength auf etwa das vierfache des defaults von 1,2 erhöhen und dann sah das Material an detailreichen Stellen stellenweise schon gut gesmoothed um nicht zu sagen vermatscht aus (Haare usw.)

    Kannst ja mal fft3dgpu Sigma 2.0 mit 3 frames mit KNLMeansCL 4.8 mit 3 frames vergleichen.

    Da gefällt mir das Ergebnis von fft3dgpu besser.

    Für Einsparungen bis 10% ohne großartige Qualitätseinbußen scheint mir auch FluxSmooth eine guter und flotter temporal denoiser zu sein. Bremst auch nur so um die 5%, und das ganz ohne GPU Einsatz.

    Sorry, ist was länger geworden, da lag mir wohl was auf der Seele ;)

  • Habe fft3d direkt lange nicht mehr benutzt, aber ich erinnere mich dass es gerne mal Banding erzeugt hat. Mein Favorit ist immer noch SMDegrain. Auch flott, stabilisiert / entfernt das Rauschen ohne alles Platt zu machen.

  • Habe fft3d direkt lange nicht mehr benutzt, aber ich erinnere mich dass es gerne mal Banding erzeugt hat. Mein Favorit ist immer noch SMDegrain. Auch flott, stabilisiert / entfernt das Rauschen ohne alles Platt zu machen.

    Kann sein, dass SMDegrain im Vergleich zu fft3dfilter vom Speed her mithält oder sogar etwas schneller ist.

    Hab's gerade mal wieder kurz angetestet mit 4K 10bit yuv420 60fps video und 10 bit output in X264.

    Ich gebe zu, ich hab mich nicht mit den ganzen Optionen auseinandergesetzt, hab's erst mit default angetestet, da war mir die erzeugte Bitrate wegen subPixel 2: (sharper Wiener (6 tap, similar to Lanczos) zu hoch. Dann habe ich subPixel 1: bicubic (4 tap Catmull-Rom) genommen, da mir das als Mittelding (nicht zu scharf, nicht zu stark weichzeichnend) dargestellt wird.

    Da kam dann etwa die Bitrate raus, die ich mit FFT3DGPU(sigma=1.00,bw=64,bh=64,plane=4,mode=2,bordersize=1,precision=1) erreicht habe. bw+bh < 64 ist bei 4K buggy, mit 32 wäre es vermutlich sogar noch etwas schneller. Mode 2 finde ich empfehlenswerter und effizienter als mode 1 - erzeugt ebenfalls weniger Artefakte als der etwas schnellere mode 0.

    Mit Sigma 1.0 (default ist 2.0) habe ich beim 3,5x Speed dieselbe Bitrate erreicht.

    Mit so einem extrem niedrigen Sigma Wert ist mir selbst bei 8bit Output noch nie sowas wie Banding aufgefallen.

    Einmal editiert, zuletzt von mogobime (20. Mai 2022 um 23:08)

  • Ich bin da bei fft3dgpu und YUV444P10 input auf was gestoßen, was den ein oder anderen interessieren könnte, da es einen ziemlichen Unterschied in der Performance macht, aber so gut wie nichts bringt. Es scheint nämlich mit dem YUV444 Sampling nicht besonders schnell umgehen zu können.

    Hab YUV444P10 an fft3dgpu gefüttert, und wollte nur im normal üblichen Farbraum als YUV420P10 ausgeben.

    Also ein ConvertToYUV420() Aufruf nach dem fft3dgpu(...) Aufruf (ich filtere mit fft3dgpu(plane=4,...) chroma immer mit, bringt weitere Vorteile bei der Komprimierbarkeit). So macht es beispielsweise auch Hybrid.

    Am Ende stehen immer die Benchmark-Werte, das vorangestellte x1 x2 x3 usw. sind die verwendeten avisynth threads bzw. die prefetch(x) Einstellung am Ende:

  • Dann hab ich ConvertToYUV420() vor den fft3dgpu(...) Aufruf verschoben (Für Benchmark Werte wie gesagt ganz runter scrollen):

    -> ConvertToYUV420() vor fft3dgpu(...) war 37,5% schneller bei den jeweiligen Bestwerten!

  • Dann wollte ich noch wissen ob es großartige Unterschiede bei den erzeugten files gibt und habe sie mit ffmpeg direkt miteinander verglichen (PSNR + SSIM ermittelt).

    SSIM:

    -> 0.99x durchgängig sowohl bei Y als auch bei UV sieht nur nach minimalsten Unterschieden aus.

    PSNR:

    -> Auch hier durchgängig niedrige einstellige Werte.

    Komplette files im Anhang, war zu groß um es als Text zu posten...

  • Hab das zusätzlich noch durch avsmeter64 gejagt, und da sind die Unterschiede noch viel deutlicher:

    x1 FFT3DGPU(sigma=2.00,bw=64,bh=64,bt=3,plane=4,mode=2,bordersize=1,precision=1)-ConvertToYUV420 - lsmash - avs2yuv - 4K YUV444P10 in YUV420P10 out 0-7T +1F.avs (ConvertToYUV420 nach FFT3DGPU):


    x1 ConvertToYUV420-FFT3DGPU(sigma=2.00,bw=64,bh=64,bt=3,plane=4,mode=2,bordersize=1,precision=1) - lsmash - avs2yuv - 4K YUV444P10 in YUV420P10 out 0-7T +1F.avs (ConvertToYUV420 vor FFT3DGPU):

    -> 82% schneller, da hat wohl beim encoding mit X264 meine überlastete CPU gebremst!

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!