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 6th December 2017, 17:33   #421  |  Link
MysteryX
Soul Architect
 
MysteryX's Avatar
 
Join Date: Apr 2014
Posts: 2,010
but then when I was working for L'Oreal in Paris, my job was mostly to port code from one of their core framework to another (back-porting), running on different versions of .NET

Copy/paste served well.

but .NET isn't C++
MysteryX is offline   Reply With Quote
Old 6th December 2017, 18:19   #422  |  Link
Gavino
Avisynth language lover
 
Join Date: Dec 2007
Location: Spain
Posts: 3,379
Quote:
Originally Posted by MysteryX View Post
but then when I was working for L'Oreal in Paris, my job was mostly to port code from one of their core framework to another (back-porting), running on different versions of .NET

Copy/paste served well.
It may well have been appropriate for this particular job (I don't know), but your approach sounds a bit like cargo-cult programming.

https://en.wikipedia.org/wiki/Cargo_cult_programming
"The term cargo cult programmer may apply when an unskilled or novice computer programmer (or one inexperienced with the problem at hand) copies some program code from one place to another with little or no understanding of how it works or whether it is required in its new position."
__________________
GScript and GRunT - complex Avisynth scripting made easier
Gavino is offline   Reply With Quote
Old 6th December 2017, 18:28   #423  |  Link
MysteryX
Soul Architect
 
MysteryX's Avatar
 
Join Date: Apr 2014
Posts: 2,010
Quote:
Originally Posted by Gavino View Post
It may well have been appropriate for this particular job (I don't know), but your approach sounds a bit like cargo-cult programming.
Simply L'Oreal is building all their e-commerce websites over a platform that they keep upgrading over time, and while many of their websites use their latest platform, the large website I was responsible for (using 50GB databases and $200k of sales per day!!) stayed on an older version of their platform because specific optimizations were required for that website -- and then sometimes the newer features were needed in that older platform and thus had to be back-ported.

This is no different than any other company. As Windows or Linux get security fixes, those fixes are back-ported to older versions.

Quote:
Originally Posted by Gavino View Post
https://en.wikipedia.org/wiki/Cargo_cult_programming
"The term cargo cult programmer may apply when an unskilled or novice computer programmer (or one inexperienced with the problem at hand) copies some program code from one place to another with little or no understanding of how it works or whether it is required in its new position."
This sounds like what's needed to port STAR, whatever it is! Pinterf, tried that?

Last edited by MysteryX; 6th December 2017 at 19:48.
MysteryX is offline   Reply With Quote
Old 12th December 2017, 17:29   #424  |  Link
real.finder
Registered User
 
Join Date: Jan 2012
Location: Mesopotamia
Posts: 909
so I back to this https://forum.doom9.org/showthread.p...90#post1783190

with 8 bit motion analyze



then with 16 bit motion analyze



Code:
LSMASHVideoSource("chroma.mp4")
c=last

ConvertBits(16)
SMDegrain(globals=3,chroma=false )
global fv1 = fv1.MScalevect(bits=8)
global bv1 = bv1.MScalevect(bits=8)
global fv2 = fv2.MScalevect(bits=8)
global bv2 = bv2.MScalevect(bits=8)
#~ SMDegrain(globals=3,chroma=false )

c
SMDegrain(globals=1)
ConvertBits(8)
There is an improvement in some places, but some few others are inverse (worst)
__________________
My Avisynth Stuff
real.finder is offline   Reply With Quote
Old 3rd February 2018, 04:56   #425  |  Link
burfadel
Registered User
 
Join Date: Aug 2006
Posts: 2,208
With MVtools 2.7.24, it says in the included docs (as well as the original for MVTools) that the parameters for MSCDetection include Ysc, however if specifying Ysc it says MSCDetection does not have a named argument "Ysc".

Additionally, no matter what settings for thSCD1 and thSCD2 I use, the whole output is either completely black or completely white for extended periods when using a Y8 source (even in 8-bit). Isn't the output just supposed to be white for the first frame of a detected scenechange?
Quote:
Creates scene detection mask clip from motion vectors data. The mask is created both on the luma and on chroma planes. Output without scene change is 0.
I'm looking to invert this so scene changes are black and the rest is white in the mask. How do the other functions like MFlowFPS, MDegrain etc work internally regarding scene changes presuming they are working correctly?

If using an 8-bit Y12 source with chroma channels, the output is just a single colour like pink or green! Using the default settings, the whole 29 minute show of the clip I used for Masktools (UK Men Behaving Badly), using the Y12 8 bit source there was just a bit of pink output at the beginning for a couple of seconds and the rest was in green. For Y8 it was white at the beginning for those few seconds and the rest of the show was black. There were of course a quite a lot of scene changes that were meant to be there!

Last edited by burfadel; 3rd February 2018 at 05:30.
burfadel is offline   Reply With Quote
Old 4th February 2018, 10:01   #426  |  Link
pinterf
Registered User
 
Join Date: Jan 2014
Posts: 848
Quote:
Originally Posted by burfadel View Post
With MVtools 2.7.24, it says in the included docs (as well as the original for MVTools) that the parameters for MSCDetection include Ysc, however if specifying Ysc it says MSCDetection does not have a named argument "Ysc".
Good catch. Contrary to the documentation the implemented name of the parameter is Yth (and as I see it was the case in the old 2.5.x times), which is obviously wrong, because it has the very same purpose as in MMask. It seems that this parameter was never used as a named parameter and probably left on the default.
Quote:
Originally Posted by burfadel View Post
Additionally, no matter what settings for thSCD1 and thSCD2 I use, the whole output is either completely black or completely white for extended periods when using a Y8 source (even in 8-bit). Isn't the output just supposed to be white for the first frame of a detected scenechange?
I'm looking to invert this so scene changes are black and the rest is white in the mask. How do the other functions like MFlowFPS, MDegrain etc work internally regarding scene changes presuming they are working correctly?

If using an 8-bit Y12 source with chroma channels, the output is just a single colour like pink or green! Using the default settings, the whole 29 minute show of the clip I used for Masktools (UK Men Behaving Badly), using the Y12 8 bit source there was just a bit of pink output at the beginning for a couple of seconds and the rest was in green. For Y8 it was white at the beginning for those few seconds and the rest of the show was black. There were of course a quite a lot of scene changes that were meant to be there!
(Y12 is YV12 I suppose, and not a 12 bit greyscale)
Once StainlessS provided me this test script, could you try this, this works for me.
Code:
<source>
ConvertBits(8) #or whatever

Function EndOfSceneClip(clip c,Int "thSCD1",Int "thSCD2") { # All Luma Samples set 255 at EOS
    thSCD1=Default(thSCD1,400)  thSCD2=Default(thSCD2,130)
    sup=c.MSuper(pel=1,sharp=0,rfilter=2,hpad=16, vpad=16)
    bv=sup.MAnalyse(isb=true, delta=1,blksize=16/*,overlap=8*/)
    Return c.MSCDetection(bv,thSCD1=thSCD1,thSCD2=thSCD2)
}

Function StartOfSceneClip(clip c,Int "thSCD1",Int "thSCD2") { # All Luma Samples set 255 at SOS
    thSCD1=Default(thSCD1,400)  thSCD2=Default(thSCD2,130)
    sup=c.MSuper(pel=1,sharp=0,rfilter=2,hpad=16, vpad=16)
    fv=sup.MAnalyse(isb=false,delta=1,blksize=16/*,overlap=8*/)
    Return c.MSCDetection(fv,thSCD1=thSCD1,thSCD2=thSCD2)
}

EOS = EndOfSceneClip()
SOS = StartOfSceneClip()
#return EOS
SSS="""
    e = EOS.AverageLuma
    s = SOS.AverageLuma
    Subtitle(String(current_frame)+String(e,"] EOS=%.1f")+String(s," : SOS=%.1f"))
    (e!=0.0)
        \ ? Subtitle("End Of Scene",Size=48,Text_Color=$FF0000,Y=Height/2-24,Align=5)
        \ : (s!=0.0) ? Subtitle("Start Of Scene",Size=48,Text_Color=$0000FF,Y=Height/2+24,Align=5)
        \ : NOP
    return last
"""

Scriptclip(SSS)
ConvertBits(8)
pinterf is offline   Reply With Quote
Old 4th February 2018, 12:05   #427  |  Link
burfadel
Registered User
 
Join Date: Aug 2006
Posts: 2,208
Yes that works . So how do I translate that into a mask such that it is only white at the start frame of a scene change? I want to reuse a calculate forward search 'fvec1'. The documentation makes it sound like it was a simple process of outputting such a mask.

I guess it would also be a handy inclusion in the documentation.

Last edited by burfadel; 4th February 2018 at 14:41.
burfadel is offline   Reply With Quote
Old 4th February 2018, 12:20   #428  |  Link
feisty2
I'm Siri
 
feisty2's Avatar
 
Join Date: Oct 2012
Location: Los Angeles, California
Posts: 2,119
Quote:
Originally Posted by MysteryX View Post
but then when I was working for L'Oreal in Paris, my job was mostly to port code from one of their core framework to another (back-porting), running on different versions of .NET

Copy/paste served well.

but .NET isn't C++
now I think its a bit unfair to put older C++(98, 03) and recent C++(11 and later) in the same category tho, they have very different type systems and thus have very different syntax for pretty much everything, even the most basic stuff like defining a variable or a function

the older C++ has a nominal type system, the type system inherited from C and also adopted in some other C influenced languages like java or c#, recent C++ has an inferred and structural type system with "auto" being the one and only type throughout almost the entire language, yes even for function parameters, the only type would be "auto" since C++20 (Concepts TS), so for OOP interfaces and inheritances between types are now rendered useless in C++20, instead replace them with (static variant of) duck typing OOP like in Python or JavaScript

human language, older C++ is syntactically closer to C and java, recent C++ is syntactically closer to Python and JavaScript
__________________
If I got new ideas, will post here: https://github.com/IFeelBloated
feisty2 is offline   Reply With Quote
Old 13th February 2018, 18:42   #429  |  Link
`Orum
Registered User
 
Join Date: Sep 2005
Posts: 92
Color shifting in 16-bit processing?

I'm seeing some strange color shifting when doing 16-bit processing with MDeGrainN (it does not occur with 8-bit), toward U-/V- (AKA green). First, let me share the script I wrote to simplify using it:
Code:
################################
#  Scripted_MDeGrain by `Orum  #
#      v0.3 on 2017-06-04      #
################################

# *NOTE* Some defaults are changed!
# Differing defaults: overlap

function Scripted_MDeGrain(clip c, bool "chroma", bool "mt", int "hpad", int "vpad", int "pel", int "MSlevels", int "sharp", int "rfilter", int "blksize", \
	int "blksizeV", int "MAlevels", int "search", int "searchparam", int "pelsearch", bool "truemotion", int "lambda", int "lsad", bool "globalm", int "plevel", \
	int "pnew", int "pzero", int "pglobal", int "overlap", int "overlapV", int "dct", int "divide", int "sadx264", int "badSAD", int "badrange", bool "meander", \
	bool "temporal", bool "trymany", bool "multi", int "tr", int "thSAD", int "thSADC", int "plane", int "limit", int "limitC", int "thSCD1", int "thSCD2", \
	bool "lsb", int "thSAD2", int "thSADC2", bool "debugSCD") {

# Shared params
chroma		= default(chroma, true)																# Use chroma (in addition to luma)?
mt				= default(mt, true)																	# Use multi-threading?
tr				= default(tr, 2)																		# Temporal radius of motion vector search

# MSuper params
hpad			= default(hpad, 8)																	# Horizontal padding for better motion estimation
vpad			= default(vpad, 8)																	# Vertical padding for better motion estimation
pel			= default(pel, 2)																		# Accuracy of motion estimation (1, 2, or 4)
MSlevels		= default(MSlevels, 0)																# Number of hierarchical levels in super clip frames (0 = all)
sharp			= default(sharp, 2)																	# Subpixel interpolation when pel > 1 (0 to 2)
rfilter		= default(rfilter, 2)																# Hierarchical levels smoothing filter (0 to 4)

# MAnalyse params
blksize		= default(blksize, 8)																# Horizontal block size (4, 8, or 16)
blksizeV		= default(blksizeV, blksize)														# Vertical block size (4, 8, or 16 - must be <= blksize?)
MAlevels		= default(MAlevels, 0)																# The number of levels used in the hierarchical analysis while searching for MVs
search		= default(search, 4)																	# See readme (0 to 5)
searchparam	= default(searchparam, 2)															# Meaning dependant on value of search; see readme
pelsearch	= default(pelsearch, pel)															# Searchparam at finer levels
truemotion	= default(truemotion, true)														# Influences other parameter's defaults
lambda		= default(lambda, truemotion ? 1000 * blksize * blksizeV / 64 : 0)	# Coherence of the vector field
lsad			= default(lsad, truemotion ? 1200 : 400)										# SAD limit for lambda (recommended > 1000 w/ truemotion)
globalm		= default(globalm, truemotion)													# Estimate global motion? (only supports pans, not zoom/rotate)
plevel		= default(plevel, truemotion ? 1 : 0)											# Penalty for lambda level scaling (0 to 2)
pnew			= default(pnew, truemotion ? 50 : 0)											# Penalty to SAD cost for candidate vectors
pzero			= default(pzero, pnew)																# Penalty to SAD cost for zero vector
pglobal		= default(pglobal, 0)																# Penalty to SAD cost for global vector
overlap		= default(overlap, blksize/2)														# Horizontal block overlap (must be even & < blksize)
overlapV		= default(overlapV, overlap)														# Vertical block overlap (must be even & < blksizeV)
dct			= default(dct, 0)																		# Use DCT for SAD calculation (0 to 10; see readme)
divide		= default(divide, 0)																	# Post-processing for MVs (0 to 2; see readme)
sadx264		= default(sadx264, 0)																# Use SAD from x264 if available (0 to 12; see readme)
badSAD		= default(badSAD, 10000)															# SAD threshold to widen search for bad vectors (10000 = disable)
badrange		= default(badrange, 24)																# Range (radius) of search for bad blocks (use positive values for UMH, negative for Exhaustive)
meander		= default(meander, true)
temporal		= default(temporal, false)
trymany		= default(trymany, false)
multi			= default(multi, false)

# MDeGrain params
thSAD			= default(thSAD, 400)																# SAD threshold for luma plane
thSADC		= default(thSADC, thSAD)															# SAD threshold for chroma planes
plane			= default(plane, 4)																	# Set which planes to process (0 to 4; 0 = Y, 1 = U, 2 = V, 3 = UV, 4 = YUV)
limit			= default(limit, 255)																# Limit luma change (0 = filter has no effect, 255 = unlimited)
limitC		= default(limitC, limit)															# Limit chroma change (0 = filter has no effect, 255 = unlimited)
thSCD1		= default(thSCD1, 400)																# Block change threshold for a scene cut
thSCD2		= default(thSCD2, 130)																# Percent of blocks that must change to be a scene cut (0 to 255; 0 = 0%, 130 = 51%, 255 = 100%)
lsb			= default(lsb, false)
thSAD2		= default(thSAD2, thSAD)
thSADC2		= default(thSADC2, thSADC)

# Added custom params
debugSCD		= default(debugSCD, false)															# Debug scene change detection thresholds (green = no cut, magenta = cut)

sup = c.MSuper(hpad=hpad, vpad=vpad, pel=pel, levels=MSlevels, chroma=chroma, sharp=sharp, rfilter=rfilter, mt=mt)
mvs = sup.MAnalyse(blksize=blksize, blksizeV=blksizeV, levels=MAlevels, search=search, searchparam=searchparam, pelsearch=pelsearch, lambda=lambda, chroma=chroma, delta=tr, truemotion=truemotion, lsad=lsad, plevel=plevel, global=globalm, pnew=pnew, pzero=pzero, pglobal=pglobal, overlap=overlap, overlapV=overlapV, dct=dct, divide=divide, sadx264=sadx264, badSAD=badSAD, badrange=badrange, meander=meander, temporal=temporal, trymany=trymany, multi=true, mt=mt)
mvd = c.MDeGrainN(sup, mvs, tr, thSAD=thSAD, thSADC=thSADC, plane=plane, limit=limit, limitC=limitC, thSCD1=thSCD1, thSCD2=thSCD2, lsb=lsb, thSAD2=thSAD2, thSADC2=thSADC2, mt=mt)

debugSCD ? StackVertical(mvd.Crop(0, 0, -0, -8), c.MSCDetection(mvs.SelectEvery(tr * 2, 1), thSCD1=thSCD1, thSCD2=thSCD2).Crop(0, 0, -0, 8)) : mvd
}
And now for the script to demonstrate the problem:
Code:
src = ColorBars(pixel_type="YV24").AddGrain(var=5, uvar=5)
ebd = src.Scripted_MDeGrain(tr=2, thSAD=150, lsb=false)
sbd = src.Scripted_MDeGrain(tr=2, thSAD=150, lsb=true).ConvertFromStacked(16).ConvertBits(8)

Interleave( \
	src.Histogram("color").Crop(640, 0, -0, -224).Subtitle("source"), \
	ebd.Histogram("color").Crop(640, 0, -0, -224).Subtitle("8 bit degrain"), \
	sbd.Histogram("color").Crop(640, 0, -0, -224).Subtitle("16 bit degrain") \
)

Trim(999, 1001)
...which when run should output this:


You can clearly see the dots "migrate" toward the upper left when using the 16-bit processing. I concede that this could instead be an issue with either my script or ConvertFromStacked()/ConvertBits(), so I'd like to see if anyone else can confirm the issue is indeed in MVTools.

Edit: Forgot to mention, this is with MVTools v2.7.24, and AviSynth+ r2580

Edit2: Also, I can at least say ConvertFromStacked()/ConvertBits() are not the problem, as simply cropping to the size of the source clip instead of using those functions results in the same problem.

Edit3: The shift is perhaps even easier to spot if using Histogram("levels") instead of in the "color" mode. You can also see that this shift affects even the luma.
__________________
Halos? Aliasing? Rainbows? Not on my watch...

Last edited by `Orum; 13th February 2018 at 21:15.
`Orum is offline   Reply With Quote
Old 13th February 2018, 23:23   #430  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 3,232
^It doesn't seem to affect SMDegrain, or at least not as much for U,V .

eg. If you replace with
Code:
ebd2 = src.smdegrain(tr=2, thsad=150, lsb=false)
sbd2 = src.smdegrain(tr=2, thsad=150, lsb=true, lsb_out=true).ConvertFromStacked(16).ConvertBits(8)

interleave(src, ebd2,sbd2)
histogram("levels")
I'm not familiar with "Scripted_MDeGrain" but I would have a closer look at that to see why
poisondeathray is offline   Reply With Quote
Old 14th February 2018, 00:40   #431  |  Link
`Orum
Registered User
 
Join Date: Sep 2005
Posts: 92
I don't use SMDegrain because it does a lot of other things within the filter that I don't want it to do (it uses several other filters IIRC), and back when I originally wrote Scripted_MDegrain it didn't even even exist. Everything within my filter should be covered by MVTools itself or the built-in functions to AviSynth.

I'm slightly curious as to why SMDegrain doesn't have as many problems, but I suspect it's due to the numerous other filters it applies.
__________________
Halos? Aliasing? Rainbows? Not on my watch...
`Orum is offline   Reply With Quote
Old 14th February 2018, 02:13   #432  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 3,232
Quote:
Originally Posted by `Orum View Post
I don't use SMDegrain because it does a lot of other things within the filter that I don't want it to do
My understanding is it doesn't do anything else unless you explicitly specify it. By default TR=1 is the default MDegrain1 , TR=2 is the default MDegrain2, etc.... ie. it's just a simple wrapper for MDegrain , unless you specify the other options

Quote:
I'm slightly curious as to why SMDegrain doesn't have as many problems, but I suspect it's due to the numerous other filters it applies.
I think it uses dither tools for the lsb part , so that might be the difference .
poisondeathray is offline   Reply With Quote
Old 14th February 2018, 04:55   #433  |  Link
raffriff42
Retried Guesser
 
raffriff42's Avatar
 
Join Date: Jun 2012
Posts: 1,306
Quote:
Originally Posted by `Orum View Post
I'm seeing some strange color shifting when doing 16-bit processing with MDeGrainN (it does not occur with 8-bit), toward U-/V-
...

Edit3: The shift is perhaps even easier to spot if using Histogram("levels") instead of in the "color" mode.
You can also see that this shift affects even the luma.
This is the ConvertBits rounding error first discussed here (although only luma shift was noticed back then, not chroma).
Use ConvertBits(8, dither=0)
EDIT or use ColorYUV(off_y=0.48, off_u=0.48, off_v=0.48).ConvertBits(8)

Last edited by raffriff42; 14th February 2018 at 05:14.
raffriff42 is offline   Reply With Quote
Old 14th February 2018, 05:11   #434  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 3,232
Quote:
Originally Posted by raffriff42 View Post
This is the ConvertBits rounding error first discussed here.
Use ConvertBits(8, dither=0)
EDIT or use ColorYUV(off_y=0.48, off_u=0.48, off_v=0.48).ConvertBits(8)
When he just crops lsb without using convertbits, the error is still there. So it cannot be ConvertBits rounding issue

Quote:
Originally Posted by `Orum View Post

Edit2: Also, I can at least say ConvertFromStacked()/ConvertBits() are not the problem, as simply cropping to the size of the source clip instead of using those functions results in the same problem.
poisondeathray is offline   Reply With Quote
Old 14th February 2018, 05:17   #435  |  Link
raffriff42
Retried Guesser
 
raffriff42's Avatar
 
Join Date: Jun 2012
Posts: 1,306
Doing that does not round, it truncates, which is the nature of the bug. No wonder they look the same.
raffriff42 is offline   Reply With Quote
Old 14th February 2018, 05:27   #436  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 3,232
Quote:
Originally Posted by raffriff42 View Post
Doing that does not round, it truncates, which is the nature of the bug. No wonder they look the same.
That makes sense

DitherPost also works, which I'm guessing is what smdegrain uses
poisondeathray is offline   Reply With Quote
Old 14th February 2018, 06:01   #437  |  Link
`Orum
Registered User
 
Join Date: Sep 2005
Posts: 92
Ah, that makes sense. Hopefully that will get fixed upstream soon, as so few utilities support anything beyond 8-bit, so the functions will see lots of use for previewing. Those that aren't aware of the bug will probably be just as puzzled as I was.

Thanks.
__________________
Halos? Aliasing? Rainbows? Not on my watch...
`Orum is offline   Reply With Quote
Old 14th February 2018, 20:30   #438  |  Link
real.finder
Registered User
 
Join Date: Jan 2012
Location: Mesopotamia
Posts: 909
Quote:
Originally Posted by `Orum View Post
I don't use SMDegrain because it does a lot of other things within the filter that I don't want it to do (it uses several other filters IIRC), and back when I originally wrote Scripted_MDegrain it didn't even even exist. Everything within my filter should be covered by MVTools itself or the built-in functions to AviSynth.
all used plugins by default are MaskTools2 and MVTools2

and you can set tv_range=false and it will be only MVTools2
__________________
My Avisynth Stuff
real.finder is offline   Reply With Quote
Old 15th February 2018, 16:35   #439  |  Link
pinterf
Registered User
 
Join Date: Jan 2014
Posts: 848
Quote:
Originally Posted by `Orum View Post
I'm seeing some strange color shifting when doing 16-bit processing with MDeGrainN (it does not occur with 8-bit), toward U-/V- (AKA green). First, let me share the script I wrote to simplify using it:
Thanks, well documented case and it seems to be a tough and very interesting problem, already spent a lot of hours on it.

First I found that 16 bit Degrain results (either stacked (since 2.6.0.5) or native) are not rounded from a 32 bit intermediate. Internally there is a 11-bit extra precision when Overlap is used. Before dropping that extra 11 bit accuracy and converting back to 8..16 bits, a 2^10 rounder should be added to have the final result.

Nor is the 8 bit code perfect, there is a 6 bit shift and its rounding at an earlier phase, and a non-rounding 5 bit shift (6+5=11) when the final result is created from a 16 bit intermediate buffer.

When I have put the proper rounding in the 16bit-like paths, the stacked version became OK, but the native still held a shift, but _only_ after ConvertBits(8). Which is a simple bit shift, the very same as striping off the lower part from a stacked-16 clip.

The script which was adding the noise is good to test. Noise is random, but on average it should be zeroed out. I'm testing with clips with uniform 128-129-128-129 pixel values, plus noise.

How could we turn the shift into numbers instead of looking at Histogram?

We can examine the native 16 bit MDegrain2 result using the AverageLuma runtime function. Interestingly, it showed similar (but of course 256 times as much) and correct result, as the 8 bit Degrain result.

But right after we are stripping the lower byte (=ConvertBits(8)), the AverageLuma result becomes much lower. E.g. AverageLuma=32696 (=127.71*256) becomes 127.42 after converting to 8 bits. Probably that means that there is only a minor residual error somewhere, which should be investigated. (And of course: at wht step does the difference appear between the stacked and the native 16 bit method.
pinterf is offline   Reply With Quote
Old Yesterday, 02:33   #440  |  Link
real.finder
Registered User
 
Join Date: Jan 2012
Location: Mesopotamia
Posts: 909
since the native 16 bit is slower than lsb, even with this https://forum.doom9.org/showthread.p...23#post1833823 it's little faster but still way slower than the lsb method

can mdegrain has "bits" parameter? so it can be used instead of lsb with avs+
__________________
My Avisynth Stuff
real.finder 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 03:00.


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