Amazing discovery in capture resolutions (IMHO)

[SatStorm]

Huge difference...

I see daily how lucky we the PAL users are...

[BrainStorm69]

This is the sort of thread that really gets me excited! I can't wait to try some VHS capturing tests myself this weekend. Nice pics fmctm1sw! What I'd really like to see is a comparison between a VHS image captured at 368x480 and cropped down 1/2 D1 and the same VHS image captured at D1 and rendered down to 1/2 D1 using TMPGenc.

Great thread so far!

[trevlac]

@SatStorm

#15 "Okay, I'll shut up. Some fellas have to keep their tongues flappin' but not me. I was brought up right. My pa used to tell me to shut up and I'd shut up. I wouldn't say nothin'. One time darn near starved to death. WOULDN'T TELL HIM I WAS HUNGRY!!"



@Anyone Who thinks a test pattern has any value

For those of us who like to watch test patterns, here is a full res capture. The image was recorded via s-video from dvd in standard play vhs mode no vcr filters (edit mode). I then captured it back via s-video on my bt878 card. The purpose of this test was to show how low vhs resolution can be. It actually varies depending on the machine. Between 260 and 360 pixel width. The height is always 480 for NTSC. This clip shows my machine does about 320.

I determine 320 by looking at the wedge that is vertical. At the point where you can not see the lines, is the measure. I call it 240 but that may be generous. To go to a 4:3 wide picture measurement, you must multiply 240 by 1.333 = 320. I give that number because most people here talk in terms of 4:3 frame width = resolution.

http://pics.trevlac.us/img.htm?VHS712.png


@BrainStorm69

That would be an interesting test. I'm glad you did not mention 352 cap on your aver. Due to the bt vertical filter, you would lose resolution even from vhs. You can compare my <368 type cap and my vhs cap. The VHS cap has better height wise resolution. Close to the full 480. If you did a post cap resize across the width, it would not effect the height resolution.

[BrainStorm69]

@trevlac -

Exactly, so the question is whether rendering down to 1/2D1 looks worse or the same (from a width perspective) as capturing at 368 and just cropping.

I'm pretty new to this, and I'm not sure what TMPGenc does to the video to render it down, so I don't know if theoretically they should look the same, or if the rendered down video should look a little worse.

[lordsmurf]

As far as I'm concerned, this is just another reason to boycott the BT/CX chipset. That's terrible.

[SatStorm]

It is not a chipset fault, it is a driver fault.
BT/CX chipset "activates" a filter from a point and beyond, and the unofficially drivers we all using with those chipsets can't handle it correct.

[racerxnet]

If the drivers are open source you could rewrite the driver to your specific liking. You could also move the filter point to what ever your little heart desires, compile and run.

To Smurf:

Why boycott the chipset without understanding the card and how it functions? This would apply to all chipsets as well and the fun in taking apart the code and how the functions (algorithm) are applied. Is this to technical for you to understand? The "I like this card" and "I don't like this card" without the technical expertise to back it up does nobody any good. I could say "I don't like my C++ class" equating to all not to take it (I enjoy writing code). It's the challenge to understand that drives us.

To Trevlac:

I've been following the thread at Doom regarding the BX chipset/VCR capture and have to wonder if the VCR has been calibrated, (tape path, Head phase, pre amp, and so on) which has a dramatic effect on the recorded results.The tip penetration from the ferrite tips also play an important roll in picture clarity as well. Though your bandwidth seems quite good using a standard VHS tape. I have to wonder how JVC claims to get svhs results without the added media to the tape for the added bandwidth. Without this where does the added picture information reside in the tape structure? The VCR can only encode so much information helically based on the tape media applied.

If your VCR is capable of recording in SVHS get a SVHS tape and record your test data and play back the results. I'd like to see what your bandwidth is regarding this.

[vhelp]

TGIF everyone :P

@ brainStorm69,

I think that there is something missing here. Like the "link" hehe..

When you capture (assuming VHS) there are purposes to capping at higher
resolutions. One reason, is so that when you resize down (assuming for
x/CVD or xSVCD) you would benefit from this resizing. THE TRICK (or technique) is, you resize from a higher resolution (ie, 720) this is known
as the "smart" way. At least to me it is. I cap ta 720, and let TMPG
resizing down to 352 (though I don't really use 352 anymores) The advantange
of this technique, is that the image is not distorted (imo) and does not get
warped out of phase (or shaprness) (to my eyes anyways) Here is a for instance
for those that don't quite understand (or believe) :P ... say you capped at
352, then added 8pixel boarders (can be all around or left/right only) and
then you brought it inside tmpg, and encoded as 352 x 480. What you would
get (at least in my experience) is larger boarders (sometimes double) and
this is what I was refering to as "out of phase" or "warped" etc.
But, if you capped at 720, then added in your 8pixel boarders, and then
finally encoded inside TMPG, you would get perfect sync'ed boarders (ie, 8pixels)
.
.
So, it's wise to know these kinds of techniques. Now, IMO, the above flaw
in resizing w/ 8pixel boarders is just example, and also that one should
be aware of in future dealings w/ resizing. Sure there are numerous resize
filters out their, and I'm sure many are great, but this has ben my technique
when dealing w/ this particular issue (above)


@ all,

It is my gut fealing, that over the years, where I've heard (read) people's
preference to cap at 352 vs. 720, or 720 vs. 352, when talking about VHS as
the source, that THEIR poor experience w/ 352 was no doubt the result
of the actual cap card being used that was at fault here, at those
lower resolutions (ie, 352) but that when those that argued, "no.." "..you
cap at 720" were correct, but only because their cap card just so happend
to be in tune w/ this resolution, while those capping at 352's were not
in tune. Hope that was understood. So, really.., noboday was at fault in
their acusations 352 vs. 720 !! It was the cap card YOU had at the time.
Well, I better say, capture card AND/OR driver state. Coiensidence ??? :P
Well, but NOW THAT YOU KNOW.. there you go.

The best way to capture and encode w/ "meets" or "exceeds" results, is to
test your scenarios and note your findings for future reference. In the
mean time, I think we should come up w/ a standard "test platform" for various
types of sources (ie, VHS; Cable; Satellite etc) and use accordingly to our
goal at hand. But a test should be competed for a user's card/device/medium
before any goals are set forth. If they want best results, that is :P

-vhelp

[lordsmurf]

It is not a chipset fault, it is a driver fault.
BT/CX chipset "activates" a filter from a point and beyond, and the unofficially drivers we all using with those chipsets can't handle it correct.

Well, then, nevermind. But are you sure it's just the drivers, and not faulty chips?

And then again, that begs the questions, why can't anybody write good drivers? Especially for their own cards?

[vhelp]

@ lordsmurf,

And then again, that begs the questions, why can't anybody write good drivers? Especially for their own cards?

Yeah.., how about, "conspericy" - - - (spelling)
-vhelp

[BrainStorm69]

@vhelp...

That's very interesting. Do you know why you would get borders that are double the 8 pixels when you resize from 368x480 to 352x480? Seems counterintuitive. I would think, though, now that you mention it, capping at 368 and cropping of 8 pixels on each side would mess with the aspect ratio a bit.

I have been doing what you call the smart way...i.e., capping at 720x480 and resiziing down to 352x480. I was just wondering if that gives sharper results than capping at 368 and cropping.

I'll just have to try some experiments, I guess. Get some good ole' empirical data

[fmctm1sw]

I saw someone mention earlier about how a resized D1 capture would look resized to 352. I captured at 640x480, 704x480, and 720x480 with virtualdub uncompressed. I resized all to 352x480 (lanczos 3) are herre is the 704x480 result. The other look much the same to me. If you want to see other PM me:

[vhelp]

@ brainstorm69,

If you capture at 368, then the "smart" way would be to crop 4 pixels from
the left and right side (8 in total) to equal 352. But, actually, you don't
want to crop if you can help it, cause it usually requires resizing, and that's
where the hit is in quality. Mind you, I'm speaking w/in vdubs relm.

If your source is widescreen, then you don't have too much to worry about.
But, for fullscreen, you do. And, you have to be careful. The more sensitive
your source originality (ie, VHS) the more attention/careful you have to be.
.
.
So, if you cap @ 368, then first observe your capture cards left/right side
areas. See if there is some black to it. Usually 4 pixels anyways. But, if it
is flush.. if it is flush, then remember that there is some room for
overscan 4 to 8 pixels (or more) on each side.. so..

* cap @ 368
* crop 4 pixels off left and right sides (total 8 pixels) = 352 x 480
* frameserve into TMPG.. encode @ 352 x 480

Remember not to do anything else to this source else you'll add to the end
result. I still think that you should add in a resize here. ie,

* after cropping above, you'll want to resize ..
* from 352 - - w/ a resize[704x480]
* then frameserve into TMPG and encode @ 352 (let TMPG resize down w/
...it's built-in interpolation routine.


If your card does a better job at 704 ...

* cap @ 704
* resize[704x480, 720x480]
* frameserve into TMPG.. encode @ 720 x 480

This will put 8 pixels of black on each side (total of 16 pixels) making the
total size of 720.

Note, there's no such thing as "adding extra sharpness" (other than using a
sharpen filter, which is totally different) but rather, you maintain the level
of original sharpens.. hence aspect ratio.

FWIW.. I don't know just how much different 368 vs. 352 is, so I can't say
for sure what will work in a given system, but the above should work fine.

-vhelp

[fmctm1sw]

This is a (old) VHS tape cap. One capped right at 352x480, the other capped at 368x480 and lanczos3 resized to 352x480:

[lordsmurf]

By what method are you providing screen caps? I want to pull in some ATI ones at various resolutions, but want to retain the exact method for acquiring the caps.

[fmctm1sw]

By what method are you providing screen caps? I want to pull in some ATI ones at various resolutions, but want to retain the exact method for acquiring the caps.

Poor man's method I'm afraid... I use virtualdub and save the image sequence as BMPs. Then I use MSPaint (I know...) and paste them next to each other. I save that as a new BMP. Then I use TMPG to make a JPG. I think I had to go with about 79% to keep it under 50kb...

edit: And if memory serves me, I goofed with the Stooges cap and used huffyuv converted to YUY2 (best setting).... Th radar image was uncompressed RGB.

[lordsmurf]

By what method are you providing screen caps? I want to pull in some ATI ones at various resolutions, but want to retain the exact method for acquiring the caps.

Poor man's method I'm afraid... I use virtualdub and save the image sequence as BMPs. Then I use MSPaint (I know...) and paste them next to each other. I save that as a new BMP. Then I use TMPG to make a JPG. I think I had to go with about 79% to keep it under 50kb...

edit: And if memory serves me, I goofed with the Stooges cap and used huffyuv converted to YUY2 (best setting).... Th radar image was uncompressed RGB.

I'll do Vdub -> photoshop

[lordsmurf]

Look at this:
https://www.videohelp.com/forum/viewtopic.php?p=777078

This is my ATI AIW 7200 AGP vs my APEX DRX-9000

Notice the fine details in the Papa John's Pizza logo (and the words, Better Ingredients, Better Pizza). The ATI card is very sharp, and that's using MPEG-2 capture at 352x480.

It would be noise free if I had the groundloop isolator finished. The error just appeared in the past few weeks. Not really sure why. My old captures were noise free.

[fmctm1sw]

I see. Not quite as dramtic a difference as I saw in mine.

[FulciLives]

I need some help here ...

Now granted it is super late and I'm half falling asleep. So maybe this is MY fault.

But I don't "get it"

I have an AverTV Stereo PCI capture card (BT chipset) and when I capture it does some type of internal resize thing and I get NO BLACK border on the sides.

So if I capture at 368x480 and crop 8 from each side to get down to 352x480 then I can't see how I will NOT get an ASPECT RATIO eror.

If I resize from 368x460 to 352x480 using AviSynth and CCE (my choice of encoding) then don't I "loose" the benefit of capturing at 368x480 since I'm now using a software resize filter?

- John "FulciLives" Coleman

[fmctm1sw]

I need some help here ...

Now granted it is super late and I'm half falling asleep. So maybe this is MY fault.

But I don't "get it"

I have an AverTV Stereo PCI capture card (BT chipset) and when I capture it does some type of internal resize thing and I get NO BLACK border on the sides.

So if I capture at 368x480 and crop 8 from each side to get down to 352x480 then I can't see how I will NOT get an ASPECT RATIO eror.

If I resize from 368x460 to 352x480 using AviSynth and CCE (my choice of encoding) then don't I "loose" the benefit of capturing at 368x480 since I'm now using a software resize filter?

- John "FulciLives" Coleman

I cannot speak for the cropping 8 off each side idea, I havn't tried it yet. And I cannot speak for software resizing methods either. But, I do know this: With my setup, I obtain a clearer, more detailed image at 352x480 if I capture at a minimum 368x480 and resize to 352. I've tested this by capping at 640/704/720x480 and resizing too. It doesn't seem much different than the 368 to me....

[lordsmurf]

@fmctm1sw
You've got some source errors, just as much as resolution loss. There are scrolling distortions in your video images. Related?

Also, the 3 STOOGES images look to be sharpened. It has symptons of a digitally sharpened image. While it would be easy in Photoshop, I don't doubt your honesty. So look at the encoder that shrank from 720 to 352.

[fmctm1sw]

@fmctm1sw
You've got some source errors, just as much as resolution loss. There are scrolling distortions in your video images. Related?

Also, the 3 STOOGES images look to be sharpened. It has symptons of a digitally sharpened image. While it would be easy in Photoshop, I don't doubt your honesty. So look at the encoder that shrank from 720 to 352.

The scrolling distortion is symptomatic of channel 3. That's the bases' "information" channel. Whenever I capture it (rarely, but it has some good stuff for text comparison), I get those lines. Maybe it comes from a computer or something.

On my Stooges cap, no sharpening (honest).

Please help me understand (or see) these source errors and resolution losses. I used the "resize" filter in Virtualdub (Lanczos 3) to shrink the image from XXX to 352.

[lordsmurf]

The filter that resized may have an algorithm that sharpens or is similar to sharpening. A full resolution descale would not have those harsh edges and stray pixels I see.

[fmctm1sw]

I'll take a look and try some different resizing methods. Are you downloading the picture and using something to blow it up real big to look at it? I see the sharpening effect easily enough but stray pixels?

Edit: And I was kind of excited about the whole sharpening thing. I use the temporal smoother a lot and it has a tendancy to soften.

[lordsmurf]

I'll take a look and try some different resizing methods. Are you downloading the picture and using something to blow it up real big to look at it? .

Using a Nikon program.

[vhelp]

hi guys :P

When I mentioned my resizing method, I was not indicating any "external"
filtering for the resizing part. I was using vdub's built-in resizing. I use the
technique I laid out above (or other page) and I no "sooped up" or
artificial end result. I much rather have eaither a faint hint of blur or the
sources orginal sharpness (note, I did not say, "sharpend" :P )

I know this can be done in an AVS script, either using AddBoarders(x,x)
or built-in resizer, but I'm not a script guru yet. hehe..
.
.
And, as I have said earlier, there are a lot of resizing filters which (as lordsmurf
hinted) use various techniques to simulate better resizability.

I believe if you're going to resort to resizing, you mustn't taint the time-line.
Leave source as is, but utilize the great algorithem to acheave the resizing
results. Sharpness is good, but not if its artificia, as in Lanczos 3,
which seems to be the case to an extent. Heck, but if it does a good job,
and is not noticalble so much (don't show the newbie) then I would say that
the filter fmctm1sw used showed good results - Lanczos 3 but pics
don't show the whole picture (video that is) you don't see artifacts unless the
image is moving.. so I never judge 100% by pics, though they have their
place in discussions :P

@ fmctm1sw, the 3 stoogies looked nice in any case, fwiw.
-vhelp

[trevlac]

Exactly, so the question is whether rendering down to 1/2D1 looks worse or the same (from a width perspective) as capturing at 368 and just cropping.

I'm pretty new to this, and I'm not sure what TMPGenc does to the video to render it down, so I don't know if theoretically they should look the same, or if the rendered down video should look a little worse.

Well I can tell you what I think...based upon my own tests.
- Cap 352 is the worst (as we agree)
- Cap 720 resize 352 is much better
- Cap 368 crop to 352 is marginally the best

This is why:

Those EEs at Brooktree/Conexant know digital signal processing better than we think. Our software does not do as good of a resize as they do on the chip. The software uses less complex filters (fewer coefficients). The software also does not do 'odd' sizes well. Easy sizes are droping every 2nd, 3rd, 4th, etc pixel. For a 2/3 resize like svcd, the chip 1st interpolates up by 2 placing zero value pixels in the holding spots, filters, and then decimates down by 3.

At least that is my take.

@All

The drivers implement the filter, but I would call it a chip flaw. The reason for the filter is to avoid aliasing when you decimate more than 50%. This is a reasonable thing that needs to be done. The drivers are doing what the manufacturer recommends. Also, you can not change the coefficients (filter cutoff) much if at all. The chip does the work, the driver just gets a few choices.

Aspect Ratio

368 will throw your aspect off a bit. However, 720 will almost never give you the correct aspect ratio. This is because few things short of a dv capture type device capture the full digital frame. All cards/devices sample/capture a fixed number of 'pixels'. These are then resized to the size you asked. The fixed size is determined by how the driver is implemented. The BTwincap driver always caps 712 pixels for NTSC. If you ask for 720, it will resize from 712 and your aspect will be off. If you capture at 712 you would have to crop to 704 and resize to 352 if you wanted a 'very' proper aspect. If you cap at 368 and crop to 352, your aspect is not off by as much as you might think. And unless you understand what I've said, your aspect is probably a bit off.

Most BT/CX drivers seem to cap 688 pixels. ATI does 704. Of course this all depends upon the driver. To learn more, look at the following excellent guide.

http://www.arachnotron.nl/videocap/site/capture_area2.html

[trevlac]

The filter that resized may have an algorithm that sharpens or is similar to sharpening. A full resolution descale would not have those harsh edges and stray pixels I see.

That is exactly what it does. It's a bicubic with more agressive settings. (At least that's my understanding. I'll read the source code of Avisynth if you want me to, but it ain't easy to understand.)

The ATI has better internal filters than the BT. Smurf's 352 caps should be better. A BT 368 cap could be better than an ATI 352 cap, but this would only be the case for a source that has greater resolution. VHS does not. TV probably can contain the detail, but a given source may not. Also, if you wanted the detail, you would want to keep a larger frame size.

For the BT, 368 is nice because it does not mess with the vertical and you can crop to 352 without effecting the aspect much. Especially if you use the BTWincap driver.

Honestly, I've researched the hell out of this.

The easy way: Like Satstorm said: Cap at 704. Resize to 352. Nearest neighbor might actually be a good choice here, I'm not sure.

The hard way: Figure out your cap card/drivers natural size, understand the resolution of your source, understand what your 'resize' or any filter you use does, understand mpeg compression, blah blah blah .....

[lordsmurf]

Whe I used an AVerMedia card (BT chips) the 352 captures were garbage. At first I blamed 100% on PowerVCR, NeoDVD and iuVCR. I now give 50% of the blame to the chips/drivers.

Even at 720x480, it looked ... I don't know ... off somehow. Was still unacceptable, is why I bought a second ATI AIW card.

This does given a better explanation.