Avisynth+

[tebasuna51]

Originally Posted by Groucho2004

Time for a new thread or a moderator to update the first post. I think the latter is a better option.

My EDIT in first post have a link to last pinterf version (Avisynth+ r2772-MT) and to first post than begin with pinterf avs+ discussion.

I can't do anything more. I think is better a new thread by pinterf.

[videoh]

You done good, tebasuna51. Thank you.

[Dogway]

Originally Posted by Groucho2004

http://avisynth.nl/index.php/Expr

In fear of repeating myself...

Originally Posted by Dogway

I have no clue what scale_inputs does.

?

[pinterf]

Originally Posted by Dogway

In fear of repeating myself...
?

Use it when you don't want to bother with the different bit-depths within your Expr script. Depending on your choice, the Expr expression will always see your input clip to be 8 (or other bit depth, fine tuned with the i8, i10, etc Expr keywords)

The parameter helps converting old 8-bit-only Expr (or mt_lutxxx family) expression strings to a generic good-for-all-bit-depth string.

Since there is an automatic input conversion phase (e.g. pixel values of a 10 bit input clip will be divided by 4.0 to have them in the 8 bit range), then a back-conversion phase (result will be multiplied by 4.0 before converting the intermediate pixel result back to 10 bit integer). Using this method Expr itself is a little bit slower, but the conversion takes place only when the input bit-depth is different from the bit-depth used in Expr.

[pinterf]

Regarding the new thread, yeah, I'll start it, promise, unfortunately my draftsman is on holiday , I wanted to write a proper intro w/o mis-spelling.
Anyway it's time for a new release but I found way too many other tasks and coding adventures for myself, so it's just a question of weeks.

[Dogway]

Thanks pinterf, I think I got it.

Float style code only works with 32bit float videos, but integer style code works with everything, unless you have uknown bitdepth variables (float, integers, clips) in which case you can use the scale_inputs setting to bring them to a common denominator (8-bit).

This is my Expr version of mt_merge(), if you pinpoint something odd or not optimized please correct me. (not working with 32bit float)

function expr_merge ( clip a, clip b, clip msk, bool "luma", string "scale_inputs") {

luma = Default(luma, true)
scale_inputs = Default(scale_inputs, "all")

luma ? Eval("""
 msk
 w = Width()
 h = Height()
 Y = ConvertToY8()
 U = Y.BicubicResize(W/2,H/2,-.5,.25, src_left=0.25 - (0.25/w))
 V = U
 msk=CombinePlanes(Y, U, V, planes = "YUV", sample_clip=msk)""") : nop()

code="x z range_max - abs * y z * + range_size / "
expr(a,b,msk,code,code,code, scale_inputs=scale_inputs) }

[pinterf]

1.) You can omit abs by exchanging range_max and z in your script

(x * (range_max - z) + y * z) / range_max

(Expr uses 32 bit floats internally, regardless of the input pixel bit depth, so 255 becomes 255.0 and this floating point number is used until at the end the result is automatically rounded and converted back to integer (for 8-16 bit clips).
But in actual integer pixel-type implementations like in mt_merge or Avisynth Overlay there are simplifications:

(x * range_max - x * z + y * z) / range_max -->
x + (y - x) * z / range_max

is used, this is one less multiplication. But in real life it's a bit more difficult, as masks are stretching from 0..255 (8 bits example). E.g. for 8 bits division by range_max is replaced by division by 256 which is an easy right-bit-shift-8. In exchange the mask extremes (255) have to be treated specially: for maximum mask value we are returning always y. The * 255 right-shift-8 will not work properly for all input combinations.

-- end of popular science -- )

2.) You can write code, code, code as code: when an expression is not given for a plane plane, it will be copied from the previous one.

[ChaosKing]

Originally Posted by Reel.Deel

Thanks to Asd there is now a 64-bit VariableBlur v0.7 (among other plugins). See http://avisynth.nl/index.php/AviSynth%2B_x64_plugins

Source code(s) available here: http://avisynth.nl/index.php/User_talk:Asd

I have put it on github https://github.com/avisynth-repository/VariableBlur

[real.finder]

Originally Posted by Dogway

This is my Expr version of mt_merge(), if you pinpoint something odd or not optimized please correct me. (not working with 32bit float)

function expr_merge ( clip a, clip b, clip msk, bool "luma", string "scale_inputs") {

luma = Default(luma, true)
scale_inputs = Default(scale_inputs, "all")

luma ? Eval("""
 msk
 w = Width()
 h = Height()
 Y = ConvertToY8()
 U = Y.BicubicResize(W/2,H/2,-.5,.25, src_left=0.25 - (0.25/w))
 V = U
 msk=CombinePlanes(Y, U, V, planes = "YUV", sample_clip=msk)""") : nop()

code="x z range_max - abs * y z * + range_size / "
expr(a,b,msk,code,code,code, scale_inputs=scale_inputs) }

why you made merge function? if it because this old bug then pinterf already fix it

and there are already MasknotCL, MaskCL and my https://pastebin.com/aLP9Mb3z and all these in avs26 nowadays is useless since the bug fixed, unless you use avs 2.5

[Dogway]

The goal was that if someone wanted to keep a 32f bit process chain they could saving on quantization processing time and error accumulation (bitdepth down conversion) on the usual heavy filtering done in the scripts, but without removing the support for integer type bitdepths. Float precision is also benefitial for less degradation in dark images or parts of them.

I understand this is currently not possible due to the right-shift mechanism (discrepancies in masks), unless we get an official expr_merge with said optimizations. For now I will apply your suggestions (a ternary op in masks) until we get an internal function. I haven't cared for cosmetics yet.

Edit: @real.finder, because I asked a few days ago about an internal equivalent of mt_merge and nobody replied, so assumed there were none (long time out of touch) . Your script does the job perfectly although with a dependency. I will spend my time on my other tools.

Edit2: After testing smaskmerge() also didn't work for 32bit so I adapted mine and now is bitdepth agnostic.

[real.finder]

Originally Posted by Dogway

Edit: @real.finder, because I asked a few days ago about an internal equivalent of mt_merge and nobody replied, so assumed there were none (long time out of touch) . Your script does the job perfectly although with a dependency. I will spend my time on my other tools.

Edit2: After testing smaskmerge() also didn't work for 32bit so I adapted mine and now is bitdepth agnostic.

and



and



the formula seems work fine even in float, what you mean by "didn't work for 32bit"?

[Dogway]

Test with this, as pinterf explained a hack is needed when mask is range_max in float precision. I also had to remove the try catch for cl_exprxyz() in smaskmerge.avsi since it was triggering an error in the script.

16-bit integer__________32-bit float

blankclip(length=48,width=720,height=480, color=$00000,pixel_type="YV12")
expr("sx frameno + 32 % 16 < range_half range_max ?","sx frameno 2 / + 16 % 8 < range_half sx 15 / - range_half ?","sx frameno 2 / + 16 % 8 < range_half sx 8 / - range_half ?")

ConvertBits(32) # 32bit float vs 8-16bit integer

video=last
video2=video.trim(20,0)

	x1=string(20)
	x2=string(600)
	y1=string(50)
	y2=string(340)
msk=expr("sx "+x1+" >= sx "+x2+" <= & sy "+y1+" >= sy "+y2+" <= & & range_max range_min ?", "range_half", "range_half").trim(0,-1).FreezeFrame(0, FrameCount(last)-1, 0)

##########################

smaskmerge(video, video2, msk,3,3,3, luma=true)

ConvertBits(8)

# Debug Chroma planes
# ExtractU()

[real.finder]

so the problem only in chroma? I think this because the zero-chroma-center transition, don't know how chroma mask in float should be, let see what pinterf said and how it work in mt_edge and mt_merge

[pinterf]

Without reverse engineering the Expr itself, yep, float chroma goes -from 0.5 to 0.5, sometimes it can be tricky to apply on it a universal Expr. Perhaps with "range_size"? Anyway, masks are just weights going from 0 to 1.0.

[real.finder]

Originally Posted by pinterf

Without reverse engineering the Expr itself, yep, float chroma goes from -0.5 to 0.5, sometimes it can be tricky to apply on it a universal Expr. Perhaps with "range_size"? Anyway, masks are just weights going from 0 to 1.0.

in this case range_size not suitable for non-float, in 8 bit will be 256 not 255

maybe temporary shifting to 0-1.0 for float chroma if there are only universal (luma) Expr available? or with some parameter to set that

same for masktools lut things

[LouieChuckyMerry]

Hello, and thanks in advance for any help. About five years ago, kind, patient people here and elsewhere helped me develop a quite nice basic template for shriveling and improving my Blu-rays with 10-bit x264 using MeGUI with SEt's MT AviSynth. I'm still using MeGUI, but I've recently upgraded to pinterf's AviSynth+ and am wanting to verify that I've translated my template correctly.

The original SEt AviSynth MT template is:

SetMemoryMax(XXXX)
SetMTMode(X,X)
SOURCE INFORMATION HERE
SetMTMode(X)
SMDegrain(TR=X,ThSAD=XXX,RefineMotion=True,Plane=0,Chroma=False,LSB=True,LSB_Out=True)
F=DitherPost(Mode=-1)
S=F.FastLineDarkenMod("Settings Depend On Source")
D=MT_MakeDiff(S,F).Dither_Convert_8_To_16()
Dither_Add16(Last,D,Dif=True,U=2,V=2)
GradFun3("Settings Depend On Source",LSB_In=True,LSB=True)
### Preview Source OR Send 16-bit Output To x264 10-bit ###
# DitherPost()
Dither_Out()

with the x264 custom command line:

--demuxer raw --input-depth 16 --sar 1:1

while my current pinterf AviSynth+ template, with the same above x264 custom command line, is:

SOURCE INFORMATION HERE
SetFilterMTMode("Default_MT_Mode",2)
SMDegrain(TR=X,ThSAD=XXX,RefineMotion=True,Plane=0,Chroma=False,LSB=True,LSB_Out=True)
F=DitherPost(Mode=-1)
S=F.FastLineDarkenMod("Settings Depend On Source")
D=MT_MakeDiff(S,F).Dither_Convert_8_To_16()
Dither_Add16(Last,D,Dif=True,U=2,V=2)
GradFun3("Settings Depend On Source",LSB_In=True,LSB=True)
ConvertFromStacked
ConvertBits(10,Dither=0)
Prefetch(X)

which outputs normal-looking 10-bit video at ~15% higher frames per second than the SEt AviSynth MT script. Thanks pinterf .

Anyway, I just want to make sure that all is well before I attack further encoding. I'm using the newest .dll's-.avsi's I could find: pinterf's dual signature MaskTools2.2.18.dll, pinterf's MVTools2.7.41.dll, Dither1.27.2.avsi, SMDegrain3.1.2.93s.avsi.

And some questions:

0) Is the new AviSynth+ template truly processing in 16-bits from the beginning to the output?

1) Is the "ConvertBits(10,Dither=0")" call necessary given that I'm sending 16-bit to 10-bit x264; ie, would removing this cause a lack of proper dithering?

2) Is the:

F=DitherPost(Mode=-1)
S=F.FastLineDarkenMod("Settings Depend On Source")
D=MT_MakeDiff(S,F).Dither_Convert_8_To_16()
Dither_Add16(Last,D,Dif=True,U=2,V=2)

block proper for AviSynth+? Or can it be improved?

3) What have I missed?

Thanks again for any help; I really appreciate it .

[LouieChuckyMerry]

As I was checking some test clips, I noticed that very rarely there's an error message from, I think, AviSynth+ superimposed across the top, center of single frames:

Script error: Invalid arguments to function 'IsCombedTIVTC'
([ScriptClip], line 1)

Here's a couple screenshots: S1.E1-Simpsons[NTSC]-AviSynth+ErrorMessages. Is there any way to stop this happening (other than not creating script errors )? The script runs fine otherwise (I've used it successfully in the past with SEt's AviSynth MT and this never happened). Also, if anyone would answer my questions above from 7 May about syntax I'd be very thankful for the help .

EDIT: Turns out that adding "PreFetch(X)" to the end of a script for encoding interlaced video improves speed but causes errors. Sorry for the bother; a more detailed explanation is in the MeGUI: General Questions and Troubleshooting Thread.

[stax76]

ConvertBits(10,Dither=0)

This outputs 10 bit, you can certainly serve 16 bit to x265, I don't know which way is better.

[LouieChuckyMerry]

Originally Posted by stax76

ConvertBits(10,Dither=0)

This outputs 10 bit, you can certainly serve 16 bit to x265, I don't know which way is better.

Thanks, stax76. Can you explain the difference between:

ConvertFromStacked.ConvertBits(10,Dither=0)

and

ConvertFromStacked

given the script? That is, does the first line dither the raw 16-bit to 10-bit then send this 10-bit output to x264 10-bit while the second would send raw 16-bit to x264 ten bit? More importantly, I guess, is there a difference in quality? Seems silly to me to dither then serve instead of just serving the 16-bit to x264 10-bit, if that's the case.

[Motenai Yoda]

If wasn't fixed, x265's --dither doesn't work other than for 8bit output, without --dither it'll do a truncate.
for x264 it should work well as it apply a sierra dithering iirc