Color banding and noise removal

[Izuchi]

Is it possible to to serve high bit depth scripts to Virtualdub and create lossless 16-bit avi files which can then be encoded using x264 --input-depth 16? I think I know the answer, but just want to make sure.

[feisty2]

dither_out ()

[Reel.Deel]

Is it possible to to serve high bit depth scripts to Virtualdub and create lossless 16-bit avi files which can then be encoded using x264 --input-depth 16? I think I know the answer, but just want to make sure.

Why not just use Avs2YUV (http://avisynth.nl/index.php/Avs2YUV) or avs4x26x (http://forum.doom9.org/showthread.php?t=162656) to pipe high bit-depth video to x264?


dither_out ()
I see why you have 1,226 posts...

[Sparktank]

Shouldn't you be able to encode to x264 using avs2yuv/av4x26x ?
Using Dither_out()

The documentation gives example to encode 10bit:
Dither_quantize (bitdepth=10)
Dither_out ()

Which works if you set:
avs2yuv -raw "script.avs" -o - | x264-10bit --demuxer raw --input-depth 16

VDub should not really be needed. Unless you want a lossless intermediate.
Which would probably serve better if you used FFMPEG to create ffvhuff lossless intermediate.
I haven't really used VDub in a long time, unless I test with UTVideo Codec lossless intermediates.

ffmpeg -codec jpeg2000 -i "video.mxf" -map_metadata -1 -pix_fmt yuv444p12le -vcodec ffvhuff "output-ffvhuff-yuv444p12le.mkv"

ffmpeg supported (ffvhuff) pixel formats:
yuv420p yuv422p yuv444p yuv411p yuv410p yuv440p

gbrp gbrp9le gbrp10le gbrp12le gbrp14le gray gray16le

yuva420p yuva422p yuva444p

gbrap

ya8

yuv420p9le yuv420p10le yuv420p12le yuv420p14le yuv420p16le
yuv422p9le yuv422p10le yuv422p12le yuv422p14le yuv422p16le
yuv444p9le yuv444p10le yuv444p12le yuv444p14le yuv444p16le

yuva420p9le yuva420p10le yuva420p16le
yuva422p9le yuva422p10le yuva422p16le
yuva444p9le yuva444p10le yuva444p16le

rgb24 bgra

[Izuchi]

Yes, I was thinking of creating some lossless intermediary files, should have been more clearer. Thanks, Sparktank I'll give that a try.

[real.finder]

Thanks for your answer, cretindesalpes, I appreciate it. I've been slowly learning a bit here and a bit there and wanted to make sure I was putting the pieces together correctly. Another question, if I may. I updated Dither a few days ago, from v1.25.1 to v1.27.1 (I'm a bit slow) and in the process unwittingly added the avstp.dll to my plugins folder. I typically use the basic above script with SEt's MT AviSynth 2.6 like so:

SetMemoryMax(2048)
SetMTMode(3,7)
LoadPlugin("F:\[0]StandAloneApps\MeGUI-2500(core)2443(data)0.3.5(libs)[Portable]\tools\lsmash\LSMASHSource.dll")
LWLibavVideoSource("D:\Temp\[0000]ReEncTemp\TheUnbearableLightnessOfBeing[S]{1988}[720p]\OriginalVideo,OriginalAudio[ViGi].mkv")
SetMTMode(2)
SMDegrain(tr=3,thSAD=400,RefineMotion=True,Plane=0,Chroma=False,Lsb=True,Lsb_Out=True,PreFilter=2)
F=DitherPost(Mode=-1)
S=F.FastLineDarkenMod()
D=MT_MakeDiff(S,F).Dither_Convert_8_To_16()
Dither_Add16(Last,D,Dif=True,U=2,V=2)
GradFun3(Lsb_In=True,Lsb=True)
# DitherPost
Dither_Out()

This has always given me good results (except for the occasional corrupt source), but with the avstp.dll in my plugins folder the output video had nasty artifacts every few seconds. Once I figured out that the avstp.dll was the cause of the glitches I found my way to your thread (http://forum.doom9.org/showpost.php?p=1564516&postcount=1) and, after reading the "Short user manuel" I don't understand why the avstp.dll would cause so much trouble. To my obviously wrong understanding it should help. Or is the problem that SMDegrain and FastLineDarkenMod aren't AVSTP enabled?

was the artifacts be like http://i.imgur.com/cvt0nW9.jpg ?

[StainlessS]

Just thought I'de point out that FFTW library used by eg FFT3DFilter as fftw3.dll and dftTest as libfftw3f-3.dll (same dll, just different name)
has been updated several times since the one included in dither tools. (not sure what date last update was). http://www.fftw.org/index.html


Here some update history, current version v3.3.4

FFTW 3.3.4

* New functions fftw_alignment_of (to check whether two arrays are
equally aligned for the purposes of applying a plan) and fftw_sprint_plan
(to output a description of plan to a string).

* Bugfix in fftw-wisdom-to-conf; thanks to Florian Oppermann for the
bug report.

* Fixed manual to work with texinfo-5.

* Increased timing interval on x86_64 to reduce timing errors.

* Default to Win32 threads, not pthreads, if both are present.

* Various build-script fixes.

FFTW 3.3.3

* Fix deadlock bug in MPI transforms (thanks to Michael Pippig for the
bug report and patch, and to Graham Dennis for the bug report).

* Use 128-bit ARM NEON instructions instead of 64-bits. This change
appears to speed up even ARM processors with a 64-bit NEON pipe.

* Speed improvements for single-precision AVX.

* Speed up planner on machines without "official" cycle counters, such as ARM.

FFTW 3.3.2

* Removed an archaic stack-alignment hack that was failing with
gcc-4.7/i386.

* Added stack-alignment hack necessary for gcc on Windows/i386. We
will regret this in ten years (see previous change).

* Fix incompatibility with Intel icc which pretends to be gcc
but does not support quad precision.

* make libfftw{threads,mpi} depend upon libfftw when using libtool;
this is consistent with most other libraries and simplifies the life
of various distributors of GNU/Linux.

FFTW 3.3.1

* Changes since 3.3.1-beta1:

- Reduced planning time in estimate mode for sizes with large
prime factors.

- Added AVX autodetection under Visual Studio. Thanks Carsten
Steger for submitting the necessary code.

- Modern Fortran interface now uses a separate fftw3l.f03 interface
file for the long double interface, which is not supported by
some Fortran compilers. Provided new fftw3q.f03 interface file
to access the quadruple-precision FFTW routines with recent
versions of gcc/gfortran.

* Added support for the NEON extensions to the ARM ISA. (Note to beta
users: an ARM cycle counter is not yet implemented; please contact
fftw@fftw.org if you know how to do it right.)

* MPI code now compiles even if mpicc is a C++ compiler; thanks to
Kyle Spyksma for the bug report.


EDIT: Needs to be in system32 (or equiv on 64bit) as both fftw3.dll and ibfftw3f-3.dll (ibfftw3f-3.dll is name as supplied in zip).

[AzraelNewtype]

EDIT: Needs to be in system32 (or equiv on 64bit) as both fftw3.dll and ibfftw3f-3.dll (ibfftw3f-3.dll is name as supplied in zip).

It's SysWOW64 on 64-bit OS... for the 32-bit dlls. If you're doing 64-bit avs, you put the 64-bit versions into system32 still. I'm only spelling it out because it's hilariously confusing.

Thanks Microsoft.

[StainlessS]

Thank you AzraelNewtype.

It's hilariously confusing.

Thanks Microsoft.


Another MS sweetie,

According to MS, Your System drive is the one you boot to, and your Boot drive is the one your system is on !

Always good for a giggle, is MS.

[creaothceann]

Does it have to be in System/SYSWOW64, or can it also be in a directory included in %PATH%?

[Groucho2004]

Does it have to be in System/SYSWOW64, or can it also be in a directory included in %PATH%?
The latter also works.

[LouieChuckyMerry]

was the artifacts be like http://i.imgur.com/cvt0nW9.jpg ?

It's difficult to tell by your screenshot because I never encoded any anime with the AVSTP.dll issue, but it looks very similar. For my non-anime encodes, it looked like frost or ice (white artifacts) on the edges of images in the frame and was especially noticeable when there was action (camera pans, movement, etc.).

[real.finder]

It's difficult to tell by your screenshot because I never encoded any anime with the AVSTP.dll issue, but it looks very similar. For my non-anime encodes, it looked like frost or ice (white artifacts) on the edges of images in the frame and was especially noticeable when there was action (camera pans, movement, etc.).

the screenshot from pan too

and didn't happened in all video, it happened in ED in this frame only, and in avs 64 (with setmtmode) without AVSTP, and after I see it in the final encode I try to reproduce it but it didn't reproduced with many tries

[LouieChuckyMerry]

the screenshot from pan too and didn't happened in all video, it happened in ED in this frame only, and in avs 64 (with setmtmode) without AVSTP, and after I see it in the final encode I try to reproduce it but it didn't reproduced with many tries

If you can't reproduce it then perhaps it was just a one-time occurrence? I've experienced, very rarely, artifacts because the source file was corrupted, possibly a bad mux or a digital glitch.

[real.finder]

If you can't reproduce it then perhaps it was just a one-time occurrence? I've experienced, very rarely, artifacts because the source file was corrupted, possibly a bad mux or a digital glitch.

I tried with the same source and script

[bxyhxyh]

Hello, guys

If I use dither_resize16(1280,720,csp="YV24") on 1080p clip, this works ok.

I always resized chroma and luma separately before.
Are they same?

[Desbreko]

Yes, that'll be identical to resizing the chroma separately like this:

y = Dither_resize16(1280,720, u=1, v=1)
u = UToY8().Dither_resize16(1280,720, src_left=0.25)
v = VToY8().Dither_resize16(1280,720, src_left=0.25)
YToUV(u,v,y)

Resizing the chroma separately as Y8 clips is useful if you're using AviSynth's resizers or something else like nnedi3_rpow2 instead of Dither_resize16 on it, but otherwise, it's simpler and probably also faster to just use the csp option.

[fvisagie]

Resizing the chroma separately as Y8 clips is useful if you're using AviSynth's resizers or something else like nnedi3_rpow2 instead of Dither_resize16 on it, but otherwise, it's simpler and probably also faster to just use the csp option.

Please explain in what situations one would want to do one of these (separately resize or use the csp option), and why?

Thanks,
François

[Desbreko]

It's for when you want to downscale the luma of a video with subsampled chroma without losing any more of the chroma resolution. Specifically, a lot of anime is produced at 720p or thereabout and upscaled to 1080p for release on Blu-ray, so converting the 1080p YV12 video on the BD to 720p YV24 when you encode it lets you avoid wasting bits on upscaled luma.

[fvisagie]

Thanks.

[LouieChuckyMerry]

Hello :) . I've been using the following script on HD sources with good results:

SMDegrain(TR=1,ThSAD=100,RefineMotion=True,Plane=0,Chroma=False,Lsb=True,Lsb_Out=True)
LinearResize(1280,720,Lsb_In=True,Lsb_Out=True)
F=DitherPost(Mode=-1)
S=F.FastLineDarkenMod(Strength=24)
D=MT_MakeDiff(S,F).Dither_Convert_8_To_16()
Dither_Add16(Last,D,Dif=True,U=2,V=2)
GradFun3(Radius=16,Lsb_In=True,Lsb=True)
Dither_Out()

but now find myself wondering if I could improve speed and-or quality by doing the resizing before the denoising (this seems logical, at least to me, to make the denoising area smaller first). I've searched about for an answer but can't find anything of value. Please, would One Of You Who Knows More Than I explain to me which should come first and why (or point me to a thread that specifically discusses this issue). Thank you very much.

[creaothceann]

Resizing automatically removes noise simply because it removes pixels; on the other hand the remaining noise might then be harder to remove? Probably depends on the filter.

[StainlessS]

I would say no matter if upsize or downsize, denoise first, resize last.

Order of operations according to the old TmpGenc app.


1 ) Source range (trim)
2 ) Inverse Telecine
3 ) Ghost Reduction
4 ) Noise Reduction
5 ) Sharpen
6 ) Color Correction
7 ) Deinterlace
8 ) Clip frame (crop/Resize)
# 9 ) 3/2 Pulldown
10) FrameRate Conversion

[LouieChuckyMerry]

Resizing automatically removes noise simply because it removes pixels[emphasis LCM]; on the other hand the remaining noise might then be harder to remove? Probably depends on the filter.

Thanks for that; I've never thought of it that way but it makes perfect sense now that I read it.


I would say no matter if upsize or downsize, denoise first, resize last.

Order of operations according to the old TmpGenc app.


1 ) Source range (trim)
2 ) Inverse Telecine
3 ) Ghost Reduction
4 ) Noise Reduction
5 ) Sharpen
6 ) Color Correction
7 ) Deinterlace
8 ) Clip frame (crop/Resize)
# 9 ) 3/2 Pulldown
10) FrameRate Conversion


Interesting. What made me recently question my approach was remembering that MeGUI's default script has:

#deinterlace
#crop
#resize
#denoise

listed after the source. Hmmm, which application is correct? I've always understood (ha ha ha) that inverse telecine-deinterlace come first, when applicable, and have always done as such with no apparent problems; however, my dealings with interlacing have (thankfully) been infrequent and almost always involve seemingly endless trial-and-error and-or begging for help somewhere. That or I wait for the Blu-ray ;) . Given your above post, would you then reckon that my script:

SMDegrain(TR=1,ThSAD=100,RefineMotion=True,Plane=0,Chroma=False,Lsb=True,Lsb_Out=True)
LinearResize(1280,720,Lsb_In=True,Lsb_Out=True)
F=DitherPost(Mode=-1)
S=F.FastLineDarkenMod(Strength=24)
D=MT_MakeDiff(S,F).Dither_Convert_8_To_16()
Dither_Add16(Last,D,Dif=True,U=2,V=2)
GradFun3(Radius=16,Lsb_In=True,Lsb=True)
Dither_Out()

should be rearranged to:

SMDegrain(TR=1,ThSAD=100,RefineMotion=True,Plane=0,Chroma=False,Lsb=True,Lsb_Out=True)
F=DitherPost(Mode=-1)
S=F.FastLineDarkenMod(Strength=24)
D=MT_MakeDiff(S,F).Dither_Convert_8_To_16()
Dither_Add16(Last,D,Dif=True,U=2,V=2)
GradFun3(Radius=16,Lsb_In=True,Lsb=True)
LinearResize(1280,720,Lsb_In=True,Lsb_Out=True)
Dither_Out()

[StainlessS]

I am very definitely no expert,(nor hardly even a novice),
but maybe the FastLineDarken, GradFun and Dither stuff should be (I think) POST resize.
(they just were not a factor in TmpGenc days)

EDIT: Downsize, Better qual if denoise first, then resize down, faster if downsize first but with penalties in quality.
Upsize, no penalties in, denoise, then resize up.

EDIT: Qwik rule of thumb: the one that takes longest produces better quality (generally speaking, its a tradeoff).

[fvisagie]

3 ) Ghost Reduction
4 ) Noise Reduction
5 ) Sharpen
...
7 ) Deinterlace


I'm just not sure that mostly spatial operations should be applied to temporally separated fields. Better output should result from applying deinterlacing first, at least according to my understanding.

[StainlessS]

OK, do you have some general order of process, could be of interest to many ?

[fvisagie]

I'm even less of an expert than you, but from the discussions on the topic I've read and/or participated in, there seem to be two main anchor points around the rest of the processing.

The more hard-and-fast of the two is deinterlacing. When needed, in order to preserve field integrity deinterlacing should come before spatial and/or geometric transformation operations like resizing, [sub]titling, sharpening, denoising etc. Arguably, this group might also include exposure/colour correction that is non-linear and/or non-global, e.g local contrast enhancement. LCE may cause loss of coherence between adjacent fields.

The less hard-and-fast anchor point is in fact denoising. Preferably this is done last 1) to clean up after all fudging is complete, and 2) to prevent denoising from reducing detail needed in earlier processing.

However, that brings one to the topic of this whole thread - denoising can cause or worsen banding;). Although I have been fortunate enough not to need debanding much, circumstances like quality of input, severity of banding and strength of denoising needed seem to indicate the appropriate debanding-denoising sequence on a case-by-case basis. I.e., suck it and see ;).

[LouieChuckyMerry]

The more hard-and-fast of the two is deinterlacing. When needed, in order to preserve field integrity deinterlacing should come before spatial and/or geometric transformation operations like resizing, [sub]titling, sharpening, denoising etc. Arguably, this group might also include exposure/colour correction that is non-linear and/or non-global, e.g local contrast enhancement. LCE may cause loss of coherence between adjacent fields.

Thanks for the lucid explanation.


The less hard-and-fast anchor point is in fact denoising. Preferably this is done last 1) to clean up after all fudging is complete, and 2) to prevent denoising from reducing detail needed in earlier processing.

However, that brings one to the topic of this whole thread - denoising can cause or worsen banding;). Although I have been fortunate enough not to need debanding much, circumstances like quality of input, severity of banding and strength of denoising needed seem to indicate the appropriate debanding-denoising sequence on a case-by-case basis. I.e., suck it and see ;).

As creaothceann typed, "Resizing automatically removes noise simply because it removes pixels.". So it seems reasonable that one would denoise before resizing so that the resizer has a higher quality source for pixel selection(?). Of course, I'm even less expert than you ;) . The sharpening is typically after denoising (and resizing, if applicable) from what I've read (although the best sharpener is to not blur, which is where masking come into play; bummer that this slows things down so much). I think I'll stick with my original script with Denoise-->Resize-->Sharpen-->Deband (I'm 99.99% sure that debanding comes last :p ).

Thanks for the help.

[Boulder]

You could try sharpening while downsizing. Didée once came up with a brilliant suggestion to abuse BicubicResize: http://forum.doom9.org/showthread.php?p=1579385#post1579385

That's what I do when I go from 1080p to 720p, which is about 99% of the time. You just need to adjust b and c according to the source to compensate the loss of sharpness.

[fvisagie]

The sharpening is typically after denoising (and resizing, if applicable)

Indeed, that slipped my mind.

[cretindesalpes]

dither 1.27.2 (http://forum.doom9.org/showthread.php?p=1386559#post1386559):
Fixed Dither_crop16 which wasn’t passing the align parameter if there was no horizontal cropping. Thanks to Reel.Deel for making me check.
Fixed Dither_srgb_display with autopar=false and 1440×1080 input.
Fixed Dither_quantize with reducerange=true, some rare pixel values were wrongly quantized. Thanks to _08 for reporting this bug.
Fixed a picture corruption in Dither_bilateral16. Thanks to _08 for reporting what was actually a combination of two different bugs.

[Sparktank]

:cool: :thanks:

[LouieChuckyMerry]

You could try sharpening while downsizing. Didée once came up with a brilliant suggestion to abuse BicubicResize: http://forum.doom9.org/showthread.php?p=1579385#post1579385

That's what I do when I go from 1080p to 720p, which is about 99% of the time. You just need to adjust b and c according to the source to compensate the loss of sharpness.

Thanks for that. Would you recommend this method for downsizing animation?


cretindesalpes: thanks for the updated dither :thanks:

[Motenai Yoda]

the last version include the fix of this test build too?
http://forum.doom9.org/showpost.php?p=1731185&postcount=927

[cretindesalpes]

the last version include the fix of this test build too?
http://forum.doom9.org/showpost.php?p=1731185&postcount=927
Yes, but I probably forgot to report it in the history.

[Motenai Yoda]

@cretindesalpes what is the exact formula for the elasticity of limit_dif16?
AFAIU it's something like "x" up to threshold then "x * (((thr*elast) -x)/(thr*(elast -1)))" up to thr*elast

[asarian]

Using the following line,

Dither_convert_yuv_to_rgb (matrix="601", output="rgb48y", lsb_in=false)

Would still produce a lsb_out = true (16 bit) output clip, right?

Thanks.

[AzraelNewtype]

Probably not, though you could test it yourself in about 10s. If the height doesn't double it's still 8-bit.

[asarian]

Probably not, though you could test it yourself in about 10s. If the height doesn't double it's still 8-bit.

You're right: that was a simple enough test. :)

It *does* produce a 16-bit clip, btw (960p for a 480p source).

[real.finder]

official mvtools v2.5.11.20 has been released and pinterf did some fix too https://github.com/pinterf/mvtools/tree/mvtools-pfmod

can we have new mvtools mod16 ?

[Reel.Deel]

official mvtools v2.5.11.20 has been released and pinterf did some fix too https://github.com/pinterf/mvtools/tree/mvtools-pfmod

can we have new mvtools mod16 ?

pinterf's mod is based on mvtools v2.6.0.5 so it already includes mod16.

[real.finder]

pinterf's mod is based on mvtools v2.6.0.5 so it already includes mod16.

but it don't have official mvtools v2.5.11.20 changes

and not work with avs 2.5 (some people still use it)

[asarian]

but it don't have official mvtools v2.5.11.20 changes

and not work with avs 2.5 (some people still use it)

Hmm, so I just upgraded the wrong AviSynth mvtools?! LOL. Guys, please, don't confuse me. :) It's hard enough to keep everything apart as it is.

[pinterf]

I came up with the my mod mainly because of the 2.6 Api and to fix some memory exceptions of the x64 version. Really not big modifications. At about the same time Physic came back to business after many years and fixed some other things with the 2.5.11.20 version. But this is for 32 bit only. Note that the 2.6.0.5 version (and thus my mod also) is still 8 bit except the output of mdegrain. Looking at the complexity of the code I think it would be easier to backport the plugin from VapourSynth when we need a true (stacked :) )16 bit or even float! (Avisynth+ 2017 :) ) version.

[asarian]

Well, looks like your modded version works great! :) Thanks for all your hard work!

[James Freeman]

With this line:
Dither_convert_rgb_to_yuv(matrix="2020")
http://www.mediafire.com/convkey/e11a/3raelcy59pqjqq6zg.jpg

What can be the cause??

[Groucho2004]

With this line:

http://www.mediafire.com/convkey/e11a/3raelcy59pqjqq6zg.jpg

What can be the cause??
Either Avisynth cannot find dither.dll or you're missing some MS runtime libraries (or both).
You can troubleshoot your Avisynth install with this (http://forum.doom9.org/showthread.php?t=170647) tool.

Also, post your full script.

[James Freeman]

Either Avisynth cannot find dither.dll or you're missing some MS runtime libraries (or both).
You can troubleshoot your Avisynth install with this (http://forum.doom9.org/showthread.php?t=170647) tool.

Also, post your full script.

My Script:

AVISource("D:\renderin\signpost.avi",audio=false).AssumeFPS(25,1)
Dither_convert_rgb_to_yuv(matrix="2020")
That's it.

Am I supposed to copy the files from the Win32 directory to the same with the .avsi file?

[Groucho2004]

Am I supposed to copy the files from the Win32 directory to the same with the .avsi file?
Correct.

[James Freeman]

It works.

[bilditup1]

So, I was told in another thread (https://www.doom9.org/showthread.php?p=1769244#post1769244) that this is the proper way to use dither tools to change the color matrix whilst downscaling:

Dither_convert_8_to_16 ()
Dither_resize16 (640, 480, csp="YV24") # change to the desired dimensions
Dither_convert_yuv_to_rgb (matrix="709", output="rgb48y", lsb_in=true)
r = SelectEvery (3, 0)
g = SelectEvery (3, 1)
b = SelectEvery (3, 2)
Dither_convert_rgb_to_yuv (r, g, b, matrix="601", lsb=false, mode=0, output="YV12")

Two questions about this:
First, why is the downscale being done here as opposed to just using AviSynth's resizers at the very end of the script? What benefit comes from doing this? Having less to process for the color matrix conversion?
Second, why process in rgb48y?
I'm not asking because I'm skeptical. I just would like to know how this works, as I'm new to Dither.

[Motenai Yoda]

maybe the resize can be done this way if you don't want Dither_convert_yuv_to_rgb to upscale chroma planes, you can use chromak="spline36" to reduce the chroma blurring too, but differences will be negible.
You can use Dither_resize16 at the end too, it will be better than internal avs resizers coz works with better input precision (I don't know for avs+).

internally conversion between colorimetries is done using rgb coz those define how to convert yuv to/from rgb

I don't know how well colormatrix will do, sure it can't get/output at 16bit precision, but I hope all calculation are done internally in float/double, not integer as MisterX said.

[bilditup1]

...

Thanks for taking the time to explain.

[colours]

First, why is the downscale being done here as opposed to just using AviSynth's resizers at the very end of the script? What benefit comes from doing this? Having less to process for the color matrix conversion?

maybe the resize can be done this way if you don't want Dither_convert_yuv_to_rgb to upscale chroma planes, you can use chromak="spline36" to reduce the chroma blurring too, but differences will be negible.
You can use Dither_resize16 at the end too, it will be better than internal avs resizers coz works with better input precision (I don't know for avs+).

AVS and AVS+ both use 16-bit fixed point precision internally (iirc), but they accept and produce only 8-bit output. By using Dither_resize16, you get less rounding error, and if you want an 8-bit output, you now also have the option to apply error diffusion to make it all pretty and dithered. (The posted script does have error diffusion disabled for some reason, though. Bizarre.)

And yes, the downscaling is done right after padding the input to 16-bit as this reduces the number of samples needed to process, thus increasing the speed. Leaving downscaling to the end wouldn't affect accuracy much (might even be very slightly better?), but would be considerably slower depending on the downscaling factor.

The YCbCr→RGB conversion requires the chroma subsampling to be undone at some point, so by converting to 4:4:4 directly in Dither_resize16, we avoid unnecessary resampling, which is both faster and more accurate.

[Motenai Yoda]

The YCbCr→RGB conversion requires the chroma subsampling to be undone at some point, so by converting to 4:4:4 directly in Dither_resize16, we avoid unnecessary resampling, which is both faster and more accurate.

for me doing this way is definitively better, but I agree slower
Dither_convert_8_to_16 ()
Dither_convert_yuv_to_rgb (matrix="709", output="rgb48y", lsb_in=true, chromak="spline36")
r = SelectEvery (3, 0)
g = SelectEvery (3, 1)
b = SelectEvery (3, 2)
Dither_convert_rgb_to_yuv (r, g, b, matrix="601", output="YV24")
Dither_resize16 (640, 480, csp="YV12") # change to the desired dimensions
ditherpost()

PS for cretindesalpes
I was trying this and that with paris clip from Derf's, and I notice some values in the V channel (the yellow papers on the table, the orange of the ball) change, even without resize and the same matrix, just doing yuv->rgb->yuv

ps2 it also happen with avs internal converttorgb, but less

[Reel.Deel]

(The posted script does have error diffusion disabled for some reason, though. Bizarre.)


The script started out as just a sample from the documentation, forgot to change it.


for me doing this way is definitively better, but I agree slower

Regarding the script in post #1055, if you add chromak="spline36" to Dither_convert_rgb_to_yuv then you get visually the same result as your script above but much faster (around 70% in my tests).
Here's a comparison between the two methods: 1x (http://diff.pics/XgaKRgNK8uJJ/1) | 3x (http://diff.pics/Qa0uYe7V3sG7/1)
Here's the original picture (https://web.archive.org/web/20160607151237/http://s32.postimg.org/4y6h17rsj/IMG_4850.png) I used in the script below, I also change the dithering mode to satisfy colours.


FFImageSource("IMG_4850.png")
Dither_convert_rgb_to_yuv (matrix="709", output="YV12", lsb=true)
o = last

o.Dither_resize16 (640, 360, csp="YV24") # change to the desired dimensions
Dither_convert_yuv_to_rgb (matrix="709", output="rgb48y", lsb_in=true)
r = SelectEvery (3, 0)
g = SelectEvery (3, 1)
b = SelectEvery (3, 2)
Dither_convert_rgb_to_yuv (r, g, b, matrix="601", lsb=true, output="YV12", chromak="spline36")
a = last

o.Dither_convert_yuv_to_rgb (matrix="709", output="rgb48y", lsb_in=true, chromak="spline36")
r = SelectEvery (3, 0)
g = SelectEvery (3, 1)
b = SelectEvery (3, 2)
Dither_convert_rgb_to_yuv (r, g, b, matrix="601", output="YV24")
Dither_resize16 (640, 360, csp="YV12") # change to the desired dimensions
b = last

a = a.Dither_convert_yuv_to_rgb (matrix="601", output="rgb24", lsb_in=true, chromak="spline36", mode=6).Subtitle("A")
b = b.Dither_convert_yuv_to_rgb (matrix="601", output="rgb24", lsb_in=true, chromak="spline36", mode=6).Subtitle("B")
Interleave(a,b)

[Motenai Yoda]

Regarding the script in post #1055, if you add chromak="spline36" to Dither_convert_rgb_to_yuv then you get visually the same result as your script above but much faster (around 70% in my tests).
yep is still faster and difference is negible, but I think B is still a little bit better

I suspected resize was optional as if you would to downsize or not.
if not you can add chromak="spline36" to Dither_convert_yuv_to_rgb too and remove Dither_resize16 call.

[real.finder]

yep is still faster and difference is negible, but I think B is still a little bit better

I suspected resize was optional as if you would to downsize or not.
if not you can add chromak="spline36" to Dither_convert_yuv_to_rgb too and remove Dither_resize16 call.

did you try HDRMatrix? http://forum.doom9.org/showthread.php?p=1753267#post1753267

[tormento]

@cretindesalpes

AVS+ is getting more features in these days, such as high bit colors spaces.

Do you think it could be useful to create a specific build of your suite?

[real.finder]

No, this is not a gamma function, and actually it makes the data going even further from the linear-light scale. The purpose is to amplify the scale of the dark parts relative the the other parts. So it acts like a luma-based multiplier on the SAD. With a slope s0 = 2.0, thSAD for the darkest parts is implicitly divided by 2. The c parameter indicates the length of the transition between the dark and normal SAD.

Here are some graphs to show how the curve looks for different s0 and c values:

http://img20.imageshack.us/img20/3832/s0c.th.png (http://img20.imageshack.us/img20/3832/s0c.png)

Blue = original luma, green = mapped luma

Note that for high c or s0 values, the brightest parts have also their thSAD modified (in the other direction), because the slope of the curve near 1 tends to flatten.

the image no longer there, can someone upload it somewhere?

edit: got it form Dogway (http://forum.videohelp.com/threads/369142-Simple-MDegrain-Mod-v3-1-2d-A-Quality-Denoising-Solution?p=2454111&viewfull=1#post2454111)

[TheSkiller]

Okay, this may be a dumb question, but how do I make Dither convert RGB32 or RGB24 to RGB48y? :scared:

If I try to use dither_convert_8_to_16() when the clip is RGB24 or RGB32 I get this error message:

"Avisynth open failure:
BlankClip: color_yuv only valid for YUV color spaces
dither.avsi, line 1045
dither.avsi, line 1052"

[colours]

Okay, this may be a dumb question, but how do I make Dither convert RGB32 or RGB24 to RGB48y? :scared:

Interleave(ShowRed("y8"), ShowGreen("y8"), ShowBlue("y8")).Dither_convert_8_to_16()

[~ VEGETA ~]

I want to discuss something with you, which is masking the details of the video out and leave only flat areas. I didn't do much tests and I am using vapoursynth now I didn't achieve flexibility yet.

My method is this: make an edge mask and make it strong so that it includes all edges and details. Since details are somehow similar to edges. Playing around with the mask (I guess it was sobel or something) makes better results, although I didn't know how to make it expand in VS at that time.

Now that I have the details, I just inverse the result to get the no-details areas, hence, flat ares. Now I can use smdegrain without fear.

I do mask the dark areas (using levels) to safely apply f3kdb the way I want, I almost never apply filters to the whole video. However, when I want to use gradfun3, I take extra care because sometimes its results are bad... like masking out the dark areas and the extremely bright ones, then apply it to that area.

As for add_grain or GrainFactory3, sometimes I like them but they are not suitable for normal anime and I haven't used them on actual encode.


What do you think of this way? what is your way?

[sneaker_ger]

My method is this: make an edge mask and make it strong so that it includes all edges and details. Since details are somehow similar to edges. Playing around with the mask (I guess it was sobel or something) makes better results, although I didn't know how to make it expand in VS at that time.
I wonder if there's any plugin that works like the activity masking from Daala and could be useful for your idea. Scroll down to "Activity Masking: Putting the P in PVQ":
https://people.xiph.org/~jm/daala/pvq_demo/

[~ VEGETA ~]

I wonder if there's any plugin that works like the activity masking from Daala and could be useful for your idea. Scroll down to "Activity Masking: Putting the P in PVQ":
https://people.xiph.org/~jm/daala/pvq_demo/

Seems interesting enough. What do you use to achieve what I posted?

thanks

[sneaker_ger]

I never bothered with masking. I just filter everything.

[~ VEGETA ~]

I never bothered with masking. I just filter everything.

oh but what filters do you use?

[feisty2]

I want to discuss something with you, which is masking the details of the video out and leave only flat areas. I didn't do much tests and I am using vapoursynth now I didn't achieve flexibility yet.

My method is this: make an edge mask and make it strong so that it includes all edges and details. Since details are somehow similar to edges. Playing around with the mask (I guess it was sobel or something) makes better results, although I didn't know how to make it expand in VS at that time.

Now that I have the details, I just inverse the result to get the no-details areas, hence, flat ares. Now I can use smdegrain without fear.

I do mask the dark areas (using levels) to safely apply f3kdb the way I want, I almost never apply filters to the whole video. However, when I want to use gradfun3, I take extra care because sometimes its results are bad... like masking out the dark areas and the extremely bright ones, then apply it to that area.

As for add_grain or GrainFactory3, sometimes I like them but they are not suitable for normal anime and I haven't used them on actual encode.


What do you think of this way? what is your way?

details = mt_makediff(last, last.removegrain(20).removegrain(20).removegrain(20))
last.removegrain(20).removegrain(20).removegrain(20)
#blah blah blah to flat components
last.mt_adddiff(details)

[GMJCZP]

How do I convert a video from 12 bit to 8 bit with X264? Do I need to use Dither Tools to avoid banding?

[kgrabs]

How do I convert a video from 12 bit to 8 bit with X264? Do I need to use Dither Tools to avoid banding?

With --input-depth 12 in the command line, x264 will use Sierra-2-4A error diffusion to dither to the target depth.

Otherwise, with 12 bit interleaved format, this should be mostly identical to ditherpost defaults (ordered dither):

f3kdb(0,0,0,0,0,0, keep_tv_range=true, dither_algo=2, input_mode=2, input_depth=12, output_mode=0, output_depth=8)

[real.finder]

With --input-depth 12 in the command line, x264 will use Floyd Steinberg error diffusion to dither to the target depth.

Otherwise, with 12 bit interleaved format, this should be mostly identical to ditherpost defaults (ordered dither):

f3kdb(0,0,0,0,0,0, keep_tv_range=true, dither_algo=2, input_mode=2, input_depth=12, output_mode=0, output_depth=8)

or

f3kdb_dither(mode=0, stacked=false, input_depth=12)

[GMJCZP]

Thank you very mucho to both.

I am getting a distorted image with many colors when using both formulas with f3kdb.

I do not work neither version 1.5.1 nor f3kdb-rev410.
With the f3kdb-rev410 32 bit version does not deserve the function f3kdb_dither (mode = 0, stacked = false, input_depth = 12).

[real.finder]

Thank you very mucho to both.

I am getting a distorted image with many colors when using both formulas with f3kdb.

I do not work neither version 1.5.1 nor f3kdb-rev410.
With the f3kdb-rev410 32 bit version does not deserve the function f3kdb_dither (mode = 0, stacked = false, input_depth = 12).

what avs you use? and by what source filter and it's version?

[GMJCZP]

Avisynth sET avisynth_20150220; ffms2-2.23.1-msvc.

Edit: I already tried with Avisynth 2.6.0 RC3 (AviSynth_150419) and same result.

[real.finder]

Avisynth sET avisynth_20150220; ffms2-2.23.1-msvc.

Edit: I already tried with Avisynth 2.6.0 RC3 (AviSynth_150419) and same result.

the output in your case is always 8 bit, you must use avs+, and avs+ already has bits converter too

[GMJCZP]

the output in your case is always 8 bit, you must use avs+, and avs+ already has bits converter too
I understand. The alternative is pass directly the source in x264 with the option --input-depth 12 and make and lossless x264 8 bit output for future modifications.

[sneaker_ger]

With --input-depth 12 in the command line, x264 will use Floyd Steinberg error diffusion to dither to the target depth.
x264's dithering is based on Sierra-2-4A.

[GMJCZP]

How strange, in Simplex264 I put --input-depth 12 and I get the video with the strange colors.

[sneaker_ger]

What exactly is your script and the command Simplex264 uses? If AviSynth outputs 8 bit and you tell x264 the input is 12 bit that's gotta result in disaster, naturally.

[GMJCZP]

In simple x264 I put directly (withouth avisynth) the source and the custom parameter --input-depth 12.

With both avisynth and avisynth+ I get the same results, opening the script with VirtualDub:

FFVideoSource("video.mp4") # source is x265 12 bit
AssumeFPS("ntsc_film")
f3kdb(0,0,0,0,0,0, keep_tv_range=true, dither_algo=2, input_mode=2, input_depth=12, output_mode=0, output_depth=8)

[sneaker_ger]

At least for AviSynth FFVideoSource() will already dither to 8 bit. For AviSynth+ it may output native 12 bit but then again f3kdb() does not support anything high-bitdepth natively in AviSynth+. It may depend on the exact ffms2 and AviSynth+ version but I believe your script never makes sense. You could try LWLibavvideosource() (L-Smash Works) with stacked=true and e.g. format="YUV420P16" (*) parameters, then input_mode=1 for f3kdb().


(*) format="YUV420P16" for 4:2:0 sub-sampling. Change accordingly if required.

[GMJCZP]

Could you please put the new script? My head is spinning.

EDIT: It works with Avisynth+:

LWLibavvideosource("C21 jap.mp4" )
AssumeFPS("ntsc_film")
f3kdb(0,0,0,0,0,0, keep_tv_range=true, dither_algo=2, input_mode=2, input_depth=12, output_mode=0, output_depth=8)

Now, is the script correct to go from 12 bit to 8 bit?

EDIT2: the outpu in Simplex264 is with garbage, lol.

[sneaker_ger]

Yes, should be correct. It should also work like that in normal AviSynth.

[GMJCZP]

Yes, should be correct. It should also work like that in normal AviSynth.

Ok, but and the output with garbage with simplex264? Should I define the format with LWLibavvideosource?

[sneaker_ger]

I cannot comprehend that sentence.

[GMJCZP]

The output with x264 presents garbage, is it not that I need to define the format with LWLibavvideosource to prevent encoding errors?
EDIT: placing LWLibavvideosource ("video.mp4", format = "YUV420P12") causes VirtualDub to display the same garbage as when encoding with Simplex264.

[sneaker_ger]

You already had the correct script in #1085. Don't change it. The script outputs 8 bit so you must not set any bitdepth parameters in x264/Simplex264.

[GMJCZP]

You already had the correct script in #1085. Don't change it. The script outputs 8 bit so you must not set any bitdepth parameters in x264/Simplex264.

Okay, but with that script the video looks like garbage after coding without set the bitdepth.

[sneaker_ger]

(Simple)x264 command/log?

[GMJCZP]

In these last tests with LWLibavvideosource coding errors have been my fault.
I added the Stab() function in the script and when removing everything was solved, thanks Sneaker_Ger and all for your patience.

Now the question remains: Do DePan/Repair have any incompatibility with 12 bit?

[real.finder]

In these last tests with LWLibavvideosource coding errors have been my fault.
I added the Stab() function in the script and when removing everything was solved, thanks Sneaker_Ger and all for your patience.

Now the question remains: Do DePan/Repair have any incompatibility with 12 bit?

the old avs don't support anything more than 8 bit, there are some hack way in some old filter like f3kdb and dither, any new filter that support anything more than 8 bit will need avs+, in old avs will work in 8 bit only cuz no one care about old hacks if there are native support

[tormento]

>>>> dither-1.27.2.zip <<<< (http://ldesoras.free.fr/src/avs/dither-1.27.2.zip)
Could you give it a bump to adapt to latest AVS+ with high bit support too? :)

[felicityb]

Hello!! So I've recently gotten into making animated gifs using VirtualDub's gif creator and Avisynth (I don't got Photoshop monies). A major problem I'm running into is that it creates horrible banding, and I was wondering if Dither's color conversion scripts could help me out. Anyway, long story short - I keep getting this lovely message anytime I tried to call any Dither functions into my script.

"Avisynth Read Error: CAVIStreamSynth: System exception - Illegal Instruction at 0x5ab57ea0"

The script will open, but I get a gray box and anytime I try to scroll through the video, I get that message. I have the latest version of Dither and the 16bit mod of MaskTools, and I'm running the latest stable avs+.

This is my script -

ffvideosource(source="C:\Users\The Boys\Desktop\Dance.avi")

Dither_convert_yuv_to_rgb(matrix="601", interlaced=false,
tv_range=false, cplace="MPEG2", lsb_in=false,
chromak="spline64", mode=0, ampo=1, ampn=1,
staticnoise=false, slice=false, output="rgb24", noring=true)

And this does this with videos encoded with any codec. My initial test was with a video encoded with Lagarith, but then I tried one encoded in h.264 (it was a YT rip), and boop - same result.

[StainlessS]

Create a report with Groucho2004 AvsMeter, just so we know what you are using (versions etc).
Run command prompt,

then eg CD C:\Z (or change directory to some other known directory, I have a C:\Z folder)

AvsMeter -AvsInfo -log # will create log in Z directory. # Edit with AvsMeter in Z directory, or somewhere in your PATH.
Post it here.

Also, if possible, use AviSource, rather than FFMpegSource, just to remove it from the problem space.
also, does problem disappear if you change the arguments to Dither_convert_yuv_to_rgb ?

EDIT: Latest version Dither Tools is 1.27.2:- http://avisynth.nl/index.php/Dither_tools

EDIT: My log was 42KB (D9 post limit is 16KB in Usage forum), if you cut out the Internal(builtin) and External function/filter
names it should be cut down some (mine went down to 15KB), so you can post in thread.

[felicityb]

Create a report with Groucho2004 AvsMeter, just so we know what you are using (versions etc).
Run command prompt,

eg CD C:\Z (or change to some known directory, I have a C:\Z folder)

AvsMeter -AvsInfo -log # will create log in Z directory. # Edit with AvsMeter in Z directory, or somewhere in your PATH.
Post it here.

Also, if possible, use AviSource, rather than FFMpegSource, just to remove it from the problem space.
also, does problem disappear if you change the arguments to Dither_convert_yuv_to_rgb ?

EDIT: Latest version Dither Tools is 1.27.2:- http://avisynth.nl/index.php/Dither_tools

EDIT: My log was 42KB (D9 post limit is 16KB in Usage forum), if you cut out the Internal(builtin) and External function/filter
names it should be cut down some (mine went down to 15KB), so you can post in thread.

Sorry for the wait, it's been quite a while since I've used CLI. Anyway, here's the relevant bits of the log file.


[OS/Hardware info]
Operating system: Windows 7 (x86) Service Pack 1.0 (Build 7601)
CPU brand string: Intel(R) Pentium(R) M processor 1.60GHz
CPU features: MMX, SSE, SSE2


[Avisynth info]
VersionString: AviSynth+ 0.1 (r1576, x86)
VersionNumber: 2.60
File / Product version: 2.6.0.5 / 2.6.0.5
Interface Version: 5
Multi-threading support: No
Avisynth.dll location: C:\Windows\system32\avisynth.dll
Avisynth.dll time stamp: 2014-01-03, 00:14:26 (UTC)
PluginDir2_5 (HKLM, x86): C:\Program Files\AviSynth\plugins
PluginDir+ (HKLM, x86): C:\Program Files\AviSynth+\plugins+


[CPP 2.5 / 32 Bit Plugins]
C:\Program Files\AviSynth\plugins\AddGrainC.dll [1.7.1.0]
C:\Program Files\AviSynth\plugins\dfttest.dll [1.9.4.0]
C:\Program Files\AviSynth\plugins\dither.dll
C:\Program Files\AviSynth\plugins\eedi3.dll [0.9.2.0]
C:\Program Files\AviSynth\plugins\FFT3DFilter.dll [2.1.1.0]
C:\Program Files\AviSynth\plugins\gradfun2db.dll
C:\Program Files\AviSynth\plugins\mvtools2.dll [2.6.0.5]
C:\Program Files\AviSynth\plugins\SmoothUV.dll [1.4.0.0]
C:\Program Files\AviSynth\plugins\SSE2Tools.dll
C:\Program Files\AviSynth\plugins\TBilateral.dll [0.9.11.0]
C:\Program Files\AviSynth\plugins\TUnsharp.dll [0.9.3.0]

[CPP 2.6 / 32 Bit Plugins]
C:\Program Files\AviSynth+\plugins+\DirectShowSource.dll
C:\Program Files\AviSynth+\plugins+\ImageSeq.dll
C:\Program Files\AviSynth+\plugins+\Shibatch.dll
C:\Program Files\AviSynth+\plugins+\TimeStretch.dll
C:\Program Files\AviSynth+\plugins+\VDubFilter.dll
C:\Program Files\AviSynth\plugins\DePan.dll [2.13.1.3]
C:\Program Files\AviSynth\plugins\DePanEstimate.dll [2.10.0.2]
C:\Program Files\AviSynth\plugins\DirectShowSource.dll [2.6.0.3]
C:\Program Files\AviSynth\plugins\ffms2.dll
C:\Program Files\AviSynth\plugins\masktools2.dll [2.1.0.0]
C:\Program Files\AviSynth\plugins\MedianBlur2.dll
C:\Program Files\AviSynth\plugins\RgTools.dll
C:\Program Files\AviSynth\plugins\TCPDeliver.dll [2.6.0.7]

[Scripts / AVSI]
C:\Program Files\AviSynth+\plugins+\colors_rgb.avsi
C:\Program Files\AviSynth\plugins\colors_rgb.avsi
C:\Program Files\AviSynth\plugins\Dehalo_alpha_MT2.avsi
C:\Program Files\AviSynth\plugins\dither.avsi
C:\Program Files\AviSynth\plugins\FFMS2.avsi
C:\Program Files\AviSynth\plugins\FineDehalo.avsi
C:\Program Files\AviSynth\plugins\LRemoveDust.avsi
C:\Program Files\AviSynth\plugins\mt_xxpand_multi.avsi
C:\Program Files\AviSynth\plugins\RemoveDustHD.avsi
C:\Program Files\AviSynth\plugins\tA7aHtYP.avsi

[Uncategorized / 32 Bit DLLs]
C:\Program Files\AviSynth\plugins\libfftw3f-3.dll

[Uncategorized / Other]
C:\Program Files\AviSynth+\plugins+\colors_rgb.txt
C:\Program Files\AviSynth\plugins\ffms2.lib
C:\Program Files\AviSynth\plugins\ffmsindex.exe


I changed FFMPEGSource to AVISource and I get the same message. I also ran the avs script through AVS Meter and it gives me the same error. And I've tweaked nearly every argument in the script, left some on default, etc etc. Gives me the same message.

[StainlessS]

[Avisynth info]
VersionString: AviSynth+ 0.1 (r1576, x86)
VersionNumber: 2.60
File / Product version: 2.6.0.5 / 2.6.0.5
Interface Version: 5
Multi-threading support: No
Avisynth.dll location: C:\Windows\system32\avisynth.dll
Avisynth.dll time stamp: 2014-01-03, 00:14:26 (UTC) # Old ver$, Update to current Pinterf Avisynth+ r2542 (20171114)

[Scripts / AVSI]
C:\Program Files\AviSynth\plugins\tA7aHtYP.avsi # Dont like, looks like typical malware name. No hits on Google. What is it ?

[Uncategorized / 32 Bit DLLs]
C:\Program Files\AviSynth\plugins\libfftw3f-3.dll # Should be in System32 EDIT: Think for dfttest and/or others.

[Uncategorized / Other]
C:\Program Files\AviSynth\plugins\ffms2.lib # Maybe Delete (not intended to be here)


Update to Avisynth+ r2542 (20171114), (Not MT Version, unless required) here:- https://github.com/pinterf/AviSynthPlus/releases

Many updates since your version AVS+, maybe problem fixed already.

EDIT: OK, Google'ed tA7aHtYP without the 'avsi' and its, DeHaloHmod 11 11 2016 http://pastebin.com/tA7aHtYP
Suggest rename to something more descriptive.

[felicityb]

Update to Avisynth+ r2542 (20171114), (Not MT Version, unless required) here:- https://github.com/pinterf/AviSynthPlus/releases

Many updates since your version AVS+, maybe problem fixed already.

EDIT: OK, Google'ed tA7aHtYP without the 'avsi' and its, DeHaloHmod 11 11 2016 http://pastebin.com/tA7aHtYP
Suggest rename to something more descriptive.

I upgraded everything and I'm still getting the same error. AVSMeter says the error is coming directly from Dither.dll.


AVSMeter 2.6.8 (x86) - Copyright (c) 2012-2017, Groucho2004
AviSynth+ 0.1 (r2544, MT, i386) (0.1.0.0)

Exception 0xC000001D [STATUS_ILLEGAL_INSTRUCTION]
Module: C:\Program Files\AviSynth\plugins\dither.dll
Address: 0x60457EA0


I also couldn't find a version of avs+ r2544 without MT

[Groucho2004]

I upgraded everything and I'm still getting the same error. AVSMeter says the error is coming directly from Dither.dll.


AVSMeter 2.6.8 (x86) - Copyright (c) 2012-2017, Groucho2004
AviSynth+ 0.1 (r2544, MT, i386) (0.1.0.0)

Exception 0xC000001D [STATUS_ILLEGAL_INSTRUCTION]
Module: C:\Program Files\AviSynth\plugins\dither.dll
Address: 0x60457EA0

I suggest starting from scratch. Remove all plugins (make a backup, just in case) and add plugins as needed.

I also couldn't find a version of avs+ r2544 without MTThere is no such thing. AVS+ has been multi-threaded since r16xx.

[StainlessS]

There is no such thing. AVS+ has been multi-threaded since r16xx.

OK, but whats difference in the '-MT' postfixed versions then ???

Latest release

r2544-MT
53b8d15

Avisynth+ r2544-MT

@pinterf pinterf released this 15 days ago · 2 commits to MT since this release
Avisynth+ r2544 (20171115)

20171115 r2544
Fixes

Expr: fix "scalef" for 10-16 bits

modification, additions

Expr optimization: eliminate ^1 +0 -0 *1 /1

Avisynth+ r2542 (20171114)
Fixes

Fix: RGB (full scale) conversion: 10-16 bits to 8 bits rounding issue; pic got darker in repeated 16<->8 bit conversion chain
Fix: ConvertToY: remove unnecessary clamp for Planar RGB 32 bit float
Fix: RGB ConvertToY when rec601, rec709 (limited range) matrix. Regression since r2266



EDIT: Arh, the one in red is not post fixed, perhaps pinterf adds -MT or not, depending upon mood :)
EDIT: Nah, my mistake, all are postfixed now in actual file name.
EDIT: Guess that I should not skim read.
EDIT: Think I'm finally gonna try avs+ (long-long time since done that), and in x64 I think.

[tormento]

Am I wrong or dither is one of the most used plugin and yet with old AVS 2.5 API?

@pinterf and @all

A refresh would be welcome. Last version is AFAIK 1.27.2 from 2015.

[DJATOM]

Am I wrong or dither is one of the most used plugin and yet with old AVS 2.5 API?

@pinterf and @all

A refresh would be welcome. Last version is AFAIK 1.27.2 from 2015.

https://mega.nz/#!f4sHXYgQ!Hf-5Di0ymJIiMko2XlB8YSsqtkNbedSe9Bn4CkPyRO4 I just made both win32 and x64 versions with AvisynthPluginInit3. If you know valid up-to-date mt modes for dither, I can add them internally.

[tormento]

I just made both win32 and x64 versions with AvisynthPluginInit3.
:thanks:
If you know valid up-to-date mt modes for dither, I can add them internally.
I use external MT with AVS+ (if I've correctly understood your question).
SetFilterMTMode("DEFAULT_MT_MODE", 2)
…
Prefetch(6)

[DJATOM]

# Filters from Dither 1.25.0. Tested by Firesledge (not extensively though)
SetFilterMTMode ("DitherPost", MT_NICE_FILTER)
SetFilterMTMode ("SmoothGrad", MT_NICE_FILTER)
SetFilterMTMode ("Dither_box_filter16", MT_NICE_FILTER)
SetFilterMTMode ("Dither_bilateral16", MT_NICE_FILTER)
SetFilterMTMode ("Dither_limit_dif16", MT_NICE_FILTER)
SetFilterMTMode ("Dither_resize16", MT_NICE_FILTER)
SetFilterMTMode ("Dither_out", MT_NICE_FILTER)
SetFilterMTMode ("Dither_removegrain16", MT_NICE_FILTER)
SetFilterMTMode ("Dither_repair16", MT_NICE_FILTER)
SetFilterMTMode ("Dither_median16", MT_NICE_FILTER)
SetFilterMTMode ("Dither_add16", MT_NICE_FILTER)
SetFilterMTMode ("Dither_sub16", MT_NICE_FILTER)
SetFilterMTMode ("Dither_max_dif16", MT_NICE_FILTER)
SetFilterMTMode ("Dither_merge16", MT_NICE_FILTER)
It was in my MtModes.avsi, but Idk if that's up-to-date.

[tormento]

It was in my MtModes.avsi, but Idk if that's up-to-date.
Never had problems with mode 2.

[DJATOM]

Mode 2 will eat more RAM, so it's better to stick with mode 1 if possible. Anyway new build (now with sources), with mt mode 1 declared internally: https://mega.nz/#!CtcRVLgZ!qzrTRjvu9IGCoembfyf6oPkjj5-tqfWniOrbuG_lmjY

[GMJCZP]

Thanks DJATOM for the new paint job!

[tormento]

@DJATOM
I gave a try to your latest build of dither and it gives me error.

Script:
SetMemoryMax(8000)
SetFilterMTMode("DEFAULT_MT_MODE", 2)
LoadPlugin("D:\eseguibili\media\DGDecNV\x64\DGDecodeNV.dll")
DGSource("E:\in\2_00 Fuga di mezzanotte\fuga.dgi")
#CompTest(1)
SMDegrain (tr=6, thSAD=400, refinemotion=false, lsb=true, mode=0, contrasharp=false, PreFilter=4, truemotion=false, plane=4, chroma=true)
Prefetch(6)
Gives me the error:
[2018-04-11][22:44:18] Simple x264 Launcher (Build #1124), built 2018-02-27
[2018-04-11][22:44:18]
[2018-04-11][22:44:18] Job started at 2018-04-11, 22:44:18.
[2018-04-11][22:44:18]
[2018-04-11][22:44:18] Source file : E:\in\2_00 Fuga di mezzanotte\fuga_6_lsb.avs
[2018-04-11][22:44:18] Output file : E:\in\2_00 Fuga di mezzanotte\fuga_6_lsb.mkv
[2018-04-11][22:44:18]
[2018-04-11][22:44:18] --- SYSTEMINFO ---
[2018-04-11][22:44:18]
[2018-04-11][22:44:18] Binary Path : D:\eseguibili\media\x264 launcher
[2018-04-11][22:44:18] Avisynth : Yes
[2018-04-11][22:44:18] VapourSynth : No
[2018-04-11][22:44:18]
[2018-04-11][22:44:18] --- SETTINGS ---
[2018-04-11][22:44:18]
[2018-04-11][22:44:18] Encoder : x264 (AVC/H.264), 64-Bit (x64), 8-Bit
[2018-04-11][22:44:18] Source : Avisynth (avs)
[2018-04-11][22:44:18] RC Mode : CRF
[2018-04-11][22:44:18] Preset : slow
[2018-04-11][22:44:18] Tuning : <None>
[2018-04-11][22:44:18] Profile : High
[2018-04-11][22:44:18] Custom : --level 4.1 --keyint 240 --aq-mode 2 --sar 1:1
[2018-04-11][22:44:18]
[2018-04-11][22:44:18] --- CHECK VERSION ---
[2018-04-11][22:44:18]
[2018-04-11][22:44:18] Detect video encoder version:
[2018-04-11][22:44:18]
[2018-04-11][22:44:18] Creating process:
[2018-04-11][22:44:18] "D:\eseguibili\media\x264 launcher\toolset\x64\x264_x64.exe" --version
[2018-04-11][22:44:18]
[2018-04-11][22:44:18] x264 0.155.2901 7d0ff22
[2018-04-11][22:44:18] (libswscale 5.0.101)
[2018-04-11][22:44:18] (libavformat 58.10.100)
[2018-04-11][22:44:18] (ffmpegsource 2.30.0.0)
[2018-04-11][22:44:18] built on Feb 26 2018, gcc: 7.3.0
[2018-04-11][22:44:18] x264 configuration: --chroma-format=all
[2018-04-11][22:44:18] libx264 configuration: --chroma-format=all
[2018-04-11][22:44:18] x264 license: GPL version 2 or later
[2018-04-11][22:44:18] libswscale/libavformat/ffmpegsource license: GPL version 2 or later
[2018-04-11][22:44:18]
[2018-04-11][22:44:18] Detect video source version:
[2018-04-11][22:44:18]
[2018-04-11][22:44:18] Creating process:
[2018-04-11][22:44:18] "D:\eseguibili\media\x264 launcher\toolset\x64\avs2yuv_x64.exe"
[2018-04-11][22:44:18]
[2018-04-11][22:44:18] Avs2YUV 0.24bm5
[2018-04-11][22:44:18]
[2018-04-11][22:44:18] > x264 revision: 2901 (core #155)
[2018-04-11][22:44:18] > Avs2YUV version: 0.24.5
[2018-04-11][22:44:18]
[2018-04-11][22:44:18] --- GET SOURCE INFO ---
[2018-04-11][22:44:18]
[2018-04-11][22:44:18] Creating process:
[2018-04-11][22:44:18] "D:\eseguibili\media\x264 launcher\toolset\x64\avs2yuv_x64.exe" -frames 1 "E:\in\2_00 Fuga di mezzanotte\fuga_6_lsb.avs" NUL
[2018-04-11][22:44:18]
[2018-04-11][22:44:20] error: System exception - Access Violation
[2018-04-11][22:44:20] (D:/Programmi/Media/AviSynth+/plugins64/SMDegrain-3.1.2�97.avsi, line 739)
[2018-04-11][22:44:20] (D:/Programmi/Media/AviSynth+/plugins64/SMDegrain-3.1.2�97.avsi, line 200)
[2018-04-11][22:44:20] (E:\in\2_00 Fuga di mezzanotte\fuga_6_lsb.avs, line 16)
[2018-04-11][22:44:20]
[2018-04-11][22:44:20] PROCESS EXITED WITH ERROR CODE: 1

Same script works fine with standard dither.dll

[DJATOM]

Yes, I forgot to add one line, fixed version (https://mega.nz/#!2wNGQLqD!3ZNAnfwb4HNljE5XE9ZbzrurVWqu1vs_QSMqXTHZzb4).

[tormento]

Yes, I forgot to add one line
Tested, working.

[Dreamject]

This topic is not active, I created new, but may be somebody can give me instruction to launch dither tools on PotPlayer https://forum.doom9.org/showthread.php?p=1861062

[Sparktank]

Now that AVS+ and avsresize are updated nicely, would it take much for someone to update this to accept non-stacked colorspaces or yuv420ps ?
I like the linear/sigmoid functions in this resizer, but find it tedious to keep converting to/from stacked.

I just might jump on VS for this plugin to resize in placebo-likeness.

[Natty]

can someone suggest me few ways to remove banding occured in few scenes after heavy denoising? i am just using this. but it doesn't remove banding completely.

f3kdb(preset="veryhigh", input_depth=16, output_depth=16)

[ChaosKing]

Try higher Y/cb/cr values and/or higher grain values.
https://f3kdb.readthedocs.io/en/latest/usage.html#cmdoption-arg-y
https://f3kdb.readthedocs.io/en/latest/presets.html

[Natty]

thanks. i found a stable setting :thanks:

[LouieChuckyMerry]

Happy Day!

[TheProfosist]

So I have been out of the game for some time (early pages of this thread ~2011) and dither is really having me scratch my head once again.

Im looking to output 4:4:4 10bit to x264. I have used dither in the past and do do this exact function however the younger me never took any notes so I am at a loss as to whats needed why and where. Below are two example scripts that I was hoping someone could help me dissect and figure out what was done is these and if that is still the best way to go about things. I would like to do the script a bit better like the second one making it easier to follow but would like to put together better notes and comments than the first one has. Im sure there are some plugins im missing that ill have to round up as well.


Xamd (should be 444): https://pastebin.com/f1c4vkWb

Beck (dither 16bit to 10bit): https://pastebin.com/7dGdpfyf


Ill have to grab some additional plugins as im definitely missing some that are in those scripts. Are the best files to use sill the ones in the beginning of the thread and their special mod16 versions or should I be looking into @DJATOM 's fixed version linked above? Git also has an updated version of dfttest. No idea it its compatible however.

Yes, I forgot to add one line, fixed version (https://mega.nz/#!2wNGQLqD!3ZNAnfwb4HNljE5XE9ZbzrurVWqu1vs_QSMqXTHZzb4).


thanks in advance for the help. Ill have the progress of the AVS script as well as the final one on pastebin once complete

[DJATOM]

@TheProfosist Applying debilinear onto entire source is bad idea. You will definitely mess up captions (they are applied onto source after upscaling), you must do some masking for them and resize with regular downscaler.

[TheProfosist]

@TheProfosist Applying debilinear onto entire source is bad idea. You will definitely mess up captions (they are applied onto source after upscaling), you must do some masking for them and resize with regular downscaler.

are you talking about


#TextSub("E:\TEMP\5cmPerSec\02 - Video\5cmPerSec JP RA Subs.ass")


if so its commented out so ignore that. Its just a remnant of modifying a script ive used before

what im wondering is the order of operations of using dither



in beck I used dfttest but I didnt in xamd

notes from the xamd script say "##dfttest (lsb=true) or whatever generating stack16 data"


I think i remember why I had crop in the first 16bit filters area and that was because if I needed to crop I also had to re-pad it to a mod 16 resolution



the other big difference in these scripts is the end.

Beck just has f3kdb

f3kdb(dither_algo=3, input_mode=1, input_depth=16, output_mode=1, output_depth=10)



where as Xamd has


SmoothGrad (radius=16, thr=0.25, elast=2)


ly = debilineary(960,540,lsb_inout=true)
lu = utoy8().dither_resize16(960,540,kernel="blackman",src_left=0.25,u=1,v=1)
lv = vtoy8().dither_resize16(960,540,kernel="blackman",src_left=0.25,u=1,v=1)
ytouv(lu,lv,ly)


## Finally DitherPost() or Dither_convey_yuv4xxp16_on_yvxx()
Dither_quantize(10, reducerange=true, mode=8)
Dither_convey_yuv4xxp16_on_yvxx()


if i recall correctly debilinear is what is up converting to 444



basically trying to figure out what I did and why which should aide me in using dither again. That is unless there is a better way to use this since its likely had updates since those AVS were written

[DJATOM]

No, I meant XamD source. It's upscaled from 540p and then OP/ED texts was applied onto it. So descaling will introduce artifacts on those captions.

[TheProfosist]

No, I meant XamD source. It's upscaled from 540p and then OP/ED texts was applied onto it. So descaling will introduce artifacts on those captions.

Ah well I can worry about that when I get the rest of the stuff working. Right now I dont have a specific source ill be using it on. Also back then it wasnt uncommon for me to use ordered chapters (i think thats the correct term) and clean op/ed if the anime allowed for it.

Right now im mostly interested in the flow of using dither. What you would use where are why. In that previous post I gave some examples. No clue if any of that is relevant anymore either since its been so long.

[real.finder]

in dither.avsi Dither_resize16nr Function I think there are bug in this line
sr_v = Float (height) / Float (src.height ())

the "Float (src.height ())" should be "Float (src.height ()/2)" since it's lsb stacked clip

find it when I was porting/mixing things to support HBD

here what I have for now, will add it later to ResizeX, any suggestions?
# base on Dither_resize16nr
Function sResizeXnr (clip src, int width, int height,
\ float "src_left",
\ float "src_top",
\ float "src_width",
\ float "src_height",
\ string "kernel",
\ int "taps",
\ float "a1",
\ float "a2",
\ string "cplace",
\ bool "luma",
\ bool "chroma",
\ bool "mt",
\ string "mt_params",
\ string "dither_params",
\ bool "desampling",
\ int "dither_mode",
\ bool "noring"
\ )
{
noring = Default (noring, true)

Assert (width > 0 && height > 0, "sResizeXnr: width and height must be > 0.")

sr_h = Float (width ) / Float (src.width () )
sr_v = Float (height) / Float (src.height ())
sr_up = max (sr_h, sr_v)
sr_dw = 1.0 / min (sr_h, sr_v)
sr = max (sr_up, sr_dw)
Assert (sr >= 1.0)

# Depending on the scale ratio, we may blend or totally disable
# the ringing cancellation
thr = 2.5
nrb = (sr > thr)
nrf = (sr < thr + 1.0 && noring)
nrr = (nrb) ? min (sr - thr, 1.0) : 1.0
nrv = (nrb) ? Round ((1.0 - nrr) * 255) * $010101 : 0

main = src.ResizeX (width, height,
\ src_left =src_left,
\ src_top =src_top,
\ src_width =src_width,
\ src_height=src_height,
\ kernel =kernel,
\ taps =taps,
\ a1 =a1,
\ a2 =a2,
\ cplace =cplace,
\ luma =luma,
\ chroma =chroma,
\ mt =mt,
\ mt_params =mt_params,
\ dither_params=dither_params,
\ desampling=desampling,
\ dither_mode=dither_mode
\ )

nrng = (nrf) ? src.ResizeX (width, height,
\ src_left =src_left,
\ src_top =src_top,
\ src_width =src_width,
\ src_height=src_height,
\ kernel ="gauss",
\ a1 =100,
\ cplace =cplace,
\ luma =luma,
\ chroma =chroma
\ ) : main

nrm = (nrb && nrf) ? main.BlankClip (color_yuv=nrv, height=main.Height()) : main

rgm = 1
rgc = (nrb) ? -1 : 0
ild = Defined(luma)
icd = Defined(chroma)
rgl = ild ? (luma ? rgm : rgc) : rgm
rgch = icd ? (chroma ? rgm : rgc) : rgm
y = ild ? luma ? 3 : 2 : 3
u = icd ? chroma ? 3 : 2 : 3
v = u
(nrf ) ? main.repair (nrng, rgl, rgch) : main
(nrf && nrb) ? mt_merge (main, last, nrm, y=y, u=u, v=v, luma=chroma) : last
}

[real.finder]

can we have port of vs fmtconv (https://forum.doom9.org/showthread.php?t=166504) to avs/avs+ with HBD? I try to update/port/rewrite crt_display to avs+ HBD then I see it use fh, fv in dither_resize16

and its not only for crt_display and "fh, fv", dither_resize16/fmtconv has many other things like kernel inversion mode and additional Kernels

[tormento]

can we have port of vs fmtconv (https://forum.doom9.org/showthread.php?t=166504) to avs/avs+ with HBD?
AVSResize wouldn't fit?

[real.finder]

AVSResize wouldn't fit?

it's not https://forum.doom9.org/showthread.php?p=1906754#post1906754

https://i.postimg.cc/hzgKxtwq/Untitled.png (https://postimg.cc/hzgKxtwq)

[cretindesalpes]

Dither 1.28.0 (http://forum.doom9.org/showthread.php?p=1386559#post1386559):
Added Dither_lutspa8 and Dither_lutspa16.
Fixed height issue in Dither_resize16nr. Thanks to real.finder for the report.
DLL recompiled with Visual C++ 2019.

[kedautinh12]

Dither 1.28.0 (http://forum.doom9.org/showthread.php?p=1386559#post1386559):
Added Dither_lutspa8 and Dither_lutspa16.
Fixed height issue in Dither_resize16nr. Thanks to real.finder for the report.
DLL recompiled with Visual C++ 2019.

Thanks

[real.finder]

Dither 1.28.0 (http://forum.doom9.org/showthread.php?p=1386559#post1386559):
Added Dither_lutspa8 and Dither_lutspa16.
Fixed height issue in Dither_resize16nr. Thanks to real.finder for the report.
DLL recompiled with Visual C++ 2019.

thanks, but is there any plan to support HBD in avs+ or port fmtconv to avs? since the HBD filters nowadays are way more than lsb ones and also there are float point in HBD of avs+

[cretindesalpes]

real.finder: sorry, there is no plan at the moment. I don’t do much video processing these days and have other projects with higher priority.

EDIT—another update:

MVTools 2.6.1.0 (http://forum.doom9.org/showthread.php?p=1386559#post1386559)
MSuper, MDegrain1/2/3/N: YV16 and YV24 colorspaces are supported for filtering. Analysis still requires YV12 or YUY2 clips.
FlowFPS, FlowInter and MMask: fixed a memory intialization bug that could produce slightly different results each run. Thanks to dubhater for the fix.
MAnalyse, MRecaculate: fixed block size parameter check in divide mode. Thanks again to dubhater.
MDepan: parameter zerow is now actually taken into account.
DLL recompiled with VC++ 2019, source files and projects modified accordingly.

EDIT—second update:

Dither was updated to v1.28.1. Fixed a regression in mode 20 of Dither_removegrain16.

[tormento]

Sorry to resurrect some old stuff but...

Is there any newer version of Dither?

I have checked 1.28.1 version and it's still a 2.5 plugin.

If positive, perhaps I have lost the release. Please address me ;)

[real.finder]

Regarding Dither modernization for HBD, I think it's impossible to do it as it now, After thinking and talking with people that do encode from long times, it's better to port dither_bilateral16 (it's seems work differently from the rest and as some friend said "it strikes a nice balance between strength and detail loss"), Dither_box_filter16 (same as dither_bilateral16 case), and SmoothGrad to independent plugins and backport fmtconv (https://forum.doom9.org/showthread.php?t=166504) (ported done https://forum.doom9.org/showthread.php?t=183139 thanks to cretindesalpes), if these done then we will not need dithertools anymore in avs+

[kedautinh12]

True, but no one backport it now

[kedautinh12]

I seen 299792458m update dfttest 1.9.6 of pinterf with new commits, can anyone compile it?? thanks
https://github.com/299792458m/dfttest_mod/commits/196

[kedautinh12]

New fork of fmtconv
https://github.com/AkarinVS/fmtconv

[cretindesalpes]

backport fmtconv (https://forum.doom9.org/showthread.php?t=166504) [...] in avs+
I’m currently working to make fmtconv easier to port to other standards. The bitdepth part requires the most work here. However I’m not sure if I’ll do the final port yet.

[StainlessS]

I’m currently working to make fmtconv easier to port to other standards. The bitdepth part requires the most work here. However I’m not sure if I’ll do the final port yet.

The pussycat is still alive, we are all happy to hear that,
live long and prosper CD. [OK you made some recent posts too, I did not miss all of them].

[GMJCZP]

The pussycat is still alive, we are all happy to hear that,
live long and prosper CD. [OK you made some recent posts too, I did not miss all of them].

+1, Thanks cretindesalpes for your contributions.

[real.finder]

I’m currently working to make fmtconv easier to port to other standards. The bitdepth part requires the most work here. However I’m not sure if I’ll do the final port yet.

good news, thanks! if you have time can you port dither_bilateral16, Dither_box_filter16 and SmoothGrad to independent plugins with new appropriate names and HBD?

[kedautinh12]

DFTTest latest ver
https://github.com/pinterf/dfttest/releases

[kedautinh12]

Updated dither - 1.28.1.1 x64 from Asd-g: updated to 2.6 plugin, added support for passthrough frame properties
https://gitlab.com/uvz/AviSynthPlus-Plugins-Scripts/-/blob/master/plugins64%2B/dither.dll

[real.finder]

if you have time can you port dither_bilateral16, Dither_box_filter16 and SmoothGrad to independent plugins with new appropriate names and HBD?

for now I think we only miss Dither_bilateral16 alternative
Dither_box_filter16 and Dither_bilateral16 https://forum.doom9.org/showthread.php?p=1951312&highlight=dither_bilateral16#post1951312

SmoothGrad https://forum.doom9.org/showthread.php?p=1952859&highlight=Dither_box_filter16#post1952859