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. |
6th December 2017, 17:33 | #421 | Link |
Soul Architect
Join Date: Apr 2014
Posts: 2,559
|
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++ |
6th December 2017, 18:19 | #422 | Link | |
Avisynth language lover
Join Date: Dec 2007
Location: Spain
Posts: 3,431
|
Quote:
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." |
|
6th December 2017, 18:28 | #423 | Link | ||
Soul Architect
Join Date: Apr 2014
Posts: 2,559
|
Quote:
This is no different than any other company. As Windows or Linux get security fixes, those fixes are back-ported to older versions. Quote:
__________________
FrameRateConverter | AvisynthShader | AvsFilterNet | Natural Grounding Player with Yin Media Encoder, 432hz Player, Powerliminals Player and Audio Video Muxer Last edited by MysteryX; 6th December 2017 at 19:48. |
||
12th December 2017, 17:29 | #424 | Link |
Registered User
Join Date: Jan 2012
Location: Mesopotamia
Posts: 2,587
|
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)
__________________
See My Avisynth Stuff |
3rd February 2018, 04:56 | #425 | Link | |
Registered User
Join Date: Aug 2006
Posts: 2,229
|
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:
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. |
|
4th February 2018, 10:01 | #426 | Link | ||
Registered User
Join Date: Jan 2014
Posts: 2,309
|
Quote:
Quote:
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) |
||
4th February 2018, 12:05 | #427 | Link |
Registered User
Join Date: Aug 2006
Posts: 2,229
|
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. |
4th February 2018, 12:20 | #428 | Link | |
I'm Siri
Join Date: Oct 2012
Location: void
Posts: 2,633
|
Quote:
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 |
|
13th February 2018, 18:42 | #429 | Link |
Registered User
Join Date: Sep 2005
Posts: 178
|
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 } 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) 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. Last edited by `Orum; 13th February 2018 at 21:15. |
13th February 2018, 23:23 | #430 | Link |
Registered User
Join Date: Sep 2007
Posts: 5,345
|
^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") |
14th February 2018, 00:40 | #431 | Link |
Registered User
Join Date: Sep 2005
Posts: 178
|
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. |
14th February 2018, 02:13 | #432 | Link | ||
Registered User
Join Date: Sep 2007
Posts: 5,345
|
Quote:
Quote:
|
||
14th February 2018, 04:55 | #433 | Link | |
Retried Guesser
Join Date: Jun 2012
Posts: 1,373
|
Quote:
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. |
|
14th February 2018, 05:11 | #434 | Link | |
Registered User
Join Date: Sep 2007
Posts: 5,345
|
Quote:
|
|
14th February 2018, 06:01 | #437 | Link |
Registered User
Join Date: Sep 2005
Posts: 178
|
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. |
14th February 2018, 20:30 | #438 | Link | |
Registered User
Join Date: Jan 2012
Location: Mesopotamia
Posts: 2,587
|
Quote:
and you can set tv_range=false and it will be only MVTools2
__________________
See My Avisynth Stuff |
|
15th February 2018, 16:35 | #439 | Link | |
Registered User
Join Date: Jan 2014
Posts: 2,309
|
Quote:
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. |
|
17th February 2018, 02:33 | #440 | Link |
Registered User
Join Date: Jan 2012
Location: Mesopotamia
Posts: 2,587
|
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+
__________________
See My Avisynth Stuff |
Thread Tools | Search this Thread |
Display Modes | |
|
|