Color banding and noise removal

[Elvellon]

Great, thank you!

[cretindesalpes]

Dither 1.22.0 (http://forum.doom9.org/showthread.php?p=1386559#post1386559) is the last release of the year:
Added temporal processing to Dither_median16.
Added Dither_resize16nr, a simple ringing-cancellation wrapper around Dither_resize16.
Added a noring parameter to conversion functions between YUV and RGB.
Added lsb, center and bkgcolor to Dither_srgb_display.
Replaced Dither_convey_yuv4xxp16_on_yvxx with Dither_out, which also works correctly with YV16 input. The old function is still there for compatibility, mapped on the new one.
Dither_addborders16 now works with RGB clips.
Badly designed and buggy resizing functionalities in Dither_srgb_display were rewritten.
I’ll try to backport the new or improved features from fmtconv to Dither as soon as I’m done with the fmtconv optimisations. In the meantime, I wish you all a happy new year.

[ganymede]

Thank you very much Mr. DesAlpes, and happy new year to you !
Dither_out, which also works correctly with YV16 inputDo you mean that it is possible to pipe 4:2:2 data outside avisynth, using a fake YV12 stream, or is 4:2:0 the only option ?

[Lenchik]

WhyDither_resize16nr (Width (), Height () / 2, kernel="impulse -1 20 -1",
\ fh=-1, fv=-1, cnorm=true, center=false, y=3, u=2, v=2)give greenish output while Dither_resize16 with same parameters don't?

[Tanbheer]

your filter functions are so hard to understand. I have always used GradFun2DBmod so far for removing banding.
Can you give me an equivalent parameter of GradFun3 for this parameter GradFun2DBmod(thr=1.4,thrC=1.4,mode=3,str=0.8,strC=0.0).
I want to try & compare

[SAPikachu]

My friend maven mawen found a bug in Dither_quantize with bitdepth=14. After debugging I think the culprit is in Dither_quantize_out_n.

Test case:


ColorBars
ConvertToYV12.Grayscale

dither_convert_8_to_16

StackHorizontal( \
f3kdb(y=0, cb=0, cr=0, grainy=0, grainc=0, input_mode=1, input_depth=16, output_mode=1, output_depth=14, dither_algo=1), \
Dither_quantize(14, reducerange=true, mode=-1) \
)



As of Dither 1.22.0, LSB part of Dither_quantize's output is totally different from f3kdb's. If I get it right, ofs2 in Dither_quantize_out_n is incorrect when output bit depth is 14 (exponent becomes -1), so the result is incorrect.

(Actually I don't fully understand this function, so please correct me if I am wrong. :P )

[mawen1250]

Function Dither_quantize (clip src, int bitdepth, bool "reducerange",
\ int "mode", float "ampo", float "ampn", int "pat", bool "dyn", bool "prot",
\ clip "mask", float "thr", bool "interlaced", int "y", int "u", int "v",
\ bool "staticnoise")
In addtion, due to the definition of "int bitdepth", I can only use Dither_quantize(10) but Dither_quantize(bitdepth=10) returns error.

[cretindesalpes]

Dither 1.22.1 (http://forum.doom9.org/showthread.php?p=1386559#post1386559) (update from v1.22.0 (http://ldesoras.free.fr/src/avs/dither-1.22.0-to-1.22.1.zip)) should address the problems raised by Lenchik, SAPikachu and mawen1250:
Fixed green frame output in Dither_resize16nr for some combination of the y, u and v parameters.
Fixed Dither_quantize for 14-bit output. It is not perfect but much better than before.
Made the bitdepth parameter in Dither_quantize a named argument.
Fixed var and uvar scaling in Dither_add_grain16 to match more accurately AddGrainC.

ganymede:

Yes, you should be able to pipe 16-bit 4:2:2 with a fake YV16 stream. Make sure that x264 reads planar 4:2:2.

Tanbheer:

Try this:
GradFun3 (thr=1.4*0.3, smode=2, lsb=true)
Dither_add_grain16 (var=0.8, uvar=0, soft=2)
DitherPost (mode=6)
Should be close, but not exactly the same because GradFun2DbMod applies the grain through a luma mask.

Dogway:

I’m going to investigate this issue in the next days.

[Tanbheer]

your filter functions are so hard to understand. I have always used GradFun2DBmod so far for removing banding.
Can you give me an equivalent parameter of GradFun3 for this parameter GradFun2DBmod(thr=1.4,thrC=1.4,mode=3,str=0.8,strC=0.0).
I want to try & compare

Anyone have any answer plz. :o

[Are_]

Anyone have any answer plz. :o

Just two post above yours.

http://forum.doom9.org/showthread.php?p=1609899#post1609899

[S_Prince]

Hello All..

I Am Getting A Problem By Using MDegrain3..

i Am using this script :

h = Height ()
w = Width ()

super = MSuper(pel=2, sharp=1)
bv3 = MAnalyse(super, isb = true, delta = 3, overlap=8, blksize=16)
bv2 = MAnalyse(super, isb = true, delta = 2, overlap=8, blksize=16)
bv1 = MAnalyse(super, isb = true, delta = 1, overlap=8, blksize=16)
fv1 = MAnalyse(super, isb = false, delta = 1, overlap=8, blksize=16)
fv2 = MAnalyse(super, isb = false, delta = 2, overlap=8, blksize=16)
fv3 = MAnalyse(super, isb = false, delta = 3, overlap=8, blksize=16)

MDegrain3(super, bv1, fv1, bv2, fv2, bv3, fv3, thSAD=400, lsb=true)

msb = last.Crop (0, 0, w, h)
lsb = last.Crop (0, h, w, h)
DitherPost (msb, lsb)


But It is giving the following error:

http://img163.imageshack.us/img163/1709/239ql.png


Please Anyone Can tell Me How To Get Rid of This Error..The it Will Be Really Helpful.. :o

[cretindesalpes]

S_Prince:

You need the modified MVTools from the dither package instead of the regular one.

You can also replace the 3 last lines with just DitherPost().

[S_Prince]

S_Prince:

You need the modified MVTools from the dither package instead of the regular one.

You can also replace the 3 last lines with just DitherPost().
Thanks For The Reply.

Okay.Is this 1 called Modifed MVtools 'mvtools-2.6.0.5'..I Found it in dither package ;)

& Yes I shall try to replace the last 3 lines with ditherpost.I'll Surely try I will redirect the result to You.



Thanks

[Tanbheer]

Tanbheer:

Try this:
GradFun3 (thr=1.4*0.3, smode=2, lsb=true)
Dither_add_grain16 (var=0.8, uvar=0, soft=2)
DitherPost (mode=6)
Should be close, but not exactly the same because GradFun2DbMod applies the grain through a luma mask.
Thank you very much for your reply
I tried it. Giving me this error. I have used your modified mvtools2 also. but same error
http://imgit.me/i/9C6b3X4.jpg

[cretindesalpes]

You need a more recent version of AddGrainC (I think v1.4 or later ). Check this one (http://forum.doom9.org/showthread.php?p=1587215#post1587215), for example.

[Tanbheer]

You need a more recent version of AddGrainC (I think v1.4 or later ). Check this one (http://forum.doom9.org/showthread.php?p=1587215#post1587215), for example.

Thanks a lot man . It works now. Now i need to find a good de-noising filter which works best with GradFun3.
VagueDenoiser always worked great with GradFun2DBmod. I am sure your denoising scripts on dither package are great. Will try & check it out. Again very hard function i must say. There are so many parameters & options there :o Its like reading a rocket science.

[TheProfileth]

For the longest time I have been getting this error every time I try to use rgb or yv24 with dither tools it is odd.
For example I am using something close to one of the examples in the documentation AVCSource("stuff.dga")
Dither_convert_8_to_16 ()
Dither_convert_yuv_to_rgb (lsb_in=true,matrix="709", output="rgb48y",noring=true)
r = SelectEvery (3, 0)
g = SelectEvery (3, 1)
b = SelectEvery (3, 2)
Dither_convert_rgb_to_yuv (r, g, b, matrix="709",output="yv24", mode=6,noring=true)http://eypic.net/images/errorfif.png
Is something up with my mt_masktools or am I just doing something wrong?

[martin53]

With mv2tools.dll from the package 2.6.0.5 that is contained in dither 1.22.1, I frequently get the following error message:
MVTools: vector clip is too small (corrupted?)
([GScript], line 42)
([GScript], line 55)
([GScript], line 63)
(_FSubstitute.avsi, line 744)
...
With my 2nd most recent mvtools2.dll from the package mvtools-2.5.11.9-svp, I never see this error.

Unfortunately, I can not yet provide a simple example script that produces the error. It is produced when using my _FSubstitute script from the 'bye by blurred frames (http://forum.doom9.org/showthread.php?t=166446)' thread on various source clips. That script uses MVAnalyse in a not everyday manner during script compile time of the RTE to get global motion information with MDepan.
I posted version 01/13/2013 of that script with the actual code (from StainlessS) in the mentioned lines. The first line of the error msg is 'cGM.RT_AverageLuma(currentframe, w=1, h=1)', for your reference.

RT_AverageLuma() in this line forces the global motion clip cGM to be evaluated during script compile, so MDepan writes the global motion figures to the logfile. The logfile must be available for reading a few lines below when the motion figures are read to the string variable sMD.

[StainlessS]

Martin53, This will not solve the mvtools problem but,

you can use RT_YankChain(currentframe) instead of RT_AverageLuma(currentframe,w=1,h=1).
Also a little faster than I might have expected.
It just forced fetches the frame without any sampling.

[martin53]

( StainlessS,
thanks, will download your new package)

Here is more detail regarding the MVtools issue.

I stripped down my function a bit, and added debugging operations. Currentframe is just a copy of current_frame and is 6 at the end, iDelta is 1. Frames 2,5,6 are processed until the error occurs. With frame 2 and also iDelta=1, the whole script works good. With frame 5, the error currently appears, but in another function of the script that uses MVtools on the same frame after this function. After each source code change, there may be a then reproduceable issue with frame 5 in this function, or not before frame 6. I could not figure out a relation between the code changes (like is the ImageWriter function dot-appended to MAnalyse or in a separate line) and the first failing frame number. The failing frames also depend on how I navigate through the clip. The previous description is true when starting with frame 1 and then go forward frame by frame.

c_ = (iDelta==-1) ? c : c.FreezeFrame(currentframe-1, currentframe-1, currentframe+iDelta)
cS = c_.MSuper(pel=4)
cV = cS.MAnalyse(truemotion=true, global=true, isb=false, delta=1, search=3, pelsearch=4, searchparam=1, pzero=255, plevel=1, blksize=16, blksizeV=16, overlap=4, divide=2)
RT_debug("[<-]#"+string(currentframe), "Vector clip w=", string(cV.width)," h=",string(cV.height))
cVM = cV.ImageWriter(ScriptDir+"\cV", 0, 0, type="ebmp").RT_AverageLuma(currentframe, w=1, h=1)
cVM = 0
c
cGM = c_.MDepan(cV, log=LOGFILE, zoom=zoom>0, rot=rot>0, range=0, thSCD1=thSCD1, thSCD2=thSCD2)
cGM.RT_AverageLuma(currentframe, w=1, h=1) ### ERROR LINE ### # Force frame read of Global Motion clip, and MDepan testing.
cGM = 0 # Destructor of temp Global Motion clip called here and log file available after here (created in Destructor)
c # Hopefully destructor of temp last clip called here and log file available after here

sMD = RT_ReadTxtFromFile(LOGFILE)

- DebugView (from 1st blue code line) looks the same for all 3 processed frames: '[4168] RT_Debug: [<-]#6 Vector clip w= 33000 h= 1'
- an 'image' of all 3 processed vector clip frames is written (2nd blue code line), see attached archive if you are able to analyse that
- still, an error message over the clip says that the line with the red note fails because of a too small vector clip
- The new parameter mt=false with the MVtools functions did not help

I was wondering if the vector clip is not available at all at the right time - but the existence of the outputs of the blue lines indicates that it is there when MDepan is called...

Please tell me how I can contribute more.

[cretindesalpes]

I haven't checked this issue in detail yet, but I suspect something related to ScriptClip or other runtime functions. Actually, MVTools vector clips need that the filter that generated them (MAnalyse, MRecalculate…) is still instantiated when they are used. The reason is simple: the vector clips use a hack to attach private data to the clip descriptor (before the first frame is generated). The number of audio channels actually conveys a pointer to this data structure, which belongs to the filter, not to the clip. If the filter is deleted before the clip, or if multiple vector clips from different filters are merged, weird things can happen. The original MVTools have a minimal protection to check the validity of a vector clip but this was not enough. I added more error checking in my mod16 version, hence it's less tolerant to errors.

Of course there could be another reason but this is the first thing that comes in mind.

[martin53]

Are you suggesting that there is no solution to the issue, and that e.g. my script might have suffered from a hidden problem all the time?

I maybe could check this if I knew how to detect a certain suspicious misbehaviour of the previous versions.
I am sceptical though because then I think I would have seen sporadic unexpected results, but the whole thing *seems* to run satisfyingly with the mentioned older dll.

Of course, it would be a very sad end to the story if MVtools were just unable to do what is needed here.

The task was to get global motion data (pan, zoom rotate) between two arbitrary frames of a clip, in order to precompensate the global motion before e.g. MFlowInter resynthesizes a frame. My research had shown that the synthesized results are *much* better this way.

A hack to mix up a clip data structure with a filter instance data structure indeed sounds weird. Although I don't understand the reasons it was made this way, it sounds possible to add that structure to every frame of the vector clip instead, or solve the problem any other way - would that be something you could try?

EDIT: Or even if MDepan had a sister function that just returned the string MDepan writes to the log file. Then I could omit a bunch of tricks.

[Lenchik]

As a suggestion to future releases of dither plugin:
Add support for Rec.2020 (http://en.wikipedia.org/wiki/Rec._2020) colorimetry conversions. Don't know whether it is difficult keeping in mind that Rec. 2020 defines a color depth of either 10-bits or 12-bits (http://www.itu.int/rec/R-REC-BT.2020-0-201208-I/en).

[Chyrka]

Hi!
What the hell is:
http://thumbnails102.imagebam.com/23572/7164b4235710556.jpg (http://www.imagebam.com/image/7164b4235710556)
when I use

Dither_convert_8_to_16 ().Dither_resize16(784,574,0, 2, -0, -0,"spline64")
DitherPost (mode=-1)
instead of
http://thumbnails101.imagebam.com/23572/ddf343235710574.jpg (http://www.imagebam.com/image/ddf343235710574)
when I use

Spline64Resize(784,574,0,2,0,0)
:confused:

It doesn't happen with zero cropping
Dither_resize16(784,574,0, 0, -0, -0,"spline64")
Also usacale/downscale/in-out picture size doesn't matter.
And heignt of messed up stripe at the bottom is proportional to top-cropped pixel amount.

[cretindesalpes]

Chyrka:

It looks like an discrepancy between the avs and dither resizing functions regarding the value of 0 for src_width and src_height. In Dither_resize16, 0 means "input width or height" whereas in XxxResize it works exactly like in Crop(). I'll probably change this behaviour in the next release to match the Avisynth resizers.

Lenchik:

It's possible for the R’G’B’<->Y’Cb’Cr’ conversion but keep in mind that the RGB colorspace has not the same primaries (at all) as the Rec.601/Rec.709 colorspaces. It would require a conversion between these colorspaces with a 3D LUT.

Dogway:

How could I solve the problems you report if you delete your posts?

[Overdrive80]

Hi, actually I am using ditherpack for filtering. However I had have troubles with mvtools for this pack. I am doing vfr file with this script:

In first pass, I deinterlace video file encoding with lagarith:

DGDecode_mpeg2source("C:\Users\Isra\Desktop\Bleach\VID 2\VideoFile1.d2v", info=3)

ColorMatrix(hints=true, threads=0,interlaced=true)

part1=trim(0,38811).tfm().tdecimate()
part2_in=trim(38812,41089)


part2=part2_in.QTGMC( Preset="very Slow", EdiMode="EEDI2",fpsdivisor=2).aaf().assumefps(part1.framerate)

part1++part2

In secong pass, filtering video:

SetMemorymax(1024)
setmtmode(5,4)

avisource("F:\001\1. Desentralazar.avi")

#Desentrelazado
#Crop & resize

crop(4,0,-4,0).Spline64resize(720,480)

# Filtrado

Setmtmode(3)

original=last

aa=spline64Resize(width(original)*2,height(original)*2).SangNom(aa=29).spline64Resize(width(original),height(original)).mergechroma(original).finesharp(sstr=1.8)


prefiltrado= dfttest(sigma=4,tbsize=1,tmode=0,lsb=true).ditherpost(mode=2)

super=Msuper(prefiltrado)

backward_vec3 = MAnalyse(super, isb = true, delta = 3, overlap=4,search=4)
backward_vec2 = MAnalyse(super, isb = true, delta = 2, overlap=4,search=4)
backward_vec1 = MAnalyse(super, isb = true, delta = 1, overlap=4,search=4)

forward_vec1 = MAnalyse(super, isb = false, delta = 1, overlap=4,search=4)
forward_vec2 = MAnalyse(super, isb = false, delta = 2, overlap=4,search=4)
forward_vec3 = MAnalyse(super, isb = false, delta = 3, overlap=4,search=4)

prefiltrado.MDegrain3(super,backward_vec1,forward_vec1,backward_vec2,forward_vec2,backward_vec3,forward_vec3,
\plane=3,lsb=true).ditherpost(mode=2)

contrasharpening(last,aa)

toon(0.15)

gradfun3()

If I use plane=4 or 1, I got this https://dl.dropbox.com/u/19135067/example.avi

And if I use other option crash operation. Log:

VirtualDub crash report -- build 32842 (release)
--------------------------------------

Disassembly:
02d0b3c0: 0feada pminsw mm3, mm2
02d0b3c3: 660ff9cb psubw xmm1, xmm3
02d0b3c7: 660f6f5c2460 movdqa xmm3, [esp+60h]
02d0b3cd: 660f65d9 pcmpgtw xmm3, xmm1
02d0b3d1: 660f6fe1 movdqa xmm4, xmm1
02d0b3d5: 660fd54c2450 pmullw xmm1, [esp+50h]
02d0b3db: 660ff94c2470 psubw xmm1, [esp+70h]
02d0b3e1: 660f65a4248000 pcmpgtw xmm4, [esp+80]
0000
02d0b3ea: 660f6ffd movdqa xmm7, xmm5
02d0b3ee: 660f71d701 psrlw xmm7, 01h
02d0b3f3: 660ff9c7 psubw xmm0, xmm7
02d0b3f7: 660fe5c1 pmulhw xmm0, xmm1
02d0b3fb: 660f6f8c249000 movdqa xmm1, [esp+90]
0000
02d0b404: 660f71f002 psllw xmm0, 02h
02d0b409: 660f6fd3 movdqa xmm2, xmm3
02d0b40d: 660fdb5c2440 pand xmm3, [esp+40h]
02d0b413: 660febd4 por xmm2, xmm4
02d0b417: 660f6ff5 movdqa xmm6, xmm5
02d0b41b: 660ff9f0 psubw xmm6, xmm0
02d0b41f: 660fdfd6 pandn xmm2, xmm6
02d0b423: 660f6fc1 movdqa xmm0, xmm1
02d0b427: 660febd3 por xmm2, xmm3
02d0b42b: 660fdbe5 pand xmm4, xmm5
02d0b42f: 660febd4 por xmm2, xmm4
02d0b433: 660fdbc2 pand xmm0, xmm2
02d0b437: 660fdfca pandn xmm1, xmm2
02d0b43b: 660f73d901 psrldq xmm1, 01h
02d0b440: 660f67c1 packuswb xmm0, xmm1
02d0b444: 660fd60402 movq [edx+eax], xmm0 <-- FAULT
02d0b449: 660f6dc0 punpckhqdq xmm0, xmm0
02d0b44d: 660fd60401 movq [ecx+eax], xmm0
02d0b452: 83c008 add eax, 08h
02d0b455: 836c242001 sub dword ptr [esp+20h], 01h
02d0b45a: 89442428 mov [esp+28h], eax
02d0b45e: 0f85c8fcffff jnz 02d0b12c
02d0b464: 5f pop edi
02d0b465: 5e pop esi
02d0b466: 5b pop ebx
02d0b467: 8be5 mov esp, ebp
02d0b469: 5d pop ebp
02d0b46a: c21c00 ret 001c
02d0b46d: cc int 3
02d0b46e: cc int 3
02d0b46f: cc int 3
02d0b470: 83e940 sub ecx, 40h
02d0b473: e968f1ffff jmp 02d0a5e0
02d0b478: cc int 3
02d0b479: cc int 3
02d0b47a: cc int 3
02d0b47b: cc int 3
02d0b47c: cc int 3
02d0b47d: cc int 3
02d0b47e: cc int 3
02d0b47f: cc int 3
02d0b480: b818040100 mov eax, 00010418
02d0b485: e826a80100 call 02d25cb0
02d0b48a: a1f8b0d302 mov eax, [02d3b0f8]
02d0b48f: 33c4 xor eax, esp
02d0b491: 89842414040100 mov [esp+10414], eax
02d0b498: 53 push ebx
02d0b499: 55 push ebp
02d0b49a: 56 push esi
02d0b49b: 57 push edi
02d0b49c: 8d84241c020000 lea eax, [esp+21c]
02d0b4a3: 33f6 xor esi, esi
02d0b4a5: 50 push eax
02d0b4a6: 8d7c2418 lea edi, [esp+18h]
02d0b4aa: 33ed xor ebp, ebp
02d0b4ac: 89742414 mov [esp+14h], esi
02d0b4b0: e89b010000 call 02d0b650
02d0b4b5: 83c404 add esp, 04h
02d0b4b8: 8bcf mov ecx, edi
02d0b4ba: 51 push ecx
02d0b4bb: 6a01 push 01h
02d0b4bd: 68 db 68h
02d0b4be: 0000 add [eax], al

Built on Aegis on Fri Dec 24 13:18:44 2010 using compiler version 1400

Windows 6.1 (Windows Vista x64 build 7601) [Service Pack 1]

EAX = 47920020
EBX = 000001e0
ECX = b86dffe0
EDX = b87345e0
EBP = 38e0b574
ESI = 38e0b5bc
EDI = 00443214
ESP = 38e0b4d0
EIP = 02d0b444
EFLAGS = 00010a03
FPUCW = 027f
FPUTW = ffff

Crash reason: Access Violation

Crash context:
An out-of-bounds memory access (access violation) occurred in module 'dither'...

...writing address 00054600.

Pointer dumps:

EAX 47920020: 53535351 53535353 53535353 52525253 53535353 53535353 53535353 53535353
ESI 38e0b5b8: 000001e0 02d2f1c8 00000000 00000000 00000000 00000000 00000000 00000000
EDI 00443210: 0000b887 8b8b9900 000000b8 a3f7ca23 000000b8 0005d12b 83800000 958900d2
ESP 38e0b4d0: 142cce38 4fc30020 47920020 00000000 00000000 00000416 000003f6 01392cb0
38e0b4f0: 0000005a 000003f7 47920020 08310000 00054600 b87345e0 08364600 b86dffe0
38e0b510: 536e536c 536f5370 536e536e 536e536d 06660666 06660666 06660666 06660666
38e0b530: 00150015 00150015 00150015 00150015 065e065e 065e065e 065e065e 065e065e
EBP 38e0b570: 47922a50 47974620 02d0ae55 38e0b5bc 00000000 00054600 47920020 47974620
38e0b590: 4fc30020 4fc84620 ea888816 00000000 38e0f6ac 000002d0 4fc84620 00054600
38e0b5b0: 00000000 4fc30020 000001e0 02d2f1c8 00000000 00000000 00000000 00000000
38e0b5d0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

Thread call stack:
02d0b444: dither!_AvisynthPluginInit2@4 [02cf0000+a460+10fe4]
02d0ae55: dither!_AvisynthPluginInit2@4 [02cf0000+a460+109f5]
02d0ad48: dither!_AvisynthPluginInit2@4 [02cf0000+a460+108e8]
02d0ad07: dither!_AvisynthPluginInit2@4 [02cf0000+a460+108a7]
02d0aba8: dither!_AvisynthPluginInit2@4 [02cf0000+a460+10748]
02d16151: dither!_AvisynthPluginInit2@4 [02cf0000+a460+1bcf1]
02d0a75b: dither!_AvisynthPluginInit2@4 [02cf0000+a460+102fb]
6e56cde5: AviSynth!avs_delete_script_environment [6e500000+68d20+40c5]
6e56b9f2: AviSynth!avs_delete_script_environment [6e500000+68d20+2cd2]
6e56add3: AviSynth!avs_delete_script_environment [6e500000+68d20+20b3]
02cfd960: dither!_AvisynthPluginInit2@4 [02cf0000+a460+3500]
02b649b6: avstp!avstp_wait_completion [02b60000+4830+186]
02b64827: avstp!avstp_enqueue_task [02b60000+47f0+37]
02cfb4e2: dither!_AvisynthPluginInit2@4 [02cf0000+a460+1082]
02b64761: avstp!avstp_destroy_dispatcher [02b60000+4720+41]
02cf5e11: dither!00005e11
77ae33f7: ntdll!RtlInterlockedFlushSList [77ab0000+32775+c82]
77acfab2: ntdll!NtAllocateVirtualMemory [77ab0000+1faa0+12]
77aee605: ntdll!NtdllDefWindowProc_A [77ab0000+3e5e2+23]
77ae3426: ntdll!RtlInterlockedFlushSList [77ab0000+32775+cb1]
02ea5a74: lagarith!00005a74
77ade35c: ntdll!RtlInitUnicodeString [77ab0000+2e1f8+164]
77ae3426: ntdll!RtlInterlockedFlushSList [77ab0000+32775+cb1]
77ae3054: ntdll!RtlInterlockedFlushSList [77ab0000+32775+8df]
77b1031c: ntdll!RtlFindMessage [77ab0000+5fcbd+65f]
77b10343: ntdll!RtlFindMessage [77ab0000+5fcbd+686]
77acf9b9: ntdll!NtSetEvent [77ab0000+1f9a4+15]
77aeb591: ntdll!RtlpUnWaitCriticalSection [77ab0000+3b56c+25]
77aeb562: ntdll!RtlIntegerToUnicodeString [77ab0000+3b19d+3c5]
77acf8b1: ntdll!NtWaitForSingleObject [77ab0000+1f89c+15]
77aeb4c4: ntdll!RtlIntegerToUnicodeString [77ab0000+3b19d+327]
76099d45: msvcrt!malloc [76090000+9cee+57]
7609b0d7: msvcrt!??2@YAPAXI@Z [76090000+b0c9+e]
77acf9b9: ntdll!NtSetEvent [77ab0000+1f9a4+15]
6e56601a: AviSynth!0006601a
6e564e6a: AviSynth!00064e6a
02d16151: dither!_AvisynthPluginInit2@4 [02cf0000+a460+1bcf1]
02d0a75b: dither!_AvisynthPluginInit2@4 [02cf0000+a460+102fb]
6e56cde5: AviSynth!avs_delete_script_environment [6e500000+68d20+40c5]
6e56b9f2: AviSynth!avs_delete_script_environment [6e500000+68d20+2cd2]
6e56add3: AviSynth!avs_delete_script_environment [6e500000+68d20+20b3]
02cf4edc: dither!00004edc
6e564e6a: AviSynth!00064e6a
02d16151: dither!_AvisynthPluginInit2@4 [02cf0000+a460+1bcf1]
02d0a75b: dither!_AvisynthPluginInit2@4 [02cf0000+a460+102fb]
6e56cde5: AviSynth!avs_delete_script_environment [6e500000+68d20+40c5]
6e56b9f2: AviSynth!avs_delete_script_environment [6e500000+68d20+2cd2]
6e5711a7: AviSynth!DllCanUnloadNow [6e500000+6ea80+2727]
7705338a: kernel32!BaseThreadInitThunk [77040000+13378+12]
77aebf42: ntdll!RtlInitializeExceptionChain [77ab0000+3bedf+63]
77aebf15: ntdll!RtlInitializeExceptionChain [77ab0000+3bedf+36]

-- End of report

[cretindesalpes]

I couldn't reproduce the crash but got the artefacts. They seem related to only MSuper/MAnalyse/MDegrain in MT mode 3 (it works well in MT mode 2, in single-threaded mode or stepped frame by frame manually in MT 3), and not dependent on the lsb parameter. I'm going to investigate this further as I don't know much about what MT mode 3 does.

[Overdrive80]

I tried use different modes on MT, but result is the same. However, I encoding without MDegrain and not occurs.

[TheProfileth]

Hey cretindesalpes, so I have been messing with stuff lately and I rediscovered a filter that I quite liked that utilizes a standard median but makes it a bit more applicable to general use the only issue was that it was excruciatingly slow and didn't support 16bit. I am speaking of BucketMedian where the latest version cane be found here (https://github.com/chikuzen/BucketMedian/). https://github.com/chikuzen/BucketMedian/
Either way my request of you was if you could possibly implement the limiting system into the dithertools median. Would be very useful especially given its ability to help in the process of debanding by homogenizing regions seen here (http://2.bp.blogspot.com/-DHnJAnGEaYY/T38SwtO2n1I/AAAAAAAAAJ8/CL4M7ormi0o/s1600/BucketTest000328.png) the introduction of the limiters would make the median filter an even more helpful tool for both denoising and debanding.
Also keep up the good work :)

[Elvellon]

Hi, there's a discussion going on a local forum. Is 16 bit resizing only useful when the unscaled image has been denoised and/or debanded in 16 bits, i.e., the noise/dither has been messed with and we need to keep 16 bits through resizing? Is Dither_convert_8_to_16().Dither_resize16(W,H).DitherPost() rather useless?

[mandarinka]

Hmm, I wanted to test something and needed a 16bit version of plain avisynth merge(), to do a 50:50 weighting of two clips. What would be a good way to script that?

I was thinking about Dither_merge16 with luma=true and a mask with luma set to 32768, but that sounds hacky (also, is that a proper luma center for this purpose?)

[06_taro]

Why not simply use Merge(a16, b16, weight) for those 16-bit clips?

For 16-bit stacked msb+lsb clips:
new_value16
= a16 * ( 1 - weight ) + b16 * weight
= ( msb_a * 256 + lsb_a ) * ( 1. - weight ) + ( msb_b * 256 + lsb_b ) * weight
= ( msb_a * ( 1. - weight ) + msb_b * weight ) * 256 + ( lsb_a * ( 1. - weight ) + lsb_b * weight )
which equals to StackVertical(Merge(msb_a, msb_b), Merge(lsb_a, lsb_b)), and equals exactly to Merge(a16, b16) as merge is only a per-pixel linear combination without overflow/underflow.
So Merge works for 16-bit inputs as well.

[mandarinka]

Isn't there going to be a +-0,5 rounding error in the merged MSB? That sorta makes it sorta pointless to process with LSB after it...

Unless I am viewing it wrong.

[06_taro]

Ah my fault, yes merge is done in floating point and msb may need to be rounded.

[mandarinka]

Hmm, I'll go with:

Dither_merge16(16bitclipA,16bitclipB, Dither_convert_8_to_16().dither_lut16("32768"),luma=true))

[bennynihon]

cretindesalpes, I just stumbled on this filter after getting some unsatisfactory banding when encoding Blu-ray disks using x264 at crf 22. Amazing work.

But I'm curious what settings people would suggest when wanting to encode film Blu-ray sources. Currently, I'm using the following as it seems to be a great compromise in terms of quality and speed.

GradFun3(thr=1.2 * 0.3, smode=0, lsb=true)
Dither_add_grain16(var=0.8, uvar=0, soft=2)
DitherPost(mode=0)

But given that these are clean Blu-ray sources without any discernible banding in the source, the GradFun3() call may be unnecessary. Ultimately what I'm after is the ability to selectively add dither to flat areas of a frame, to reduce the likelihood that banding will occur in these areas after encoding it with x264. As it is now, I feel as if I'm first debanding the source, then adding grain to the entire frame, then dithering. I'd like to selectively add grain/dither to flat areas as I mentioned. Any pointers as to what might be good options to try? Thank you!

[bennynihon]

Is there a way to combine the MSB portion of one source, and the LSB portion of another to create a 16-bit stacked clip? Basically, I'd like to use Dither_add_grain16, but only add the grain to the LSB of the source.

[mandarinka]

clipA.Dither_get_lsb() will give you teh least significant bits separately from clipA

clipB.Dither_get_msb() will give you the most significant bits from another clipB

You can combine it simply with stackvertical, in this case: stackvertical(clipB.Dither_get_msb(),clipA.Dither_get_lsb())

PS.
No disrespect, but due to the way gradfun3 works, it oversmooths the source quite a bit. Maybe try to use flash3kyuu_deband (http://forum.doom9.org/showthread.php?t=161411) first - it is much milder to the source (detail) as far as my experience goes and debands pretty well at the same time.

[bennynihon]

clipA.Dither_get_lsb() will give you teh least significant bits separately from clipA

clipB.Dither_get_msb() will give you the most significant bits from another clipB

You can combine it simply with stackvertical, in this case: stackvertical(clipB.Dither_get_msb(),clipA.Dither_get_lsb())

PS.
No disrespect, but due to the way gradfun3 works, it oversmooths the source quite a bit. Maybe try to use flash3kyuu_deband (http://forum.doom9.org/showthread.php?t=161411) first - it is much milder to the source (detail) as far as my experience goes and debands pretty well at the same time.

Thanks. stackvertical was what I was looking for. Adding grain just to the LSB and then dithering isn't as powerful against banding when encoding as simply letting it apply grain to all 16-bits. I'll continue doing that.

[x265]

should i use a dehalo filter before or after converting to 16bits using the Dither_convert_8_to_16( )? Is the code correct?

DGSource("C:\Users\Abhijith Nair\Desktop\location\Episode.dgi")
Interp=NNEDI3(nns=4, qual=2, pscrn=4)
deint = tdeint(edeint=Interp, emask=tmm())
tfm(pp=6, micmatching=2, slow=2, clip2=deint)
smartfade(dgm=true)
tdecimate(mode=1)
Episode=trim(1918, 30688)
Preview=trim(32368, 32727)
Opening=avisource("opening.avs")
Ending=avisource("ending.avs")
AlignedSplice(Opening, Episode, Ending, Preview)
Dehalo_Alpha_mt(ss=3.0)
Dither_Convert_8_to_16()
Dither_crop16(2,4,-2,0)
GradFun3(thr=0.48, smode=2, lsb_in=true, lsb=true)
Dither_Quantize(bitdepth=10, reducerange=true, mode=0)
Dither_Out()

[feisty2]

should i use a dehalo filter before or after converting to 16bits using the Dither_convert_8_to_16( )?

depands on your dehalo filter supports 16bit or not
if your dehalo script supports 16bit process first upsample to 16bit and turn on "lsb_in" parameter

[x265]

Should i use smode=3 or 2 for the gradfun3 filter?

[ajp_anton]

Nevermind =).

[Yellow_]

Hi, have a quick query regarding function: Dither_convert_rgb_to_yuv

Converts an RGB clip to YUV using high bitdepth calculations.

src

An 8 or 16-bit RGB clip to be converted to RGB. if only src is defined, the clip is considered as 8-bit RGB. If g and b are defined too, the three are assumed as 16-bit stacked clips containing the red, green and blue channels.... I guess this is for importing "rgb48y", ie: R,G,B planes as YCC? Is it possible to import 16bit per channel RGB imagery through Dither Tools, or should I be looking at another plugin, sure there was one sometime ago that would handle 16bit?

**EDIT**

No bother I've resolved this query. :-) But got a new one.

[Yellow_]

I have a problem using dfttest packaged with Dither Tools with 16bit planar YCC 4:4:4 YV24

This is an extract of the script:

MSB = RawReadPlanar("yuv444p16le.yuv", "YUV444", 1088, 448, packing="16:0:8").ConvertToYV24()
LSB = RawReadPlanar("yuv444p16le.yuv", "YUV444", 1088, 448, packing="16:8:8").ConvertToYV24()
StackVertical(LSB, MSB)

When I add:

Dfttest(sigma=0.25, lsb=true, lsb_in=true)

The output is a complete frame as the original source except it's obviously stacked16 but exactly 1 quarter of the image (bottom left hand quarter has red, blue and green chroma noise overlaid the 'proper' image. I guess this is because it's 4:4:4 but whether it's a bug or just unsupported I'm unsure. It only happens with a denoiser.

[Reel.Deel]

Dfttest only supports YV12 and YUY2. That's strange how it doesn't give an error with YV24.
I've tried using it with Y8 and I got the colorspace error. That's the only reason I know. :)

[Yellow_]

Thanks, ok I'll go on a hunt for a denoiser for YV24 or find a work around.

[zero9999]

This change in AviSynth 2.6a4 broke GradFun3 with radiusc:


* Force int call arguments to user script function float params to be explicit floats.


fix:

Function GradFun3 (clip src, float "thr", int "radius", float "elast",
\ int "mask", int "mode", float "ampo", float "ampn", int "pat",
\ bool "dyn", float "dthr", int "smode", float "wmin", float "thr_det",
\ float "thr_edg", int "debug", int "subspl", bool "lsb", bool "lsb_in",
\ bool "staticnoise", float "thrc", int "radiusc", float "elastc",
\ int "y", int "u", int "v")

[spawnbsd]

cretindesalpes, now that x264 supports BT2020 colorimetry, any chance we can get an update to dither tools with proper BT2020 support ? =)

[cretindesalpes]

Yes people already asked me about BT.2020. Sorry for my slow replies, I’m not visiting the forum regularly these days and didn't code much for the Dither tools either. I want to finish optimizing fmtconv for Vapoursynth first, then backport the changes to Dither and finally add new features. I may release a quickfix in the meantime for various problems reported with the latest Avisynth 2.6a4.