autodb_dpir: A new autodeblocker tool using DPIR

[LightArrowsEXE]

Issue to keep track of changes I would still like to see. This new feature is available on the autodeblock branch.

Current docstring and parameters:

def autodb_dpir(clip: vs.VideoNode, edgevalue: int = 24,
                strs: Sequence[float] = (30, 50, 75),
                thrs: Sequence[Tuple[float, float, float]] = [(1.5, 2.0, 2.0), (3.0, 4.5, 4.5), (5.5, 7.0, 7.0)],
                matrix: Optional[Matrix] = None,
                cuda: bool = True, device_index: int = 0,
                ) -> vs.VideoNode:
    """
    A rewrite of fvsfunc.AutoDeblock that uses vspdir instead of dfttest to deblock.

    This function checks for differences between a frame and an edgemask with some processing done on it,
    and for differences between the current frame and the next frame.
    For frames where both thresholds are exceeded, it will perform deblocking at a specified strength.
    This will ideally be frames that show big temporal *and* spatial inconsistencies.

    Thresholds and calculations are added to the frameprops to use as reference when setting the thresholds.

    Keep in mind that vsdpir is not perfect; it may cause weird, black dots to appear sometimes.
    If that happens, you can perform a denoise on the original clip (maybe even using vsdpir's denoising mode)
    and grab the brightest pixels from your two clips. That should return a perfectly fine clip.

    Thanks Vardë, louis, setsugen_no_ao!

    Dependencies:

    * vs-dpir
    * rgsf

    :param clip:            Input clip
    :param edgevalue:       Remove edges from the edgemask that exceed this threshold (higher means more edges removed)
    :param strs:            A list of DPIR strength values (higher means stronger deblocking).
                            You can pass any arbitrary number of values here.
                            The amount of values in strs and thrs need to be equal.
                            Note that the current highest vsdpir can go as of writing is ``strength=75``
    :param thrs:            A list of thresholds, written as [(EdgeValRef, NextFrameDiff, PrevFrameDiff)].
                            You can pass any arbitrary number of values here.
                            The amount of values in strs and thrs need to be equal.
    :param matrix:          Enum for the matrix of the input clip. See ``types.Matrix`` for more info.
                            If `None`, gets matrix from the "_Matrix" prop of the clip
    :param cuda:            Device type used for deblocking. Uses CUDA if True, else CPU
    :param device_index:    The 'device_index' + 1º device of type device type in the system

    :return:                Deblocked clip
    """

As this issue was created a bit late, I will only include issues we have yet to properly figure out. Comments/suggestions are welcome. Please mention any and all issues with the function either here or in the #lvsfunc channel on our Discord server.

To-do:

• Figure out what kind of threshold to use

~~At the time of writing, it does a conversion to and from 8bit values. The easiest method would be allowing a range of [0, 1], as that is what is returned in the frameprops, and is ultimately what is being used for the actual calculations. However, I feel this isn't as palatable as regular numbers are. I am currently considering a [0, 100] range. Would like more thoughts and opinions on this before really making a call. ~~ Sticking with 8bit-esque values for the time being. May change later.

• Figure out a good set of default values

The current default values seem decent for my use-cases, but I have only really tested it on two specific sources. More user feedback would be appreciated here. No response, so staying with this until I find time to revisit it.

• See if we can somehow move the meat of the function to ModifyFrame functionality

Frame evals are much slower to run and initialise than simple frame modifications, but I am not familiar enough with how to write a function use ModifyFrame properly. ModifyFrame seems to cause memory problems, likely due to different memory allocation in ModifyFrame than FrameEval that messes up by forcing every instance of DPIR to be initialised or something? Either way, not feasible currently.

For these issues, PRs/comments are most appreciated.