Scripts and filters for an Opera (sample videos included)

[sanlyn]

Better VCR may help that tape, preferably one with sharpening options.
AG-1980 would be my choice on this tape.

The cap is from a portion of the tape I haven't got to yet. It's too bright and undersaturated. I couldn't use my PA-1 proc amp to record; apparently copy protection left a semi-transparent dark gray band along the bottom, it gets picked up by every proc amp I've tried. An AG-1980 would be great. Can't even find a bad one any more. But even with one of those, the tape still needs lots of cleanup. Should have seen this frame before NeatVideo -- but that's another story.

[jairovital]

lordsmurf
thank you for your suggestion. Unhapply I have no tape at all... This video came from an old DVD, nobody knows who converted it from tape to DVD. As sanlyn had said before, it's a CVD (Chinese version of Super Video -- i.e., a CD, not a DVD). All my effort to restore it is because its history's value.

sanlyn
man, I can see you are sleeping less than me. Your studies and analysis on the video are wonderful. Here, at this thread, we can found too much material to learn and go deeply into video secrets. Superb.

I understand all you're talking about color mess and hardness to get a better look. But I think we are reaching its limits. No way to have a better source. It is like a parchment. It'll always look like an old piece of paper. Sometimes teared, somewhere blurry and illegible. No matter I do it'll never look like a modern sheet of paper, white, slim and smooth, ever.

So, what you say about my flow chart I posted yesterday? Do I go ahead? Encoding to huffyuv and saving WAVs? And then? Which filters and NV settings do I have to apply?

I think you already have good suggestions of setting to apply. We'll never reach the heaven with this kind of source video. You're a great, man, very smart, but not god yet..

[poisondeathray]

Also note corruption along the right edge. Likely this came from the tape, along with the stripes across the top. No fix for this.

I posted a treatment for the colored lines at the top and right stripe earlier. I wouldn't call it a "fix" , rather an improvement

The approach is to clean the U,V planes in YUV space BEFORE the RGB conversion , but apply them using masks, so you limit the damage of the filter to those areas specifically. If you applied the filter to the whole frame, it would destroy the "good parts" (if you can say there are any good parts LOL ). This is easier to do in the original MPEG2 YUV colorspace, because the chroma planes are easily accessible separately from the luma.

Now it's better to do this in other software like After Effects, because it better tools like feathered masks and rotoscoping tools (the sharp line demarcations of the mask are blended gradually instead of abruptly - see picture 2b below. The line isn't very visible in this particular case in the final composite, because only the chroma plane is denoised) There might be a way to do feathered masks in avisynth, but it's beyond my lowly avisynth capabilities; and I would love to learn how to (maybe someone can show me)

Top - Picture on left is the original, on right is treated with masks
Bottom - Same, but shows mask area

I didn't do any other corrections. This is just a suggestion to what you could use as a starting point before converting to RGB and applying your other filters, etc...

This is messy code, and there's probably way neater/simpler way to do this, but I left it broken out, so it's easier to understand. Technically, you could group the even and odd field pairs, then apply the filters, then interleave them before weaving, but for these particular filters it doesn't matter. (However it is important to separate the fields, or the chroma gets associated incorrectly)

If you wanted just the composited picture, delete the last stackhorizontal line and replace with "e" . If you wanted to see the mask area (like in picture 2b, just uncomment the levels lines (i.e. remove the "#" where it says levels)

#original source , separating fields
mpeg2source("test.d2v")
assumetff
separatefields
crop(0,2,0,-2,true)
addborders(0,2,0,2)
a=last
 
#top overlay
a
chubbyrain2()
smoothuv(radius=7)
crop(0,0,0,-220,true)
#levels(50,1,255,0,255)
b=last
 
#bottom overlay
a
chubbyrain2()
smoothuv(radius=7)
tweak(sat=0.9)
crop(330,0,0,0,true)
#levels(50,1,255,0,255)
c=last
 
#overlay the top onto original
overlay(a,b)
d=last
 
#overlay the right border onto the last composite above ("d")
overlay(d,c,x=330)
weave()
e=last
 
#compare original with composite
stackhorizontal(a.weave,e)

[sanlyn]

jairo, I'll add more notes later. Have to spend most of the day outdoors at my wife's request, foraging for food. Also have a PC cutomer's machine to repair.

Your flowchart: nothing wrong there, but see below about the video size limitation. I realize you have to do some remuxing, but you'll have a nervous breakdown trying to do it for each little piece. You should make one huge master AVI of the entire opera. With huffyuv, that would be anywhere from 40 to 70 GB. You then work with that master AVI, a piece at a time. Try to make the AVI pieces less than 4.7-GB so you can save them to disc. You're going to need a huge hard drive for this project, unless you keep working a few pieces and then archiving them to make more hard drive room. I use two external hard drive enclosures with 350-GB drives each. That doesn't count the 7 hard drives I have on the 3 PC's I built.

You're embarking on a project with three serious limitations. Those are the same limitations that almost everyone in this forum started with, so don't feel you're the only one.

The first limitation is your CVD. It was made with apparently mediocre gear in an inappropriate format. The color and detail problems are enough trouble to begin with, but the frame size is the worst of it. If you could overcome that size restriction, you final product could look much better.

One way to handle that is to make a 640x480 AVI recording. You'd need a suitable capture device and learn to use VirtualDub's capture utility, which happens to be a very good program. Unfortunately today's PC capture cards have nowhere near the quality of the analog hardware of a couple of years ago (that's right, my friends: analog!). digitalfaq has some updated info on today's devices. I haven't had to get into that for 6 years because I have two excellent ATI AllInWonder cards and never need anything else. Check digitalfaq's recommendations and then take a look at the pro video division of B&H Photo in New York (http://www.bhphotovideo.com). You might be able to get a clean 640x480 via Windows Media Center somehow,there will be info in the forum on that. Don't use the capture device's software for this: it sucks. Use VirtualDub. With a 640x480 master, you could encode to DVD at 704x480 with far better playback results.

Your biggest investment will be patience. Video restoral is painstaking, even for pros. Example: NeatVideom is used by many pros. You don't yet realize that NeatVideo is a specialized, highly configurable device. You use it for grungy stuff that won't respond to anything else, because NeatVideo is thorough and slow-running. It will process at roughly 2 to 3.5 frames per second. Figure your opera runs 3 hours at 30 fps, and you'll quickly realize how long it would take NeatVideo to filter it. More often, you'll use lesser filters for less troublesome scenes. That means you have to learn to cut up scenes for special processing and rejoin them later. One example: I decided while converting 20-year-old tapes that I'd save some of the better 1980's-era commercial ads. I found one 15-second ad for the Alaska Tourism Bureau that I thought was just beautiful graphically. I cleaned it up from very damaged tape, but that 15-second ad took 9 filters, dozens of AVI versions (mostly failures), and 14 hours of work.

Not everyone is so exacting. For that ad I had to find and experiment with new techniques. In the end I learned much that became invaluable many times over.

None of this is meant to discourage. Your workflow is a good idea and should work OK as a general plan. There's no push-button answer, no single NeatVideo setting. VHS has horrible color problems even on pristine tapes. Color balances change scene by scene and often within scenes. You'll have to use histograms, vectorscopes, gradation curves, learn to recognize problems and what colors are involved, and so on. Something that works on one section of tape won't work on others.

I'll try to look up a few things later and get back to you. Just keep pluggin' away, jairo!

[sanlyn]

Also note corruption along the right edge. Likely this came from the tape, along with the stripes across the top. No fix for this.

I posted a treatment for the colored lines at the top and right stripe earlier. I wouldn't call it a "fix" , rather an improvement

The approach is to clean the U,V planes in YUV space BEFORE the RGB conversion , but apply them using masks, so you limit the damage of the filter to those areas specifically. If you applied the filter to the whole frame, it would destroy the "good parts" (if you can say there are any good parts LOL ). This is easier to do in the original MPEG2 YUV colorspace, because the chroma planes are easily accessible separately from the luma.

Some great ideas here, poisondeathray. Thanks for posting. It's about time I re-learned AviSynth for an upcoming project. Been away from it too long.

[lordsmurf]

The videos in post #63...
Look at running this through ColorMill, via VdubMod.

[jairovital]

You then work with that master AVI, a piece at a time. Try to make the AVI pieces less than 4.7-GB so you can save them to disc. You're going to need a huge hard drive for this project, unless you keep working a few pieces and then archiving them to make more hard drive room.

I didn't understand very well I need to make an AVI file to process it later. Why can I take the those source Mpegs files from DVD via DGIndex and apply filters at same time? Is it because spatial and temporal noise analysis?

If you could overcome that size restriction, you final product could look much better.

One way to handle that is to make a 640x480 AVI recording. You'd need a suitable capture device and learn to use VirtualDub's capture utility, which happens to be a very good program.

Unfortunately, at this time, it is completelly beyond my scope. Your are right: with a bigger resolution I could work wth more comfort. But... no way to buy hi-tech capture devices...

Not everyone is so exacting. For that ad I had to find and experiment with new techniques. In the end I learned much that became invaluable many times over.

Me too. I'm learning valuable information with this job.

None of this is meant to discourage. Your workflow is a good idea and should work OK as a general plan. There's no push-button answer, no single NeatVideo setting. VHS has horrible color problems even on pristine tapes. Color balances change scene by scene and often within scenes. You'll have to use histograms, vectorscopes, gradation curves, learn to recognize problems and what colors are involved, and so on. Something that works on one section of tape won't work on others.

Thank you sanly. In fact I'm not feeling discourage with the challenger. I know that all of this is teaching me a lot.

But, take a look at my real world: I'm not trying to make very very fine tune work on that video. I have no resources neither knowledge to do every advice you are giving me. Analogue device capture of 640x480 res, color balances change scene by scene, use of histograms, vectorscopes, gradation curves, to recognize problems with colors and so on, are too much for me at this moment. It would be a project for a company, a sector of government, a museum or a team from VideoHelp experts.

I'll try to look up a few things later and get back to you. Just keep pluggin' away, jairo!

Great. All I need to finish this project is just few lines from you, like VDub filters and NV settings. I know, I know, it's not enought. But it is what I'll do when I finish that big AVI I said few posts above. I'm not sure to use ColorMill and NeatVideo, so I ask your help to point me some basic settings, even if that project deserves much more.

There's no push-button answer, no single NeatVideo setting.

I know, I know... But I have my hands tied to make all the long todo list it deserves... If you say no, I'll put same seetings that killed too many details. The final result, surely will be better than what I have now with the ugly original source.

But... but... If you suggest some tips, then it would be the best result I could have.

[davexnet]

Hi everybody -
is there some misunderstanding in this thread ? I thought Jairo's source was the DVD @352*480. Is this not so?
Then there is no "capture" as such - you simply copy the VOB's to the harddrive and process those.
What's the point of increasing the resolution to 640*480? Does converting it to HuffyUV or some other lossless
format give you anything ?

If you want your target to be a new color corrected and noise reduced DVD, keep it at that format and resolution,
it's perfect legal, 1/2 D1. I'm not an Avisynth expert but it seems that MV tools do offer some assistance with "steadying"
the video and make it a little less crappy-VHS looking. I'm not sure if there is any equivalent in native Avidemux or
Virtualdub - Unless Flaxen's VHS filter may help.

That's about all you can do and you will see an improvement. Correct the color a little.
Some temporal noise reduction and a steadying of the picture.
And of course the sound, as was stated earlier. That's it.

[sanlyn]

davexnet, I think jairo already has a solution for the audio problem, so that's one step ahead. I've suggested VirtualDub as the basic filtering platform because there are many effective and user friendly VDub filters that don't require complicated AviSynth scripts and colorspace conversions. MV Tools: I don't think that software can work directly on VOB/MPEG, but maybe so. Anyone who knows MV Tools might help us with that.

I don't think it's possible for jairo to capture a 640x480 version. He apparently doesn't have the gear for that, so we're stuck with 352x480. I have various reasons for suggesting that a video be processed in AVI in its intended display format. For one thing it's easier to see what you're doing (but not absolutely necessary). For another, a larger frame can help preserve detail (what little there is), has much higher bitrates and thus more data to "describe" the video, and presents fewer resizing and scaling problems on playback. I've seen it work well in the past. But again, that option isn't available under the circumstances.

MV Tools requires, I think, two passes. First, you build a motion analyzer file. The second pass applies the analysis data to the video. I think that's how MV Tools does it, from my experience some time back in AviSynth. I stopped using it because it didn't get the results I wanted when working with low-quality VSH transfers. Maybe another member can help on this.

I'm ruling out NeatVideo for this project. Even at very weak settings, it would take NeatVideo 36 to 40 hours of continuous running to work this opera. VirtualDub's temporal smoother at a value of 4 or 5 cleaned up much of the simmering schmutz. Most other temporal filters I've used generated motion trails and other artifacts when set strong enough to clean a video as well as temp smoother did -- not optimal, but a very visible improvement.

A second run with ColorMill could reduce about 8 points of green, add some 5 or 6 points of blue, and do some mild sharpening in a single run. See http://fdump.narod.ru/rgb.htm. Pretty much the same color correction and sharpening could be done with TMPGEnc 2.5's filters, but they take some fiddling to learn to use.

Those steps would make mild but visible improvements. But you'd still be working with AVI. I don't know many applications that can work directly on VOB/MPG without decompressing/recompressing several times and creating severe problems with lossy MPEG compression. Huffyuv is suggested for AVI because it doesn't destroy anything and reduces the working files to 1/3 that of uncompressed AVI. Of course, you can make so many decompress/recompress runs with huffyuv that you ultimately start seeing comprerssion problems, so you need to take a little care in that regard.

poisondeathray offered a workable solution for the border noise that I thought worked nicely, but it requires AviSynth -- not a real problem, but it is an extra step.

[sanlyn]

jairo, here's something you can try. Load one of your DGIndex-extracted AVI's into VirtualDub. Scroll thru the video until you reach one of those noisy scenes. Try to choose a scene that also has some movement or camera motion, to test later for any ghosting or trailing on movement. Use VirtualDub to cut the beginning of the video so that your processing will start at that scene.

Load VirtualDub's Built-in temporal smoother. It's in the filter list near the bottom of the list and is marked "(internal") in the right-hand border of the list. Set the filter strength to 5. Then go back to the main VDub window and Click "Save As AVI...", then name it and save it wherever you want. Let the processing run for about a minute, then abort it. You will have saved about 1 minute of test AVI to look over. The filter should clean a lot of that noise in shadow areas and elsewhere.

[jairovital]

sanlyn
This morning, just when wokeup I tried your suggestions about temporal smoother and collormill. Wonderful! I think there is no reason to keep insisting with that NeatViedo. Its processing delays too much and results are questionable (but with my newbie settings, I must add). I used ColorMill 2.1 with MiddlePoint 10, DarkGreen -20, DarkSaturation -30 and MiddleSaturation 20.

I'm happy with what I see now. Temporal Smoother thrown away that flys and mosquitos at background curtain.

But I have two questions: how to proceed? Run Temporal Smoother and save huffyuv, and after that run ColorMill? Or I can run both at same time?

I'm fighting right now with poisondeathray's script to remove color stripes. It says it could not find chubbyrain2. What dll or avs do I need?

Edited:I found Chubbyrain2 at doom9. I saved it as an avs file and imported it to poisondeathray's script. Now it is claiming the absence of yv12convolution...

I think I'm getting the right route to go.

[poisondeathray]

It says it could not find chubbyrain2. What dll or avs do I need?

function ChubbyRain2(clip c, int "th", int "radius", bool "show", int "sft")
{
#based on Mug Funky's ChubbyRain
th = default(th,10)
radius = default(radius,10)
show = default(show,false)
sft = default (sft, 10)
u = c.utoy()
v = c.vtoy()
uc = u.mt_convolution(horizontal="1",vertical="1 -2 1",Y=3,U=0,V=0)
vc = v.mt_convolution(horizontal="1",vertical="1 -2 1",Y=3,U=0,V=0)
cc = c.mt_convolution(horizontal="1",vertical="1 2 1",Y=2,U=3,V=3).bifrost(interlaced=false).cnr2().temporalsoften(radius,0,sft,2,2)
rainbow=mt_lutxy(uc,vc,Yexpr=string("x y + "+string(th)+" > 256 0 ?")).pointresize(c.width,c.height).mt_expand(y=3,u=-128,v=-128)#.blur(1.5)
overlay(c,cc,mask=rainbow)
show==true? rainbow : last
}

You can either make that an .avs file and use Import() , or make it an .avsi file and it will autoload, or just copy that to the bottom of your script.

There are required plugins like bifrost , masktools as well

[jairovital]

poisondeathray
As I edited in my #71's post, I could solve partially my problem. Now I have masktools, bifrost, cnr2 and smoothuv, all of them requested from your script.

I'd like to say that it works like a charm. Wonderful and ellegant solution for that color stripes on top and right of the scenes. Thanks, man.

My monday is starting very well with sanlyn's and your's suggestions!

[sanlyn]

sanlyn
This morning, just when wokeup I tried your suggestions about temporal smoother and collormill. Wonderful! I think there is no reason to keep insisting with that NeatViedo. Its processing delays too much and results are questionable (but with my newbie settings, I must add). I used ColorMill 2.1 with MiddlePoint 10, DarkGreen -20, DarkSaturation -30 and MiddleSaturation 20.

I'm happy with what I see now. Temporal Smoother thrown away that flys and mosquitos at background curtain.

But I have two questions: how to proceed? Run Temporal Smoother and save huffyuv, and after that run ColorMill? Or I can run both at same time?

I'm fighting right now with poisondeathray's script to remove color stripes. It says it could not find chubbyrain2. What dll or avs do I need?

Edited:I found Chubbyrain2 at doom9. I saved it as an avs file and imported it to poisondeathray's script. Now it is claiming the absence of yv12convolution...

I think I'm getting the right route to go.

Try a few minutes of test video first, cleaned up and burned to DVD, and play it on your tv. If you're using an uncalibrated computer monitor (they're almost always too bright and too "cool"), your ColorMill settings might have very dense darks. Your Colormill numbers are bigger than mine, but that software is a "season to taste" affair. Run a couple of short tests first for a checkup with your TV. PC and TV seldom look the same, until you learn your PC monitor's characteristics and can judge the results by eye beforehand. That would be better than processing and burning 3 hours of video and deciding you didn't like it.

While it might work a little better if you make separate runs (one for poison's AviSynth fix, followed by temp smoother, and a third for Colormill -- that would be three runs), I don't think you'd have a problem with two runs. Run the border fix first, then save it and run it with temp smoother + Colormill loaded together. That way, you'll end up with two saved versions instead of 3. Because this is only 2 recompress operations, you can save each with huffyuv without a problem -- or you'll run out of disk space very quickly.

Rather than filter the whole opera, try working with 30-minute segments . Not really necessary, but at least you wouldn't tie up your PC for such long stretches at one time. For long processing runs, I start it at bedtime and let it run all night.

NeatVideo is a special-purpose product. Using it on everything in sight is a waste. Save NV for higher-quality captures that will return something more for your investment.

[jairovital]

sanlyn
Yes, I understand all you said. We are getting close to the end of this thread. But I still have 2 more questions:

that way, you'll end up with two saved versions instead of 3. Because this is only 2 recompress operations, you can save each with huffyuv without a problem

1 - You talked about recompress. Is it the menu item under Video, in VDub? or I use "Full Processing Mode"?

2 - I have another project where TMPGenc suggest to encode using 7000 kbps, but GSpot and DVD-Lab says it is around 5000 kbps. I put 6000 and the final m2v file is 5.6 Gb. If I encode again decreasing it is better than leave as it and use later DVDShrink to fit in DVD? In which way I get less loss of quality? Reduce kbps or shrink it?

[sanlyn]

sanlyn
Yes, I understand all you said. We are getting close to the end of this thread. But I still have 2 more questions:

that way, you'll end up with two saved versions instead of 3. Because this is only 2 recompress operations, you can save each with huffyuv without a problem

1 - You talked about recompress. Is it the menu item under Video, in VDub? or I use "Full Processing Mode"?

2 - I have another project where TMPGenc suggest to encode using 7000 kbps, but GSpot and DVD-Lab says it is around 5000 kbps. I put 6000 and the final m2v file is 5.6 Gb. If I encode again decreasing it is better than leave as it and use later DVDShrink to fit in DVD? In which way I get less loss of quality? Reduce kbps or shrink it?

You need to check two "Video" settings in VirtualDub. You should use "Full Processing Mode" for video and audio, unless you're just making a copy and not doing any processing. Under "Compression," make sure huffyuv is selected (the default for each new VirtualDub session is uncompressed).

I can't answer for the "other project" you mention, I don't know what it entails, its size, length, etc.. BTW, I don't recall TMPGEnc's encoder ever "suggesting" a bitrate. Are you sure you're using TMPGenc-Plus 2.5? If you're using the latest v.4 or later, it's does not encode as well. Pegasus tried to discontinue the old 2.5, but there was such an uproar from hobbyists and pro's that they restored 2.5 to their download page.

GSpot usually quotes a "target" bitrate specified in the file headers. The actual playback bitrate may dip below or exceed that figure during play. GSpot also tells you whether it was CBR (Constant Bit Rate) or VBR (Variable Bit Rate). If that other project is said to be encoded at 5000, it was apparently good enough, but it could have been an "average" or "target" VBR. I almost hesitate to ask, but why are you re-encoding the entire video?

Your opera will be a 352x480 video played back at 4:3 image ratio, full-screen (which means it will play back at 640x480). In TMPGenc (or CCE) use variable bitrate (VBR), choose 2-pass encoding and use "slow" for motion control. Within the VBR bitrate dialog box choose Max=5000, Average=4000, Minimum=2000. In GSpot, your bitrate might be stated as the max value or the average value. On a 352x480 DVD played back in PowerDVD, the bitrate display in PowerDVD will dip between 3000 and 4500, but usually stays around 4000 if that was your target bitrate. If a video is encoded at CBR, the playback bitrate display never changes.

[sanlyn]

jairo & others, some Vastly Simplified Tips on color balance:

The distribution of RGB color in VHS is crappy, to say the least. I have yet to see a VHS tape that doesn't have some kind of color cast.

When a PC or TV monitor is calibrated with test instruments, 3 main colors are used to set an accurate display from darks thru midtones to brights. You'll be surprised to learn that those 3 colors are White, Gray, and Black. Those 3 colors are used because each contains equal portions of Red, Green, and Blue. The higher the RGB values, the brighter the color.


1) The brightest White on a PC has RGB values 255,255,255. Normally NTSC aims for a slightly lesser white at RGB-235. Almost anything in that brightness range starts losing detail. Today's TV can handle brighter-than-235, but on many sets RGB 220 or higher starts looking burned out.

2) Gray has many shades between white and pure black. A light gray similar to greyed-out Windows commands is around RGB 192,192,192. The gray of shaded areas on white shirts lies between all-145 and all-128. The kind of dark gray you see on the brighter parts of truck tires (they're not really black!) would be RGB-64,64,64 to 40,40.40 or so.

3) Pure Black is RGB 0,0,0. NTSC "TV black" is RGB-16. Today's TV's can handle RGB-0, but remember that as you get near this point from about RGB 24 to RGB 8, you get dark grays that "look" black but lose detail.

VirtualDub expands NTSC video RGB 16-235 to PC RGB 0-255. When you render to DVD, the encoder compresses back to NTSC 16-235.

When trying to fix color balance in an image, look for objects that should be displayed as whites, grays, or blacks. Be careful with stage plays such as your opera. Theaters use lighting effects, such as throwing a cold blue-gelled spotlight on center-stage singers. The colors under or near colored light sources reflect the lights' colors. Stage lighting also tends to be dimmer in corners and backgrounds, where it might turn warmish. So if the objects you're studying look as if they're under artsy lighting, you have no way of judging color "accuracy" based on such lighting alone.

You don't always find objects that are plain gray or black, but you often find whites (shirts, hats, other clothing, paper). Shoes and hair are often approach black, and gray should be close to gray, not blue or green. If you can balance these whitish or blackish colors toward equal RGB values, other colors usually fall into place. Avoid using very dark shadows as samples: shadows are seldom really "black".

With no neutral colors to work with, study flesh tones. Skin that's too pink has too much blue. Yellowish skin has too little blue, or too much green+red.

A final tip: with experience you learn to judge whether color is off because you have too much of one color or not enough of the others. Colors can be balanced by adding or subtracting their oppposite color. The opposite of each primary is a secondary color, as follows:
- The opposite of RED is CYAN (GREEN + BLUE)
- The opposite of GREEN is MAGENTA (BLUE + RED)
- The opposite of BLUE is YELLOW (RED + GREEN)

Attached is a popular pixel color sampler (csamp.exe). A fave with Photoshop folks. Create a folder named "Csamp" on your PC. Copy the .zip file to that folder and unzip it. It contains csamp.exe and a .txt file. Then copy csamp.exe to your desktop. I usually keep it in the lower right, just above the taskbar tray.

Double-click the CSamp icon (it looks like a little blue flask). When running, CSamp displays a small dialog window with a label reading "Press and Hold"; it also displays a tiny icon in the system tray. Press on the "Press and Hold" label, and hold down the mouse button. The mouse pointer becomes a crosshair. Drag the crosshair around; as it passes over pixels, the small window displays the RGB values of those pixels (it samples a 3x3-pixel area).

Let go of the mouse and the mouse pointer re-appears, but the CSamp window still runs. To start reading pixels again, click "Press and Hold" again. If you can't see the CSamp window behind other windows, left-click on its system tray icon. To turn CSamp off, right-click its system tray icon, then click "Exit". CSamp is a standalone that requires no installer.

If you lose CSamp, it can be downloaded with some Photoshop and other plugins at http://ghool.homeip.net/d/Multimedia/Graphic/?sort=d .

[Gavino]

1) The brightest White on a PC has RGB values 255,255,255. Normally NTSC aims for a slightly lesser white at RGB-235. Almost anything in that brightness range starts losing detail. Today's TV can handle brighter-than-235, but on many sets RGB 220 or higher starts looking burned out.

2) Gray has many shades between white and pure black. A light gray similar to greyed-out Windows commands is around RGB 192,192,192. The gray of shaded areas on white shirts lies between all-145 and all-128. The kind of dark gray you see on the brighter parts of truck tires (they're not really black!) would be RGB-64,64,64 to 40,40.40 or so.

3) Pure Black is RGB 0,0,0. NTSC "TV black" is RGB-16. Today's TV's can handle RGB-0, but remember that as you get near this point from about RGB 24 to RGB 8, you get dark grays that "look" black but lose detail.

VirtualDub expands NTSC video RGB 16-235 to PC RGB 0-255. When you render to DVD, the encoder compresses back to NTSC 16-235.

I think there is some confusion here between RGB levels and YUV levels.
VirtualDub does not change RGB levels. There is no expansion as such - it's simply that when converting YUV data to an RGB representation, it interprets Y=235 as R=G=B=255 and Y=16 as R=G=B=0 (as it must when following the Rec.601 specs).

[sanlyn]

I think there is some confusion here between RGB levels and YUV levels.
VirtualDub does not change RGB levels. There is no expansion as such - it's simply that when converting YUV data to an RGB representation, it interprets Y=235 as R=G=B=255 and Y=16 as R=G=B=0 (as it must when following the Rec.601 specs).

True. The description was for beginners, but thanks for clarifying that point.

[jairovital]

I can't answer for the "other project" you mention, I don't know what it entails, its size, length, etc.. BTW, I don't recall TMPGEnc's encoder ever "suggesting" a bitrate. Are you sure you're using TMPGenc-Plus 2.5? If you're using the latest v.4 or later, it's does not encode as well. Pegasus tried to discontinue the old 2.5, but there was such an uproar from hobbyists and pro's that they restored 2.5 to their download page.

Yes, I'm using TMPGenc-Plus 2.5. When I load the file *.vdr.avi from VDub frameserve, TMPGenc read the file ("judging field order) and fills the following fields: VideoType (interlace), FieldOrder (TopFieldFirst - field A), AspectRatio (4:3) and ContentVideo(Movie). I think, here the program has some information about the file. At step 4/5 of the wizard, it "suggests" to use 7000 kbps at bitrate. If I put its suggestion I'll get files bigger than a DVD's capacity.

Question is:
Use that suggestion of 7000 kbps and later use DVDShrink to fit in a DVD's capacity? or
Decrease bitrate, still in TMPGenc?

Which method is lossless?

Note: At DVDShrink I'd use its best method to compress, i.e. DeepAnalysis and AdaptiveErrorCompensation.

GSpot usually quotes a "target" bitrate specified in the file headers. The actual playback bitrate may dip below or exceed that figure during play. GSpot also tells you whether it was CBR (Constant Bit Rate) or VBR (Variable Bit Rate). If that other project is said to be encoded at 5000, it was apparently good enough, but it could have been an "average" or "target" VBR. I almost hesitate to ask, but why are you re-encoding the entire video?

sanlyn, you are giving wonderful classes here and not only me, but several users are learning a lot with them. Is it possible to you explain more about CBR and VBR? I'm not meaning the concepts; I think it's basic and we can skip it, but about the best choice for encoding, pros x contra and if DVDplayers can handle both ways of bitrate.
In time, I'm re-encoding the video just to remove a small logo at its left-top side.

Your opera will be a 352x480 video played back at 4:3 image ratio, full-screen (which means it will play back at 640x480). In TMPGenc (or CCE) use variable bitrate (VBR), choose 2-pass encoding and use "slow" for motion control. Within the VBR bitrate dialog box choose Max=5000, Average=4000, Minimum=2000.

Again the same problem: final output is bigger than DVD. What to do? Leave as it and DVDShrink over it? or decrease right now to lower values?

jairo

[sanlyn]

Yes, I'm using TMPGenc-Plus 2.5. When I load the file *.vdr.avi from VDub frameserve, TMPGenc read the file ("judging field order) and fills the following fields: VideoType (interlace), FieldOrder (TopFieldFirst - field A), AspectRatio (4:3) and ContentVideo(Movie). I think, here the program has some information about the file. At step 4/5 of the wizard, it "suggests" to use 7000 kbps at bitrate. If I put its suggestion I'll get files bigger than a DVD's capacity.

Question is:
Use that suggestion of 7000 kbps and later use DVDShrink to fit in a DVD's capacity? or
Decrease bitrate, still in TMPGenc?

Which method is lossless?

Note: At DVDShrink I'd use its best method to compress, i.e. DeepAnalysis and AdaptiveErrorCompensation.

Is it possible to you explain more about CBR and VBR? I'm not meaning the concepts; I think it's basic and we can skip it, but about the best choice for encoding, pros x contra and if DVDplayers can handle both ways of bitrate.
In time, I'm re-encoding the video just to remove a small logo at its left-top side.

Oh, my. Wish I could make this shorter.

I don't know anyone who uses the TMPGenc Wizard. I wouldn't bother, just cancel the wizard and go directly to the interface -- you're going to override many of the Wizard's suggestions anyway.

Setting up frameserving between VDub and TMPGenc is troublesome, but many do it. The info you see in the wizard about your video is also in the other tabs in the regular TMPGenc interface.

Loss isn't a serious question for either method. But you're working too hard. If all you want to do is remove some frames that have a logo, just delete the frames in an MPEG editor, save the rest of the MPEG, and re-author it. You don't have to re-encode.

Re-encoding at a higher bitrate won't gain anything. You can't create detail that wasn't there in the first place. Of course you can always use DVDShrink anyway, it's up to you.

bitrates -- if I make a big foh pah here, someone correct me:

Most DVD's are encoded using a Variable Bit Rate, as opposed to a Constant Bit Rate.

CBR or its companion CQ (Constant Quality) is an instruction to the encoder to set and maintain a bitrate and quality level that you specify. There's one problem with you specifying this quality level: all of your video likely won't require that high (or low) an encoding level in every frame. It's almost always a waste of storage. Also, when you specify a constant level the encoder doesn't inspect the video to ascertain the optimum way of encoding each frame; you've removed that choice from the equation.

A Variable Bit Rate (VBR) tells the encoder to use whatever it needs to best encode the data. This means that if the encoder senses a great many changes, motion, detail, etc., it will vary the bitrate according to changing situations, and according to a maximum and minimum rate that you specify. But the encoder has more than one way of ascertaining what that level will be, depending on the following:

If you use a 1-pass (aka single-pass) VBR, the encoder will not review many frames. It will sample a few and then hazard a guess about what the video needs. This estimate is based on several algorithms built into the program. Likely the encoder will try most of the time to strictly maintain the limits you impose with your max and min bitrate. In effect, 1-pass VBR is pretty much the equal of CBR in one respect: the encoder has been set to give processing priority to the bitrate, not to quality or efficiency.

But most people would use a 2-pass VBR. In pass #1 the encoder makes an exploratory review of the whole video. There's no encoding: the encoder is saving data characteristics for use during the 2nd pass. On Pass #2, the encoder continues to analyze but does so in light of the data it received from Pass #1. It will try to stay within your stated bitrate limits; it might go a bit lower if it thinks it can, or it might go a bit higher if it thinks it must (in other words, even though you specify a max and min, you've also given the encoder a bit of leeway in suiting the bitrate to the video). A 2-pass or other multiple-pass VBR assures the best quality as the video requires it, while not wasting storage on unnecessarily high bitrates. Many arguably believe that 2-pass VBR at a reasonable min and max will give better overall quality than an unreasonably high Constant Bitrate, mainly because a 2-pass VBR allows the encoder to do plenty of analysis before encoding. VBR is slower. Precision takes time.

Again the same problem: final output is bigger than DVD. What to do? Leave as it and DVDShrink over it? or decrease right now to lower values?

jairo

The only way to fit a 3-hour video on a single DVD is to drop the bitrate back down to 2100, which means you'd lose more quality and go back to where you started. MPEG is lossy -- not as lossy as many compressors, but you lose a lot at the low bitrates used for CVD/SVCD. After all the work of improving your video, keep your work with a decent bitrate for 352x480 DVD. If you want to lose quality and get all 3 hours on one disc, you're back to the level of CVD again and your video will look worse than the original.

[2Bdecided]

Constant Quality is the opposite of Constant Bitrate - not its "companion"!!!

VBR is an attempt at Constant Quality with some bitrate constraints.

I believe this is true within TMPGEnc MPEG-2. They have subtly different meanings in H.264 (and/or other encoders), where you have Constant Quantiser vs Constant Quality which includes some psychovisual ideas too.

Cheers,
David.

[sanlyn]

True, 2Bdecided. I think (hope) that's one point I was trying to make. Thanks for clarifying.

[sanlyn]

I keep blowing up caps and video samples of this opera. It looks to me as if at some point there has been a field-order change. I can't think of much else that would have such obvious jaggies on edges. Trying to get my hands on the original CVD, for this and other reasons. If others see the same problem, then I'm not going nuts. Or maybe I went there a long time ago.

[jairovital]

Calm down, man. CVD is on the way.

[sanlyn]

Good show, jairovital. Thank you.

[sanlyn]

Herewith, links to 3 clips from the original CVD disc (free download). Also 3 links to trial corrections for the same clips. I get the best playback with MediaPlayer Classic (free, no install needed).
(http://www.free-codecs.com/download/media_player_classic.htm)
Other Win players were too dark and off-color, or don't deinterlace as well.

Each link goes to a page that starts the video in a small viewer. Phooey! Click "Download Now" (no waiting). Or just to the right of "Download Now", click the "My4Share" folder and see all 6 (Wow!). Download all, or one at a time.

Sorry for big files, but you get the full impact of problems only when you see the 352x480 video played at its intended 640x480. That tiny web player is the pits.

NOTE: NO AUDIO!

The "original" versions were cut from unmodified VOBs. I used TMPGenc MPEG Editor v2. This is pure cut-and-copy, no changes to the original colorspace or any other aspect of the source. I purposely kept all key frames in the cut clip to avoid re-rendering of frames.

The opera is 3-hours 54-min. According to GSpot the original is MPEG2/CVD/YV12, target bitrate 2100 VBR. I believe this bitrate is near the low minimum for DVD/VCD and could run about 4 hours at 352x480. Could have been much better at a 3-hour 3000 bitrate, but the recorder might not have offered it. The title on the disc says the VHS was recorded to a Phillips DVD recorder (another bad idea). The logo at the end of the opera identifies the tape player as Aiwa, which could have been an Aiwa videocam.

"OperaA_original.mpg"
http://www.4shared.com/video/wZfothVV/OperaA_original.html
starts with frame 0 of the video, thru frame 1190. I cut 8 seconds from the middle of this clip, because the opening title doesn't change for some time. The clip displays almost all the bad news I saw when I first played this video (gets worse later). Note tape misalignment across the top border that "stabilizes" with green stripes for the whole video, and the red stain along the right (heat damage, IMO) . Also note badly worn video heads and a catalog of artifacts from terrible playback, damaged tape, and a low bitrate. A line-level TBC would have solved many problems. Too late now. Halfway thru, during the brief fade-out-fade-in look for noisy mottling and mosquito noise. (Approx 12.6 MB, 31 seconds)

"OperaB_original.mpg"
http://www.4shared.com/video/uF5-dqR7/OperaB_original.html
is 3 minutes into the overture. This scene is apparently inserted by the director into the intro from a later part of the opera. Appears to play slower than the later sequence. Frames 6371 thru 8106. Same problems. The vertical rolling and rippling is partially bad tape but also due to a special effect in this scene. The scrim (gauzy stuff with the big symbolic ocean wave on it) is part of a seascape scene. Wind apparently flows from the left, disturbing the "sea wave" and slightly billowing the nun's clothing. Near the end are two "flashes" from tape damage. Later, there's ugly damage far worse than this. (16.7 MB, 57 seconds)

"OperaC_original.mpg"
http://www.4shared.com/video/GEOJTFe2/OperaC_original.html
starts at frame 11384. Too much Green and depressed Blue are evident. When the old man opens his mouth, it's a sickening olive green inside. Shows background noise as the old man pauses in a dark area on the right. As the old man moves left, note violent noise in the scenery behind him. (16 MB, 48 seconds).

Still working on this monster. More later.

==============================================

Below, links to trial fixes for these clips. Pardon if some frames might be a tad off from the originals, which were prepared after the trials. Again, NO AUDIO.

These are all very preliminary. LOTS of tweaking ahead, and much to try in VirtualDub and Avisynth. The only noise filter used was NeatVideo. The first efforts had too much processing in the Y-channel (loses some fine detail, what little there is already, hardly enough to work with!) and/or too little in U+V. I've since discovered that most of the noise is in the color channels, not luma. I tried a slew of AviSynth and VirtualDub denoisers: they proved mostly useless, with NeatVideo giving the best results (but still needs extensive tweaking) . I note mild macroblocks (temporal set too high) and a bit of high-contrast edge ghosting. I could kill more noise, but the low detail offers little leeway for full-power filters.

Kudos to poisondeathray's ChubbyRain2 contribution for the border noise. Needs some tuning, but it's nice work! Many thanks.

I tried a handful of chroma cleaners. They had either no effect or made things worse. Also tried some AviSynth fixes for smearing/bleeding. No dice, and much colateral damage. Will keep looking.

VOB->AVI went OK with the old VirtualDubMPEG2, but I used DGIndex in the original YV12 so I could run poisondeathray's border cleaner at the same time. The trials were rendered to MPG via TMPGenc Plus 2.5 with just a smidgeon of color tweaks and light de-ghosting. No sharpening, chroma cleaners, none of that yet. I also compiled with CCE -- saw no difference.

I suspect odd goings-on with the colors, apparently an attempt during recording to compensate for Blue problems from what looks like extensive heat damage to the original VHS. More on that later. Also note occasionally jarring changes in brightness (caused by ???). For now, noise has priority.

"OperaA_trial.mpg" - Approx. 19-MB (31 secs)
http://www.4shared.com/video/03XAmsYD/OperaA_trial.html

"OperaB_trial.mpg" - Approx. 32-MB (58 secs)
http://www.4shared.com/video/hCkOpKL-/OperaB_trial.html

"OperaC_trial.mpg" - Approx. 28-MB (47 secs)
http://www.4shared.com/video/3YdW6MxP/OperaC_trial.html

Total download (all files) about 125 MB. 4shared downloads seem pretty fast.

[sanlyn]

Insurmountable problem #1 (of a great many)...

I have yet to find some way to even partially correct the jitter and ripple in text titles like this. Bad playback, for sure. Some dot crawl filters helped a bit, but they affected the entire frame. Every title in this video has the same problem.

http://dc238.4shared.com/download/6zruTbaw/OpeningTitles.mpg

[sanlyn]

For all those who are (ahem) still keeping track of this monster...

Found many VirtualDub/AviSYnth solutions to various noise problems. But the biggest hurdle is color. Big hurdle!

Blue is seriously crippled, maybe for keeps. Here is a reduced-size capture of a frame from early in the video. The histogram to its right is from VirtualDub using ColorTools. Red and Green slope smoothly down to the RGB16. But Blue info is shoved to the left and severely clipped. No Blue values below RGB20 or so, even if you use various means to expand Blue to the right. Meanwhile, down there in the dark, Red and Green data exists below RGB16.


The problem gets worse. This cap is near the opera's end. Blue is just a tiny blip at left, Red is hardly a contender. Stage lighting doesn't explain it, even if there's an amber spot center-stage, because all scenes before it look the same. Ugly.


Is this due to some colorspace conversion sometime in this video's dark (pardon the pun) past? The original broadcast/tape or whatever on VHS is apparently from France. That spells PAL to me. Whether originally broadcast in France and recorded to VHS there or in Brazil (where the NTSC/CVD disc now lives) is anyone's guess. It's known it was VHS (probably not retail) recorded to a Phillips DVD recorder in MPEG2/CVD/YV12 at 352x480 and a low bitrate. The VOBs from the original disc were joined with TMPGEnc MPEG Editor (no change in YV12 colorspace or anything else) and converted to one big AVI via DGIndex/AviSynth.

Yep, VirtualDub displays this AVI after converting to RGB32, and any VirtualDub filter it as RGB32 input and outputs that way. So be it. But even if you keet the AVI in YUV and it never saw VirtualDub again before going to something like CCE, the damn image still has crippled Blue.

Anyone have an inkling what happened to Blue? If so, how to get it back to normal?

Todday before transferring the VOBs to AVI via DGIndex, I added ConvertToRGB32(matrix="Rec601"). Here's an Avisynth histogram of frame 17113 with RGB32-REC301 (16-235).


This cap is a "Levels" histogram via AviSynth/DGIndex straight from the VOB, no AVI involved.


This cap is a "Levels" histogram via AviSynth from the AVI still sitting in YV12 before VirtualDub ever sees it. I'd post another cap of the RGB32 (non "Rec601" version), but both RGB version histograms look exactly alike.

[sanlyn]

Okay, gang (?), Blue is partially solved by nudging up the U channel while still importing the VOBs with DGindex. I hate YUV color correction, it always leaves you with a lot of single-color RGB tweaking to do. Looks better, but Blue is still untidy at the low end. Chow time.