Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Capturing and Editing Video > Avisynth Development

Reply
 
Thread Tools Search this Thread Display Modes
Old 8th July 2012, 02:54   #21  |  Link
jconklin
Registered User
 
Join Date: Mar 2006
Posts: 39
I will have to add that to the documentation. I am building and testing in Windows 7 using Visual C++ 2005.
I have been busy optimizing the code which looks like it will make it about 20% faster. I also have a first cut at makeing it multithreaded.
It is going to take me a while to get the optimizations and multithreading done and released.
jconklin is offline   Reply With Quote
Old 8th July 2012, 13:25   #22  |  Link
Schwartzvald
Ooo Royalty
 
Join Date: Aug 2005
Posts: 9
Cool.

Regarding SmoothD2c.avs... I am not so great at writing scripts, so it took me a bit of staring at:

Code:
MergeLuma: Images must have same width and height!
and the script to figure out that I couldn't use the "downsize" parameter with video that wasn't mod16 at half resolution... which includes DVD video.

The following is probably incorrect, but it throwing me a message like this would have saved me a little time:

Code:
Assert( ( (m16(ow/2) != ow/2 || m16(oh/2) != oh/2) && downsize > 1 ) ? false : true, chr(10) + "'downsize' only works with mod32 resolutions!" + chr(10))
There's probably a better way to handle it--I'm a rather low-end Avisynth user. Forgive me if the syntax here is subpar or downright incorrect.
Schwartzvald is offline   Reply With Quote
Old 9th July 2012, 02:20   #23  |  Link
jconklin
Registered User
 
Join Date: Mar 2006
Posts: 39
Quote:
Originally Posted by Schwartzvald View Post
Cool.

Regarding SmoothD2c.avs... I am not so great at writing scripts, so it took me a bit of staring at:

Code:
MergeLuma: Images must have same width and height!
and the script to figure out that I couldn't use the "downsize" parameter with video that wasn't mod16 at half resolution... which includes DVD video.

The following is probably incorrect, but it throwing me a message like this would have saved me a little time:

Code:
Assert( ( (m16(ow/2) != ow/2 || m16(oh/2) != oh/2) && downsize > 1 ) ? false : true, chr(10) + "'downsize' only works with mod32 resolutions!" + chr(10))
There's probably a better way to handle it--I'm a rather low-end Avisynth user. Forgive me if the syntax here is subpar or downright incorrect.

My appologies. I did not think about the code that resizes back to the original size. Since the routine knows that the original size works it doesn't need the m16(oh/2).
The fix is a few lines up from the bottom of the code.

Code:
Function SmoothD2c(clip clp, int "quant", int "num_shift", int "Matrix", int "Qtype", int "ZW", int "cWarpToLuma", int "downSize", int "ncpu") {
quant       = default( quant,          3 )  
num_shift   = default( num_shift,      3 )  
Matrix      = default( Matrix,         3 )  
Qtype       = default( Qtype,          1 )  
ZW          = default( ZW,             1 )  
cWarpToLuma = default( cWarpToLuma,    0 ) 
downSize    = default( downSize,       1 ) 
ncpu        = default( ncpu,           1 ) 

Assert( ( quant       >= 1  &&  quant       <=  31 ) ? true : false, chr(10) + "'quant' wrong value! [1-31]" + chr(10))
Assert( ( num_shift   >= 1  &&  num_shift   <=   4 ) ? true : false, chr(10) + "'num_shift' wrong value! [1-4]" + chr(10))
Assert( ( Matrix      >= 1  &&  Matrix      <= 110 ) ? true : false, chr(10) + "'Matrix' wrong value! [1-110]" + chr(10))
Assert( ( Qtype       >= 0  &&  Qtype       <=   4 ) ? true : false, chr(10) + "'Qtype' wrong value! [0-4]" + chr(10))
Assert( ( ZW          >= 0  &&  ZW          <=  16 ) ? true : false, chr(10) + "'ZW' wrong value! [1-16]" + chr(10))
Assert( ( cWarpToLuma >= 0  &&  cWarpToLuma <=   8 ) ? true : false, chr(10) + "'cWarpToLuma' wrong value! [0-8]" + chr(10))
Assert( ( downSize    >= 1  &&  downSize    <=   4 ) ? true : false, chr(10) + "'downSize' wrong value! [1-4]" + chr(10))

   ow  = clp.width
   oh  = clp.height
   sd1 = clp 

#   sd1 = (downSize    > 1) ? sd1.bilinearResize(m16(ow/downSize), m16(oh/downSize)) : sd1 
   sd1 = (downSize    > 1) ? sd1.bicubicResize(m16(ow/downSize), m16(oh/downSize)) : sd1 
   sd1 = (cWarpToLuma > 0) ? sd1.colorWarpToLuma(strength=cWarpToLuma)    : sd1

   u2  = sd1.UToY().SmoothD2(quant=quant, num_shift=num_shift, Matrix=Matrix, Qtype=Qtype, ZW=ZW, ncpu=ncpu) #, ZWlmDark=0, ZWlmBright=255, ZWce=1)
   v2  = sd1.VToY().SmoothD2(quant=quant, num_shift=num_shift, Matrix=Matrix, Qtype=Qtype, ZW=ZW, ncpu=ncpu) #, ZWlmDark=0, ZWlmBright=255, ZWce=1)

   #u2 = (downSize > 1) ? u2.bicubicResize(m16(ow/2), m16(oh/2)) : u2
   #v2 = (downSize > 1) ? v2.bicubicResize(m16(ow/2), m16(oh/2)) : v2
   u2 = (downSize > 1) ? u2.bicubicResize(ow/2, oh/2) : u2
   v2 = (downSize > 1) ? v2.bicubicResize(ow/2, oh/2) : v2

   sd1 = YToUV(u2, v2).MergeLuma(clp)

   return(sd1)
}
If this doesn't fix it let me know.
Thanks
jconklin is offline   Reply With Quote
Old 9th July 2012, 02:27   #24  |  Link
jconklin
Registered User
 
Join Date: Mar 2006
Posts: 39
opps. Ignore ncpu it doesn't do anything yet. I think the smoothd2 version you have will accept it as an argument but will not do anything with it.
jconklin is offline   Reply With Quote
Old 9th July 2012, 05:46   #25  |  Link
jconklin
Registered User
 
Join Date: Mar 2006
Posts: 39
And I realized that I forgot to say that smoothd2 works best at mod 8 for luma and mod 16 for chroma with the original block boundaries unshifted, it will work ok if the block boundaries have been shifted and mod 4 for luma and chroma. One of the things that drew me to smoothD and got me to do smoothD2 was working on a video that had been through enough encodes and decodes that there were frames where the block edge artifacs had been shifted 1 or 2 pixels out of there original position. Note that the "original" image in the block had not shifted, just the blocking artifact introduced at an early encoding stage. SmoothD managed to reduce it without destroying the rest of the image.
jconklin is offline   Reply With Quote
Old 16th July 2012, 07:24   #26  |  Link
Schwartzvald
Ooo Royalty
 
Join Date: Aug 2005
Posts: 9
The code you posted works, but my version doesn't accept ncpu as an argument yet, so I just remarked it out for now. Thanks.

The nature by which downsize increases the strength of the filter is interesting. At high levels, it's like a chroma vampire.

I actually have some old videos in 320x240 like you describe with shifted blocks and other ugly noise that I keep around to throw filters at. I never used the original SmoothD, but SmoothD2 did a great job with them, because of all the different ways to control strength.

What I've really been using it for is for a really bad cartoon DVD set, which I believe was authored from tape. SmoothD2c killed the rainbows and chroma blocking when nothing else I could find or set up would...
Schwartzvald is offline   Reply With Quote
Old 17th July 2012, 05:55   #27  |  Link
jconklin
Registered User
 
Join Date: Mar 2006
Posts: 39
Schwartzvald - Thank you for letting me know that SmoothD2 is working so well for you.

I agree the chroma vampire can suck the life right out of the picture
The few times I have tried to deal with it I have not had much luck. If I recall just increasing the saturation of the image blows out the color in flat areas and doesn’t bring it back enough where you want it. What I haven't tried is to take the difference between the color before SmoothD2 and the color after SmoothD2. Then use any simple smoother to smooth the difference. Then increase the saturation of the smoothed difference. Then add the result back to the image after SmoothD2 vampired the chroma.

A major improvement to SmoothD2 that I am thinking about how to implement is a dynamic strength control. SmoothD2 would determine the amount of blocking in each frame and use that to set the strength between max and min strength arguments. It should help with videos that get bit starved during 3-2 pull down. Other places in the same video need very little deblocking.

The term I use to think about the ability of a deblocker to deal effectively with both low and high levels of blocking in a video while maintaining a high amount of detail is the deblockers "dynamic range". If there is a standard term let me know so I can use it.

Many of the features I have put into SmoothD2 are there to increase its dynamic range though I admit that when I was adding them I was thinking along the lines of "I need this much deblocking, how do I get the detail back". Clearly it is easier to keep the detail if you don't lose it in the first place. So the need for SmoothD2 to change the strength it uses on a per frame basis.

If anyone has ideas on what inputs (variables, and how to compute them) should go into the dynamic strength control algorithm please let me know.

I am at the point were I need to build a decent regression test suit so if anyone has any test patterns that would be useful for testing deblockers let me know.

The next release should be out in a couple of weeks. I think I have cursed mmx enough so that it is starting to bend to my will. I have a feeling my wife would have a different perspective on that.
jconklin is offline   Reply With Quote
Old 10th August 2012, 05:35   #28  |  Link
satmonk
Registered User
 
Join Date: Oct 2005
Posts: 14
I have Windows 7 but there is the annoying message: unable to load plugin...

I have msvcr80.dll (612kb) and put this file to all important folders (system32, syswow64, avisynth plugin folder)

But the error message remains
satmonk is offline   Reply With Quote
Old 5th September 2012, 05:50   #29  |  Link
jconklin
Registered User
 
Join Date: Mar 2006
Posts: 39
Well 2 months ago I thought I would have the next release in a couple of weeks.
With luck I might actually get it out in a couple of weeks.
I also said that the single cpu speed might be as much as 25% faster.
Well it looks like it will be closer to twice as fast.
In the mean time I have a new version of SmoothD2c.avs that helps tame the chroma vampire.

Code:
###
#  This version may have a mod8 width restriction.  If it does the new version of SmoothD2 will reduce it to mod4
# This file contains the SmoothD2c() script routine.
#

###
#  REQUIRED ROUTINES
#  
#  aWarpSharp2.dll  available from http://sites.google.com/site/pavelsx2/
#  Ylevels() and YlevelsS()   see  http://avisynth.org/mediawiki/Ylevels 
#                   available from http://forum.doom9.org/showthread.php?t=79898
#  MaskTools2.dll available   from http://avisynth.org/mediawiki/MaskTools2 

###
#  RESTRICTIONS
#  
#  The Input clip must be evenly divisible by 4 in both height and width.

###
#  ARGUMENTS
#
#  SmoothD2c() provides a wrapper around SmoothD2() that takes a clip with the luma deblocked and uses SmoothD2 to deblock the chroma.
#              The arguments quant, num_shift, Matrix, Qtype, and ZW  are the same as those in SmoothD2 and have the same defaults.
#              The arguments Cpr, cWarpToLuma and downSize are specific to SmoothD2c().
#
#              Cpr (0..8) Chroma Protection Strength. Provides control over chroma desaturation at low luma levels. 
#                         It does so by building a SmoothD2 Zero Weight Mask "ZWmask".
#                         Low luma pixels map to high Zero weights in ZWMASK. 
#                         Default 0 no protection 
#                         8 strong protection.  
#
#              cWarpToLuma (0...8) uses aWarpSharp2() to warp the chroma to the luma. Default 0 no warping 8 strong warping.
#                                  This will move the chroma from high luma areas toward strong low luma edges which is
#                                  useful to reduce chroma bleeding.
#                                  Places where the chroma has been moved from may be visibly desaturated.  
#                                  NOTE: The SmoothD2c() argument Cpr will have NO effect on chroma desaturation caused by
#                                  cWarpToLuma. 
#
#              downSize (1...4) This specifies how much the image should be shrunk before deblocking.
#                               Default 1 no downsizing.  
#                                       2 reduce image to 1/2 it's original size before processing.
#                                       3 reduce image to 1/3 it's original size before processing.
#                                       4 reduce image to 1/4 it's original size before processing.
#                               This can be useful if you have really bad chroma blocking. see examples at 
#                               https://sites.google.com/site/jconklin754smoothd2/home
#

###
#  GETTING STARTED
#
#  First all parameters default to reasonable values so SmoothD2c() should work, though it will provide only very weak deblocking.  
#  The most important parameter is quant, which is the primary control of deblocking strength.  
#  If you can not get as much deblocking as desired then try using a different Matrix.  
#     Matrix 8, or Matrix 13-29 
#  If you still can't get enough deblocking then try Qtype=2 or 4.
#  If you still can't get enough deblocking then increase downSize. For Qtype=1 you probably want a Matrix between 13-29.
#  When you get enough deblocking find an area, usually in a darker part of the picture, that the chroma has washed out and start increasing Cpr 
#  until the chroma returns.  Its a balancing act between chroma washout and chroma deblocking.  
#  When you have gotten this far and you have chroma bleeding around strong luma edges then you can try increasing cWarpToLuma 
#  to see if it will help reduce it.  Note that cWarpToLuma especially at higher settings will tend to washout the chroma around the edges.
#  This chroma washout cannot be corrected by increasing Cpr.


###
#  This routine takes a clip that has already had the luma deblocked and uses SmoothD2 to deblock the chroma.
# Defaults SmoothD2c(quant=3, num_shift=3, Matrix=3, Qtype=1, ZW=1, Cpr=0, cWarpToLuma=0, downSize=1, ncpu=1)
Function SmoothD2c(clip clp, int "quant", int "num_shift", int "Matrix", int "Qtype", int "ZW", int "Cpr", int "cWarpToLuma", int "downSize") {
quant       = default( quant,          3 )  
num_shift   = default( num_shift,      3 )  
Matrix      = default( Matrix,         3 )  
Qtype       = default( Qtype,          1 )  
ZW          = default( ZW,             1 )  
Cpr         = default( Cpr,            0 )  # Chroma Protection Strength aka Chroma Vampire Be Gone
cWarpToLuma = default( cWarpToLuma,    0 ) 
downSize    = default( downSize,       1 ) 
#ncpu        = default( ncpu,           1 ) 


Assert( ( quant       >= 1  &&  quant       <=  31 ) ? true : false, chr(10) + "'quant' wrong value! [1-31]" + chr(10))
Assert( ( num_shift   >= 1  &&  num_shift   <=   4 ) ? true : false, chr(10) + "'num_shift' wrong value! [1-4]" + chr(10))
Assert( ( Matrix      >= 1  &&  Matrix      <= 110 ) ? true : false, chr(10) + "'Matrix' wrong value! [1-110]" + chr(10))
Assert( ( Qtype       >= 0  &&  Qtype       <=   4 ) ? true : false, chr(10) + "'Qtype' wrong value! [0-4]" + chr(10))
Assert( ( ZW          >= 0  &&  ZW          <=  16 ) ? true : false, chr(10) + "'ZW' wrong value! [1-16]" + chr(10))
Assert( ( Cpr         >= 0  &&  Cpr         <=   6 ) ? true : false, chr(10) + "'Cpr' wrong value! [0-6]" + chr(10))
Assert( ( cWarpToLuma >= 0  &&  cWarpToLuma <=   8 ) ? true : false, chr(10) + "'cWarpToLuma' wrong value! [0-8]" + chr(10))
Assert( ( downSize    >= 1  &&  downSize    <=   4 ) ? true : false, chr(10) + "'downSize' wrong value! [1-4]" + chr(10))
#Assert( ( ncpu        >= 1  &&  ncpu        <=   4 ) ? true : false, chr(10) + "'ncpu' wrong value! [1-4]" + chr(10))
Assert( ( clp.width   == m4(clp.width)             ) ? true : false, chr(10) + "'clip width'  must be a multiple of 4" + chr(10))
Assert( ( clp.height  == m4(clp.height)            ) ? true : false, chr(10) + "'clip height' must be a multiple of 4" + chr(10))

   ow  = clp.width
   oh  = clp.height

   sd1 = clp 

   sd1 = (downSize    > 1) ? sd1.Lanczos4Resize(m32(ow/downSize), m32(oh/downSize)) : sd1
   sd1 = (cWarpToLuma > 0) ? sd1.colorWarpToLuma(strength=cWarpToLuma)    : sd1

   zw1 = (Cpr == 0)  ?  sd1.ylevels( 0, 1.0, 255, 0, 0)  :  sd1.buildZmask(cpr=cpr)                


   u2  = sd1.UToY()
   v2  = sd1.VToY()

   cw   = u2.width
   ch   = u2.height

   zwuv = zw1.Lanczos4Resize(cw, ch)

   u2  = u2.SmoothD2(quant=quant, num_shift=num_shift, Matrix=Matrix, Qtype=Qtype, ZW=ZW, ZWmask=zwuv) 
   v2  = v2.SmoothD2(quant=quant, num_shift=num_shift, Matrix=Matrix, Qtype=Qtype, ZW=ZW, ZWmask=zwuv) 

   u2 = (downSize > 1) ? u2.Lanczos4Resize(ow/2, oh/2) : u2
   v2 = (downSize > 1) ? v2.Lanczos4Resize(ow/2, oh/2) : v2

#   u2 = (downSize > 1) ? u2.bicubicResize(ow/2, oh/2) : u2
#   v2 = (downSize > 1) ? v2.bicubicResize(ow/2, oh/2) : v2

   sd1 = YToUV(u2, v2).MergeLuma(clp)

   return(sd1)
}


###
# m4  "mod-4"   see "Crop restrictions" in http://avisynth.org/mediawiki/Crop
#               m4 is used in may scripts that do resizing.
# m8  "mod-8"   is used so that cropping will occur on luma block (8x8) boundaries
#               and that resizing will produce an integer number of luma blocks.
# m16 "mod-16"  is used so that cropping will occur on YV12 chroma block (16x16) boundaries
#               and that resizing will produce an integer number of chroma blocks.
# m16 "mod-m32" is used so that the zw1 mask can be resized to the size of the u and v planes.
function  m4(float x) {return(x<16?16:int(round(x/4.0) *4))}
function  m8(float x) {return(x<16?16:int(round(x/8.0) *8))}
function m16(float x) {return(x<32?32:int(round(x/16.0)*16))}
function m32(float x) {return(x<64?64:int(round(x/32.0)*32))}


###
# 
#  This routine builds a zero Weight Mask 
#  which is used to limit the strength of chroma 
#  processing in dark areas.
#
# Defaults buildZmask(Cpr=1)
function buildZmask(clip clp, int "Cpr") {
Cpr = default( Cpr, 1 )

    clp.SmoothD2(quant=31, num_shift=3, Matrix=29, Qtype=1, ZW=0, ZWce=1, ZWlmDark=0, ZWlmBright=255) 
    mt_invert()
    YlevelsS(90,1.01,240,0,255) # This does a non linear range expansion see http://forum.doom9.org/showthread.php?t=79898
    mask = mt_invert()

    ZWmask = (Cpr ==  0)  ?  clp                 
\          : (Cpr ==  1)  ?  mask.ylevels(32, 60.0, 255,  8, 0)
\          : (Cpr ==  2)  ?  mask.ylevels(32, 50.0, 255,  16, 0) 
\          : (Cpr ==  3)  ?  mask.ylevels(32, 30.0, 255,  16, 0) 
\          : (Cpr ==  4)  ?  mask.ylevels(32, 12.0, 255,  16, 0) 
\          : (Cpr ==  5)  ?  mask.ylevels(32,  7.0, 255,  16, 0) 
\          :                 mask.ylevels(32,  1.0, 255,  16, 0) 

    return(ZWmask)
}




###
# 
#  This routine moves the color information toward the edges in the luma
#
# Defaults colorWarpToLuma(strength=1)
function colorWarpToLuma(clip clp, int "strength") {
strength = default( strength, 1 )

  thresh = (strength ==  0)  ?    1                   
\        : (strength ==  1)  ?   24
\        : (strength ==  2)  ?   32 
\        : (strength ==  3)  ?   48  
\        : (strength ==  4)  ?   64  
\        : (strength ==  5)  ?   96  
\        : (strength ==  6)  ?  128  
\        : (strength ==  7)  ?  192  
\        :                      255  

    blur = strength + 2
    warpedColor = clp.aWarpSharp2(thresh=thresh, blur=blur, type=1, depth=14, chroma=4)
    mt_merge(clp, clp, warpedColor, y=2, u=5, v=5) 

    return(last)
}
jconklin is offline   Reply With Quote
Old 7th September 2012, 02:36   #30  |  Link
TheProfileth
Leader of Dual-Duality
 
TheProfileth's Avatar
 
Join Date: Aug 2010
Location: America
Posts: 134
Very interesting will give this a try in a bit.
I suppose that this will also work for chroma denoising as well as deblocking, or am I mistaken?
__________________
I'm Mr.Fixit and I feel good, fixin all the sources in the neighborhood
My New filter is in the works, and will be out soon
TheProfileth is offline   Reply With Quote
Old 7th September 2012, 23:46   #31  |  Link
jconklin
Registered User
 
Join Date: Mar 2006
Posts: 39
It should work well for chroma denoisning. Qtype=1 will tend to do more deblocking than smoothing, Qtype=4 will tend to do more smoothing, with values 2 and 3 in between. For Qtype=1 Matrix values between 13-29 will do increasingly more smoothing then deblocking. DownSize > 1 greatly increases smothing over deblocking.

WARNING: Last night I discovered a bug in my build system that will cause SmoothD2 to crash (produces an error message from AviSynth) if used with a system that has a msvcr80r.dll that is not compatible with the one used in my build. I have a new build that I am still testing that does not use msvcr80.dll and should fix the problem. I plan to do some more testing tonight and release it tomorrow. I will post as soon as the new release is up.
jconklin is offline   Reply With Quote
Old 9th September 2012, 07:16   #32  |  Link
jconklin
Registered User
 
Join Date: Mar 2006
Posts: 39
A shortened and rather simplified story of what it took to find and squash the bug in SmoothD2
that would, for a few users, cause SmoothD2 to crash with an error message from AviSynth.

First of all. Apologies for having put out a filter that causes problems.
This is what I have been doing to figure out what the problem is and how to fix it.

A question from Bloax. What filters does it depend on?
Given that I have over 150 filters in my plugin directory. Well you know every time I wanted to try something I would just drop it in and if it didn't break anything I would leave it there. Yea I know, really bad practice.

So

I uninstalled AviSynth.
I checked that the environment variable for the plugin directory had been removed.
I made sure there was no directory in C:\Program Files (x86)\ called AviSynth.
I downloaded the latest version of AviSynth v.2.6.0 ST, 32-bit from SourceForge, file name AviSynth_110525.exe and installed it.
It installed in C:\Program Files (x86)\AviSynth 2.5

In the plugins directory there are 3 files. colors_rgb.avsi, DirectShowSource.dll, and TCPDeliver.dll
On my machine i7-2600K windows 7 64-bit this script, 4 lines of code, runs.
Code:
LoadPlugin("C:\SmoothD2-a2\SmoothD2.dll")
AviSource("H:SmoothD2speedTest.avi").ConvertToYV12()
SmoothD2(quant=31, num_shift=4, Matrix=15, Qtype=1, ZW=0, ZWce=1, ZWlmDark=255, ZWlmBright=255, ncpu=1) 
return(last)
So

It’s not dependent on some AviSynth filter dll that I am loading.

I uninstalled AviSynth v.2.6.0 ST, 32-bit
I Download and installed Avisynth_258.exe (4.2 MB)
The script still runs
Its not an AviSynth version problem.

Robert Martens mentions Dependency Walker and msvcr80.dll which gets some but not all systems to work.

I get Dependency Walker.

Dependency walker says that SmoothD2.dll needs MSVCR80.DLL file version 8.0.50727.6195
Apparently MSVCR80.DLL is required for any dll built with Microsoft Visual C++ 2005 Version 8.0.50727.867
Note the version numbers match in the first 3 fields.

OK so it works on my machine and does not care which AviSynth is used.
It works for some people but not others...
Maybe MSVCR80.DLL needs to be in a special place.

When I do a search for MSVCR80.DLL on my C drive the search finds over 50 of them!
Oh that’s right everyone that puts out an application, Photoshop for example, needs to distribute a copy of any dll's that it uses. So most people probably already have it on their system.
When I tracked one down and did a properties on it the description was Microsoft C Runtime Library.
Good, 1 guess confirmed.
When I sorted the list by size there were 5 different sizes. oops. I know I still don't get what the problem is, some part of me has the beginning of a nasty intuition.
When I looked at examples of the different sizes, there were 4 different file versions.
The same file version came in 778KB and 612KB.
The other sizes were 803KB, 783KB, and 617KB.
Now I am starting to get a bad feeling.

I search further and find
Quote:
For your convenience, we have provided the following folders for use when redistributing VC++ runtime files.
Subject to the license terms for the software, you may redistribute the folder (unmodified) in the application local folder as a sub-folder with no change to the folder name. You may also redistribute all the files (*.dll and *.manifest)
within a folder, listed below the folder for your convenience, as an entire set.

\VC\redist\x86\Microsoft.VC80.CRT\
msvcm80.dll
msvcp80.dll
msvcr80.dll
Microsoft.VC80.CRT.manifest
Now the bad feeling really kicks in since I realize that the different versions of MSVCR80.DLL are probably not compatible with each other.
OK I will have to distribute the dlls. No big deal. I’ll have to figure out where they should get put so they will be found.
And that won't work either!!!
It can't work because if there are 2 filters that have been built using 2 different versions of MSVCR80.DLL one of them will be a version that was not the version the filter was built with.
Therefore if the versions are different and a called function is incompatible then the filter dies.

At this point, I assume I have my build system set up wrong and probably need to get the MSVCR80.DLL code linked directly into the SmoothD2 dll.
I try a different linker option; the SmoothD2.dll runs on my system and Dependency Walker show no dependencies.

And Bloax tests the new SmoothD2.dll and it works for him.

And I read the AviSynth build a filter and compiler setup docs yet again and this time I realize that of course If Microsoft had given decent hints about the different linker flags in visual studio it would have been obvious what option I should have used.

I hope that this has really taken care of the bug.

Thanks for the hints that I have gotten along the way.
Now maybe I can get a good night’s sleep.
jconklin is offline   Reply With Quote
Old 9th September 2012, 09:58   #33  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Finland
Posts: 5,718
Thanks It's refreshing to read someone really explaining how they have traced some weird errors.

By the way, the download link does not show up on the front page of your site, you need to go to the Download page to see it.
__________________
And if the band you're in starts playing different tunes
I'll see you on the dark side of the Moon...
Boulder is offline   Reply With Quote
Old 21st November 2012, 00:50   #34  |  Link
jconklin
Registered User
 
Join Date: Mar 2006
Posts: 39
I finally ran a set of speed tests on the latest version of SmoothD2. It took longer then I had planned but it was a lot more3 tests then I had expected to run. There are almost 150 tests. I compared SmoothD2 to 30 filters running on a fast hard disk, a SSD, and a Ram Disk. Also have tests showing the speed improvments available when SmoothD2's multitreading is used. Test results are on https://sites.google.com/site/jconklin754smoothd2/home/speed-tests
jconklin is offline   Reply With Quote
Old 7th February 2014, 20:27   #35  |  Link
Zaxooz
Registered User
 
Join Date: Aug 2012
Posts: 22
I really like your script, thank you for the great job done. There's a question I have about the settings as well. In your example (SmoothD2(quant=31, num_shift=4, Matrix=15, Qtype=1, ZW=0, ZWce=1, ZWlmDark=255, ZWlmBright=255, ncpu=1) you are using Matrix=15, is there any particular reason for that preference? Thanks.
Zaxooz is offline   Reply With Quote
Old 8th February 2014, 02:37   #36  |  Link
jconklin
Registered User
 
Join Date: Mar 2006
Posts: 39
I have no Idea why I used matrix=15 in the test. I probably meant matrix=5. matrix=15 would probably smooth out all the details of the image.
All matrix numbers larger than 9 should be considered experimental. I put them in as a way to learn how the matrix values modify images.

Thanks for using SmoothD2
Jim
jconklin is offline   Reply With Quote
Old 9th February 2014, 03:26   #37  |  Link
Zaxooz
Registered User
 
Join Date: Aug 2012
Posts: 22
For those interested. Matrices 9 and 15 produce desirable results as strong deblockers when used with low quants (1-3).
Zaxooz is offline   Reply With Quote
Old 11th September 2015, 03:23   #38  |  Link
hydra3333
Registered User
 
Join Date: Oct 2009
Location: crow-land
Posts: 540
Thanks.
About to experiment with this badly blocked source.
https://drive.google.com/file/d/0B5R...ew?usp=sharing

http://forum.doom9.org/showthread.ph...45#post1738145

Last edited by hydra3333; 11th September 2015 at 04:02.
hydra3333 is offline   Reply With Quote
Old 18th March 2017, 05:43   #39  |  Link
jconklin
Registered User
 
Join Date: Mar 2006
Posts: 39
What started out as an update became a new filter amDCT()

Built on the foundation of smoothD2(), amDCT() provides adaptive strength at the frame and block level based upon an analysis the video frame being processed. It also does local range expansion.

See http://forum.doom9.org/showthread.ph...44#post1801244
jconklin is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 05:42.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.