Conversation
shssoichiro
force-pushed
the
denoising
branch
4 times, most recently
from
a22fb64 to
03effba
Compare
shssoichiro
force-pushed
the
denoising
branch
2 times, most recently
from
5981bed to
23e4347
Compare
shssoichiro
force-pushed
the
denoising
branch
2 times, most recently
from
d090077 to
a65797a
Compare
src/denoise.rs
Outdated
| @@ -0,0 +1,587 @@ | |||
| use crate::api::FrameQueue; | |||
There was a problem hiding this comment.
Nit: License file is missing.
Add pre-processing denoising Align denoising arrays Autovectorization pass
shssoichiro
force-pushed
the
denoising
branch
from
a65797a to
eb5b8f8
Compare
Codecov ReportBase: 86.44% // Head: 85.22% // Decreases project coverage by
Additional details and impacted files@@ Coverage Diff @@
## master #2931 +/- ##
==========================================
- Coverage 86.44% 85.22% -1.23%
==========================================
Files 89 90 +1
Lines 34094 34597 +503
==========================================
+ Hits 29473 29485 +12
- Misses 4621 5112 +491
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
|
Have you seen this implementation? https://github.com/AmusementClub/vs-dfttest2 On my 3900X, with AVX2 enabled, it is more than twice as fast as https://github.com/HomeOfVapourSynthEvolution/VapourSynth-DFTTest in a synthetic VS script. |
|
I have, come to think of it, it is an option... Since it seems to roll its own fft code instead of using fftw. The issue with this current PR, and something I want to keep in consideration for future PRs, is that currently rav1e has no dependencies on C libraries with the exception of nasm. To keep it simple to build, we'd prefer to keep it that way. However, the best available library for doing multi-dimensional FFTs in Rust at the moment is 10-20x slower than fftw, which by extension makes this implementation 10-20x slower than the Vapoursynth version of dfttest (which uses fftw). But porting dfttest2 to Rust may be a possibility... 🤔 |
src/denoise.rs
Outdated
| // Applies a generalized wiener filter | ||
| fn filter_coeffs(&self, dftc: &mut [Complex<f32>; COMPLEX_COUNT]) { | ||
| for h in 0..COMPLEX_COUNT { | ||
| let psd = dftc[h].re.mul_add(dftc[h].re, dftc[h].im.powi(2)); |
There was a problem hiding this comment.
Is this missing squaring the real part?
There was a problem hiding this comment.
No, it translates to real * real + im^2. The reason it's done like this is because mul_add is more efficient and accurate for floating point math in places where it can be used.
6 participants
This changeset adds a
--denoiseCLI option which enables denoising prior to encoding. This takes a strength value from 0-50, where 0 disables denoising. The default is 0, or half of the--photon-noisesetting if--photon-noiseis enabled.--denoisecan be set manually and will override the denoise strength chosen by--photon-noise.The denoiser implemented is a FFT-based spatio-temporal denoiser based on the DFTTest plugin from Vapoursynth. This was chosen because it provides a reasonable balance of speed and quality.
This also moves the
--photon-noiseand--photon-noise-tableargs into the stable feature set, as was discussed in #2924.Denoising performance at this time is currently rather slow. Per @tdaede on IRC, we're thinking it makes sense to open this up for merging and improve performance in a followup changeset, given that denoising is not turned on by default.