real.finder's Avisynth Stuff

[danfgtn]

I'm trying to use some of the dehalomod for 16bit filtering, however, I'm having a little problem, the pixels at the bottom of the image become a bit darker, this only happened to me when I mistakenly used an 8bit filter in 16bit video. I think maybe I understood or done something wrong. I'll leave the images attached. Could someone help me understand what is wrong?

my script:

TFM(mode=5, slow=2, PP=0).TDecimate(mode=1, hybrid=0)

#daa3mod(slow=true)

Dither_convert_8_to_16()

#HQDeringmod(sharp=0, drrep=13, thr=8, elast=2, darkthr=0, lsb_in=true, lsb=true, lsb_out=true, tv_range=true)

#DeHalo_Alpha(rx=1.25, ry=1.25, darkstr=0.0, brightstr=1.0, lowsens=0, ss=3.0, cs=true)
#DeHalo_Alpha_2BD(rx=1.25, ry=1.25, darkstr=0.0, brightstr=1.0, lowsens=0, ss=3.0, cs=true)

#BlindDeHalo3(rx=1.25, ry=1.25)

nnedi3_resize16(target_width=1024, target_height=576, src_left=0, src_top=0, src_width=0, src_height=0, kernel_d="Spline36", 
\kernel_u="Spline36", taps=128, nsize=0, nns=4, qual=2, etype=0, pscrn=0, elast=1.0, tv_range=true, lsb_in=true, lsb=true)

DitherPost(mode=-1)
#Dither_quantize(10, reducerange=true, mode=-1)
#Dither_Out()

Prefetch(4)

Zoomed comparison:
https://i.imgur.com/Zq9YCFf.jpg

Dehalo_alpha:
https://i.imgur.com/zyD02o9.jpg

BlindDehalo:
https://i.imgur.com/gpgno0q.jpg

"Source"
https://i.imgur.com/uehyE8t.jpg

[real.finder]

Originally Posted by danfgtn

I'm trying to use some of the dehalomod for 16bit filtering, however, I'm having a little problem, the pixels at the bottom of the image become a bit darker, this only happened to me when I mistakenly used an 8bit filter in 16bit video. I think maybe I understood or done something wrong. I'll leave the images attached. Could someone help me understand what is wrong?

my script:

TFM(mode=5, slow=2, PP=0).TDecimate(mode=1, hybrid=0)

#daa3mod(slow=true)

Dither_convert_8_to_16()

#HQDeringmod(sharp=0, drrep=13, thr=8, elast=2, darkthr=0, lsb_in=true, lsb=true, lsb_out=true, tv_range=true)

#DeHalo_Alpha(rx=1.25, ry=1.25, darkstr=0.0, brightstr=1.0, lowsens=0, ss=3.0, cs=true)
#DeHalo_Alpha_2BD(rx=1.25, ry=1.25, darkstr=0.0, brightstr=1.0, lowsens=0, ss=3.0, cs=true)

#BlindDeHalo3(rx=1.25, ry=1.25)

nnedi3_resize16(target_width=1024, target_height=576, src_left=0, src_top=0, src_width=0, src_height=0, kernel_d="Spline36", 
\kernel_u="Spline36", taps=128, nsize=0, nns=4, qual=2, etype=0, pscrn=0, elast=1.0, tv_range=true, lsb_in=true, lsb=true)

DitherPost(mode=-1)
#Dither_quantize(10, reducerange=true, mode=-1)
#Dither_Out()

Prefetch(4)

Zoomed comparison:
https://i.imgur.com/Zq9YCFf.jpg

Dehalo_alpha:
https://i.imgur.com/zyD02o9.jpg

BlindDehalo:
https://i.imgur.com/gpgno0q.jpg

"Source"
https://i.imgur.com/uehyE8t.jpg

the mods I did for avs+ HBD not for lsb hack, that why, it will work with lsb like any 8 bit filter

[mp3dom]

Is it expected that the output from SMDegrain is different between a lsb input and HBD input (with same settings obviously)?

[real.finder]

Originally Posted by mp3dom

Is it expected that the output from SMDegrain is different between a lsb input and HBD input (with same settings obviously)?

it is

n16 give more or less same output as lsb (Depends on what settings you use, it should be same but there are some differences in how SMDegrain deal with both), but with HBD input will give different output.

well, there are some way to make it (with HBD input) less different (and faster) by using motion vector from 8 bit clip, back to old posts here for more info

[mp3dom]

Ok, but now I'm facing some "problems":
- with hbd input (lsmash->format yuv422p16->convertfromdoublewidth->p216), I can't use n16 (error: "MDegrainX out16 flag only for 8bit sources" - smdegrain line 545) so I guess it's a feature to ouput 8bit input to native hbd 16bit output.
- with the above hbd and prefilter 3 (uses dftttest) I get some damaged pictures. For "damaged" I mean really destroyed picture like missing objects. This doesn't happens with lsb input.

[real.finder]

Originally Posted by mp3dom

Ok, but now I'm facing some "problems":
- with hbd input (lsmash->format yuv422p16->convertfromdoublewidth->p216), I can't use n16 (error: "MDegrainX out16 flag only for 8bit sources" - smdegrain line 545) so I guess it's a feature to ouput 8bit input to native hbd 16bit output.
- with the above hbd and prefilter 3 (uses dftttest) I get some damaged pictures. For "damaged" I mean really destroyed picture like missing objects. This doesn't happens with lsb input.

for 1st point, yes indeed, it's for 8bit input, lsb_in is not real anyway (we talk about that before)

for the 2nd one, that because dftttest not update yet for HBD

1 solution for both is using 8bit motion vector (you can also scale the 8bit vector to 16bit vector or Vice versa, but in your case you don't need that)

[real.finder]

new test (cuz it use test builds of avs+ and masktools) update for SMDegrain https://pastebin.com/fU2a3Mqy

it should be faster in many cases in avs+ (will use avs+ expr), also there are new parameter "cplace" in SMDegrain_prefilters will affect prefilter 3

[mp3dom]

Ok, thanks.
Just one last question: without prefilter, is smdegrain (with hbd) working at real 16bit then?
With prefilter < 3 (uses Medianblur2) the output seems fine with hbd albeit medianblur2 afaik is not designed for hbd. Is it safe to assume that everything is running fine (and at real 16bit, or should I calculate 8bit vectors and apply to 16bit video?)

[real.finder]

Originally Posted by mp3dom

Ok, thanks.
Just one last question: without prefilter, is smdegrain (with hbd) working at real 16bit then?
With prefilter < 3 (uses Medianblur2) the output seems fine with hbd albeit medianblur2 afaik is not designed for hbd. Is it safe to assume that everything is running fine (and at real 16bit, or should I calculate 8bit vectors and apply to 16bit video?)

real 16bit? with HBD I did no workaround so now some options will not work with HBD until it's plugins get update, lsb did use a lot of workarounds indeed, but not HBD or even n16 use any, so all things with HBD and n16 are "real"

for HBD, the only safe prefilter for now are -1 to 1 (2 need medianblur2 and it not updated yet for HBD), and 4, contrasharp=true may work with SD (with HD it use minblur with r=2 so it need medianblur2), also contrasharp=int usage will work if you use https://forum.doom9.org/showthread.php?t=174752

[mp3dom]

Many thanks again!

[Motenai Yoda]

Eru you can also generate and use your own HBD prefilter clip to feed into smdegrain

[tormento]

Originally Posted by real.finder

update for SMDegrain

Will you please, one day, update html doc too?

[pinterf]

Originally Posted by real.finder

new test (cuz it use test builds of avs+ and masktools) update for SMDegrain https://pastebin.com/fU2a3Mqy

it should be faster in many cases in avs+ (will use avs+ expr), also there are new parameter "cplace" in SMDegrain_prefilters will affect prefilter 3

Masktools link updated to test8:
https://forum.doom9.org/showthread.p...70#post1845370
(mt_merge: cplace="mpeg2" now works for 4:2:2 as well, stacked 16 bit support (does anybody use it?) and make "mpeg2" default)

[danfgtn]

Originally Posted by real.finder

the mods I did for avs+ HBD not for lsb hack, that why, it will work with lsb like any 8 bit filter

Excuse my ignorance, but I can not understand. I thought hbd would directly imply a 16bit filtering, however I'm not understanding how hbd works without it. Could someone please explain to me how hbd works on an 8bit filter, and how does it differ from a standard 8 bit filter without it?

(And just to make sure I'm not confusing myself, hbd means high bit depth, right?)

[real.finder]

Originally Posted by tormento

Will you please, one day, update html doc too?

not likely

Originally Posted by danfgtn

Excuse my ignorance, but I can not understand. I thought hbd would directly imply a 16bit filtering, however I'm not understanding how hbd works without it. Could someone please explain to me how hbd works on an 8bit filter, and how does it differ from a standard 8 bit filter without it?

(And just to make sure I'm not confusing myself, hbd means high bit depth, right?)

yes, HBD = high bit depth

we used to say HBD to mention native avs+ Deep color

lsb (stacked) = hack, hack that use normal 8bit clip but with double Height

also avs+ HBD dont need any parameters to work unlike most lsb filters, nor need set bit depth like some lsb and double width filters, and work with multi bits in same function (filter) and that never and ever will be in lsb or double width, if filter support HBD then it work like you use the filter in 8bit mode (most of times)

[tormento]

Originally Posted by real.finder

SMDegrain
or the 3rd post here, see videohelp link and the top of script for the changes log

It doesn't point anymore to the latest version, i.e. 98s, that you sent on this forum only

[real.finder]

Originally Posted by tormento

It doesn't point anymore to the latest version, i.e. 98s, that you sent on this forum only

yes, I didn't post it their for 2 reasons 1- it need more tests

2- it need another edits, since I was think the use_expr=2 mean always in avs+

[real.finder]

new update for SMDegrain https://forum.doom9.org/showthread.p...02#post1790702

[real.finder]

updates for: Abcxyz_MT2, VHSHaloremover, DeHaloH, DeHalo_alpha_mt2, FineDehalo, Masked_DHA, BlindDeHalo3_mt2 and FastLineDarkMOD

keep in mind they no fully optimized for speed yet, the updates manly for not get wrong output in new masktools (2.2.15 and up), and not use realtime and use avs+ expr instead for speedup, so yes it faster in many cases now but it need another optimize for every mt_lut* line by test use_expr=3 and so to see if it faster or slower since expr is not faster in most cases, but it's faster in some cases

[danfgtn]

Hello everyone!

I'm having problems with daa3mod, a horizontal of greenish pixels is appearing at the bottom of the video. When I use KNLMeans in any part of the script after daa3mod sometimes the frames seem to merge the chroma with the previous frame. When removing daa3 the frames return to normal with KNL, I do not know what one has to do with the other, but I noticed that.

I do not know if it's just coincidence, but when using a mod16 resolution the horizontal greenish pixels do not appear, however, the problem with KNL is not eliminated in that way.

Following are images of both problems:

"greenish"
"chroma merge(?)"
"What's going on here?"

Does anyone know a way to solve this? Sorry if this is not a problem with the filter, im a noob in avisynth.

Tests made in AvS+ r2728
masktools in the latest version

My Script


By Google Translate