Log in

View Full Version : Color banding and noise removal


Pages : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 [22] 23

James Freeman
15th April 2016, 22:51
It works.

bilditup1
2nd June 2016, 08:53
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
2nd June 2016, 22:18
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
4th June 2016, 01:04
...

Thanks for taking the time to explain.

colours
6th June 2016, 21:04
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
6th June 2016, 23:00
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
7th June 2016, 16:23
(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
7th June 2016, 17:55
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
12th June 2016, 19:07
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
14th July 2016, 10:24
@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
27th July 2016, 14:47
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
3rd October 2016, 20:34
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
5th October 2016, 07:50
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 ~
14th October 2016, 11:41
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
14th October 2016, 14:14
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 ~
14th October 2016, 15:46
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
14th October 2016, 17:20
I never bothered with masking. I just filter everything.

~ VEGETA ~
14th October 2016, 18:55
I never bothered with masking. I just filter everything.

oh but what filters do you use?

feisty2
15th October 2016, 16:42
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
14th February 2017, 05:57
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
14th February 2017, 13:09
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
14th February 2017, 14:19
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
14th February 2017, 18:33
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
14th February 2017, 20:26
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
15th February 2017, 02:58
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
15th February 2017, 07:42
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
15th February 2017, 21:17
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
15th February 2017, 21:32
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
15th February 2017, 21:33
How strange, in Simplex264 I put --input-depth 12 and I get the video with the strange colors.

sneaker_ger
15th February 2017, 21:46
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
15th February 2017, 22:06
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
15th February 2017, 22:21
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
15th February 2017, 22:49
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
15th February 2017, 23:22
Yes, should be correct. It should also work like that in normal AviSynth.

GMJCZP
15th February 2017, 23:29
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
15th February 2017, 23:30
I cannot comprehend that sentence.

GMJCZP
15th February 2017, 23:32
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
15th February 2017, 23:39
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
15th February 2017, 23:46
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
15th February 2017, 23:53
(Simple)x264 command/log?

GMJCZP
16th February 2017, 00:04
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
16th February 2017, 13:21
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
26th February 2017, 11:42
>>>> 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
29th November 2017, 02:04
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
29th November 2017, 02:20
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
29th November 2017, 03:07
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
29th November 2017, 14:28
[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
29th November 2017, 20:21
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
29th November 2017, 21:57
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
30th November 2017, 12:11
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.