Full-Image Averaging (Favg) denoise

[MasterQuestionable]

͏    Follow-Up: ​https://trac.ffmpeg.org/wiki/denoise#favg

͏    Derived from my recent research on available denoise techniques.
͏    This seems to achieve theoretical best compressibility enhance: though unsure for subjective quality.
͏    .
͏    Some past research seems to prove the applicability:
͏    ​https://www.rationalqm.us/hiq/smoothhiq.html
͏    (sort of ͏"smartblur" derived Local Means?)

͏    The idea should work for audio too.

[MasterQuestionable]

͏    Theoretically the quality couldn't be much worse than weighted NLM. (and likely impossible to be worse than simple frequency clamp after FFT)
͏    But the algorithm seems to have significant speed benefit: potentially even faster than the FFT alone...

[MasterQuestionable]

͏    The filter essentially only needs to handle 1 parameter:
͏    The difference threshold:
͏    |*| Valid range 0 ~ 1
͏    |*| May be expressed in percentage (e.g. 3.125%)
͏    |*| Or fraction (e.g. 8/255, 2,048/65,535)
͏    .
͏    Additional parameters shall just mean the threshold for each component (i.e. RGB, YUV etc.), or channel for audio:
͏    When undefined [1] assume the closest defined parameter. [2]
͏    Excessive parameters shall just be silently ignored. (support for arbitrary component configuration)
[1] "-" may be used instead of empty; for clarity.
͏    .
͏    It might be desirable to prepend a ͏"format" in the filter-chain (e.g. "format=rgb24,..."): to avoid the BGR alike havoc.

͏    Info about the interpreted fraction form should be reported: when the threshold not specified in corresponding fraction; unless the component/sample format is float derived.
͏    Warning should be given when the evaluation leads 0 or 1 (unless explicitly specified as [3]): as they are sort of special case.
[ [3]
͏    "0", "0%", "1", "100%";
͏    "${num}/${denum}", where ${num} = ( ${denum} | 0 ). ]

[ [2]
͏    E.g. "favg=3.125%:-:-:6.25%:::0"
͏    ${ /@[1-3]/ } = 3.125%
͏    ${ /@[4-6]/ } = 6.25%
͏    Rest = 0 ]

[MasterQuestionable]

͏    Some low-effort testing seems to indicate the algorithm being able to give output similar (in some cases identical...) to ͏"nlmeans".

͏    This commit should be a good start point: (as copy)
͏    ​https://trac.ffmpeg.org/ticket/4910#comment:16
͏    .
͏    The algorithm is essentially NLM without the patch matching weighting.
͏    (and optimized to avoid pointless work)

͏    See also: ​https://www.mail-archive.com/search?l=ffmpeg-devel@ffmpeg.org&q=subject:%22nlmeans%22&o=oldest&f=1

͏    [ Quote Clément Bœsch @ CE 2018-05-07 17:24:46 UTC:
​https://www.mail-archive.com/ffmpeg-devel@ffmpeg.org/msg69473.html
͏    ... , the filter badly needs some performance improvements.
͏    Also, any suggestion on how not to make it spend 80% of the time in "nlmeans_slice" welcome. ]
<^>    Never considered to drop the patch matching outright..?