Sure, but working with such a small file, running an efficient script would make it impossible to get a decent indicator of a difference. You ran my script in half the time, which makes it obvious my machine is running much slower, but that wouldn't be a significant difference over scripts lasting only a few seconds.

Is there anything I can do about the right-hand side of this?

Not really, unless you have Premiere Po, Vegas Pro, After Effects, or similar app that can work with layer blending and gradient masks. Even then, it would take some experimentation and lots of time. The color is totally corrupt: there's not a single correct hue anywhere in the frame. The overall color cast is yellow, but with different casts in brights and shadows, and no clean whites or blacks anywhere.....Adding some blue overall might change one factor (blue is yellow's opposite color), but it would discolor other areas that already have too much blue. There are derainbow plugins like BiFrost and SmoothUV, and people like to point to CamcorderColorDenoise (unfortunately requires RGB conversion) as solutions. But none eliminate uneven edge stains having wide gradient edges. Even with pro color tools it would be a project in itself.

I do have Premiere and After Effects. I've had a bit of a fiddle with Premiere in terms of the whole picture, but I've not much idea how all those tools work. Would it just be a case of creating a mask to cover the green smudge on the side and trying to make it match? It's the fade that's the issue; if it had hard edges I could probably muddle my way through to at least getting something closer to the main picture.

I know it's always going to look like garbage, but given that it started out all being bright green and so washed-out you couldn't see the lines...

It's been through VDub, so it's RGB anyway.

I've seen that kind of masking done, but never did it myself. Any video I'm familiar with that looked as bad as the one you mention was seldom worth the trouble. They were almost always converted to grayscale, which is what has been done to save what's left of many old color movies.

Okay, now VirtualDub is screwing with me. I'm trying to get the two corner cameras to match the sideline camera, but whenever I hit F2 in VirtualDub it changes the colors. I don't have to make any change to the script whatsoever. It just cycles through these three, in the same order. I thought it might have been caching and rotating between the last three version of the script for some reason, but if I just go in and remove the Histogram, then press F2, the Histogram disappears and the colors change. WTF is going on? How do I know what colors the final AVI will have?

Attachment 6740
Attachment 6741
Attachment 6742

Why is the Histogram in every image? I thought you said you removed the Histogram for some images. At what point in the svript is the histogam line entered? If you load a histogram into the image before running code, the histogram becomes part of the image that the code will se. Are you thinking that the histogram is not part of the image that comes from Avisynth (if you do, it's not correct). Does this happen when you do the same thing in AvsPmod? Why aren't you posting the changes you're making in your script?

The histogram is the last line in the script, those three images are just the result of hitting F2 and copying to the clipboard. No changes to the script whatsoever. I moved to VDub from AvsPmod because that was giving me wonky results in the preview.

Removing the histogram as the only change still alters the color from the previous version of the script; I tried that just to see if it was somehow cycling between cached script versions. No frames from that test are included.

TweakColor(hue=0.2,startHue=35,endHue=80)

Did a good job of getting rid of the pinkish/reddish color over everything, although the effect was stronger than I'd have liked. But if I changed hue to 0.1 or 0.3, it went back to being really red again. Which makes no sense whatsoever. I also tried using MergeChroma with the TweakColor as the merging clip, and adjusting its weight, to try and lessen the effect, but I could only get a really strong effect or no effect.

May have been negative instead of positive hue numbers, I don't exactly recall, but that's roughly what was going on.

Here's the full script used for those three screenshots:
And if I use this script, I get these results:
Attachment 6743
Attachment 6744

Approximate original frames (obviously QTGMC changes the frame numbers):
Attachment 6745
Attachment 6746

I think you have the two scripts confused. The top script has Histogram commented-out in the last line, yet the pictures you posted show the histogram in all three frames. The bottom script gives different results becausae the filters don't use the same settings as script #1. And besides that, the bottom two images you just posted have a color change as well as a change in the shape of the histogram, which would occur only if the filters in the lines above the histogram line had been altered. In the second script you add a Histogram, then apply FixChromaBleeding and ChromaShifit to the histogram images, then deinterlace the histogram images with QTGMC, which is a sequence logic error. Are you sure you're not getting your scripts mixed up?

By the way, TweakColor and Tweak when used with very low saturation values such as 0.1, 0.3, etc. will bring the affected areas closer and closer to gray. Also, if you want to check saturation specifically you should be using the Vectorscope in the Histogram("Color2") function.


I doubt it. The numeric range 20 to 80 doesn't include much red, it includes mostly blue and some bluish-red (purple) magenta range, so blueish-pink and bright pink would be the only range affected -- pure red wouldn't be touched. Red doesn't start taking over until at least the 80-value mark. And you have plenty of red oversaturation along with some reddish-yellow (orange) , which would include red plus a smaller proportion of green).

According to the two game images you just posted, the flashing and oversaturation appear to be in red and yellow, not magenta.

I commented out the Histogram line after taking those earlier captures, but before copying. The scripts are correct.

Yes, there are different results between the two scripts. But the frame where the player in yellow has the ball is script one, and the frame where the player in white has the ball is script two. And yet there are three differently-colored versions of the first frame, and two differently-colored versions of the second. Script one was never applied to the second frame, and script two was never applied to the first frame.

But this is my point: that's not true. All I did to get the change in color and shape of the histogram to change was press F2. I did not modify the script. Seriously, without even going into AvsPmod or Notepad or anything, I can just sit there in VDub repeatedly hitting 'F2' to switch between the two different sets of colors.

It should be true, and if everything were working it would be true, but it isn't true and I don't get it.

That's the idea; some highlights were turning pink.

I just uncommented the Histogram line when things started going wonky to see if the shape changed, I wasn't too fussed about exactly which Histogram was displaying. All three histograms in the first frame are different, both histograms for the second frame are different, therefore it's not some sort of display issue.


You can doubt it all you like, but it happened. Things shouldn't be red at hue=0.1 and hue=0.3, but green at hue=0.2, either, but that also happened. I mean, the third yellow-with-ball frame is very close to what I want to get out of it, but I don't know if that's what a non-crazy version of VDub would display for that same script.

Koberulz, no one can guess which changes you made in a script text before posting, or what you did before or after you hit F2, changed scenes, or what. I believe you originally said that you get color changes when you remove a Histogram statement from a script, then you show three images of the same frame, one with color changes but all three with the same histogram. If you removed a histogram line, why is does a histo0gram appear in all images?

I mention using low saturation numbers and you change the comment to the "hue" parameter. I'm afraid I can't follow your train of thought or guess about how you're changing your workflow or the which camera shot you're watching. I can only repeat that the color changes for one camera view won't work exactly the same way for another camera view because you have 3 cameras with 3 different problems in one video (and at this point, even that conclusion is a guess about what you've said earlier). We started with one change in one script, now I'm looking at no changes in two scripts and not knowing which script you refer to.

And your second script has a logic error and runs too slow for quick filter change comparisons. The original script you posted (if you haven't changed nit again):

I would suggest the changes in blue to correct the logic and to speed on/off comparisons. Change the comment markers to turn off/turn on different lines.:

You could also use conditional test structures instead of changing comment markers around, but that gets too complicated.

My point about the histogram line was that it changes whether or not I add/remove the Histogram line.

So, super-simple. Here's the script:
Which results in this:
Attachment 6747

If I press F2, without changing the script at all, I get this:
Attachment 6748

And if I press F2 a second time - still no changes to the script - I now get this:
Attachment 6749

All three are exactly the same script.

Now we understand what you're doing, LOL!

You know, you have one strange operating system there. It's inexplicably slow, can't wo9rk without features like Euro turned on, delays output of parts of running processes with no explanation.......I would have reinstalled the whole show by now, even though it does take me 4 to 5 days every time I've done it over the years. The alternative is to have a qualified tech get into your home and go through that system. I wouldn't call the crew that "inspected" your machine earlier. If they didn't detect a slowdown they don't know what they're doing. To begin with, no one's PC should take 5 minutes to get going from a cold boot, Vista or no Vista. You have a mainstream CPU and a reportedly fast motherboard design that's competitive even today for standard definition video work. When this system was built, didn't those guys install Intel chipset drivers? Have you ever gone to the Intel support site and found chipset driver updates? I don't see how you live with it.

My computer functions just fine with Aero turned off, I don't though. Not sure what you mean by 'delays output of parts of running processes'.

What result do you get if you run that script on the unprocessed frame?

It looks as if part of your processing is running and sending output, some other area isn't painting properly or don't make it to your frame server client (which is Virtualdu8b). For all I know, it could be your graphics card.

I don't have the unprocessed frame. And temporal YUV filters like the ones being used are ineffective on a single frame that's already been converted to RGB.

You'd get enough of a result off the unprocessed JPG I posted to tell which, if any, of my three versions is accurate though wouldn't you?

If not, here's a five-frame Direct Stream Copy of the capture.

I've been running the script on the ColorIssues.avi for 2 hours now, making changes and hitting F2 while another of my own scripts is running at the same time in a copy of VirtualDub with one of my problem captures. So far, no problems. I just leave the ColorIssues project displayed continually while I move back and forth between that script and other Windows apps.

After a while (the length of time depends on the system) VirtualDub runs out of memory with repeated use of features like F2, which has to load stuff in memory so it can remember where you were when you click F2. I don't see any changea yet. I'll just keep it running and clicking F2 until something strange happens. A video of 5 frames isn't exactly a heavy processing load.

What I was asking was which of the three images it resembles. I don't know what results I should be getting, color-wise.

I've got three instances of VirtualDub running - one for each camera - and the scripts open in AvsPmod. Could that be the issue?

Yes. Now you tell us! I have no idea why you're going through all that to match camera shots. Why run a script (in 6 locations) when you could match shots just opening three copies of the unprocessed AVI, then run the script on the selected shot.


I worked through all this material and time not knowing how you were actually running these scripts, so I'll post the results anyway. I ran 3 different scripts in 3 different copies of VirtualDub -- your original script, a different script #1, then a Script #2 that added more plugins to eat up memory. At the same time that I was clicking F2 for over 4 hours on those three scripts, I was running a long process on another project in copy #4 of VirtualDub. I figured sooner or I'd have memory problems somewhere and get goofy result eventually. And as you know, I don't (and won't) use AvsPmod to check that specific interference problem.

The image below is what I get when running the original script in VirtualDub. The closest color match I see is your top #1 image posted earlier. None of the vectorscopes exactly match the one I get, the cloest (with more red data) would be your top image as well.

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

The image below resulted from running a different script (Script #1).
http://www.digitalfaq.com/forum/atta...1&d=1479744375

The cleanest image below resulted from adding more plugins in script #2.
http://www.digitalfaq.com/forum/atta...1&d=1479744425

Eventually, after clicking F2 on and off for over 4 hours, that Script #2 copy of VirtualDub gave me a white blank screen and the message "VirtualDub has run out of memory", so I close it down. All the other scripts were still running. Meanwhile, colors and vectorscopes never changed. The Scriot ! and Script 2 images have cleaner whites and blacks -- white and black in your original script have a green tint and more noise in the darks.

This line in your script "SmoothLevels(0,1,255,16,235)" is pulling up more noise out of supoerblacks. There's no detail down there and it's turning your borders and shadows toward greenish dark gray. The original script has green, red, blue, and magenta specular "hot spots" or small patches in the audience that are tamef in my script #2 with MCTD and SmoothUV(). No matter how you look at it, this video is mostly nosie and distortion. You should explain this to the owner and find out what the heck was done with the original video, not that it would make a difference. It is what it is.

Please give us the full story of what you're doing, next time.

Your Original script:

Test Script #1:
Test Script #2, too clobber memory:

Sorry, it just didn't even occur to me until you brought up the memory thing that it was even worth mentioning.

I don't understand what you have in mind here, or where the six locations came from. Each script is only open twice - AvsPmod and VDub.

Just in case you've misunderstood what I said: I have three scripts in AvsPmod: CornerCamLeft, HardCam, and CornerCamRight. I have three instances of VDub, each with those AVS files open, sitting at relevant frames. I was then making adjustments to try and get them to match as closely as possible, but once the colors started seeming entirely random I gave up and posted here. So yes, levels and such might still need tweaking.

Where is that coming from?

I've got MCTD in its own script, and then another script with the MergeChroma and SmoothUV. Which I can't run because MCTD won't bloody work, but all of that is irrelevant if I can't get the colors right.

The owner is an organisation, not an individual; I'm sure anyone with direct knowledge of the mistreatment it's suffered is long gone. I had to throw them samples from the last tape I worked through on here to get them to give me the work instead of the guy who was doing it with a DVD/VHS combo unit.

I do try, but sometimes I don't know enough about things to know what's worth mentioning, and what's even less relevant than the phase of the moon.

And sometimes I just forget to mention things I know are important, because sometimes humans are stupid.

Is there a difference in the number of # symbols used to comment? I notice sometimes you've used one, and sometimes three...I think I've seen two used as well. Didn't know you could comment out parts of lines, that might be helpful.

What does ChromaWarpSharpener do?