Dogway's Filters Packs

[Reel.Deel]

Originally Posted by simple_simon

Well that really doesn't make sense for deep_resize to be changing the frame properties to 709 colorspace when it isn't. It should either assume the colorspace by the input frame resolution or leave it unspecified.

I looked at the script and the only place that I can guess where the frame properties are being set are in ConvertFormat. There's a few calls to that function withing deep_resize. I'm not sure what color format it converts to, it's hard to follow along.

ColorBars(pixel_type="YV12")
propClearAll()
deep_resize(width*2, height*2, grain=0)
propShow(size=24)

At least 4 properties are being set:

Originally Posted by poisondeathray

avsresize would look like

z_convertformat(pixel_type=last.pixeltype,  colorspace_op="170m:709:709:l=>709:709:709:l")

You no longer recommend full=>full ?

[poisondeathray]

Originally Posted by Reel.Deel

You no longer recommend full=>full ?

Good point - Full is probably still better, I don't think anything has changed.

I rarely use colormatrix (or related) anymore for upscaling, because almost everything SD I'm upscaling uses machine learning at some point, so it's converted to RGB early on

[simple_simon]

Originally Posted by poisondeathray

z_convertformat(pixel_type=last.pixeltype,  colorspace_op="170m:709:709:l=>709:709:709:l")

Why wouldn't this be the correct way to do it?

z_ConvertFormat(colorspace_op="470bg:601:170m:full=>709:709:709:full")

And does it matter where in the script chain I do the color conversion? Should it be early in the script or after all the cleanup and resizing is done?

Originally Posted by Reel.Deel

At least 4 properties are being set:

That's what I'm seeing too.

[poisondeathray]

Originally Posted by simple_simon

Why wouldn't this be the correct way to do it?

z_ConvertFormat(colorspace_op="470bg:601:170m:full=>709:709:709:full")

Matrices 470bg and 170m have the same values Kr = 0.299, Kb = 0.114, so it's the same mathematically

Transfer also have the same values for "601" and "709" so, it's the same mathematically

Primaries are debatable - you actually shift the colors if you go from 170m to 709. Technically, you're supposed to adjust the primaries, but >95% of the time, it's not actually done upstream for the transfer to the DVD in the first place - so you end up with slightly shifted colors if you adjust them in my experience. Primaries are typically not adjusted for in broadcast, BD, DVD, web streaming either (except for HDR) You only get the "correct" colors, if the primaries were handled correctly all the way through, upstream and downstream and the playback method.

And does it matter where in the script chain I do the color conversion? Should it be early in the script or after all the cleanup and resizing is done?

It probably doesn't matter too much, but I'd generally do it near the end.

OTOH, some types of artifacts related to colormatrix conversion can occur with some types of animation (there are some threads and examples on this on this forum and others), so depending on how picky you are , you might want to filter them farther, so earlier could be better in some cases

[poisondeathray]

Originally Posted by TDS

Sorry, me again

I thought I'd give this a try, and as per usual (for me), I'm getting an error with AVSMeter..

https://github.com/Dogway/Avisynth-S...Pack.avsi#L401

Import("%AVISYNTHPLUGINS%\PD_TOOLS\EXTOOLS\ExTools.avs")
Import("%AVISYNTHPLUGINS%\PD_TOOLS\GRADE-PACK\Masks Pack.avs")
Import("%AVISYNTHPLUGINS%\PD_TOOLS\MASK-PACK\Grade Pack.avs")
Import("%AVISYNTHPLUGINS%\PD_TOOLS\RESIZERS-PACK\Resizers Pack.avs")
Import("%AVISYNTHPLUGINS%\PD_TOOLS\SCENES-PACK\Scenes Pack.avs")
Import("%AVISYNTHPLUGINS%\PD_TOOLS\TRANSFORM-PACK\Transforms Pack.avs")
Import("%AVISYNTHPLUGINS%\PD_TOOLS\TRANSFORM-PACK\Transforms Pack-Models.avs")
Import("%AVISYNTHPLUGINS%\PD_TOOLS\TRANSFORM-PACK\Transforms Pack-Transfers.avs")
video=ex_autolevels(video,interval=0.5,th=0.1)

You need to run SceneStats before ex_autolevels . 2pass is probably better with a log file, but might be difficult to do in ripbot alone

video = SceneStats(video, mode="Range+Stats",Y=true,UV=false) #1pass , no log file written
video = ex_autolevels(video, interval=0.5,th=0.1)

[poisondeathray]

Try with a small short test video first to see if it "works" at all on your setup - because it can take a while while calculating

[poisondeathray]

Originally Posted by TDS

Thanks again, PDR, that got it to work...

But I'd hate to think how long it would take to process a 1080p or 4K movie length

It was just a quick test to rule out configuration problems (if any)

Actually you can run the 2pass method, since avsmeter is available in ripbot. The analysis will not seem to "hang" and it will "bake" the analysis results into the text file. ie. use avsmeter to run the 1st pass, change the script for the encoding pass (or passes) . Make sure you run the analysis pass single threaded (no prefetch, or prefetch (1), also source filter with threads=1, and/or use a very robust indexed method like DGSource. You also have to edit the log file, there is a repeated section at the top that you have to delete (open in a text editor, and delete all the lines up to the 2nd "Type string" line)

dogway posts this warning in ScenesPack.avsi - that's what it means

### BEWARE!! For some reason in the exported log the first scene has repeated stats so manually remove those lines before loading the file.

analysis pass

video = SceneStats(video, mode="Range+Stats",Y=true,UV=false, path="path\source_stats.log")

encode pass/passes

video = ReadStats(video, "path\source_stats.log")
video = ex_autolevels(video, interval=0.5,th=0.1)

There are other "auto" leveling filters and methods that you can try out too...

[poisondeathray]

Originally Posted by TDS

What are the other's ??

What kind of "auto leveling" are you wanting ?

Is it more "general" brightness/darkness/contrast issues, or to deal with "luminance flicker", or "white balance" / color balance/color cast , or something else?

For the general category, you can try AutoLevels, or AutoAdjust

[poisondeathray]

Originally Posted by TDS

Well, I have tried several white balance types, and they don't work with RipBot (well they do, but they don't).

I used to use a white balance filter when I was using Adobe Premier, and that worked well, I've even tried 3DLUT's to varying degrees of success.

I find I'm tweaking the colours in most of my encodes, mainly taming down "red's".

For avisynth white balance, I find RGBAdapt_AWB_Process is quite good and customizable - results are close to commercial plugins in some cases - but IIRC you had issues running it. It works in ripbot, loading the video then copy/pasting - I just tried it.

And playing with ripbot - I think I figured out the "no error message" black screen MPCHC ripbot preview issue that you sometimes have. AWB_Func didn't work, at first no error message. It turns out I had a typo, which the now visible error message conveyed. What you need to do is move the seekbar in MPCHC, and the error message will pop up

You can also try coloryuv(autowhite=true) , it' s not as advanced but can do the job adequately in some cases

If you prefer the PP filter's, you can use PP . One option is to frameserve in (Premiere AVS Import plugin) / frameserve out (Advanced Frameserver, or Debugmode Frameserver - now called "Cumincode Framserver") . Or use intermediates. I personally prefer intermediates when using PP

[poisondeathray]

Originally Posted by TDS

I recall that it DID work that way, BUT it did not invoke the distributed encoding function, which is the basically the whole point of RipBot (as far as encoding is concerned)

Even if you got it working - the results would not be ideal distributed anyways. Any distributed, or chunked method will have potential issues with temporal filters "at the seams". Temporal auto leveling is probably the worst type of filter you could use with chunks - it would predispose you to flicker at the joins. You can reduce some of the issues if you overlap the chunks and discard the overlaps before joining, but I don't think ripbot had that feature the last time I checked

Don't use Premiere anymore, no mkv support

You can indirectly import MKV's through an .avs. The AVS import plugin doesn't work for many people, but AVFS (avisynth virtual file system) works for everyone and with just about every program (other NLE's too) . Vapoursynth version of avfs is better - because it has fourcc emulation such as UYVY for 8bit422, v210 for 10bit422 - these are treated as "YUV" in NLE's with YUV capable timelines like PP, instead of being "mishandled" as RGB (many lossless YUV codecs and uncompressed YUV formats are mishandled by most NLE's, and get converted to RGB) . "RGB" is usually not a big issue if you're using some auto leveling/auto white balance plugin - because most will be working in RGB anyways

Another option is if you re-wrap (streamcopy) into MP4, PP can import AVC, HEVC too. Native file import such as MP4 colorspace is handled properly

[Dogway]

Originally Posted by LeXXuz

Thanks DTL and Dogway for your input. Really appreciate it.
Something new to fiddle around with the next couple of days.

I updated ex_autolevels(), now it's really robust but as I said it's a global operator, I might look into local in the future.

I also updated ex_luma_rebuild() to allow for ex_levels() type of normalization with 'lo' and 'hi' args, but optimized without any performance penalty.

Also updated StabPlus() with ex_autolevels(). Actually you could hack open the StabPlus() function to reuse some code with the below script.

ffvideosource("noisy_original.mkv")
propSet("_FieldBased",0)

ConvertBits(16)
ex_Luma_Rebuild(15.0, 0.004, 21, tv_out=true)
ConvertBits(8,dither=1)
StabPlus()
crop(2,2,-6,-2)
SceneStats("Range+Stats")

pref = ex_autolevels(hi=true,tv_out=false)
temp =             Pref.TemporalSoften(5,255,0,25,2)
rep  = temp.Repair(Pref.TemporalSoften(1,255,0,25,2))

pref = ex_merge(rep, pref, MotionMask(rep,dir=0,scale=3,sharpness=2))
SMDegrain(2, 600, mode="TemporalSoften",str=2,prefilter=pref,RefineMotion=true)


ex_unsharp(0.3)
gr = 1
size = (720/2133.) * 3.3
GrainFactory3mod(g1str=7*gr,g2str=9*gr,g3str=7*gr,g1size=1.7*size,g2size=1.4*size,g3size=1.2*size,g1cstr=0.5*gr,g2cstr=0.3*gr,g3cstr=0.1*gr,temp_avg=1,tv_range=true)

For the new SMDegrain update, I'm still missing a bugfix in ex_retinex() for lvl=1 and highlights=false. Just was burnt out with the latest fixes.

This is the new output: link

For comparison I was curious to test videoFred's script, it does a good job on stabilization and luma flicker but there's still some wobble: link

[anton_foy]

Originally Posted by Dogway

I updated ex_autolevels(), now it's really robust but as I said it's a global operator, I might look into local in the future.

I also updated ex_luma_rebuild() to allow for ex_levels() type of normalization with 'lo' and 'hi' args, but optimized without any performance penalty.

Also updated StabPlus() with ex_autolevels(). Actually you could hack open the StabPlus() function to reuse some code with the below script.

ffvideosource("noisy_original.mkv")
propSet("_FieldBased",0)

ConvertBits(16)
ex_Luma_Rebuild(15.0, 0.004, 21, tv_out=true)
ConvertBits(8,dither=1)
StabPlus()
crop(2,2,-6,-2)
SceneStats("Range+Stats")

pref = ex_autolevels(hi=true,tv_out=false)
temp =             Pref.TemporalSoften(5,255,0,25,2)
rep  = temp.Repair(Pref.TemporalSoften(1,255,0,25,2))

pref = ex_merge(rep, pref,MotionMask(rep,scale=10,sharpness=5))
SMDegrain(2, 600, mode="TemporalSoften",str=2,prefilter=pref,RefineMotion=true)


ex_unsharp(0.3)
gr = 1
size = (720/2133.) * 3.3
GrainFactory3mod(g1str=7*gr,g2str=9*gr,g3str=7*gr,g1size=1.7*size,g2size=1.4*size,g3size=1.2*size,g1cstr=0.5*gr,g2cstr=0.3*gr,g3cstr=0.1*gr,temp_avg=1,tv_range=true)

For the new SMDegrain update, I'm still missing a bugfix in ex_retinex() for lvl=1 and highlights=false. Just was burnt out with the latest fixes.

This is the new output: link

For comparison I was curious to test videoFred's script, it does a good job on stabilization and luma flicker but there's still some wobble: link

Looking really good! But something is happening on the right in the bushes when the chef is passing by it. Warping kind of.

[Dogway]

Sure, I said before it's not perfect. For these kind of borked sources the best solution is not a surgeon fix, but call TemporalSoften and fix several issues at once.
You can play with the temporal radius of TemporalSoften and SMDegrain to balance the effect, or use a pyramidal approach where you refine motion vectors further and further.
Maybe applying BM3D with high radius to 'rep' frame can improve some stabilization.

[anton_foy]

Originally Posted by Dogway

Sure, I said before it's not perfect. For these kind of borked sources the best solution is not a surgeon fix, but call TemporalSoften and fix several issues at once.
You can play with the temporal radius of TemporalSoften and SMDegrain to balance the effect, or use a pyramidal approach where you refine motion vectors further and further.
Maybe applying BM3D with high radius to 'rep' frame can improve some stabilization.

Actually this is to me very interesting as I am experimenting with wobble and jitter locally to stab. Not quite there yet though but hundreds of ideas.

[Dogway]

I was curious to test the performance of ex_autolevels() on a synthetic test so I made this gradient patch with alternating lifted blacks and gamma.

This is ex_autolevels:

Out of curiosity I also tested Autolevels(), I don't know if I'm doing something wrong here, the call is:

Autolevels(filterRadius=10, output_low=0, output_high=255, ignore=0.05, sceneChgThresh=255)

I had to raise sceneChgThresh as it was detecting flicker as SC


Probably if I run a second pass of ex_autolevels() with original stats it can be stabilized further. Will check that.
EDIT: Yes, it's more stable with a second run but 'lo' and 'hi' have to be disabled to avoid a re-normalization:

ex_autolevels(true ,true,false,reStats=false,tv_in=false)
ex_autolevels(false,true,false,reStats=false,tv_in=false)

[LeXXuz]

Looks very interesting! Where would you suggest to put this in a (double) SMDegrain call?


Out of curiosity I took a much closer look on other transfers I did over the last couple of month.

Now that I developed a certain eye for this texture wobble, I see it in a lot of films I did in the past. SD and HD. Even films where you would not expect this because you can hardly see any luma flickering in the source.

I start to believe this texture wobble is some kind of general side effect of the way SMDegrain removes noise or from the motion compensation. I still understand too little on how the entire process works to judge this.

SMDegrain does a terrific job on films that had a very good AD transfer and where filmgrain really is the only kind of noise present. Same goes for modern digital productions where grain is added in post-processing for some arguable reasons.

But on sources where other types of noise are involved, escpecially these 'unstable' sources, the side effects become clearly superficial when you try to go for a clean overall look.

I just had a SD film here where in one scene almost the whole picture wobbled. Right now I'm playing around with other denoisers on this one to see what they can do.

[anton_foy]

@Dogway I think I found what is causing that wobble in the bushes.

MotionMask(rep,dir=0,scale=3,sharpness=2)

with the temporalsoften lines above it.
Try and see if you change the temporalsoften params lower if the wobble disappear.

[Dogway]

I've been refining ex_autolevels() and now I get it almost perfectly flicker free.
First I had a bug in ArrayDelVal() in ExTools which I'll update soon. Then I added 'Deflicker' arg to ex_autolevels() to make the normalization per scene (autolevels) or per frame (deflicker).

Effectively running 2 passes makes it balanced enough for the gamma flicker.

ex_autolevels(true ,true,false,Deflicker=true,tv_in=false)
ex_autolevels(false,true,false,Deflicker=true,tv_in=false)

This is how you make a flickering patch:

GradientLinear(zoom=1, positive=true, precision=4)
trim(0,32)
SceneStats("Range")

ScriptClip(function [] () {
    lo = rand(30)
    gm = (rand(100)-50)/200.+1
    ex_levels(0,gm,255,lo,255,tv_range=false)
} )

SceneStats("Stats")

...Deflickering here...

ConvertBits(8,dither=1)

For comparison the next is a double call of Deflicker(scene=255,percent=100)

Originally Posted by anton_foy

@Dogway I think I found what is causing that wobble in the bushes.

MotionMask(rep,dir=0,scale=3,sharpness=2)

with the temporalsoften lines above it.
Try and see if you change the temporalsoften params lower if the wobble disappear.

Yes I know, but hadn't time to test a new approach. Want to try with my heavy grain prefilter preset like in 21 grams sample, using pyramidal temporal denoising.

Originally Posted by LeXXuz

Looks very interesting! Where would you suggest to put this in a (double) SMDegrain call?

I start to believe this texture wobble is some kind of general side effect of the way SMDegrain removes noise or from the motion compensation. I still understand too little on how the entire process works to judge this.

SMDegrain does a terrific job on films that had a very good AD transfer and where filmgrain really is the only kind of noise present. Same goes for modern digital productions where grain is added in post-processing for some arguable reasons.

It's DCT flicker, or in other words low frequency temporal "noise", motion and luma flicker just makes it worse. You can take a lowpassed version, temporally denoise it (tricky) and add it back to source. In any case using a radical approach like with temporalsoften prefilter works, I'm going to test with other forms of hardcore prefilters. For best results stabilize your clip motion and luma flicker beforehand then fix DCT flicker.

EDIT: Here an updated script with less wobble but also less background stabilization. Link
I tested with ex_reduceflicker() as the clip presented bob-like jitter and worked very nice, also reduced luma flicker a bit further despite not being designed for that.

ffvideosource("noisy_original.mkv")
propSet("_FieldBased",0)

ConvertBits(16)
ex_Luma_Rebuild(15.0, 0.004, 21, tv_out=true)
ConvertBits(8,dither=1)

StabPlus()
crop(2,2,-6,-2)
SceneStats("Range+Stats")

pref  = ex_autolevels(     true ,true, true,Deflicker=true,tv_out=false)
pref  = ex_autolevels(pref,false,true,false,Deflicker=true,tv_out=false)
pref2 = ex_reduceflicker(pref,3,true)
pref3 = SMDegrain(tr=3,mode="temporalsoften",blksize=32,thSAD=900,prefilter=pref2,str=2,contrasharp=false,refinemotion=false)

bk = SMDegrain(pref3,tr=3,mode="MDegrain",blksize=16,thSAD=400,refinemotion=true)
ft = SMDegrain(      tr=2,mode="MDegrain",blksize=16,thSAD=300,refinemotion=true,prefilter=bk)
ex_merge(bk, ft, MotionMask(pref3,scale=10,sharpness=5))

ex_unsharp(0.3)
gr = 1
size = (720/2133.) * 3.3
GrainFactory3mod(g1str=7*gr,g2str=9*gr,g3str=7*gr,g1size=1.7*size,g2size=1.4*size,g3size=1.2*size,g1cstr=0.5*gr,g2cstr=0.3*gr,g3cstr=0.1*gr,temp_avg=1,tv_range=true)

EDIT2: And another variation, less smearing and wobble but again a bit more nervous background. I also replaced StabPlus() with the next videoFred's suggestion, so much better that I removed ex_reduceflicker().

ffvideosource("noisy_original.mkv")
propSet("_FieldBased",0)

ConvertBits(16)
ex_Luma_Rebuild(15.0, 0.004, 21, tv_out=true)
ConvertBits(8,dither=1)

StabPlus2()
crop(2,2,-6,-2)
SceneStats("Range+Stats")

pref  = ex_autolevels(     true ,true, true,Deflicker=true,tv_out=false)
pref  = ex_autolevels(pref,false,true,false,Deflicker=true,tv_out=false)
pref3 = SMDegrain(tr=3,mode="temporalsoften",blksize=32,thSAD=900,prefilter=pref,str=2,contrasharp=false,refinemotion=false)

bk=SMDegrain(tr=2,mode="temporalsoften",blksize=16,thSAD=400,LFR=false,refinemotion=true,prefilter=pref3)
ft=SMDegrain(tr=2,mode="MDegrain"      ,blksize=16,thSAD=300,LFR=false,refinemotion=true,prefilter=bk)
ex_merge(bk, ft, MotionMask(pref3,scale=10,sharpness=5))

ex_unsharp(0.3)
gr = 1
size = (720/2133.) * 3.3
GrainFactory3mod(g1str=7*gr,g2str=9*gr,g3str=7*gr,g1size=1.7*size,g2size=1.4*size,g3size=1.2*size,g1cstr=0.5*gr,g2cstr=0.3*gr,g3cstr=0.1*gr,temp_avg=1,tv_range=true)

[simple_simon]

Anybody have an idea what might be causing the horizontal chroma lines in these two screenshots? They don't exist in the source video.

https://send.cm/d/KEeM
https://send.cm/d/KEeP

This is the script I'm using:

z_convertformat(pixel_type=last.pixeltype, colorspace_op="170m:709:709:full=>709:709:709:full").propSet("_ColorRange",1)
tfm(mode=1, pp=7)
tdecimate(mode=0, dupthresh=1.4)
lsfplus(strength=60,ss_x=1.5,ss_y=1.5,soft=30,overshoot=1)
removegrain(mode=5)
propSet("_FieldBased",0).deep_resize(960,720,grain=0,qual=2,gpuid=-1,show=false)
prefetch(2)

I thought I had my upscaling routine nailed down but I guess I'm going to have to go back and redo everything again.

[poisondeathray]

Originally Posted by simple_simon

Anybody have an idea what might be causing the horizontal chroma lines in these two screenshots? They don't exist in the source video.

Move z_convertformat after IVTC. "colormatrix" or similar applied on fields can cause similar issue, because it's applying a progressive transform while still organized in fields. There is an interlaced=true/false switch , but I believe it's non functional. Better just to move it