Will do. Tomorrow a.m. after I download you AVSMeter posted and other materials.

Wow, I forgot about that! Will include source code from now on. My bad.

Done. ZIP attached with 4 logs:

Intro_Script1.log
Intro_AVISource_x10.log
First_Script.log
Second_Script.log

I just remembered, the only background app running was the usual antivirus (Kaspersky Antivirus 2016) , and CPU was checked at 0% at the start of each run.

Not entirely sure what you were after with power saving - I already had both of those settings set to 'never', but I was on the 'balanced' profile. Set it to 'high performance' and ran all four scripts.

No, I was just saying that because I got the 0.04fps encoding issue with the Studio clip on your first script, I never went through your second script in detail.

What's the difference between them? I had a look on the Wiki and it seems the only different parameter is 'dither', which only exists in Tweak. 'Smooth' and 'interp' seem to do roughly the same thing.

Neither do I.

If I drag the input high down, things get lighter and the wave form moves up. If I drag the input high up, things get darker and the wave form moves down.

If I drag the output high down, things get darker and the wave form moves down. If I drag the output high up, things get lighter and the wave form moves up.

I'm just not sure what the difference is. Doing it in VDub, everything has a max of 255 and a min of 0, so in cases where things need to be higher or lower than those on the input I use the output in the opposite direction.

In AviSynth, there doesn't appear to be a minimum or maximum, so I can set input_low to -30 and input_high to 280 and it's all fine...although I'm not sure how much I'm changing that I shouldn't just be doing with gamma anyway.

The 'how do I figure out how to use it?' was in reference to RemoveSpots.

While we're on the subject, the color wheel in the TweakColor documentation doesn't match the color wheel on the Tweak Wiki page. But using Tweak's color wheel with TweakColor seemed to get better results than using TweakColor's color wheel with TweakColor. Am I going crazy or is the supplied color wheel wrong?

Thanks for the logs, both.

Choose "change plan settings" next to "High Performance", then "Change advanced power settings", set Min & Max Processor State to 100% and the cooling policy to Active. Don't know whether this will help, but it's worth a try.

Min and Max Processor State are already 100% (minimum was 5 when I had it under 'balanced'), I don't see a cooling policy option.

Ah, okay. I did a quick search and it seemed as though Min was always 5 on default plans. :o

I did see one post in a WoW thread that said a Hyper-Threaded quad-core would show 12% CPU usage for single-threaded apps (100% / 8 logical cores = 12.5%). But that was really the only search result I could find referring to this. Changing it to 13% does find a few more, such as this. Meanwhile, the number of results discussing why quad-cores get "stuck" at 25% CPU usage is innumerable. I would have expected it to be easy to find results talking about the 12% cap if it's common to 8-core systems.

But let's go back and compare your AVSMeter results to your VirtualDub tests.

Balanced
High Performance
Well within the margin of error here, I'm sure. There's no real difference between those two power plans with your system while running scripts. Feel free to use Balanced, after all. Sorry for that little diversion. (I can't use it on the system I'm typing to you from, personally: whether due to this AMD CPU's own power saving settings, the mobo, or something else, allowing it to throttle down the clock speed slows down my entire system. It isn't smart enough to kick the speed back up when I actually need it. Like yours though, my Intel build performs perfectly as expected on Balanced.)

But the real point here:
50 seconds is a lot shorter than 90-94. You can double-check that VDub can also do ~50 sec by using File -> Run video analysis pass. You'll have to actually watch the window the entire time, as it closes once completed.

I believe your ~90-sec result is bottlenecked by HDD I/O. If you're reading to the same drive as you're writing to, it needs to thrash back and forth the entire time when both the input & output are a lossless file. Have you tried reading from internal and writing to external?

sanlyn's results:

94 seconds again.

Screenshots of Perf and Log tabs of that VDub window may indicate something.

BTW, I think you all won. I had to install Lagarith.
See the messy ordeal post here: http://www.digitalfaq.com/forum/vide...ed-messed.html
Huffyuv 32-bit in 64-bit ffdshow is borked for PAL.

I need to run some speed tests. I may switch from Huffyuv to Lagarith for all encoding. Not sure yet.

So, Lagarith test files are now fine for me. :o

This might be relevant, but it just ran in 47 seconds.

Yeah, the top summary figures are an estimate from eyeballing VirtualDub's output window which disappears just as it makes its last update. I'm surprised my estimate was that close.

Well, there's a slowdown in koberulz' system somewhere. For some info on what I'm using most of the time, the PC I'm on right now has 4 SATA hard drives in IDE mode. The C: drive is a 250GB that has only the OS and installed program files, except for Avisynth, VirtualDub, and freebie standalone utilities that are on the 320GB Drive D: (which is also used for storage, pictures, documents, saved forum posts, plugin downloads, Wiki pages, web articles, PDF's etc., periodically backed up on an external USB drive). Drives E: and F: are 500GB each for intermediate working files, scripts for SD and HD work, and processing. I ran AVSmeter on Drive E:. A DVD reader and a BluRay/DVD burner are mapped as Drives G: and H:. USB and a.c. powered external drives are for additional storage and backups only, no processing. All original lossless captures underway and archived are on external USB's -- I pull off portions of them as needed for processing.

Kaspersky Antivirus is a resource hog that slows things down tortuously when it does auto hard drive scans, so I turned scanning off and do it manually overnight. Windows Automatic updates has been turned off for years (big deal, there are no XP updates anyway). Any other software that uses auto update is disabled when possible. As an estimate of my old XP/AMD cheapo Biostar mobo machine used for capture, it would take about twice as long to run any script. I have a newer small Win7 Pro x64 refurb PC but noticed no outstanding speed increase running Avisynth -- I just don't have to reboot as often as with XP when working heavy processing for long periods.

I've done a little work with high definition on the win7 PC, but I guess I'm just a holdout. I do almost everything on XP, being a bah-humbug renegade who thinks mostly that what Microsoft did to everything post-XP is near criminal. HD hasn't yet given me the buzz I expected from it, even on my big plasma TV.

Maybe others can explain the slowdown, I'm running out of ideas.

In the meantime, I still had some AviSynth questions in this post:

...now I can't even get a standard AVI - no AviSynth or VirtualDub processing at all - to run at more than 2fps.

EDIT: Closed VDub, reopened it, tried to open the video file:
---------------------------
ffdshow error
---------------------------
AVISource autodetect: couldn't open file 'Captures\Capture 1st AVT.avi'
Error code: 3
(ffdshow_dec_avisynth_script, line 3)
---------------------------
OK
---------------------------


I don't get it. It's just an AVI file?

Sorry, I had something typed but it got lost in the AVSmeter activity.

With all versions of Avisynth later than 2005 or so, the color functions of Tweak and TweakColor are essentially the same. Tweak has additional paramrters for adjusting luminance factors (Brightness and Contrast). The old and new versions of Tweak have "Hue" and "coring" functions that TweakColor doesn't have.

Yes, "Smooth" in TweakColor and "interp" in Tweak are similar. TweakColor has no "dither" function. Minsat and Maxsat are also similar. The complaint about the older Tweak versions was that the effect of adjusting color ranges was not as precise as it is these days or in TweakColor. Tweakcolor was a 2004 modification of the older Tweak. If you like, you can use Tweak in the same way that TweakColor was used. Bit if you use Tweak, set "coring" to false.

You don't say what function you refer to but I'm guessing you refer to "Levels" and to "dragging" as the way the controls are pictured in AvsPmod, which I don't use. Avisynth's Levels is a command-line version of the Levels filters found in GUI's. It works pretty much the same way the GUI versions do. Input and output settings refer to the left-hand and right-hand pointers in GUI Levels controls. Gamma refers to the middle pointer. Most levels filters adjust luminance, not chroma. In RGB advanced controls such as Photoshop Pro or After Effects you'll find Levels controls for all colors as well as luminance. YUV levels controls work on luma only.

No, numerically there's no min or max value specified that I know of, but you can use a "Levels" control to either adjust for valid levels or to completely crush darks and blow out highlights, as you wish.

There are 3 different functions in RemoveSpotsMC. The syntax for the three functions is:
function RemoveSpotsMC(clip, int "limit", bool "_grey")
function RemoveSpotsMC2X(clip, int "limit", bool "_grey")
function RemoveSpots(clip, int "limit", bool "_grey")

For each of those functions you can use code that calls them using default values:
RemoveSpotsMC()
or
RemoveSpotsMC2X()
or
RemoveSpots()

If you look at the script you'll see that the default values for "limit" are defined in the script, It wouldn't be as good idea to change the default, since the script itself changes them. "Limit" is a threshold or strength/mode value.

The three functions are arranged in such a way that you can call any of them separately.
- If you specify RemoveSpots() alone, there is no motion vector search to help determne more precisely what is a spot and what isn't. The spot remover action is perfomed only once, on one image.
- If you use RemoveSpotsMC() a motion vector search is performed -- basically meaning that image motion is examined to help determine whether something that looks like a spot exists in more than one image. This version then calls the spot remover activity only once.
- If you use RemoveSpotsMC2X(), the same motion vector search is performed but cleaners are performed twice.

The only syntax value people change is "_grey", which refers to grayscale images. "_grey" default is false for color video), set it to true for monochrome. For monochrome _grey to be truly effective, however, insure that your image is truly greyscale by using Avisynth's grayscale() filter before calling these functions.

The motion vector operations in the script are from MVTools, while other operators are in the original RmoveDirt() plugin. MVTools and RemoveDirt are required for Remove Spots, but if you have something like QTGMC you already have those support plugins.

You see a lot of YUV color wheels in lots of places. You even see squares and triangles. The wheel in the .rtf document was prepared by someone else (I don't even recall where I found it) and assumes that the zero-position of the wheel is at the center top of the wheel. The YUV wheel in the Tweak Wiki is more common, where the "start" position of the wheel is at the right-hand horizontal corner. This position in the image is considered as 0 degrees. The way it's pictured makes no difference except to help those who think a wheel should "start" at a certain physical location. In the inner coded workings of YUV, there is no such visual distinction. The center degree location for a pure YUV red is always at "110" as far as the coding is concerned, and likewise the accepted range for the "reddishness" of a color extends for 60 degrees from 80 to 140 around the wheel, regardless of where the 0 position is physically pictured. YUV's internal coding doesn't use a physical picture. Use degree numbers as your reference, despite the way different pictures show the positions.

:huh1:

What does Line 3 say?

VirtualDub is where I've done all my levels adjustments in the past, along with Photoshop. But AvsPmod's work basically the same way.

Right, I get that. It's the interaction between input, output and gamma that I'm not quite across. If I want to make something darker, for example, I can decrease gamma, increase input low, or decrease output high. They all seem to do pretty much the same thing.

Well, for example, I have this piece of garbage:
Attachment 6647

Which I adjusted with Levels(-30,0.7,280,16,235).
Attachment 6646

But I'm not sure if I'm doing that right, or if I should be keeping input and output within the 0-255 range and just playing with the gamma, or what. I mean, I seem to be getting more detail than I started with. Certainly more than my previous effort where I didn't adjust the levels until the VDub stage.


What does this all mean, in practical terms? What is it even doing?

Well, I was trying to use the wheel to guesstimate the correct number. I ended up plugging in 0-359, just to make sure it worked, and then bringing them closer together until approximately the correct range was affected (in this case, the green basketball court above).


There is no line 3. It's an AVI file. Just an AVI file. Not even an AVS that merely opens an AVI file, it's literally just an AVI file.

I also had that file open via an AVS in AvsPmod and another instance of VirtualDub, after closing everything it now works fine, including playback speed. Bizarre.


EDIT: I also keep getting this when I open AvsPmod:
Attachment 6648

Not quite. If you have out of range darks or brights in YUV, as soon as they go to RGB they're cllipped. You can't retrieve all of it, you can only brighten or darken what's left. If you brighten or darken those areas, you're working mostly with noise after clipping.

Depends on what part of the spectrum you want adjusted. Gamma works mostly on the midtones, say about RGB 64 to RGB 180, the range being centered at RGB 128. Input low works from RGB 0 upward to the midrange, input high works in the opposite direction and down toward the midtones.

The preferred range in YUV is y=16-235. If you can post a short piece of that video segment I'll try to show how to handle it. The "fixed" image posted is washed out and has a strong color cast.

In short, the functions look for spots, dropouts, and other garbage and repair them by comparing "good" data in adjacent areas and/or frames. Each function is more thorough than the other, with the MC2X version the most thorough. How it decides what's a spot and what isn't is in the programmer's source code. You''ll need the source code and your C++ and assembler language manuals to read through that. I couldn't help you there.

Specifying 0-359 selects and desaturates all colors, not just one. If that's what you wanted to do you could have just used the "sat" parameter in Tweak and not specified any StartHue or EndHue. But I don't think that's how you should do it. Judging from the original image posted, the scene already appears to have low saturation.

Don't open the same file in two different apps at the same time. The two apps are competing for access.

Another reason why I don't use AvsPmod. I have the same Autolevels dll with the sme name, so I don't know what AvsPmod's problem is. But you seem to have some junk in your plugins folder. Renaming one version of a dll and adding another dll with similar internal code will be a problem. You also have two versions of mvtools v2 in your plugins, not good because both have similar internal code and function names. If you needed a different version for one project and another version for another project, keep one of them separately in another folder and import the one you want explicitly with LoadPlugin().

I run projects using AVisynth 2.6 most of the time, but I have older projects that require v2.5 and 2.5 plugins. I can switch versions of Avisynth.dll in the System folder, but I have to explicitly import some 2.5 dll's in the script from another folder. That's not as often as it seems, as most 2.5 plugins also work in v2.6. But a few oldies don't.

Most people don't download a zip'd or compressed plugin package into the plugins folder. They download zips into a separate folder somewhere, unzip it there, look over the specs, and move only the needed dll's or avsi into the plugins folder. Otherwise you have a plugins folder full of cpp's, htm's, readme's, and other junk that shouldn't be there.

I just meant in terms of dragging sliders to adjust numbers.


If you think that's washed out you should see the version made with a DVD recorder/VHS combo unit. Or even the version where I adjusted levels in VDub instead of AviSynth.

What I posted also isn't finished, it was just the AviSynth step (and possibly not all of that, I don't exactly recall). Further color work is occurring in VirtualDub, although it's still complicated by the fact that there's really not much in the original anyway.

Irritatingly, it's an overcompensation made at half time as a response to the first half being underlit, but that didn't clip any details so I've been able to actually get that one looking okay. I'm running the first part of that script through VDub as we speak, so no samples until tomorrow.


So it basically works like noise removal?

I set it to 0-359 just because I couldn't see any effect when I had it around what I thought should have been 'green'. I then gradually increased startHue and decreased endHue until it was doing what I needed. And I was working with hue, not saturation (basketball courts aren't green).

With my computer being so slow, having just the AVI open is the only way I can scan through the footage, and I've done that no worries in the past. Might just have been AvsPmod.

That's how they are in lordsmurf's plugin pack; I just downloaded it and copied everything across; from the post to which he attached it I get the impression he just zipped his own plugins folder.

Samples of that other game.

Thanks for the new captures.

These were made with defective cameras? Or something just as disatrous, whatever it was. 1stHalf isn't just underexposed, it's worse than that. Both captures have crippled output in the blue, magenta, and red range. The best you can do is to try and stertch those valus into something visiblem but the results will look prtty bad.

This "levels" statemnet needs a mention:
With this type of YUV there are no values of "-30" or "280". The capture card clipped darks at y=16 and brights can't go higher than y=-255 with this type of video. so the dark and bright input levels you mention don't exist. The "Levels" and "Color2" YUV histograms below can illustrate those points, where you can also see that color values barely exist in the lower half of the vectorscope except as a few dimly colored dots:

http://www.digitalfaq.com/forum/atta...1&d=1476539821

Basically what that levels statement does is to drag some of the brightst values into the y=235 range and make some burned-out brights a little darker. The other color work raised what little red and magenta was available, but because so many color values are missing in the lower half of the vectorsope it affected the court colors adversely (the markings on the floor aren't white, for one thing, and shadows elsewhere are green). But you're correct in that the best you can do is to stretch the avaialbe data to look like something else, even if few of the colors look correct. Another problem is that the capture itself apparently tried to include values that are outside of the video's capabilities.

1stHalf,avi is simply a dark capture where levels and color values hover around the dark-to-midtone range, and most color values approach gray. The originals are simply too corrupt for anyone to expect very much. Even if you made 1stHalf a grayscale image, it has no values beyond the midrange. You can make the darks and mids brighter, but there's no color detail to be retrieved. What remains of the video is mostly noise.

Not sure if it's just my imagination, but there does seem to be more detail when I have -30 and 280 there than when I have 0 and 255.

And yeah, I wasn't expecting much from either of them. Although I've got the first half looking pretty decent, actually. Good enough that it's overtaken the first half in terms of watchability, at least.

And yeah, I have no idea what was going on with the camera or its settings.

Attachment 6663Attachment 6664