Beiträge von mogobime

H.266? Ich bin echt in der Zeit stehen geblieben

Hab schon h.265 nicht die Beachtung geschenkt, die es vielleicht verdient hätte, weil ich einfach schon zu viele total weichgezeichnete Videos damit gesehen habe. Viele Leute glauben wohl den Mythos, dass man damit mit der halben Bitrate von h.264 arbeiten kann.

Was in meinen Augen, jedenfalls auf einen aktuellen x264 encoder bezogen, weit von der Wahrheit entfernt ist.

Auf jeden Fall wenn man z.B. mit 10 Bit x264 mit aktivierter "Automatic Adaptive Quantization" (-aq-mode 2) vergleicht. Keine Ahnung warum dieser aq-mode nie zur Standardeinstellung gemacht wurde. Im 10 Bit Betrieb kann mann dann auf jeden Fall -aq-strength gut absenken, ohne dass Probleme wie Banding entstehen und ordentlich Bitrate einsparen.

Möchte da mal das h.265 Video sehen, dass bei der halben Bitrate vergleichbare Qualität liefert. Sieht bestimmt aus wie das x264 h.264 video mit Blur Filter.

Aber jetzt wird's zu sehr OT

Klar...

Mein ja nur, wenn man eh nach 420 encodet und hat warum auch immer ein 444 file vorliegen, dann scheint das für normale Augen keinerlei Unterschied zu machen, wenn man im Skript gleich als erstes das sampling auf 420 runterskaliert.

Sonst werden folgende Filter u.U. bis zum Faktor 2 runtergebremst. Das dann bewußt in Kauf zu nehmen ist wohl eher was für Gourmets, oder irgendwelche ganz speziellen Skripte, die im Verlauf irgendwo irgendwie ganz speziell die Chroma Informationen separat verwursten.

Ich als Otto-normal Avisynthler kenn da keinen Anwendungsfall, aber es gibt ihn bestimmt...

Deswegen kann man entsprechenden 444/422 Input auch auf 420 downsampeln, und das am Besten in einem AviSynth Skript gleich als allerestes, im Falle von 444 spart das immens Rechenleistung...

Jedenfalls ist es (außer vielleicht in irgendwelchen ganz speziellen Fällen, wo man irgendwas einzeln mit dem Chroma machen will) ziemlich unsinnig das erst am Ende des Skripts zu machen und desewegen bei 444 schlimmstenfalls die doppelte Rechenzeit in Anspruch zu nehmen.

OT: Putin hasst das...

Nachtrag zum YUV422 Vergleich:

Hab bei den 3 Filtern noch SSIM und vor allem die Netflix Qualitätsmetrik VMAF ergänzt, die KI basiert arbeitet um die menschliche Wahrnehmung möglichst gut abzubilden.

Um es kurz zu machen: Die files bei denen die Farbraumkonvertierung vor dem Filteraufruf durchgeführt wurden Unterscheiden sich auch hier praktisch nicht. VMAF score liegt jedesmal über 99 (100 ist max).

So hohe Werte werden z.B. in der Praxis bei einem Vergleich Quelle -> encodetes file praktisch nie erreicht. Auch der SSIM liegt immer bei 0.99x.

Zip-Files hab ich durch neue mit den Logfiles und Werten für jedes einzelne Frame ersetzt

Fazit für YUV422

Gleich vorneweg nochmal: Alle Messungen wurden, wie zuvor auch, per Skript mind. 2-3x durchgeführt und nur das beste Messergebis gespeichert um Zufallsschwankungen durch startende Hintergrundprozesse etc. möglichst auszuschließen bzw. zu reduzieren.

Hier sieht es doch so aus, als ob nicht nur das Multithreading bei neo_fft3d verbessert wurde.

CPU Auslastung war bei neo zwar 5-8% höher, aber neo_fft3d war bei bei

X264 bis zu 40,5% (regular) / 36% (early yuv420 conversion) schneller als das normale FFT3DFilter und bei AVSMeter bis zu 31,2% (regular) / 41,8% (early yuv420 conversion).

FFT3DGPU setzt sich hier logischerweise noch weiter von FFT3DFilter ab:

X264 213% (regular) / 193% (early yuv420 conversion) und AVSMeter 88,2% (regular) / 77,3% (early yuv420 conversion).

Bei X264 muss man bedenken, dass bei FFT3DGPU und x264 preset superfast die CPU zu nur etwa 15% ausgelastet war.

Bei einem im realen Einsatz verwendeten preset fast oder medium müssten die Unterschiede noch gravierender sein, da dürften sich neo_fft3d + fft3dfilter nochmal knapp halbieren, während FFT3DGPU nur 10-25% langsamer werden sollte. Also selbst mit dieser älteren Budget GPU vermutlich real world Zugewinne um bis zum Dreifachen durch FFT3DGPU, da über 90% der Rechenkapazität fürs encoding freibleiben.

Für YUV422 input bei FFT3DFilter + neo_fft3d gilt: Sie kommen damit noch schlechter klar als FFT3DGPU, und der Geschwindigkeitsvorteil durch "early yuv420 conversion" bringt (im Fall von neo_fft3d) sogar fast doppelt so viel Geschwindigkeitszuwachs wie bei FFT3DGPU!

Hier sollte man erst Recht darüber nachdenken, den ConverToYUV420 call vorzuziehen, wenn man das chroma subsampling aufs übliche YUV420 ändert.

cut_TGM_TLR-C_3840x1608_HEVC_YUV422_10bit.mkv - 4K, 10 bit, YUV422 mit FFT3DFilter

FFT3DFilter(bw=64,bh=64,plane=4,interlaced=false)-prefetch(X)-ConvertToYUV420 [cut_TGM_TLR-C_3840x1608_HEVC_YUV422_10bit.mkv].log:

Bestwert 3.68 fps

ConvertToYUV420-prefetch(X)-FFT3DFilter(bw=64,bh=64,plane=4,interlaced=false) [cut_TGM_TLR-C_3840x1608_HEVC_YUV422_10bit.mkv].log:

Bestwert 4.61 fps

-> X264 25,3% schneller mit ConvertToYUV420() for Filteraufruf.

6 FFT3DFilter(bw=64,bh=64,plane=4,interlaced=false)-prefetch(X)-ConvertToYUV420 [cut_TGM_TLR-C_3840x1608_HEVC_YUV422_10bit.mkv].log (AVSMeter64):

6 ConvertToYUV420-prefetch(X)-FFT3DFilter(bw=64,bh=64,plane=4,interlaced=false) [cut_TGM_TLR-C_3840x1608_HEVC_YUV422_10bit.mkv].log (AvsMeter64):

-> Avsmeter64 25,8% schneller mit ConvertToYUV420() vor Filteraufruf!

Qualitätsmetriken - direkter Vergleich der beiden output clips miteinander:

Bei neo_fft3d waren die Geschwindigkeitsunterschiede bei exakt gleichem Setup sogar noch deutlicher.

cut_TGM_TLR-C_3840x1608_HEVC_YUV422_10bit.mkv - 4K, 10 bit, YUV422 mit neo_fft3d

neo_fft3d(bw=64,bh=64,y=3,u=3,v=3,interlaced=false)-prefetch(X)-ConvertToYUV420 [cut_TGM_TLR-C_3840x1608_HEVC_YUV422_10bit.mkv].log:

Bestwert 5.17 fps

ConvertToYUV420-prefetch(X)-neo_fft3d(bw=64,bh=64,y=3,u=3,v=3,interlaced=false) [cut_TGM_TLR-C_3840x1608_HEVC_YUV422_10bit.mkv].log:

Bestwert 6.27 fps

-> X264 21,3% schneller mit ConvertToYUV420() for Filteraufruf.

6 neo_fft3d(bw=64,bh=64,y=3,u=3,v=3,interlaced=false)-prefetch(X)-ConvertToYUV420 [cut_TGM_TLR-C_3840x1608_HEVC_YUV422_10bit.mkv].log (AVSMeter):

6 ConvertToYUV420-prefetch(X)-neo_fft3d(bw=64,bh=64,y=3,u=3,v=3,interlaced=false) [cut_TGM_TLR-C_3840x1608_HEVC_YUV422_10bit.mkv].log (AvsMeter):

-> Avsmeter64 35,8% schneller mit ConvertToYUV420() vor Filteraufruf!

Qualitätsmetriken - Beide output clips direkt miteinander verglichen:

Btw - obwohl FFT3DGPU bei 4K 10 Bit YUV422 content bereits meiner RX 560 Budget GPU mit 4 GB die Grenzen aufzeigt und sie mit knapp 80% auslastet, ist es immer noch 25,1% schneller. Stromverbrauch geht dabei, wie schonmal erwähnt um max 10% oder 30W hoch, in dem Fall ist er sogar niedriger, da die CPU sich die meiste Zeit langweilt

Und neofft3d lastet hier die CPU bereits mit rund 90% aus, da ist also für nen codec nicht viel Rechenkapazität übrig...

Zitat von Selur

Yes, if you feed FFT3DGPU with a color space which holds less data to filter it is faster.

Antworte mal auf deutsch, sonst brauch ich hier noch länger um was "zu Papier" zu bringen

Am deutlichsten ist's wohl beim YUV444 Farbraum, aber auch hier bei YUV422.

Am Ende der x264 logfiles sind diesmal jeweils per ffmpeg die Unterschiede im SSIM/PSNR zwischen dem unveränderten input video und dem output Video ermittelt (keine Werte von x264, welches den Unterschied zwischen gefiltertem input und dem output video wiedergeben würde).

Man muss bedenken, dass ich hier mit CRF 10 gearbeitet habe, d.h. schon das sind Werte, die wohl die meisten als "nahe losless" bezeichnen würden.

Die Werte, wenn das akuratere setting mit ConvertToYUV420() erst am Ende verwendet wurde, Vergleich input mit output:

Die Werte beim Vergleich output FFT3DGPU-ConvertToYUV420 mit output ConvertToYUV420()-FFT3DGPU:

-> PSNR + SSIM sind bei logarithmischer Skala im UV Bereich trotz der vorgezogenen Farbraumkonvertierung fast doppelt so hoch wie zwischen Original und einem "regulär" mit CRF 10 enkodierten Video, nur um mal einen Maßstab zu haben um was für mickrige Unterschiede es da geht!

cut_TGM_TLR-C_3840x1608_HEVC_YUV422_10bit.mkv - 4K, 10 bit, YUV422 mit FFT3DGPU

FFT3DGPU(bw=64,bh=64,degrid=1.00,plane=4,mode=2,bordersize=1,precision=2)-prefetch(1,X+1)-ConvertToYUV420() [cut_TGM_TLR-C_3840x1608_HEVC_YUV422_10bit.mkv].log:

Bestwert: 7.84 fps

ConvertToYUV420-prefetch(X)-FFT3DGPU(bw=64,bh=64,degrid=1.00,plane=4,mode=2,bordersize=1,precision=2)-PreFetch(1,X+1) [cut_TGM_TLR-C_3840x1608_HEVC_YUV422_10bit.mkv].log:

Bestwert: 8.92 fps

-> X264 13,8% schneller mit ConvertToYUV420() for Filteraufruf.

6 FFT3DGPU(bw=64,bh=64,degrid=1.00,plane=4,mode=2,bordersize=1,precision=2)-prefetch(1,X+1)-ConvertToYUV420 [cut_TGM_TLR-C_3840x1608_HEVC_YUV422_10bit.mkv].log (AvsMeter64):

6 ConvertToYUV420-prefetch(X)-FFT3DGPU(bw=64,bh=64,degrid=1.00,plane=4,mode=2,bordersize=1,precision=2)-PreFetch(1,X+1) [cut_TGM_TLR-C_3840x1608_HEVC_YUV422_10bit.mkv].log (AvsMeter64):

-> Avsmeter64 18,4% schneller mit ConvertToYUV420 vor Filteraufruf.

Qualitätsmetriken - direkter Vergleich der beiden output clips miteinander:

-> Auch hier für Normalnutzer vernachlässigbare marginale Unterschiede zwischen den beiden output videos.

Hab noch was zu fft3dgpu in Hybrid. Ein paar Optionen sind in Hybrid nicht umgesetzt, aber die ein oder andere ist vielleicht doch nützlich:

Zitat

float degrid = 1.0

Enables degriding. Only works well with mode=1. Doesn't degrid the Kalman filter (but it does degrid the sharpening (if enabled) after kalman filter). default 1.0 for mode=1, 0.0 for mode=0 or 2.

float scutoff = 0.3

Sharpening cutoff frequency, relative to max.

float svr = 1.0

Sharpening (and dehalo) vertical ratio (to horizontal) (default=1.0 - same as horizontal, 0 - no vertical sharpening)

float smin = 4.0

float smax = 20.0

Minimum and maximum limit (approximate noise margin) for sharpening stage.

float kratio = 2.0

Ratio of threshold to sigma to reset Kalman filter. Variation threshold = sigma*kratio, good value is about from 1.5 to 3.0

int ow = bw/2

int oh = bh/2

Overlap width and height. This only works with mode=1. This specifies how big the overlap between the blocks are. Overlap size must be less than or equal to half the blocksize. ow must be even.

int wintype = 0

weighting windows type:

• 0 : same analysis and synthesis half-cosine window, used in all versions before 1.4.
• 1 : intermediate between 0 and 2
• 2 : flat analysis window, rised cosine (Hanning) synthesis window.

Alles anzeigen

Vielleicht bekommt man mit degrid den ein oder anderen Gitterartefakt, der bei manchen Auflösungen, bestimmten bw Größen und beim Erhöhen von bordersize im mode 2 auftritt, damit in den Griff...

Und was ich auch erst jetzt bemerkt habe, ist dass negative Werte beim Sharpening ein Smoothing bewirken. Damit sind auch die ganzen sharpening Feintuning Einstellungen scutoff, smin und smax (den Schreibfehler ausm AviSynth Wiki hab ich gleich mal oben entfernt, da steht 2x smin...) interessant. Sharpening bzw. Smoothing auf bestimmte Bereiche zu begrenzen hört sich auch gut an, da es sich auch eher nur um einen leichten Effekt handelt, kann man den möglicherweise durch Anheben des smin Wertes oder ändern der scutoff Frequenz noch etwas verstärken/verändern.

Kann ja auch durch setzen von bw=-1 unabhängig vom denoising verwendet werden, und schon hat man einen GPU basierten sharpener/smoother.

Wintype verstehe ich zwar nicht wirklich, aber möglicherweise beeinflusst das die Arbeitsweise und auch Performance des Filters?!?

Auch noch Wert drüber nachzudenken:

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

4K content mit fft3dgpu im mode 2 nur Y zu filtern scheint tatsächlich eine Alternative zu sein (bei meiner mittlerweile etwas schwachbrüstigen GPU). Den üblichen, selbst nervig auffälligen noise bekommt man trotzdem gut reduziert. Wenn man dann noch den Codec-internen noise filter mit z.B. nur 1000 mitlaufen lässt, passt auch die Komprimierbarkeit. Chroma noise reduction bei 4K werde ich mir (außer für Testzwecke) denke ich künftig schenken, wenn's nicht gerade explizit in der Hinsicht stark verhunztes Material mit irgendwelchem stark auffälligem Farbflimmern ist.

Selur:

Und hast du mal überlegt bei fft3dgpu die Konvertierung ins Zielfarbformat per default for den Filteraufruf zu setzen?

Kann ja heute Abend mal noch testen wie's bei YUV422 aussieht. RGB content hab ich leider keinen.

Ich finde potentiell bis zu 82% mehr Speed sind ein Effizienzgewinn, der nicht ignoriert werden sollte, wenn da am Ende praktisch identischer content rauskommt und gerade im UV Bereich der SSIM fast durchgängig bei 0.999x liegt. Bei PSNR + MSE sieht's ähnlich aus, selbst einzelne Ausschläge bewegen sich in einem bei 10 Bit content völlig unbedenklichen Bereich. Würde fast wetten, dass crf 16 statt crf 19 bei x264 die Unterschied noch weiter marginalisiert (und das ist es ja, was ein Adlerauge vermutlich verwenden würde).

Für den einen User, der's unbedingt braucht heutzutage so viel zusätzliche Rechenzeit zu verplempern um einen nicht sichtbaren Unterschied im Output zu haben, könnte man diese Avisynth TuneUp Einstellung ja umkehrbar machen. aber vermutlich existiert dieser User ohnehin nicht, denn der würde vermutlich gar keinen noise filter verwenden

Werde bei Gelegenheit auch mal checken wie's sich mit fft3dfilter + neo_fft3d verhält und ob das eher was mit den fft Algorithmen oder mit fft3dgpu im speziellen zu tun hat.

Zitat von Selur

Nebenbei: Mal überlegt anstatt AviSynth&Co zu nutzen mal eher die Noisereduction in x264&x265 zu verwenden?

Zumindest wenn es vor allem um erhöhte Komprimierbarkeit geht sollte die NoiseReduction nicht schlecht sein.

Ja, kenn ich die Funktion, und es wäre aufgrund der Anmerkung von LigH bezüglich der Erhöhung der Komprimierbarkeit ohne wirkliches Reduzieren des Rauschens eine Idee, das künftig bei Videos mit eher wenig Artefakten zusätzlich mit moderaten Werten zuzuschalten und bei fft3dgpu Sigma etwas abzusenken.

Oder aus Performancegründen (bei 4K, 10Bit & Co) wäre es bei solchen Videos wohl auch einen Versuch Wert nur Y mit fft3dgpu zu filtern, und dann noch den x264 denoiser mit 1000-2500 zuzuschalten.

Allerdings geht es mir nun auch nicht ausschließlich um die Komprimierbarkeit, es dürfen auch gerne hässliche Effekte im Original reduziert werden.

Die Möglichkeit z.B. mit Hybrid "Only Dark" Bereiche an fft3dgpu zu geben, oder in fft3dgpu nur Y oder UV oder bestimmte Frequenzbereiche stärker zu filtern, ist schon nicht schlecht. So kann man sich auf Bereiche konzentrieren, die besonders durch Artefakte auffallen, da mit hohen Sigma Werten filtern und den Rest schonend behandeln.

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!

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...

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!

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:

Zitat von FatFaster

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.

Zitat von Selur

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

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.

Zitat von Selur

hab mal wegen precision=0 in einen Issue angelegt: https://github.com/pinterf/FFT3dGPU/issues/9

Hab die Woche kaum Zeit, am besten meldeste Dich bei github an und machst selber ein oder mehrer issues auf.

Cu Selur

Ich hab mal in dem von dir eröffneten issue ein paar Infos + Screenshots meinerseits hinzugefügt, vielleicht hilft's pinterf ja weiter...