Add asymmetric frame interpolation mode for denoise.

[DTL2020]

The quality of frame interpolation with a complex and fast motion quickly degrades and with the current plugin for temporal_radius=2 we have only 2 interpolated frames of +-1 and +-2 source frames.

It may be added 2 more non-symmetric frames requests for tr=2 (and even more for tr=3 and more).

New params may be direct input of +frame_num and -frame_num as offsets from current frame number.
Default to 0 (use old denoise_tr).
And calculation of time offset internally as
double time_offset = (abs)(-frame_num)/((abs)(-frame_num) + (abs)(+frame_num))

In current version time_offset=0.5 always with equal +-frame_offset_num.

So for call
RIFE(denoise=true, -f_n=-1, +f_n=2) time offset will be 0.333 (1/3)
and for
RIFE(denoise=true, -f_n=-2, +f_n=1) time offset will be 0.666 (2/3)

And we can get more quality frames for lower total time range for interpolation/processing engine next to frame interpolation.

Expected script for total tr=2:
int_d1=RIFE(denoise=true, denoise_tr=1)
int_d2=RIFE(denoise=true, denoise_tr=2)
int_m1p2=RIFE(denoise=true, -f_n=-1, +f_n=2)
int_m2p1=RIFE(denoise=true, -f_n=-2, +f_n=1)

Interleave(int_d1, int_d2, last, int_m1p2, int_m2p1)
vsTTempSmooth(pmode=1, maxr=2)
SelectEvery(5,2)

[DTL2020]

Also it looks the current sources has an issue with denoise_tr:

The filter calls of
tr1=RIFE(denoise=true, denoise_tr=1, sc=true, sc_threshold=0.12, model=73)
tr2=RIFE(denoise=true, denoise_tr=2, sc=true, sc_threshold=0.12, model=73)
returns same frames.
Only
tr2=RIFE(denoise=true, denoise_bf=-2, denoise_ff=2, sc=true, sc_threshold=0.12, model=73)
working for tr=2 as expected (in new version of commit bd5b034 )

[Asd-g]

This is not good idea and it wouldn't give better quality in cases with complex and fast motion frames.
RIFE is not denoiser. It is frame reconstruction algo and this what are the models trained for.
They are mainly trained for t=0.5.
In the reconstruction context (and in RIFE AI context) one almost always should prefer radius 1 (1 prev, 1 next).

There is one/two very specific case where asymmetric and bigger radius would be helpful. E.g., if the neighbor frame(s) is glitched, then you can get the next good. Yet this is again in frame reconstruction context, not denoising.

Also it looks the current sources has an issue with denoise_tr:

The filter calls of
tr1=RIFE(denoise=true, denoise_tr=1, sc=true, sc_threshold=0.12, model=73)
tr2=RIFE(denoise=true, denoise_tr=2, sc=true, sc_threshold=0.12, model=73)
returns same frames.

I do get different frames from these two calls.

[DTL2020]

Yes - currently RIFE is used not only for denoising only but for general repair of media defects too (like tape defects at tape transfers). To repair 1 bad frame defect with a median-like (majority voting) algorithm we need at least 2 good samples for the current 1 bad frame sample. With RIFE(denoise_tr=1) we got only 1 expected better frame sample from -1 and +1 good frames. Also it is typically most close in time to the current damaged frame and interpolated with best quality. But to get a second good frame with symmetrical frames sampling only we can call now only RIFE(denoise_tr=2) and it interpolates from more changed -2 and +2 frames (total time radius of 4) and quality of interpolation is significantly less. So the idea is to request frame interpolation from a lower possible time radius of 3 for the current RIFE engine with RIFE(back=-1, forward=+2). And this allows us to get 2 new partial-symmetrical frames with a temporal radius of 3 (-1 +2 and -2 +1). For temporal radius 3 the frame content at motion changes less and interpolation quality is better. As I read only RIFE v4 (and more ?) can support arbitrary frame rate changes so can better support time position interpolation in all range of 0..1 instead of only mid-pos interpolation for time_pos=0.5 (typically used for 2x frame rate increasing). So may be better results for asymmetrical frames interpolation may be received with RIFE models v.4 and more ? Current test encodings results with asymmetric frames added: ConvertToPlanarRGB(bits=32) # Old symmetrical frames #tr=1 den_tr1=RIFE(denoise=true, denoise_bf=-1, denoise_ff=1) #tr=2 den_tr2=RIFE(denoise=true, denoise_bf=-2, denoise_ff=2) #2 new asymmetrical frames with better quality in comparison with tr=2 den_m1p2=RIFE(denoise=true, denoise_bf=-1, denoise_ff=2) den_m2p1=RIFE(denoise=true, denoise_bf=-2, denoise_ff=1) #process with some temporal-median engine # all interpolated frames + source - max denoise, less details Interleave(den_tr1, den_tr2, last, den_m1p2, den_m1p2) ConvertToYUV444() vsTTempSmooth(pmode=1, maxr=2, ythresh=255) SelectEvery(5,2) #no tr=2 worst frame, low denoise, more details Interleave(den_tr1, den_tr1, last, den_m1p2, den_m1p2) # more weight to best tr=1 frame ConvertToYUV444() vsTTempSmooth(pmode=1, maxr=2, ythresh=255) SelectEvery(5,2) # even less denoise, more source details Interleave(den_tr1, last, last, den_m1p2, den_m1p2) # more weight to input frame ConvertToYUV444() vsTTempSmooth(pmode=1, maxr=2, ythresh=255) SelectEvery(5,2) #no input frame - only 3 interpolated # average denoise, average details Interleave(den_tr1, den_m1p2, den_m1p2) # equal weight to all interpolated frames ConvertToYUV444() vsTTempSmooth(pmode=1, maxr=1, ythresh=255) SelectEvery(3,1)

…

On Sun, Feb 22, 2026 at 6:51 AM Asd-g ***@***.***> wrote: *Asd-g* left a comment (Asd-g/AviSynthPlus-RIFE#10) <#10 (comment)> This is not good idea and it wouldn't give better quality in cases with complex and fast motion frames. RIFE is not denoiser. It is frame reconstruction algo and this what are the models trained for. They are mainly trained for t=0.5. In the reconstruction context (and in RIFE AI context) one almost always should prefer radius 1 (1 prev, 1 next). There is one/two very specific case where asymmetric and bigger radius would be helpful. E.g., if the neighbor frame(s) is glitched, then you can get the next good. Yet this is again in frame reconstruction context, not denoising. Also it looks the current sources has an issue with denoise_tr: The filter calls of tr1=RIFE(denoise=true, denoise_tr=1, sc=true, sc_threshold=0.12, model=73) tr2=RIFE(denoise=true, denoise_tr=2, sc=true, sc_threshold=0.12, model=73) returns same frames. I do get different frames from these two calls. — Reply to this email directly, view it on GitHub <#10 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQMGLM2UJVOLB3F6P5465RL4NERSZAVCNFSM6AAAAACVAD5SYWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTSNBQGA4DEMZXGQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[Asd-g]

Try the new version 1.3.0.
Refer to README for the new parameters.

[DTL2020]

It looks the release 1.3.0 was build by some new (?) compiler: The .dll can not be loaded and system report non-readable (bad codepage ?) error message:
Cannot load file 'XXX/RIFE.dll'. Platform returned code 126: Р_Рч Р_айР_РчР_ С_казаР_Р_С<Р№ Р_Р_Р_С_Р>С_.

The dependencies application shows something like openmp .dll not present in system (Win11 host). Can you add this .dll to release or where to download it ?
The Win11 host is auto-udated at the company and I do not have rights to install other updates.

Search shows same issue with MSVC build tools - Data-Oriented-House/PortableBuildTools#23

I download some version of the .dll file from https://www.dll-files.com/libomp140.x86_64.dll.html but not sure if is it correct version.

[Asd-g]

This is the specific version used for ncnn building.

libomp140.x86_64.zip

[Asd-g]

You can try the new version 1.3.1. It doesn't require OpenMP anymore.

[DTL2020]

Yes - this version working without additional .dlls. And frames interpolation with new params _bf and _ff looks like working close to expected.