Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add pre-processing denoising #2931

Draft
wants to merge 13 commits into
base: master
Choose a base branch
from
Draft

Conversation

shssoichiro
Copy link
Collaborator

@shssoichiro shssoichiro commented May 2, 2022

This changeset adds a --denoise CLI 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-noise setting if --photon-noise is enabled. --denoise can 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-noise and --photon-noise-table args 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.

@shssoichiro shssoichiro force-pushed the denoising branch 4 times, most recently from a22fb64 to 03effba Compare May 4, 2022 17:42
@shssoichiro shssoichiro force-pushed the denoising branch 2 times, most recently from 5981bed to 23e4347 Compare May 15, 2022 22:34
@shssoichiro shssoichiro marked this pull request as ready for review May 15, 2022 22:34
@coveralls
Copy link
Collaborator

coveralls commented May 15, 2022

Coverage Status

Coverage decreased (-3.6%) to 81.947% when pulling a65797a on shssoichiro:denoising into d8ebb60 on xiph:master.

@shssoichiro shssoichiro force-pushed the denoising branch 2 times, most recently from d090077 to a65797a Compare May 19, 2022 18:33
src/denoise.rs Outdated
@@ -0,0 +1,587 @@
use crate::api::FrameQueue;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: License file is missing.

Add pre-processing denoising

Align denoising arrays

Autovectorization pass
@codecov-commenter
Copy link

codecov-commenter commented Sep 5, 2022

Codecov Report

Base: 86.44% // Head: 85.22% // Decreases project coverage by -1.22% ⚠️

Coverage data is based on head (021bfab) compared to base (d56fe64).
Patch coverage: 1.98% of modified lines in pull request are covered.

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     
Impacted Files Coverage Δ
src/denoise.rs 0.00% <0.00%> (ø)
src/lib.rs 41.93% <ø> (ø)
src/util/align.rs 87.67% <0.00%> (-7.86%) ⬇️
src/api/internal.rs 96.08% <17.39%> (-1.39%) ⬇️
src/bin/common.rs 53.56% <23.07%> (-0.94%) ⬇️
src/api/config/encoder.rs 89.30% <100.00%> (+0.05%) ⬆️
src/api/test.rs 99.23% <100.00%> (+<0.01%) ⬆️
src/me.rs 95.20% <0.00%> (-0.40%) ⬇️
src/encoder.rs 87.09% <0.00%> (-0.04%) ⬇️
src/rdo.rs 85.74% <0.00%> (+0.04%) ⬆️
... and 4 more

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.
📢 Do you have feedback about the report comment? Let us know in this issue.

@barrbrain barrbrain added this to In progress in Release 0.6 via automation Sep 13, 2022
@shssoichiro shssoichiro removed this from In progress in Release 0.6 Sep 13, 2022
@NSQY
Copy link

NSQY commented Sep 21, 2022

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.

Output 1000 frames in 3.39 seconds (294.74 fps)
vspipe -p dft.vpy -o $x . | 79.68s user | 0.47s system | 2225% cpu | 3.602 total
max memory:                425 MB
page faults from disk:     6
other page faults:         101695
Output 1000 frames in 1.52 seconds (658.97 fps)
vspipe -p dft.vpy -o $x . | 35.31s user | 0.44s system | 2074% cpu | 1.723 total
max memory:                508 MB
page faults from disk:     17
other page faults:         108478

@shssoichiro
Copy link
Collaborator Author

shssoichiro commented Sep 21, 2022

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));
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this missing squaring the real part?

Copy link
Collaborator Author

@shssoichiro shssoichiro Sep 21, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@shssoichiro shssoichiro marked this pull request as draft September 22, 2022 03:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants