Capture and device settings after first capture?

[tjmcdoug]

I captured my first VHS tape and wanted to make sure I have things set up correctly before continuing on with the remainder of all of the tapes. The workflow is a JVC SR-MV40 VCR (TBC on) to a CMD-1500 TBC to a Pinnacle 510-USB. S-video for everything. I used VirtualDub to capture (all default settings except audio set to uncompressed PCM 48KHz, video set to Huffyuv, 720x480, YUY2).

Some questions (associated with the clips):

1. "Wash" - the beginning of the clip is incredibly bright/washed out - I believe this is something that can't be corrected at the capture stage and should be addressed later, right? Considering the sudden jump to normal colors, it appears it was a camera problem? Additionally, there is some sound distortion during the jump from washed out to normal colors - I imagine this is also addressed later and not during capture?

2. "Dark" - similarly, the darkness here should also be addressed later, correct? This clip has similar sound issues as the "Wash" clip.

3. "Outdoors" - does this clip indicate that there are problems with any of my settings or am I good to continue on with the next tape?

[msgohan]

When you say "sound distortion" & "sound issues" I assume you're referring to the half-second noise that happens when the new recording starts. (There is a tell-tale rainbow pattern on a few frames at this point in each video, confirming that this is indeed a "scene cut".) Why even worry about it?

The lowest level in your samples is Y=16. All of your samples have black crush, and this level clipping at 16 makes it unrecoverable post-capture. I don't know whether this is a limitation of the Pinnacle 510 USB. The ATI 600 USB has this problem. You should raise the Brightness level during capture, at any rate. You will probably also have to lower Contrast at the same time, to keep whites in-range. See the VirtualDub Settings thread; the Histogram section.

Something in your playback/capture chain is over-sharpening, unless this tape is not a camera original.

[ginopilotino]

Quote:

Originally Posted by tjmcdoug

I captured my first VHS tape and wanted to make sure I have things set up correctly before continuing on with the remainder of all of the tapes. The workflow is a JVC SR-MV40 VCR (TBC on) to a CMD-1500 TBC to a Pinnacle 510-USB. S-video for everything. I used VirtualDub to capture (all default settings except audio set to uncompressed PCM 48KHz, video set to Huffyuv, 720x480, YUY2).

Is CMD-1500 an AVT-8710 green clone?

[msgohan]

No. It's a standards converter with audio in/out and the only controls being NTSC/PAL output switch & horizontal positioning. The AVT-8710 is completely different and has (weak) proc amp controls.

[ginopilotino]

Quote:

Originally Posted by msgohan

No. It's a standards converter with audio in/out and the only controls being NTSC/PAL output switch & horizontal positioning. The AVT-8710 is completely different and has (weak) proc amp controls.

How does it behave as TBC ? I'm not an expert but I can see some problems right and down.

[lordsmurf]

All I see are excellent captures.

All of the issues concerned about, being mentioned here, are native to the tape itself. What you're seeing is typical home-shot video.

Be sure the VCR is set properly. The oversharpening is probably R3.
- Calibration OFF
- R3 OFF
- Picture mode NORM/AUTO
- TBC ON

Like other devices, the CMD-1500 was a long-production device with multiple variations, with both names and model numbers shared by multiple entities. This specific unit being used by tjmcdoug serves as TBC. So don't everybody run out and try to get a CMD-1500, because odds are it'll be the wrong unit, and you'll have wasted money on a crappy hardware PAL/NTSC conversion box.

[tjmcdoug]

Thanks for the response! I'll take a look at the R3 setting.

What about the audio levels? Elsewhere you mentioned using Crossbar Thing to adjust audio input to 50% values (-7.5db) but I still haven't seen where to adjust the level in the Crossbar Thing (as mentioned in the other topic).

[sanlyn]

Quote:

Originally Posted by tjmcdoug

1. "Wash" - the beginning of the clip is incredibly bright/washed out - I believe this is something that can't be corrected at the capture stage and should be addressed later, right?

In this case the washout can't be corrected later because the bright end has no data to correct. Bright data has been badly clipped (destroyed), apparently in-camera. A histogram of one of the waked out frames demonstrates the clipping:

Below is frame 0 from "Wash.avi". Black borders have been cropped off to prevent them from affecting the histogram. Superimposed onto the frame is a numerical readout of various luma and chroma values from Avisynth's ColorYUV(Analyze=true)" function. To the right of the unedited frame is a YUV histogram that illustrates the luminance wash-out. In the histogram, luminance is shown as the white bar in the top panel -- the colored side borders lie on either side of the y=16-235 legal range. Data that lies inside the shaded borders is within the y=16-235. Data that falls into the shaded borders on either side will be clipped when YUV is expanded in RGB display (y=16-235 will expand to RGB 0-255 for display, so if the original YUV data extends beyond 16-235, RGB has no choice but to clip or distort the illegal data). Often, data that has crept into the shaded borders can be corrected with Avisynth controls in YUV before RGB conversion. Data that falls outside of the panels altogether and off the histogram would be irreparably clipped. Dark data is at the left side, bright data is at the right.

In the histogram below, notice the high thin white "spike" at the right-hand bright side of the top band. This is a sign of data clipped with a sharp falloff -- apparently an in-camera glitch compressed bright values into a narrow, yellowish=white blob with no detail. If there is no detail, there is nothing to correct.

Also, take note of the bricks and shadow detail in the upper left corner, which was not destroyed.


Below, frame 200 from the same "Wash.avi" with exposure looking fairly normal. Black borders have been cropped off to prevent them from affecting the histogram. Look at the loss of shadow detail in the upper left corner; part of it has turned black with no detail. The hard white spike at the left side of the histogram shows data compressed into a narrow spike and clipped at y=16. Also, the numeric readout shows that darkest ("minimum") Y value is 16. There is no data below that point that can be recovered. The numeric readout also indicates that the maximum "Y" luminance value is 227. This is acceptable, although if you heightened the bright end just a little the snow in the image would look more brilliant. But it looks bright enough already, although it has a mild but visible red tint.

Quote:

Originally Posted by tjmcdoug

2. "Dark" - similarly, the darkness here should also be addressed later, correct? This clip has similar sound issues as the "Wash" clip.

There isn't much that you can address here. Below, frame 200 of "Dark.avi" with black borders removed to prevent them from affecting the histogram. Again, notice at the left-hand side of the histogram that data stops at the white spike at the y=16 border, and the Analyzer readout shows that 16 is the darkest value. As for brights, most data stops at the equivalent of RGB 64 or so, which is pretty dark, and there's just a hint of midrange detail.


Below, see what happens if you try to brighten or recover clipped data. All that remain areis noise and distortion -- illustrating that "clipped" and "destroyed" are the same thing.

Quote:

Originally Posted by tjmcdoug

3. "Outdoors" - does this clip indicate that there are problems with any of my settings or am I good to continue on with the next tape?

Below, look at the original frame 30 in the beginning of the "Outdoors" shot, with black borders removed to prevent them from affecting the histogram. The exposure isn't too bad, but black levels are a bit low and the overall image has a dim look, especially around skin shadows. Those shadows look rather dense and unnatural, but at least levels have been raised enough during capture to prevent a sharp cutoff at y=16. The brights extend at the right out to y=228, but the they look overly bright next to all the darker stuff because of the suppressed midrange. But most of this can be fixed later.


Below, look at is frame 210 from "Outdoors.avi" with black borders removed to prevent them from affecting the histogram. Notice how the camera's autogain has darkened the entire image. Clipped darks at y=16 means you have an abrupt cutoff of shadow detail in the trees that you can't recover. The bigger problem is the way the image is darkened by your camera's autogain when the bright driveway enters the frame, suppressing the bright end toward the left-hand darks.




Above, frame 210 after an Avisynth filter has been applied to even out and extend the midrange and brights to look more natural, as well as revealing at least a little more of the tree detail. AS stated earlier, any detail below y=16 withn this capture setup won't be recovered. But overall the image looks mmore pleasing and not as grim. The two filters used were AutoAdjust.dll and Avisynth's "Levels" function, plus a little aWarpSharp2 to smooth away the red color bleed on edges.

Below, the same frame 200 from "Outdoors" as earlier, borders removed, but after the above filters have been applied to the starting frames of this shot. This part of the shot wasn't as badly affected by the cameras horrible autogain feature, so it required less levels correction. Sometimes AutoAdjust does a decent job of smoothing out luminance pumps from auto cameras. If you had corrected the later, darker frames manually, these starting frames would be too bright. However, sometimes auto filters can make the situation worse. It depends on how much damage the camera's "features" inflicted.

Quote:

Originally Posted by lordsmurf

Be sure the VCR is set properly. The oversharpening is probably R3.
- Calibration OFF
- R3 OFF
- Picture mode NORM/AUTO
- TBC ON

Looks OK, exccept that in my experience NORm/AUTO takes some care, includes image softening, often motion smearing and some ghosting from internal processing. On many tapes NORM/AUTO can look out of focus. EDIT mode defeats that processing and is designed for dubbing and capture, according to JVC manuals I've read. R3 is very primitive digital denoising that inflicts noise of its own.

Quote:

Originally Posted by msgohan

level clipping at 16 makes it unrecoverable post-capture. I don't know whether this is a limitation of the Pinnacle 510 USB. The ATI 600 USB has this problem. You should raise the Brightness level during capture, at any rate. You will probably also have to lower Contrast at the same time, to keep whites in-range. See the VirtualDub Settings thread; the Histogram section.

The Pinnacle, ATI 600 USB, and the Hauppauge USB-Live all clip at y=16. Sometimes the proc amp controls will help, but when it happens before the signal leaves the capture device it takes an external proc amp for full correction.

As for the Crossbar Thing, I'm afraid I've never had to use it.

[lordsmurf]

As a reminder, never assume the source tapes have perfect values. Home camcorder tapes have terrible color, contrast, etc. So never assume capture cards are "destroying" values. Camcorder CCD/CMOS can be just as guilty.

I was unaware that aWarpSharp2() could be used with interlaced sources. Can you share the line of script?

JVC never addressed digital capture in manuals, only vague references to "dubbing" (which had varied definitions). And even that can be (and often was) argued. I don't trust JVC's advice on it anymore than I do that R3, Calibration or B.E.S.T. are wise to use. Yes, it does have some processing effects, but that's also the entire point of owning a JVC deck, as the net effect is an improvement in tape quality, especially on the chroma NR. Using EDIT just makes your work harder post-capture, and often gives same end results post-filtering. Going back into 90s/2000s, software filtering wasn't even possible for some aspects, it's mostly a 2010s trend to deride JVC picture modes.

Some of you are starting to confuse me with all this talk of "clipping blacks". Precisely how? NTSC VHS YCrCb (actually YPrPb?) is 15/16-235 with 7.5 IRE/pedestal. PAL/NTSC-J is 16-235 with 0 IRE (sometimes effectively 0-235). Clipping only enters the equation with converting colorspaces between 0-255 and 16-235, data is truncated. But when the source VHS is capture to YUV with 16-235, where is this clipping that you refer to? Also, VHS "black" was never black, always charcoal gray.

[josem84]

Quote:

Originally Posted by lordsmurf

... But when the source VHS is capture to YUV with 16-235, where is this clipping that you refer to? Also, VHS "black" was never black, always charcoal gray.

Clipping could still occur if you don't adjust your whites and blacks within the range pre-capture. Once you convert it to RGB, the data is lost and can't be recovered in post.

[sanlyn]

Quote:

Originally Posted by lordsmurf

I was unaware that aWarpSharp2() could be used with interlaced sources. Can you share the line of script?

In this case I used:

SeparateFields()
ChromaShift(C=-2)
MergeChroma(aWarpSharp2(depth=20))
Weave()

Used in some Avisynth plugins. For example, as with MCTemporalDenoise.avsi line 675 if its interlace parameter is set to True:

Quote:

### INPUT
i = (interlaced==true) ? i.separatefields() : i

Quote:

Originally Posted by lordsmurf

where is this clipping that you refer to?

You can see it in histograms at the y=16 border and in images, and you can see the same thing when measuring in RGB. It has been noted in other posts here and in other forums, reported by other readers such as jagabo and others at videohelp. I recall some Elgato devices that do the same thing. Often you can work around it in post-processing in YUV, but you still lose anything below y=16. Data that extends into the border below y=16 can often be recovered in YUV, but not if data stops at 16.

Image below is from one of several digitalfaq threads that shows the issue. Note in the image that data stops at y=16. At y=235 and higher, data keeps going and some highlight detail could be recovered:



The above is from post #2 in the thread at http://www.digitalfaq.com/forum/vide...html#post54977.


Below, another image from, an earlier thread. Note that the Analyze figures show a minimum dark level of 16:


The histogram shows YUV data stops at y=16, and there is no way in RGB to recover any more data below RGB=0.:

[tjmcdoug]

Thanks for the detailed analysis sanlyn. My understanding of your comments is that I can't avoid the clipping issues/washout/darkness regardless of capture settings because of the source material. So I should be good to start capturing more tapes without changing anything during the capture itself and later I can deal with anything that can actually be corrected (which does not include the issues I noted here). My main goal here is to have the best settings possible at capture and to worry about any corrections that could be made (or, in this case, cannot be made) later.

[msgohan]

Quote:

Originally Posted by tjmcdoug

Thanks for the detailed analysis sanlyn. My understanding of your comments is that I can't avoid the clipping issues/washout/darkness regardless of capture settings because of the source material.

No. Lordsmurf is suggesting that. Sanlyn and I are telling you this:

Quote:

Originally Posted by msgohan

You should raise the Brightness level during capture, at any rate. You will probably also have to lower Contrast at the same time, to keep whites in-range. See the VirtualDub Settings thread; the Histogram section.

What Sanlyn did say is that trying to post-process to raise the black levels out of crushing won't help.

[lordsmurf]

Quote:

Originally Posted by josem84

Clipping could still occur if you don't adjust your whites and blacks within the range pre-capture.

How?

Again, the range of NTSC VHS (meaning the data actually analog-recorded onto tape) is 16-235 (digital<>analog equivalent). So where would 0-15 and/or 236-255 data come from? Yes, I realize that digital<>analog creates rounding errors, so 15-16 and 235-240 happens, but not much more drastically than that. It even assumes the tape had a full 16-235 worth of data, which is often does not (again, no "true black", but dark charcoals, and white is equally rare unless overexposed).

Quote:

Once you convert it to RGB, the data is lost and can't be recovered in post.

Why?

Where is it being converted RGB?

If you capture to YUV (usually YUY2 or UYVY), colorspace conversion should not be taking place.

The only possible explanations would be
- 1. if you're capturing wrong: wrong settings, wrong software, not Huffyuv as YUV.
- 2. the capture card has RGB capture colorspace
- 3. that a YUV/YCrCb chipset is somehow internally converting from YUV to RGB (or worse, a non-compliant bastard like 0-235), before software can access the data.

But the TVP5150 is YCrCb native chips, and based off reading the chip isn't powerful enough to convert YUV>RGB if it wanted to. Maybe if extra RAM buffers were inside, possibly even an actual CPU/GPU, but at greater cost and size than this sub-$100 USB stick would allow.

BTW, I know that ATI AIW are native YUY2 chips as well.

So, again ... where is the colorspace conversion coming from?

Quote:

Originally Posted by sanlyn

The histogram shows YUV data stops at y=16, and there is no way in RGB to recover any more data below RGB=0.:

Well, yeah. Why would you expect YUV 16-235 to show data beyond 16-235?

Quote:

Originally Posted by sanlyn

These charts confuse me. For one, it's not the same. It sort of looks the same, but the values don't match. Where are those from? Am I to assume one is a VirtualDub capture histogram, and the other is a post-capture Avisynth histogram?

I do see where you're saying 0-15 disappears. But my question is where those come from. Why is a VHS tape showing a 0-15 range value? Something does not add up here. YUV is 16-235, VHS is a YUV, VHS is essentially 16-235. So showing a 0-235 doesn't make sense.

Are you sure the histogram is even accurate?

Are you suggesting the card itself natively outputs 0-235?

We touched on this topic a couple years ago, but never came to an understanding: http://www.digitalfaq.com/forum/vide...html#post52152
And http://www.digitalfaq.com/forum/vide...html#post44541
And http://www.digitalfaq.com/forum/vide...html#post42215
And http://www.digitalfaq.com/forum/vide...html#post51319
Not those specific posts, just posts around those that are linked.

If all of this is true, and it does 0-235 (clipping/truncating to 16-235) are you suggesting this can be corrected with VirtualDub levels at capture? Or only by external proc amp? And at exactly which step is the 0-15 disappearing? Inside the card prior to output? VirtualDub is doing the truncation?

And even if true, why not use the VirtualDub capture option to extend 0-15 black points?

Understanding colorspace (and IRE) has never been a main strength of mine, though I do have a decent grasp on it. Remember than my main capture cards are ATI AIW. And I generally deal with such horrible videos that clipping cold be an improvement! (A jest of course, but you get the idea.)

It's time we figured this out, and can agree on what's happening.

[msgohan]

I'll post actual answers/thoughts when I have some time. This was supposed to be a quick post, and it's already ballooning out of control.

Here are some old test captures I have sitting on my hard drives. These were actually to test bright clipping of over-exposed tapes, but an in-camera fade-to-black shows some extreme darks that the ATI 600 doesn't convey.

Although the RCA full-size VHS camcorder that recorded this and the rest of my family's tapes was sold in North America, it uses NTSC-J levels = 0 IRE black. Something to consider when someone hands you a tape or posts a sample here and says it was recorded on NA equipment. That doesn't mean the engineers actually bothered to implement NA levels.

The attached ZIP files include Avisynth scripts with tweaks to levels-match and line up the samples. Unless commented out, they require my AlignExplode function for scopes & alignment, which in turn requires the VideoScope plugin DLL.

The VC500 capture was done on Win7 and ***I used its pack-in program to set the Proc Amp (because it's the only way to disable the sharpening control on Win7)***. Unfortunately, doing this causes the VC500 to clip Y<16 too.

I don't think I ever bothered to go back and do a "perfect levels" capture of this tape after acquiring my Studio 1 analog proc amp. I think I'll do that, and show the tape's actual levels on my analog waveform monitor.

Having said all that, the gist is this:

• ATI 600 clips at both ends
• DMR-ES25 clips over-brights; retains all darks
• VC500 ***this specific capture*** clips Y<16; retains brights (on XP, and with normal Win7 adjustments, both ends are intact)

Cropped the empty side of the scopes on these two PNGs to fit the forum.
CLIP1 Bloom Test - ATI 600 F111.png

You must be logged in to view this content; either login or register for the forum. The attached screen shots, before/after images, photos and graphics are created/posted for the benefit of site members. And you are invited to join our digital media community.

With further level-boosting, the house is still faintly visible even when the fade-to-black has apparently completed. This is the last frame before the scene-cut.
CLIP1 Bloom Test - DMR-ES25 F111.png

You must be logged in to view this content; either login or register for the forum. The attached screen shots, before/after images, photos and graphics are created/posted for the benefit of site members. And you are invited to join our digital media community.

[sanlyn]

Quote:

Originally Posted by lordsmurf

Again, the range of NTSC VHS (meaning the data actually analog-recorded onto tape) is 16-235 (digital<>analog equivalent). So where would 0-15 and/or 236-255 data come from? Yes, I realize that digital<>analog creates rounding errors, so 15-16 and 235-240 happens, but not much more drastically than that. It even assumes the tape had a full 16-235 worth of data, which is often does not (again, no "true black", but dark charcoals, and white is equally rare unless overexposed).

Why?

Where is it being converted RGB?

The original YUV capture is converted to RGB32 in VirtualDub when the sample was saved with VDub's "full processing mode" turned on.

Quote:

Originally Posted by lordsmurf

If you capture to YUV (usually YUY2 or UYVY), colorspace conversion should not be taking place.

The only possible explanations would be
- 1. if you're capturing wrong: wrong settings, wrong software, not Huffyuv as YUV.
- 2. the capture card has RGB capture colorspace
- 3. that a YUV/YCrCb chipset is somehow internally converting from YUV to RGB (or worse, a non-compliant bastard like 0-235), before software can access the data.

See the previous answer. An added complication occurs when you edit a YUY2 sample in VirtualDub and specify "fast recompress" using huffyuv. Even though you specify YUY2 for output, huffyuv will recompress to RGB. The best way to save an edited sample using the original colorspace is to specify "direct stream copy" for output (how many times has this been repeated??). The other way to preserve the original colorspace is to specify "fast recompress", select YUY2 (or whatever) and use a codec other than huffyuv (such as Lagarith or ut codec) if you want to avoid RGB.

Quote:

Originally Posted by lordsmurf

Well, yeah. Why would you expect YUV 16-235 to show data beyond 16-235?

It happens all the time. There's nothing that says a YUV colorspace can't contain a spectrum wider than 16-235. How about tape players and DVD recorders that pump contrast and oversaturate certain colors (old Sony's liked to make blue look like neon, cheap Panasonics and many Mitsubishi's like to make reds jump off the screen. Average viewers find these effects to be very impressive. They say it looks "great").

Quote:

Originally Posted by lordsmurf

These charts confuse me. For one, it's not the same. It sort of looks the same, but the values don't match. Where are those from? Am I to assume one is a VirtualDub capture histogram, and the other is a post-capture Avisynth histogram?

You know the difference between an Avisynth YUV levels histogram and VirtualDub's ColorTools RGB histogram. Both histograms were made post-capture from the same frame being discussed. And you know that RGB expands YUV at the dark and bright ends (YUV 16 becomes RGB 0, YUV 235 becomes RGB 255), so both histograms can't possibly look alike at the extremes. The YUV chart shows luma abruptly stopping at y=16. The RGB histogram shows RGB data abruptly slamming into the left-hand wall of the chart and stopping there. In both cases there is zero usable data beyond the left-hand stopping point.

Quote:

Originally Posted by lordsmurf

I do see where you're saying 0-15 disappears. But my question is where those come from. Why is a VHS tape showing a 0-15 range value? Something does not add up here. YUV is 16-235, VHS is a YUV, VHS is essentially 16-235. So showing a 0-235 doesn't make sense.

If that were true during capture, then advice about using proc amps and level controls for capture is unnecessary. If nothing can exist beyond 16-235, what are capture-time level controls for?

Quote:

Originally Posted by lordsmurf

Are you suggesting the card itself natively outputs 0-235?

Mine do, if 0-235 is what exists in the input signal.

Quote:

Originally Posted by lordsmurf

If all of this is true, and it does 0-235 (clipping/truncating to 16-235) are you suggesting this can be corrected with VirtualDub levels at capture? Or only by external proc amp? And at exactly which step is the 0-15 disappearing? Inside the card prior to output? VirtualDub is doing the truncation?

Wait a sec. I trust that you are aware of being able to use histograms to visualize what's happening during capture, or even the StudioOne proc amps' LED levels meter, to check signal levels. You say you use these measurements and devices during capture, but why are you using them? If you don't trust histograms there is no reason to recommend using them.

In a previous thread somewhere about 4 or 5 years ago an ATI 600 was used to capture a darkish VHS signal that clipped badly at y=16. When the input brightness was raised several points brighter, it only accomplished raising the clipping point from y=16 to about y=30. Perhaps an ATI 600 with another version of its processor would behave differently. Whether an external proc amp would be required or whether it would be OK to use VDub's internal proc amp hookup, I haven't tested for it. From the samples seen in this thread, brighter images didn't show black clipping, but darker images did.

Quote:

Originally Posted by lordsmurf

And even if true, why not use the VirtualDub capture option to extend 0-15 black points?

I invite people to try it and see. It certainly works with my capture cards -- although mine don't clip at y=16 but it's patently obvious how raising brightness for out-of-spec signals increases the amount of black data that doesn't fall back into the clipping zone of the histogram.

Quote:

Originally Posted by lordsmurf

It's time we figured this out, and can agree on what's happening.

I'm all for it. I don't happen to have a device that clips at y=16.

[tjmcdoug]

Thanks for the clarification msgohan. All of the clips I initially posted were from a single VHS tape. With the combination of some extremely bright segments and some extremely dark segments, does that mean I would need to have different settings for each segment of the tape? And different settings for each tape? Approximately how much brighter should I make the signal considering how dark some of the clips are? I realize you can't give an exact value but the levels go from -128 to +127 for both brightness and contrast. Are we talking about +10, +50, +100 for brightness? And is there any rule or guidance on how much to reduce contrast based on the increase in brightness?

[billct97]

Hi All;

It's been 2 years of inactivity but I'm back and ready to reboot my VHS broadcast TV conversion project. This thread and so many others are so very helpful and I've (re)learned a lot.

One really basic question I have is how to get a histogram during capture? I have no problem using ColorYUV(Analyze=true) or Histogram("levels") for avisynth POST capture and even fired up ColorTools histogram from Virtual Dub but only on post capture. I also see the ugly blue (luma only?) histogram in Virtual Dub. Am I missing something obvious or is there a way to get a ColorYUV histogram so I can properly adjust the TBC-3000 for capture?

Thanks,
Bill (and yes I'm using Vdub 1.9.11, have calibrated my monitor this time around)
I'll post the whole workflow later when I'm back at home and can get the specifics.

[Sergei316]

Quote:

Originally Posted by billct97

Hi All;


One really basic question I have is how to get a histogram during capture? I have no problem using ColorYUV(Analyze=true) or Histogram("levels") for avisynth POST capture and even fired up ColorTools histogram from Virtual Dub but only on post capture. I also see the ugly blue (luma only?) histogram in Virtual Dub. Am I missing something obvious or is there a way to get a ColorYUV histogram so I can properly adjust the TBC-3000 for capture?

I have been working on a solution to use a waveform/histogram monitoring during capturing over the past several months.

Using the VDub histogram works well to "CHECK" your levels. However, i have been unable to have the VDUB Histogram run during capture. I usually have the Video, timing Graph and audio levels showing during capture. But when i turn on the histogram in Vdub the video balnks out. I have three XP machines for capture and they ALL react the same way.

I have tried several older hardware based waveform/histogram equipment to check levels before capturing but have found that most of what I have obtained is not calibrated correctly or they were outright junk and do not work.

Currently using several different software based waveform/histogram solutions. The biggest drawback to this is trying to get the software to run on the same XP machine as the one you are capturing on. I have been successful using a second and third computer to just run the waveform/histogram programs.

I have atatched a PDF with an example software histogram/waveform workflows. The adjustments I make on the PA100 (great tool) allow me to see the changes on the different software that I use. I usually then verify levels with the Vdub histogram.

I would really like to get the software waveform/histogram software to run on the same PC as Vdub. I think it uses to many resources of the system to make this a viable option.

Hope this helps.

[billct97]

That is an interesting approach and I appreciate that you shared this. Anyone else? How do you check histogram levels on capture to ensure you are staying in between 16-235? Or does everyone capture in Virtual Dub using the ugly greyish blue histogram and if so is that 0-255 or 16-235?