Doom9's Forum - View Single Post - ExBlend deblender - v1.04

StainlessS · 18th December 2018, 23:29

New Thread due to Forum restriction on editing thread title when over x number of years old.
Old version here:- https://forum.doom9.org/showthread.php?t=157337

Settings.txt Part 1 of 3 : Post #1 of 6

Code:

ExBlend() By Stainless Stephen [StainlessS on Doom9]

http://forum.doom9.org/showthread.php?t=157337
New thread:- https://forum.doom9.org/showthread.php?t=175948

ExBlend() v1.04 [Req VS2008 CPP runtimes]

YV12, YV16, YV24, YV8, YUY2 PROGRESSIVE source. Avisynth v2.5+ (YV12 & YUY2 only for v2.58 plugin)

ExBlend(), is a plugin originally written for telecined clips that were downsized from 720x480 to VCD 352x240.
The damage caused by this, looks similar to damage caused by blend Deinterlacing of telecined clips, which results
in a double blend, every five frames, GGGBBGGGBBGGGBB etc where 'G' is good and 'B' is blend.
Where damage is due to Deinterlacing of telecined clips, it is likely that a denoised detection clip is required
as although the damage looks quite similar, it is not exactly the same.

--------------------------------------------------------------------------------------------

Exblend(Clip,int "mode",int "pal",float "lockthresh",float "ithresh",int "show",string "ExBfile",bool "ver",bool "revip",
string "override",int "lv",int "dv",int "disp",clip "Dclip",int "CompUB",bool "Decimate",int "DecompIx",int "DecClpIx",
bool "Debug")

-------------------------------------
SOME DEFAULTS HAVE CHANGED IN V1.04 |
-------------------------------------

int mode Running mode Default 1

0 Free Running mode (Deprecated)
Mainly for those that might whinge about having to use modes 1 & 2.
In this mode it keeps a record in memory of the blend status of all visited
frames, if you eg scan forwards and then backwards you will get exactly the
same results as the 1st visit. Jumping about is also possible so long as
you have first scanned the entire file although some metrics will be wrong.
1 Scan and Store mode (Default)
As for Free Running mode but saves a copy of the scan status data when the
clip is closed ('ExBlend.XBD'). Use this prior to mode = 2.
Its pretty pointless having filters following ExBlend() in mode 1.
2 Pre-calculated mode
Loads in Scan Status Data saved by Scan and Store mode, this is particularly
useful to examine exactly which frames are unblended and you can jump about
without the possibilty of mismatched detections. You should still not jump
about if you are examining the BlendPair count and Ratio or other counts.
In mode 1, Scan & Store, Scan entire file (with or without metrics) and When
you have everything working right you can switch
to mode 2, (with metrics off). You now can add following filters to your hearts
content and ExBlend() should not take up too much CPU.
Switching from modes 1 to 2 may seems awkward but it is intended that
this filter be used in film restoration and so it is likely that many other
filters will follow this one, having a pre-calculated data file allows
Exblend() to use minimal CPU when adding further filters and checking the
resultant video. For the same reasons, Multidecimate() could also be a good
choice.
v1.03b, added native decimation in mode 2.

int pal -1, 0, 1 , Default 0, lets Exblend() know what the original frame rate was.

This sets the filters hints, after a blended pair is found, the detector will preset
3 (23.976/24 FPS) frames either side of the pair to HINTED meaning No Blend. If 'pal' (25 FPS)
is set to 1, it will preset 4 frames either side to HINTED. This helps it fall
into sync with sequence but may have slight delayed detection if the sequence goes
out of sync. If a frame has already been preset (visited) then the hint will not
be set, this allows hints to work when scanning both forward and backwards.
Not sure if PAL is actually useful or not, never seen any clip that exhibited this
problem with a good/blended signature of GGGGBBGGGGBBGGGG etc, where there are 4
good frames and 2 blends. As it did not add much difficulty to the plugin, PAL was
implemented just incase it was ever found to be useful.

-1 AutoPal mode. (MODE 0 ONLY)
If you are not sure what the original source was you can set PAL = -1 (MODE 0 Only).
If "Unblended:Blended Pairs" Ratio is between (4.0-0.01) and 5.0 at frame 1500 (1500=60*25
= 60 seconds @ 25 FPS), it will auto switch to PAL hints, the first 60 seconds
could contain the odd extra false blend pair detection.
If AUTO PAL is activated, the Metrics P (PAL) flag is hi-lited. It's
not a good idea to rely on this auto pal switch, you should set pal=1 when you
see it in orange. If autopal is activated and you later see the ratio rise above
5.0, then it would seem that the autopal detection was in error, this can happen
if the 1st 60 seconds contains a lot of static scenes with little movement, in this
case you should change to PAL=0 to disable the autopal detection and force it
to 23/24FPS original frame rate. Again, if the 1st 60 seconds contains a lot of static
scenes and it was originally PAL 25 FPS then the autopal may fail to detect and not
auto switch to PAL mode, in this case, ratio will later fall to above 4.0 and below
about 5.0. In this case you should change to PAL=1 to force PAL mode.

0, Forced 24 (or 23.976) FPS original frame rate (Default).
If the original source was 25 FPS and PAL is set
to 0, then this can reduce the effectiveness of ExBlend() due to it erroneously
detecting false blends where it should have been hinted, thus throwing it out of sync.

1, Forced PAL 25 FPS original frame rate. If the original source was 24 FPS and PAL is set
to 1, then this can DRAMATICALLY reduce the effectiveness of ExBlend() due to it hinting
out blends and overriding what should have been a blend detection. This will again, throw
it out of sync.

The R (RATIO) metrics flag will be displayed in orange at any time the ratio is not within expected
bounds, including during the AUTO PAL detection period (if it was a 25 FPS clip originally)
but will disappear once AUTO PAL has switched.

float lockthresh Range 0.0 (Off) to about 2.0, Default 1.0 (No longer considered EXPERIMENTAL, so default 1.0)

The lockthresh arg switches on the locking function of ExBlend().
Purpose being to try and latch on to the sequence when near static scene is encountered.
If the lock is activated, the 'L' Locked flag will be set in metrics.

NoLMN[f]=x.xxxx
L=y.yyyy LMX[f]=z.zzzz

I dont really wanna explain how locking works, it may
change if someone else can implement a better version. However, for locking
to take effect, some pre-conditions have to be satisfied. The frame must
be detected as non-blended, the previous frame should have been hinted, and at
least some of the conditions that would qualify as a blend detection must
be present, so not all frames qualify for the pre-conditions. If a frame does
qualify, then you may see something like L=y.yyyy which would indicate a
locking metric for the current frame, it is this metric that is compared to
LOCKTHRESH, if below or equal, then the frame is locked (converted to a blend
detection). If the frame is locked, the L flag will be set and the metric will
be Hi-lited. Once any frame has been locked, you may see LMX[f]=z.zzzz and
this shows the frame number and lock metric for the frame with the highest
locked metric, yet encountered. There may also be an indication for the frame
with the lowest lock metric that did NOT lock as in NoLMN[f]=x.xxxx
You may want to investigate all of the minimum and maximum flagged frames
both for locking and Ignore functions. Any frame that qualifies and would pass
the locking criteria will fail silently if the merge delta is above the
ithresh Ignore setting, it will not appear or be counted as an ignored frame.

If anyone would like to improve the functionality of lock, then please
be my guest.
This filter outputs a list of LOCKED frames which can be viewed using DebugView,
or may be output to a logging file.

v1.02, can now use eg 'disp=0' to view original blended clip along with metrics to
view frames flagged for investigation for either locking or ignore.

float ithresh 0.0 to 100.0, Default 3.0

There was a weird transition in the
original clip that prompted this filter to be written, it resulted in an even
more weird effect after unblending (looked sort of embossed). This is an
attempt to avoid future similar problems, but I dont have the original problem
video any more so cant really test it, also, the detection logic has changed
a little and so the it may no longer be a problem.
If merge Delta (MD) for a detected blend pair goes above this number, then the
blends will be ignored. I suppose that you could cut down on the number of false
blend detections by lowering this but it probably does not need it,
it works fairly well as it is. If MD exceeds ithresh, the 'I' Ignored flag will
be set and the detected blended pair will be ignored, and a little futher info
will be given when show=5. If there were any IGNORED blends, then it may be a good
idea to take a look at the offending frames both with ithresh at its setting
of 3.0 and with ithresh set to eg 100.0 where the suspect blend will not be ignored.

Written since above, the ithresh setting does seem to work quite well and it's
default setting of 3.0 may cut down on false detections but may IGNORE good blend
detections too, this is conservatively set so as not to allow any bad ones
through. A clip has been observed that went out of sequence every few minutes by
throwing in a triple blend, this ithresh setting seems to avoid the unpleasant
effects of bad detections at these points. You may need to raise this if many
IGNORED blends occur, perhaps in 'not so good clips'.
This filter outputs a list of IGNORED frames which can be viewed using DebugView,
or may be output to a logging file.

v1.02, can now use eg 'disp=0' to view original blended clip along with metrics to
view frames flagged for investigation for either locking or ignore.

dll's for Avs v2.58, v2.60/+ x86 and x64.
Zip includes 3 dll's + source + full vs 2008 project files (~214KB).
See MediaFire or SendSpace in Sig for Downloads