Color banding and noise removal

[tormento]

Increase in file size. I'll test and report.

[atra dies]

Although it's technically correct, denoising in linear light isn't necessary, because usually noise pixel values are close to each other. Operating in linear light is better when averaged pixel values are far. Moreover, the current modified MDegrain accepts only 8-bit input, and the conversion to 8-bit linear is not recommended because of the important resolution loss in the dark range.

Nevermind. I now realize mvtools only had lsb out and should have known that's what was meant from the lsb part of the doc.
I wanted to raise y levels before mdegrain but I don't care now as I think I want to denoise before any other filtering anyway.
Dogway says his lsb in is a hack, he's on vacation and file set to private anyway.

I'm kinda spooked after I looked at that degrain comparison thread. I don't want to lose fine details but this is an old technoscope movie from the early 70s that has a cbr of 7mbps and I want to shrink file size while degraining. Mdegrain removes that blocking that results when encoding the film grain to 480p.

As for the resize, I want to test results now by viewing the downsize through an upsizer that most closely emulates an HDTV upsizer. What kernel would you recommend?
Before I just let AVSpmod upsize it and I think it uses point or nearest neighbor for its display.

[tormento]

What? So if I want to use mdegrain, I have to put it outside of the 16 bit section?
Try newer SMDegrain. It works in 16bit domain.

[dadix]

It would be so good if this script would have a deblock function

[Serenato]

Hello!
I have a problem with the green screen after adding GradFun3() to the script. It goes like this:
LoadPlugin ("C:\Program Files (x86)\AviSynth 2.5\plugins\dither.dll")
Import ("C:\Program Files (x86)\AviSynth 2.5\plugins\dither.avsi")
Import ("C:\Program Files (x86)\AviSynth 2.5\plugins\mt_xxpand_multi.avsi")
v1=DirectShowSource("D:\video.mkv",audio=false)
v2=DirectShowSource("D:\tips01.mp4",audio=false)
v1 ++ v2
TextSub("D:\logo.ass")
TextSub("D:\Op-Ed 01.ass")
ConvertToYV12()
GradFun3 ()

I have a copy of mt_masktools-26-x64.dll in the SySWOW64 folder and mvtools2.ll, mt_xxpand_multi.avsi, MT.dll, dither.dll in my avisynth's plugin folder. I'm rather confused, so perhaps I pasted something to the wrong place. The script is running, but the preview video is green.
Thanks for your help in advance!

[atra dies]

Hello!
I have a problem with the green screen after adding GradFun3() to the script. It goes like this:
LoadPlugin ("C:\Program Files (x86)\AviSynth 2.5\plugins\dither.dll")
Import ("C:\Program Files (x86)\AviSynth 2.5\plugins\dither.avsi")
Import ("C:\Program Files (x86)\AviSynth 2.5\plugins\mt_xxpand_multi.avsi")
v1=DirectShowSource("D:\video.mkv",audio=false)
v2=DirectShowSource("D:\tips01.mp4",audio=false)
v1 ++ v2
TextSub("D:\logo.ass")
TextSub("D:\Op-Ed 01.ass")
ConvertToYV12()
GradFun3 ()

I have a copy of mt_masktools-26-x64.dll !

You are running 2.5 so you need the masktools 25 dll.
masktools26 dll is for avisynth 2.6.
Also any plugin in the plugin folder is auto loaded so you don't need to load it in the script.

[cretindesalpes]

Try to remove your masktools dll file. If it still outputs a green screen without complaining about a missing function, that's because you have another masktool file loaded by Avisynth. Find and remove it, and retry until Avisynth can't find the masktools functions. Then you can copy again the right masktools dll in your plugin folder.

[Serenato]

Okay, I deleted every masktools and tried to run the script after I pasted the mt_masktools-26-x64.dll to the SySWOW64 folder, but it gave the green screen again. I removed it, then I got the error saying "there is no function named "mt_expand". Is it normal, right?

[cretindesalpes]

Make sure that your dll is from the Masktools version 2 alpha 48. Previous versions won't work and give a green screen. The dll should be located in the Avisynth plugin folder, not in SySWOW64. Also, I don't know if it works with the x64 version; try the 32-bit dll too.

[Serenato]

Oh, wow, it's really working! Thank you a lot!

[TheProfileth]

BTW I have been wondering this for a while but, why is there no dither_lut16xy(z)? I mean if you can already handle dither_lut16 what is the difference between adding another variable? Or am I wrong to think that it is that simple?

[cretindesalpes]

TheProfileth:

See my reply to SSH4 (http://forum.doom9.org/showthread.php?p=1522318#post1522318).

[ajp_anton]

Amount of RAM needed (hope I did it correctly):
8-bit LUT (x, xy, xyz): 256B, 64kiB, 16MiB
16-bit LUT (x, xy, xyz): 64kiB, 4GiB, 256TiB

edit: Yes I did it wrong, the 16-bit LUTs should be double that (forgot the output is also 16-bit). So 128kiB, 8GiB and 512TiB.

[TheProfileth]

TheProfileth:

See my reply to SSH4 (http://forum.doom9.org/showthread.php?p=1522318#post1522318).

Ah sorry did not see that, makes sense though I was thinking about it after I made that post, just considering the massive increase in numerical values available I am amazed you even got dither_lut16 to work. Well either way I guess my question is, is it ok to use mt_lutxy on a 16bit clip? If not is there something that could be done to help atleast achieve similar results?

[ajp_anton]

Well the lut16 isn't that difficult really. I was wrong in my previous post, but it still only needs 128kiB of RAM.
You can easily do it by combining two mt_lutxy's. One for MSB, one for LSB, and they both take MSB and LSB as separate inputs.

For that same method, for a lutxy16 you would need to use two of "mt_lutxyzw" and use up pretty much all your memory.

For a LUT for an arbitrary function, you can't really get around the amount of RAM needed. You would need something that calculates the pixels individually on the fly, or maybe a special case that can be simplified somehow.

edit: A semi-lutxy16 can be made though where one of the input clips is 8-bit, using two mt_lutxyz =).
edit2: You can do any lutxy where the input clips have a combined bitdepth of 24-bits, so 16/8 or 12/12 for example. Which combination it is doesn't really matter, you just have to re-order the bits into 3x 8-bit, so they can be imported with mt_lutxyz.

[gyth]

You would need something that calculates the pixels individually on the fly
Does anything do this already or is it so slow that anyone skilled enough to make it would know they shouldn't?

[titlis]

While seeing post about gamma correction,
some idea came up to me.

dither_convert_8_to_16()
dither_y_gamma_to_linear(curve="709")
dither_y_linear_to_gamma(curve="srgb")
ditherpost()

Would this compensate transfer function difference between
Rec.709 and sRGB?
(As most computer monitor use sRGB transfer function)

[cretindesalpes]

titlis:

This would be a good approximation, indeed. But just an approximation because the gamma curve should be applied on RGB components, not the signal luma. The latter method would involve a double colorspace conversion, which is lossy (chroma blurring or ringing). Pick your poison. Anyway, correctly compensating the Rec 709 transfer function should be the player or display's job, via a color profile. Or you'd have to have a mix of tags in the encoded stream: 709 matrix and color primaries with sRGB transfer characteristics, but I don't know if it's even possible.

gyth & ajp_anton:

There are many possible alternatives to the straigth 2D- or 3D-LUTs in 16 bits. But they require some kind of compromises: interpolation, computation on the fly, etc. This makes the coding more complex and the use less interesting than the usual 8-bit LUTs. So it's possible, but requires efforts…

[titlis]

Didn't Gamma apply only to the Luma?
I thought chroma is independent to gamma.

[tormento]

Is this AddGrainC 1.61 (http://forum.doom9.org/showthread.php?p=1534816#post1534816) compatible with your script?

[cretindesalpes]

Try it. If you find a problem, please report it.

[tormento]

I've done some encodings with almost 8-10GB memory usage with 12 threads on 8 cores, stability seems to be ok ;)

I'll watch results in the following days and I'll report quality.

[TheProfileth]

So first off I should say I am trying to use the width of the frame to help autofind a good thr for Smoothgrad but while doing this I ran into this issue.
The error that is occuring for me, is whenever I use either Smoothgrad or Dither_limit_dif16, if I set thr to be something like thr=(704/720) it says "thr must be a strictly positive number" same thing happens if I set it to be thr=(960/1280) the weird part is if I actually put in the decimal amount such as 0.75 for 960/1280 or 0.97777777777777777777777777777778 for 704/720 it works.
Also if I try to calculate externally the amount outside of the function such as doing
for SD
input=last
w=input.width()
thr=w/720
input.Dither_convert_8_to_16()
smoothgrad(thr=thr,u=2,v=2)
for HD
input=last
w=input.width()
thr=w/1280
input.Dither_convert_8_to_16()
smoothgrad(thr=thr,u=2,v=2)
it still gives me issue
the thing that might be part of the issue is how the numbers are being stored because it seems to mess up also if I do
input=last
w=input.width()
thr=w/720
thr=thr*thr
thr=thr/thr
input.Dither_convert_8_to_16()
smoothgrad(thr=thr,u=2,v=2)
it says that I am dividing by zero :scared:
when was the last time that
x>0
(x*x)/x=0
Very confused I am in this weird venture either way I hope someone can help me with this, hopefully it is just me being silly and not some big issue or something.

[cretindesalpes]

In Avisynth, dividing an integer number by another integer number gives an integer number. Therefore 704 / 720 = 0. If you want the correct result, specify the operands as floating point data: 704.0 / 720.0 = 0.9777… Or Float(blah1) / Float(blah2) if you use variables. Also for thr != 0, thr=thr*thr then thr=thr/thr will give 1, not thr.

Just out of curiosity, why setting the thr value according to the picture size? I would understand for radius, but thr? :confused:

[TheProfileth]

In Avisynth, dividing an integer number by another integer number gives an integer number. Therefore 704 / 720 = 0. If you want the correct result, specify the operands as floating point data: 704.0 / 720.0 = 0.9777… Or Float(blah1) / Float(blah2) if you use variables. Also for thr != 0, thr=thr*thr then thr=thr/thr will give 1, not thr.

Just out of curiosity, why setting the thr value according to the picture size? I would understand for radius, but thr? :confused:
Thanks I hope that helps, and btw I was doing it for both thr and radius just mainly had the issue with thr :D

[Yellow_]

Hi I'm getting an error with "Dither_convert_yuv_to_rgb(matrix="601", tv_range=false, cplace="MPEG2", chromak="bicubic", lsb_in=true, output="rgb48y")" now which never used to happen, using Dither 1.13.0 onwards all give same error. Have the correct masktools 2a 48.

error is: mt_lutxy:unsupported colorspace. Masktools only support planar YUV colorspaces (YV12, YV16, YV24) dither.avsi, lines 773, 752, 263

Source is YV12 and the only line after ffmpegsource2(file) is Dither_Convert_8_to_16()

Just converting 8 to 16 works, gives me stacked video over green frame, adding:

Dither_y_gamma_to_linear (tv_range_in=false, tv_range_out=false, curve="709") gives me a 'noisy' green frame so everything working as expected except adding Dither_convert_yuv_to_rgb...... before gives planar error. :-(

[cretindesalpes]

Are you using mt_masktools-25.dll with Avisynth 2.6 ? In other words, can you feed the masktools functions with Y8 clips ? That would explain. I'll try to find a decent workaround for this case.

Edit : in the meantime, in dither.avsi, try to replace the "vers < 2.60" with "true" line 206, 214, 217, 317 and 384.

[Yellow_]

Actually no, not using 2.6. I'm using 2.5 with mt_masktools-25.

[Kraise]

Hey, first of all thanks for making these great filters.
I only used avisynth for small things over the years so I'm still not too familiar with it. I was directed to this topic on how to encode to 10bit and make the gradients smooth in anime.

I read through half the topic not understanding a thing almost, and just got done reading some of the documentation but I still feel confused, so I have a couple of questions...

1: I can't notice banding in my DVD footage, should I still use this if I'm encoding to 10bit?

1.1: Is DVD/Blu Ray already 10 bit from the source .m2ts / .vobs?

1.2: Can we bring already 8bit sources and achieve the debanding effect still? I.E. if I wanted to bring an anime opening and add karaoke effects to it and render it back out lossless.



Sorry if those were dumb questions, I don't even know a proper script but here's one I just made up, please tell me if it's right.




If my source had no noise, and I just wanted to perform debanding before encoding I would do this? Then send it to megui?


mpeg2source("E:\Backup\VTS_05_2.d2v")
Crop(0, 0, -0, -0)
Lanczos4Resize(640, 460)

GradFun3(lsb=true)
Dither_convey_yuv4xxp16_on_yvxx ()
avs2yuv -raw "E:\script.avs" -o - | x264-10bit --demuxer raw --input-depth 16 --input-res 640x460 --fps 23.976 --output "E:\test.mp4" -



I tried previewing just this in VirtualDub and I get a strechted aspect ratio and the screen has fadded green lines and artifacts over it. Is that normal?
[CODE]mpeg2source("E:\Backup\VTS_05_2.d2v")
Crop(0, 0, -0, -0)
Lanczos4Resize(640, 460)

GradFun3(lsb=true)





and if my source had noise and I wanted to denoise and sharpen I would do this? (I added my favorite sharpener, I don't know if that's how it works or not, but you can't sharpen the footage after using dfttest() with normal sharpeners right?

LSFmod(strength=120)

mpeg2source("E:\Backup\VTS_05_2.d2v")
Crop(0, 0, -0, -0)
Lanczos4Resize(640, 460)
dfttest (sigma=16, lsb=true)
f = DitherPost (mode=-1)
s = LSFmod(strength=120)
d = mt_makediff (s, f)
DitherPost ()
mt_adddiff (last, d, u=2, v=2)
SmoothGrad ()
Dither_convey_yuv4xxp16_on_yvxx ()
avs2yuv -raw "E:\script.avs" -o - | x264-10bit --demuxer raw --input-depth 16 --input-res 640x460 --fps 23.976 --output "E:\test.mp4" -

[cretindesalpes]

Yellow_:

Sorry I couldn't reproduce the problem here. I definitely don't understand what's wrong here.

Kraise:

1. If your source has no banding and you're encoding to 10 bits with enough bitrate, you probably don't need to do anything.

1.1 DVD and bluray are 8 bit only. But this doesn't mean that the master wasn't in a higher bitdepth.

1.2 Yes. That's what GradFun3() is for.

If you try previewing a 16-bit clip (in stacked format or ready to encode), this is normal that you get garbage. Just replace Dither_convey_yuv4xxp16_on_yvxx () with DitherPost() for a convenient preview (or just remove the line and set lsb=false in GradFun3).

Also, you should be careful when mixing 8 and 16 bit processing. In your latest example, dfttest (lsb=true) generates a 16-bit clip and pass it to LSFMod, but LSFMod excepts only 8-bit clips. And the subsequent mt_makediff() will receive input clips with different height, this is not good. Same thing just a few lines below, SmoothGrad excepts a 16-bit clip. Here is a more correct script, using a simple mask :


dfttest (sigma=16, lsb=true) # last is now 16 bits
f = DitherPost (mode=-1) # 16 -> 8 bits
s = f.LSFmod(strength=120) # 8 -> 8
mask = mt_lutxy (s, f, "x y != 255 0 ?", u=0, v=0) # 8, 8 -> 8
s16 = s.Dither_convert_8_to_16 () # 8 -> 16
Dither_merge16_8 (last, s16, mask) # 16, 16, 8 -> 16
SmoothGrad () # 16 -> 16
Dither_convey_yuv4xxp16_on_yvxx () # 16 -> enco


You can also see post #250 (http://forum.doom9.org/showthread.php?p=1518953#post1518953) of this thread for more details about mixing 8- and 16-bit processing; the proposed method is slightly different.

[Yellow_]

Yellow_:

Sorry I couldn't reproduce the problem here. I definitely don't understand what's wrong here.

You were right I was running 2.6 alpha without knowing it, due to the freaking mess which is the sourceforge 'latest version' link giving me 2.6 Alpha even from within the 2.5 branch of Avisynth at Sourceforge. :-) So of coarse downloading 2.5 from 2008 + latest Directshow zip solves problems.

[titlis]

Didn't Gamma apply only to the Luma?
I thought chroma is independent to gamma.

oops... sorry
I was a bit stupid


Now I got it
Gamma is really a RGB thing right?

[canuckerfan]

Is there a way to use DitherPost() without denoising first? For example, I have a clip that is already denoised. And I don't want to apply dfttest(lsb=true) because it will denoise my clip twice. Instead, how can the clip be changed to 16-bit so that DitherPost() can be applied to it?

[mandarinka]

There is normal fucntion for 8 to 16 bit conversion: Dither_convert_8_to_16()

However, by itself it does nothing but add zeros as the bottom (least significant) bits. Of course, when you do not want to smooth your video, that's good. It doesn't make sense to do that just so that you can run ditherpost (that will only convert it back to 8bit).

If you actually want to do some dithering (debanding?) on your video, you could use gradfun3 which takes 8bit as input but can output 16bit as well as 8bit (if you want 8bit output, it actually has to use ditherpost itself).

Anyway, to answer your question properly, you need to specify what do you intend to do by using ditherpost...

[canuckerfan]

Anyway, to answer your question properly, you need to specify what do you intend to do by using ditherpost...
Basically to reduce banding and to avoid giving the clip a "glossy/shimmery" look. Maybe GradFun3 by itself can do this and I won't need to Dither?

[mandarinka]

Yeah, in that case, you'd use a debanding filter (gradfun3 or that other one, flashkyu3deband) and you can just start straight from the 8bit source. If you want to encode 8bit h.264, that would be it (gradfun3 works in 16bit internally which it converts to 8bit using ditherpost unless you set lsb=true). If you wanted to encode in 10-bit, then you should output 16-bit from gradfun3 and then use the special function to get 10-bit video for purposes of x264 encoding through avs2yuv:

gradfun3(lsb=true)
fslg_dither_to_n_bits(10, outn = true) # add mode=x if you want to specify which dithering to use in ditherpost
Dither_convey_yuv4xxp16_on_yvxx()

[cretindesalpes]

Dither 1.14.0 (http://forum.doom9.org/showthread.php?p=1386559#post1386559) package released:
Multi-threading: most dither.dll functions are now multi-threaded with the help of AVSTP (http://forum.doom9.org/showthread.php?t=164407), excepted Dither_box_filter16 and SmoothGrad (later, maybe). The speed improvement is not that impressive but still welcome.
Added staticnoise parameter to GradFun3.
MVTools v2.6.0.0:
MDegrainN: internally uses MDegrain1/2/3 when tr ≤ 3, for optimal speed.
MCompensate: added multi-compensation mode for easy use with temporal filters.
MAnalyse, MSuper, MCompensate, MDegrainN: added multithreading (but partially, not for all code paths).
MAnalyse: fixed a corruption of the global motion vector.
Dfttest v1.9.1: fixed a regression with internal dithering.
Documentation revisited.

[Dogway]

whoa unexpected! Thanks a lot!

I'm away of avisynth now but I will test when I clear a bit the work space. I wanted to ask if it is possible to default the "quiet" parameter of dfttest to true, because I'm making it to perform as a high pass prefilter for the smdegrain function, so it is backwards compatible with vanilla dfttest.

edit: btw I'm having a dilemma on whether to default truemotion true as mvtools default, or false like mctemporaldenoise, so I had in mind to test the related parameters. Because in the documentation I saw you were also hesitant on these parameters as well I'll let you know when I get to any conclusion.

edit2: and I think there is a bug for mdegrainN when using avstp.dll

[tormento]

Thanks, I'll test it in my worst encodings ;)

[atra dies]

MAnalyse: fixed a corruption of the global motion vector

Would this make a difference here?:

super = MSuper(pel=1, sharp=0)
backward_vec2 = MAnalyse(super, isb = true, blksize=4,delta = 2, overlap=0,temporal=true)
backward_vec1 = MAnalyse(super, isb = true, blksize=4,delta = 1, overlap=0,temporal=true)
forward_vec1 = MAnalyse(super, isb = false, blksize=4,delta = 1, overlap=0,temporal=true)
forward_vec2 = MAnalyse(super, isb = false, blksize=4,delta = 2, overlap=0,temporal=true)
MDegrain2(super, backward_vec1,forward_vec1,backward_vec2,forward_vec2,thSAD=400)

I am in the middle of an encode and would gladly start it over using new dither plugin if there is any bug at all with the previous version.

OT:
(Mdegrain recommendation/my opinion after a lot of trying out different parameters:
no supersampling, pel > 1 blurs,
blksize is much more accurate at 4 for SD, anything greater blurs with no supersampling,
mdegrain3 and above introduces artifacts at scene change.)

[cretindesalpes]

Dogway:

You're right! I'll release a fix soon.

atra dies:

When analysing a block, the global motion vector computed from the previous level and used as "second try" (after the "no motion" vector) is truncated so it does not point to an area located out of the picture. Previously, it was never reset to its initial value when passed to the next block, so when it was truncated once (very frequent because analysis begins at the top left of the frame), it became a bad guess for all other blocks and global motion estimation was actually ignored. Anyway the difference was minor in my tests, but I think it really depends on the scene. I think you can safely terminate your encoding with the previous MVTools…

[SSH4]

cretindesalpes
Looks like bug in new build of MVtools2 mod from your dither 1.14 pack.
mdegrainN crashed on any tr. For example:
AVCSource("g:\Endhiran.dga")
Crop(0, 132, -0, -132) #1920х816
tr = 6 # Temporal radius
super = MSuper ()
multi_vec = MAnalyse (super, multi=true, delta=tr)
MDegrainN (super, multi_vec, tr, thSAD=400, thSAD2=150)


MVTools2 from 1.13 work well.
Windows 7 64bit
Avisynth 2.6 MT
crash on both Setmode(2) and Setmode(5)

"exception c0000005 at address 0001043e"

on SD source with more complex script QTGMC, 2xMdegrainN, dfttest work well 0__0

[cretindesalpes]

Sorry for these bugs, I found that I just left half-finished code in MDegrainN :eek: . But still, I changed lots of code everywhere, so take these new Dither/MVTools with care.

Bugs fixed in Dither 1.14.1 / MVTools 2.6.0.1 (http://forum.doom9.org/showthread.php?p=1386559#post1386559):
MAnalyse: fixed potential crash in multithreading mode.
MDegrainN: fixed systematic crash in multithreading mode.
All MDegrain functions: fixed potential crash when thSAD is set to 0.

I would be interested to know the performance gain you have with the multithreaded versions. On my 4-core rig, I generally obtain a ×2.5 speed increase for a ×3.2 CPU usage (MT mode not activated).

[Dogway]

setmtmode(5,2)
SD source
setmtmode(2,2)
Crop(0, 160, -0, -160)
smdegrain(tr=3,thSAD=300,lsb=true)

597mb
80-90% CPU load
1.950fps

577mb
50-60% CPU load
1.300fps

+50% on 2.53gh intel core 2 duo
I think you gain +25% per thread.

Is it possible to default quiet to true in dfttest?

why mflow only uses 2 vectors?, can't it benefit from more vectors as mdegrain does?

[tormento]

Test setup:

2600k@4500MHz with 16GB
x264 v2183 64bit
avs4x264mod v0.6.2 compiled with LARGEADDRESSAWARE flag

SetMemoryMax(2048)
LoadPlugin("D:\eseguibili\media\dgdecnv\DGDecodeNV.dll")
DGSource(Some1080p)
ChangeFPS(last,last,true)
SMDegrain (tr=6,PreFilter=2,contrasharp=false,lsb=true,mode=6)

Dither 1.13.0: 1.95 fps 62.686.533 bytes
Dither 1.14.1: 3.76 fps 62.036.889 bytes

SetMTMode(3,8)
SetMemoryMax(2048)
LoadPlugin("D:\eseguibili\media\dgdecnv\DGDecodeNV.dll")
DGSource(Some1080p)
ChangeFPS(last,last,true)
SetMTMode(2,8)
SMDegrain (tr=6,PreFilter=2,contrasharp=false,lsb=true,mode=6)

Dither 1.13.0 MT: 6.54 fps 62.704.727 bytes
Dither 1.14.1 MT: 6.43 fps 62.039.911 bytes

[06_taro]

- Add "Y"/"U"/"V" in "Dither_merge16_8", fully support -65535~5, default value: Y=3, U=2, V=2 as mt_merge

- Fix Dither_lut16 with Y/U/V<=0 (previous Dither_lut16(Y=-x) returns Y(msb)=x and Y(lsb)=x, while the correct result should be Y(msb)=x/256 and Y(lsb)=x%256)

Function Dither_merge16_8(clip src1, clip src2, clip mask, bool "luma", int "y", int "u", int "v"){
vers = VersionNumber()

luma = Default(luma, false)

y = Default(y, 3)
u = Default(u, 2)
v = Default(v, 2)

w = mask.Width()
h = mask.Height()
Assert(src1.Width() == w)
Assert(src2.Width() == w)
Assert(src1.Height() == h * 2)
Assert(src2.Height() == h * 2)

msk = ( luma && (vers < 2.6 || ! src1.Dither_isY8()) )
\ ? mask.MergeChroma( mask.YToUV(mask).BilinearResize(w, h) )
\ : mask

msb1 = src1.Dither_get_msb()
lsb1 = src1.Dither_get_lsb()
msb2 = src2.Dither_get_msb()
lsb2 = src2.Dither_get_lsb()

p1a = Dither_lutxy8( msb1, msk, expr="256 y - x * ", Y=(y==3?3:1), U=(u==3?3:1), V=(v==3?3:1) )
p1b = Dither_lutxy8( lsb1, msk, expr="256 y - x * 256 /", Y=(y==3?3:1), U=(u==3?3:1), V=(v==3?3:1) )

p2a = Dither_lutxy8( msb2, msk, expr=" y x * ", Y=(y==3?3:1), U=(u==3?3:1), V=(v==3?3:1) )
p2b = Dither_lutxy8( lsb2, msk, expr=" y x * 256 /", Y=(y==3?3:1), U=(u==3?3:1), V=(v==3?3:1) )

p1 = Dither_add16(p1a, p1b, wrap=True)
p2 = Dither_add16(p2a, p2b, wrap=True)

Dither_add16(p1, p2, wrap=True)

( y==2 || u==2 || v==2 ) ? mt_lutxy( src1, Y=(y==2?4:2), U=(u==2?4:2), V=(v==2?4:2) ) : nop
( y==4 || u==4 || v==4 ) ? mt_lutxy( src2, Y=(y==4?4:2), U=(u==4?4:2), V=(v==4?4:2) ) : nop
( y==5 || u==5 || v==5 ) ? mt_lutxy( mask.Dither_convert_8_to_16, Y=(y==5?4:2), U=(u==5?4:2), V=(v==5?4:2) ) : nop

return ( y<=0 || u<=0 || v<=0 ) ? Dither_lut16( Y=(y<=0?y:2), U=(u<=0?u:2), V=(v<=0?v:2) )
\ : last

}

Function Dither_lut16 (clip src,
\ string "expr", string "yexpr", string "uexpr", string "vexpr",
\ int "y", int "u", int "v")
{
s_msb = Dither_get_msb (src)
s_lsb = Dither_get_lsb (src)

d_msb = Dither_lut16_msb (s_msb, s_lsb,
\ expr=expr, yexpr=yexpr, uexpr=uexpr, vexpr=vexpr, y=y, u=u, v=v)
d_lsb = Dither_lut16_lsb (s_msb, s_lsb,
\ expr=expr, yexpr=yexpr, uexpr=uexpr, vexpr=vexpr, y=y, u=u, v=v)

StackVertical (d_msb, d_lsb)
}

Function Dither_lut16_msb (clip msb, clip lsb,
\ string "expr", string "yexpr", string "uexpr", string "vexpr",
\ int "y", int "u", int "v")
{
expr = Default (expr, "x")
yexpr = Default (yexpr, expr)
uexpr = Default (uexpr, expr)
vexpr = Default (vexpr, expr)
expr = Dither_lut16_expr (expr, True)
yexpr = Dither_lut16_expr (yexpr, True)
uexpr = Dither_lut16_expr (uexpr, True)
vexpr = Dither_lut16_expr (vexpr, True)

mt_lutxy ( msb, lsb,
\ expr=expr, yexpr=yexpr, uexpr=uexpr, vexpr=vexpr, y=(y<=0?y/256:y), u=(u<=0?u/256:u), v=(v<=0?v/256:v) )
}

Function Dither_lut16_lsb (clip msb, clip lsb,
\ string "expr", string "yexpr", string "uexpr", string "vexpr",
\ int "y", int "u", int "v")
{
expr = Default (expr, "x")
yexpr = Default (yexpr, expr)
uexpr = Default (uexpr, expr)
vexpr = Default (vexpr, expr)
expr = Dither_lut16_expr (expr, False)
yexpr = Dither_lut16_expr (yexpr, False)
uexpr = Dither_lut16_expr (uexpr, False)
vexpr = Dither_lut16_expr (vexpr, False)

mt_lutxy ( lsb, msb,
\ expr=expr, yexpr=yexpr, uexpr=uexpr, vexpr=vexpr, y=(y<=0?y%256:y), u=(u<=0?u%256:u), v=(v<=0?v%256:v) )
}

[zero9999]

when run on AviSynth 2.6, Dither_convert_yuv_to_rgb(output="rgb48yv12") throws the following error: Dither_convey_rgb48_on_yv12: r,g,b must be YV12. Probably because the the convert function uses Y8 because it's available and the convey function not supporting it.

[cretindesalpes]

06_taro:

Thank you, I'll add these ones in the next version.

zero9999:

Same thing. In the meantime, you can change the IsYV12() in the assert line with IsYUV() and add just below:
r = r.ConvertToYV12 ()
g = g.ConvertToYV12 ()
b = b.ConvertToYV12 ()

[06_taro]

Bug report (Dither_resize16):
ColorBars(width=1068, height=600, pixel_type="YV12")
Dither_convert_8_to_16.Dither_resize16(1280, 720, kernel="bicubic")

Crashes since v1.12.1, works fine with v1.12.0 and older versions.
If the source resolution changes, e.g., width=1920, height=1080, or the kernel is not "bicubic", this script might not crash.

[cretindesalpes]

Dither 1.15.0 (http://forum.doom9.org/showthread.php?p=1386559#post1386559):
Added the luma parameter to Dither_merge16 and defaulted u and v to 2 (copy) excepted when luma = true (process). This behaviour is now identical to mt_merge.
Added plane filtering in Dither_merge16_8. The function now internaly uses Dither_merge16 and is much faster (×20 on a 4-core CPU).
Added support for negative plane filter values in Dither_lut16. Thanks to 06_taro for the suggestion.
Set quiet = true as default in dfttest 1.9.2.
Fixed a bug in Dither_resize16 making it crash for some combinations of source and destination sizes.