Interessant! Also behandelt FFTDFilter die U/V Kanäle anders als den Y Kanal? Aber warum? Oder ist es nur die Tatsache dass die U/V Kanäle in YV12 eine geringere Auflösung haben und man dadurch die gleiche Denoising-Stärke auf eine kleine Fläche anwendet und somit ungewollt stärker filtert? Allerdings würde das mit dem 2x Upsize dann die gleichen Ergebnisse wie die RGB -> 3x YV12 Wandlung ergeben... Hmm, ich glaub ich schreib mal ne PM an Fizick!
Als mir das mit dem Farbrauschen aufgefallen ist, habe ich FFT3DFilter mal alle Kanäle entrauschen lassen. Ich habe hierzu – den Verlust von Chrominanzinformationen in Kauf nehmend – einfach in den YV12-Farbraum konvertieren lassen. Dabei habe ich festgestellt, dass FFT3DFilter sehr wohl auch Farbrauschen entfernen kann. 
Das Problem ist doch, dass ich mit RGBHack nur einen „Helligkeitskanal“ serviert bekomme. Ich kann also immer nur die „Helligkeit“ filtern. Es sei denn, ich kopiere diesen Y-Kanal in den U- bzw. V-Kanal, was ja auch möglich ist. FFT3DFilter würde dann aber ein und dieselbe „Pixelmenge“ unter Umständen zwei- oder dreimal bearbeiten. Der R-Kanal würde unter Umständen als Y-Kanal, dann als U- und anschließend als V-Kanal behandelt werden. Ob das gut geht? Wie auch immer, mit einer "verlustfreien Umwandlung" in den YUV-Farbraum fühle ich mich einfach wohler.
Beim Spielen mit der Funktion YToUV bin ich dann auf die Idee mit dem Vergrößern und dem generellen Verzicht auf RGBHack gekommen. Abgesehen von Rundungsfehlern, haben wir es hier mit dem korrekten YUV-Farbraum zu tun.
P.S.: Ich habe die Scripte zum Entrauschen etwas vereinfacht. So findet z. B. eine Limitierung, sofern gewünscht, jetzt nur noch für den Y-Kanal statt. Mit den Parametern bw und bh (FFT3DFilter und FFT3dGPU) wird die Blockgröße gleich für alle Kanäle bestimmt. Die Parameterliste für FFT3DFilter und FFT3dGPU sieht wie folgt aus:
sigma_y = 2.0
sigma_u = 0.0
sigma_v = 0.0
bw = 32
bh = 32
limit = 0
strength = 0Das dürften die Parameter sein, die am häufigsten benötigt werden.
