Capture Resolution - Are you sure?

[trevlac]

Purpose:

I wanted to write this to solidify my understanding, and to allow people to show me where I'm wrong. I put my conclusions 1st so you could decide if it was worth reading the rest.

Conclusions:

Cap > 640x480 gets nothing xtra for NTSC on a BT878. Except maybe a nice size for DVD.
No analog source even gets close to 720x. The best is about 640x576 for China, Uk is about 590x, most of West Europe is 540x (about SVHS), and US is 450x480
VHS is a rotten 320x
Resolution results very much depend upon knowing your equipment

Background / Theroy:

Simplified (but reasonable) explination of an analog signal is a wave that varies in height from 1 to 0 volts. The variation from 1,0,1,0 in a picture is represented as white, black, white, black. The frequency of the change from 1 to 0 represents the detail or size of the changes. Faster the change, more detail. Bandwidth is a refrence to highest frequency of change. 1MHz bandwidth would allow the display of 1 white and 1 black dot on a 1 microsecond long signal.

Sampling Theory says "A signal can be reconstructed from its samples without loss of information, if the original signal has no frequencies above 1/2 the sampling frequency. (Nyquist)". Without loss of information. The converse of this is that a higher sampling frequency gets you nothing. In practice there are a number of problems. 1st is that if you do have frequencies above 1/2 the sampling frequency, you introduce aliasing or digital noise. This is where a higher frequency blends with a lower frequency at a given place in the picture.

The MHz bandwidth limits of a number of formats are as follows: vhs=3, NTSC broadcast=4.2, SVSH=5, PAL broadcast=5 to 6, DVD/DV=6.75

Pixel resolution can be calculated from Bandwidth as follows: Pixels = 2 * BW * Active Frame width in microseconds.
The ITU-601 active frame width is 53.333 so the bandwidth limited frame sizes are as follows: vhs=320, NTSC broadcast=448, SVSH=533, PAL broadcast=533 to 640, DVD/DV=720

A little bit about filters (a little bit is all I know). If you want to reduce or remove aliasing (digital noise), you should filter frequencies higher than 1/2 the sample rate out of the signal. The trouble with this is you can not just pick a number. A filter 'slowly' reduces the amplitude of a frequency. So if you want to get rid of everything above 6 MHz, you may have to start at 5.5 MHz and end at about 7 MHz for all practical purposes. Better filters with less of a 'roll' are more expensive to make. The measure of a filter is given at the point where the amplitude is reduced to -3dB. They begin reducing before that point.

Finally: Practical max sizes.

http://www.conexant.com/servlets/DownloadServlet/100119a.pdf?FileId=542
Page 76 of the BT878 specs say the following:

Digitized video needs to be bandlimited in order to avoid aliasing artifacts. Because
the Bt879 samples the video data at 8xFsc (over twice the normal rate), no
filtering is required at the input to the A/Ds. The analog video needs to be bandlimited
to 14.32 MHz in NTSC and 17.73 MHz in PAL/SECAM mode. Normal
video signals do not require additional external filtering. After digitization, the
samples are digitally low pass-filtered and then decimated to 4xFsc. The response
of the digital low pass filter is shown in Figure 32. The digital low pass filter provides
the digital bandwidth reduction to limit the video to 6 MHz.


What does this mean? Well, any frequencies in an analog signal above 28.6MHz would be noise, since the signal standard is quite a bit less. The BT878 takes the risk and does not filter these out. If they are there, you get digital noise. It then does filter the digital signal to limit a 6MHz bandwidth. The filter starts to work at 4MHz, but 6MHz = 640 pixels. If you look at the chart on that page you can see that PAL fares better. It's probably 7MHz at -3dB, but it starts to work at 5MHz. The chip then throws out 1/2 the samples and effectively gives you a rate of 14MHz and 17MHz for NTSC and PAL.

The CX2388x spec is even more interesting. It doesn't look like that chip ever filters. This might be why cards based on those chips seem noisy. You get analog noise turned into aliasing digital noise from an noisy signal.

You can see this by looking at a 6.75MHz test circle in a capture app. The BT will show no detail. The CX will show detail.
Here is an example http://www.hometheaterspot.com/html/spotadmin/uploads/lumcircle.jpg

The Philips http://www.semiconductors.philips.com/acrobat/datasheets/SAA7134HL_2.pdf spec says that they filter before sampling. They use a 7MHz filter as stated as 'B' on page 38. Page 9 of the http://www.semiconductors.philips.com/acrobat/datasheets/SAA7113H_1.pdf doc shows their filter starts at 6MHz.


VHS sizes:

An interesting thing about the BT878/CX2388x is that if you ask for a size smaller than about 360, the driver may kick in an additional filter. This looks like it starts at about 2.5MHz for NTSC and 3.5MHz for PAL. Look for "Optional Horizontal Luma Low-Pass Filter" in the docs. The reason for this is, if you reduce the size of a frame, you are effectively reducing your sample rate. If you reduce your rate below 2 * the highest frequency of your signal, you will introduce noise. You can test this by using custome sizes and a test chart. Watch the stuff jump around and then watch the resolution drop at < 360x. BTW: 360 = 3.4MHz.

Said another way, caping NTSC above 640 on a BT878 card get you no xtra resolution. Caping between 640 and when the LowPassFilter kicks in (depends on the driver), gets you aliasing noise. When the filter kicks in, your resolution drops a bunch.

Kell
Kell does not exist in a conversation about the width (horizontal) of a picture.

What do ya think ? :D

[Arachnotron]

Great work! I agree with it as far as black and white (Luma) is concerned.

I would suggest using higher cap resolutions however, even for VHS, because of color. As stated before in this forum, color (chroma) is sampled at half the sampling rate of luma by capture devices and stored that way. This is because there is less color information in the original signal and because the human eye isn't as sensitive for it anyway.

But, at least for the signal, it is NOT less by a factor 2!
For NTSC broadcast, Luma bandwith is 4.2 MHz or 448 lines in the ITU frame. But Chrominance bandwidth is 3.579545, or 382 lines in the ITU frame. So to actually represent all chrominance info in NTSC broadcast, you would still need 760 'packed yuv' pixels in the ITU frame!

In practice the chrominance bandwith will be lower, also by comb filtering loss. This may be especially true for VHS tape, which stores color in a FM modulated way I have no idea how to convert to a bandwidt figure :D.

Still, to reproduce all the info theoretically available in an analogue source in digital form, you will need a much higher resolution then you would think on grounds of luma bandwidth!

The color insensitive eye argument never really did apeal to me. I may not notice it on my current TV set. But how about the next one? If the info is there in the original signal I want it :)

[trevlac]

Originally posted by Arachnotron
But, at least for the signal, it is NOT less by a factor 2!
...
But Chrominance bandwidth is 3.579545, or 382 lines in the ITU frame.

I'm glad you argree on the luma. I'll work on the chroma. :D

I don't think you are correct on the chroma. The chroma is centered at 3.58 in an NTSC signal. It does not start at 0 and go to 3.58. The full signal bandwidth is 4.2MHz. Where there is chroma, there is essentially no luma.

Like I said, I'll work on the chroma. Let's just do composite because VHS does not have s-video out? Not even thru some funny european connector ? :) I still maintain the numbers I gave are for the total signal. 640x480 is the max info a BT878 will do for NTSC. Few analog signals have a higher resolution.

Trev

PS
I'm not saying there is no reason to cap at sizes like 768 or 720. For example, I'm not sure what an upsize resize to 768 really means if you cap at 384x576. It's just that 768 really has no more info than 384 for PAL VHS. You still have to know if your driver is using the 'optional' lowpass filter. If it is not, ironnically, 384 has more 'noise' than 768.

[Arachnotron]

I don't think you are correct on the chroma. The chroma is centered at 3.58 in an NTSC signal. It does not start at 0 and go to 3.58. The full signal bandwidth is 4.2MHz. Where there is chroma, there is essentially no luma.

If chroma contains 3.58 MHz components you still need to sample it twice that high, If it does not go to zero that would affect only lower resolutions.
But I thought that was were the color burst came in. Sync with colorburst and flip phase and to allow you to extract it.

Anyway, the point I was trying to make is that since in almost all digital formats chroma is stored at half the resolution of luma, and in analogue signals the chroma bandwidth, while lower than luma, is MORE then half that of luma, it is chroma bandwidth that determines the capture resolution when using real world formats.

If you have a certain number of chroma 'lines' in your signal, you will need twice that many pixels in digital to be able to reproduce it.

Going higher then 640x480 will do nothing for your luma. But it will increase color detail.

Let's just do composite because VHS does not have s-video out? Not even thru some funny european connector ? :confused: :confused: VHS is a tape format?.

Most standard VCR's will only output composite, but if you play back a standard VHS tape on a s-VHS VCR, you will still have a s-video output.

[trevlac]

I think 4:2:2 is derived from sampling the color carrier at 4x the bandwith. IE 3.58*4=14.32MHz. 2x is 7.16Hz. Both fall under 12 which is about 640.

Anyway, give me a chance to look this up. :D


On the VHS thing... :o :o Actually that's what I do. VHS on an SVHS machine s-video out. So that's the test. As an interesting note to people. Chroma and Luma are recorded in seperate spots on a VHS tape. They are combined when you play it thru composite.

[Arachnotron]

Anyway, give me a chance to look this up.

Of course! I like this stuff, it explains some of the differences between capture devices which cannot be explained by the raw sampling rate alone. I wonder if some of the CX23881 cards may have an external bandpass filter. Where is my screwdriver?? :)

edit

On my Hauppauge WinTV PCI FM model 747 (CX23881) there is a 2.7 µH inductor plus two unknown capacitances in the signal way, suggesting a low pass filter of some kind.

[Arachnotron]

@ Trev,

I think I know where the difficulty is. For luma, the relation bandwidth==resolution holds. But for chroma, which is a color difference signal, it doesn't.

It has to be decoded first, and the actual bandwidth depends on exactly what the color change is you are looking at. see: this (http://members.aol.com/ajaynejr/colordec.htm#Textbook) link:

The de-facto standard for NTSC horizontal chrominance resolution is about 0.5 Mhz of color component signal content representing 40 lines (per picture height; about 52 color changes all the way across the 4:3 screen).

So you are perfectly right with your final conclusions, since the color resolution, if you can even use such a term, is so much lower then luma that it doesn,t matter at least for 4:2:2.

[trevlac]

You kinda took the wind out of my sails with that post. :D

My favorite VCR facts source is having server problems so I can't post some links of a picture of bandwidth.

Here is a great link, often cited. http://www.cs.tut.fi/~leopold/Ld/VideoFormats.html

I usually avoid posting links like that because there is so much bad info out there. Professional (business) and edu links are much better / safer. But, that one seems to line up nicely with the numbers I do know. It too states that VHS chroma resolution is 40 lines for both NTSC and PAL.

For all the formats listed, you could calculate the min frame size needed by taking the "Limiance Horizontal Resolution" and multiplying it by 1.333, and the "Chroma Horizontal Resolution" and multiplying it by 1.333 * 2. Then take the highest. BTW: Luma will always be higher. :) The vertical is always 576 or 480 for all analog sources, so that's easy.

So for example: PAL VHS would be 240 * 1.333 = 320x576 Luma and 40 * 1.333 * 2 = 106x576 Chroma. Luma wins even after chroma is adjusted for the fact that it has to be stuffed into 8 bits where as luma gets 16 bits across 2 pixels.

So PAL VHS requires a max frame size of 320x576. This does not mean that some low-pass filter doesn't lower the source resolution, but for PAL on a BT878 I think you are safe at 352x576. It's always worth testing. :D

----------------

On another Note, I think you can test what your card is doing. I'll post a 'resolution chart' you can use. Basically, It shows circles that require certain bandwidth to see. If the circle has good detail, you are getting that bandwidth. If it is grey. You are not. If you see interference (movement), this may be aliasing. I'm not sure about that one. 6.75 is the most interesting circle. It is just alternating 1 pixel black and white lines. You can also play with this in virtualDub. If you precise bicubic resize to 360, you get grey in the 6.75MHz circle. About what I see on my BT878. But remember, even if the BT878 does a 6MHz filter for NTSC, there is a slope to killing the signal, so It's not completely grey. :)

-------------------

Here is the test pattern: http://pics.trevlac.us/img.htm?Resolution.png

If that does not work, past the following into a new browser window:
http://pics.trevlac.us/Resolution.png

Note: The image was mpeg compressed and then png compressed. There is some distortion due to the mpeg.

[trevlac]

Originally posted by Arachnotron
On my Hauppauge WinTV PCI FM model 747 (CX23881) there is a 2.7 µH inductor plus two unknown capacitances in the signal way, suggesting a low pass filter of some kind.

I'm now tempted to look at my MSI board, but my wife would kill me. I need to wrap presents. :) ho ho ho !

I did want to point you to This (http://www.analog.com/Analog_Root/s...sp_book_Ch3.pdf). On page 50 there is a calculation to figure out the cutoff frequency of a filter given known resitance values and capacitance values. Not sure it is practical. Like I said, I only know a little bit about filters. :)

[North2Polaris]

@Arachnotron
@trevlac

I have enjoyed following these threads.:)

@trevlac

What are the implications for your proposed revisions to the guide:

http://trevlac.us/preface.htm

“The basic rule is: the bigger the frame size, the better the quality (for more information, see section 1.3.2), but unfortunately also the higher the requirements for hardware and software. “

Based on the previous discussion of aspect ratios, resizing, and determining the capture width of your capture card/driver combination, is there not some utility in capturing at, for example, NTSC 712x480 if using a BT8x8 card and the BTWincap driver, even though, as you note above, “Cap > 640x480 gets nothing xtra for NTSC on a BT878”, at least in terms of resolution?

[Wilbert]

Conclusions:

Cap > 640x480 gets nothing xtra for NTSC on a BT878. Except maybe a nice size for DVD.
(...)

So PAL VHS requires a max frame size of 320x576. This does not mean that some low-pass filter doesn't lower the source resolution, but for PAL on a BT878 I think you are safe at 352x576. It's always worth testing.


What are the implications for your proposed revisions to the guide:

http://trevlac.us/preface.htm

I think that there are two separate issues here (assuming source is VHS for example):

1) Do I get more detail when I capture at a resolution larger than 352x576 (instead of at 352x576 itself)?

Your analysis shows that (at least it seems correct to me at first sight) this is not the case. Thus if your source is clean it would be sufficient to capture at that resolution.

2) Does the capture size matters (ie 352x576 or larger) if my source contains noise?

I still think it does. If you capture at the 'native' size (the size where the capture driver doesn't need to upscale, something like 754x576 for bt8x8 iirc) it is much easier to remove noise (and keeping detail), while capturing and removing noise at a lower resolution.

[Arachnotron]

@Trevlac,

I did want to point you to This. On page 50 there is a calculation to figure out the cutoff frequency of a filter given known resitance values and capacitance values. Not sure it is practical. Like I said, I only know a little bit about filters

I would need more info. It looks like a standard Butterworth PI filter, but one of the caps may simply there to remove DC from the signal. Because of the multilayer PCB I cannot see the exact layout, only that there are two identical circuits involving an inductor and two capacitances directly after the hosinden input.
To calculate the cutoff, I would need 3 other values: the capacitances, and the impedance of the input of the CX23881 in the frequency range.

Since the capacitances are SMD without markings, the only way to get the values would be to de-solder them and measure them. (this cannot be done in situ). That goes a little bit to far even for me :D

side note I wouldn't put it past some manufacturers to put an analogue low pass filter at lower cut-off before Phillips or BT878 chips too, to smooth out the caps.

40 * 1.333 * 2 = 106x576 Chroma

I wondered where you got the factor 2 from, untill I realized the bandwidth is 0.5-0.55 MHz on either side of the chroma carrier, resulting in a 1 MHz bandwidth. I think some of the tables overlooked that. Thanks for pointing it out!

If you precise bicubic resize to 360, you get grey in the 6.75MHz circle. About what I see on my BT878

Be carefull with 6.75 MHz patterns. If you generate them using a DVD player, the original black-white-black pattern analogue signal will already be lightgray-darkgray-lightgray because the sinc functions merge. So seeing gray in the cap does not necceserily mean the card is bandwidth limited; the DVD player already is.

try http://www.arachnotron.nl/videocap/site/dvdemu/ (IE only)
it is a crude DVD signal emulator. Put in an alternating 1-0-1-0-1 pattern and see what kind of signal you get back.


@ everyone
So far I have only been able to find derived values about VHS bandwidth. Does anyone know where to find the original technical specifications?

edit there is still a bug in my dvd emulator. Oh well. But my point about using a DVD as 6.75 MHz test source remains valid. (checked the signal on an oscilloscope)

[vhelp]

@ trevlac :)

question.. What are we suppose to do w/ these patterns that you all
love to post for demo'ing as the test templates ??

I D/L'ed the pic (Resolution.png) but what am I suppose to do w/ it ??
:eek:

-vhelp

[trevlac]

Originally posted by North2Polaris

What are the implications for your proposed revisions to the guide:


“The basic rule is: the bigger the frame size, the better the quality (for more information, see section 1.3.2), but unfortunately also the higher the requirements for hardware and software. “

Based on the previous discussion of aspect ratios, resizing, and determining the capture width of your capture card/driver combination, is there not some utility in capturing at, for example, NTSC 712x480 if using a BT8x8 card and the BTWincap driver, even though, as you note above, “Cap > 640x480 gets nothing xtra for NTSC on a BT878”, at least in terms of resolution?

I don't think the first quote is true. See my note to Wilbert below. As far as 712x480, that is what I'm going to do for DVD. That way I don't have to resize after cap. I can just crop to 704. In other words, there are good reasons to go higher. Just not resolution reasons. VHS is the real interesting case. The question is 352 high enough. Maybe, depending on what your card does. :) For a BT878 on PAL, I think it is good enough. On NTSC it is not. BTW: I have never seen a PAL 352 VHS cap. :) This is all theory and spec. It's always good to test. :D

[trevlac]

Originally posted by Wilbert
2) Does the capture size matters (ie 352x576 or larger) if my source contains noise?

I still think it does. If you capture at the 'native' size (the size where the capture driver doesn't need to upscale, something like 754x576 for bt8x8 iirc) it is much easier to remove noise (and keeping detail), while capturing and removing noise at a lower resolution.

"it is much easier to remove noise"

You may be right on that. I really don't know what happens on post processing. For example, it's not clear to me what a post cap resize really means as far as the picture detail goes.

However, here is what I think about the cap size and noise (both analog and digital). BTW: this is all based upon theroy and reading the specs. It should be a good guide for tests, but tests my show different results. :)

There are 3 factors involved.
- Max Resolution of the card
- Max Resolution of the source (320 for VHS)
- Relationship between target resolution, 'optional filters', digital noise (aliasing)

So, for NTSC VHS on the BT878.

The max resolution of the card is 640. This is because the chip filters NTSC to a -3db cutoff of 6MHz. It starts working before 640 and really doesn't stop at 640, but -3db is the standard point of measure. If any analog noise (or good signal) was above that point, it would be gone if the filter worked.

Between 640 and ~360, the BTwincap driver does not turn on the optional filter. Because VHS is lower than 360, any signal between those points is analog noise. If you reduce the size between those points, you risk turning the analog noise into digital noise (aliasing). This is because resizing is like reducing the sample rate. If any signal is say at 5MHz and you resized to less than 533 (53.33(ITU601)*2(Nyquist)*5MHz), you are aliasing the 5MHz signal.

At 360, it looks like the optional filter is turned on for NTSC. It looks to start killing frequencies at 2.5MHz and reaches -3db at 3MHz. This means it effectively removes any noise but it also removes signal (it may be debatable that a VHS has much signal at 3MHz).

Finally, The picture for PAL VHS may be much different. The optional filter does not start until about 3.5MHz. This means that it is only killing noise.

So in theory, a noisey PAL VHS capture with the optional filter at 352, should contain less noise than one at say 720. Of course, as I mentioned to start, if it is easier to post process a larger picture, the story may change. I really don't know about this, but I'm learning. :)

[vhelp]

- Max Resolution of the source (320 for VHS)

I question this resolution (ie, 320) for VHS only because on my DC10+
card (a hardware MJPEG card) it's maximum Width setting is 640. You
have to wonder why Pinnacle made this choice in the first place.
.
.
Surely, they knew what they were doing when set this as the default
maximum on this card (for NTSC) As for PAL, you also have to wonder
why they set it to 768 :eek:

Never-the-less, I wonder if VHS (should be considered) as 320 or 360
when talking in terms of "relavance"

I've played w/ VHS for a few years, and I'm still learning here and
their some. I used to capture at 352 and now, since I have my ADVC,
I just let it capture at that devices default, which happens to be
720. But, I continue to experiment w/ VHS and resolution settings
w/ my Analog capture cards.

Just to note, while I'm at it...
I've noticed that on some capture cards, the Horizantal seems to be
much cleaner than other cards. I'm still debating/testing this issue
as I write this.
.
.
Also, you can't always depend upon your PC monitor for a fianl conclusion.
You have to test also, on your TV set, (and not through your cards TV-OUT
port)
Testing (final analysis) should be done on a DVD-to-TV setup.

-vhelp

[trevlac]

Originally posted by vhelp

question.. What are we suppose to do w/ these patterns that you all
love to post for demo'ing as the test templates ??

I D/L'ed the pic (Resolution.png) but what am I suppose to do w/ it ??
:eek:



@V,

Good to hear from you. :)

Here are the sparce insturctions from my test disc.

This resolution wedge pattern allows measurement of vertical and horizontal resolution. The vertical wedges measure horizontal resolution from 200 to 540 TVL (the limit of 4:3 ratio DVD images). The horizontal wedges measure vertical resolution to 480 TVL. Additionally, circular patches of lines spaced at 3.0, 3.58, 4.18, and 6.75 MHz act as additional measures of image resolution. A central zone plate pattern helps evaluate color seperator function.


So you could make a dvd with the picture as a still, (or buy the test disc to assure all the png/mpeg compression is not invalidating the results).

Then view the most narrow ends of the wedges. They show how much resolution you have. Where the lines blend is where the resolution ends. This is really a ball park measure because the loss will not be complete at any point, and the pattern is not easy to see. Finally, the MHz patterns can be viewed. If for example the 6.75MHz circle shows lines, you have the max resolution possible from a DVD (or close). If yours is grey, you don't. To go from MHz to DVD pixels, a simple calc is MHz*80*1.333 So for the circles shown, the horizontal DVD pixel size is 320, 382, 446, & 720, Which btw are about the rez for VHS, Notch Filtered NTSC, Full NTSC bcast, and DVD.

Some Notes:
If you resize the pattern, it will change. Pad lines if you want a PAL pattern. You should view this on your TV, PC, and thru your capture card to get an idea of the differences. Thru the capture card at different rez, you can get an idea of the filters that take place. Also, you may be able to see aliasing if no filter is there. I suspect this is what is happening when you see wavy lines in the grey background or in a circle. Do not view on the PC thru power/win dvd. These types of programs will change the size of the picture. View it at 720.

Hope this helps. :) :)

edit Another point is to make sure your capture card contrast and brightness settings are correct. Use b&w if your driver lets you.

[trevlac]

Originally posted by vhelp
I question this resolution (ie, 320) for VHS only because on my DC10+
card (a hardware MJPEG card) it's maximum Width setting is 640. You
have to wonder why Pinnacle made this choice in the first place.
.
.
Surely, they knew what they were doing when set this as the default
maximum on this card (for NTSC) As for PAL, you also have to wonder
why they set it to 768 :eek:

640x480 is a 4:3 square pixel frame size (NTSC on a PC). If you are not going back to DVD, there is no point in having higher. 768x576 is 4:3 PAL on a PC.


I also wondered about the 640 limit and the advertised comments of being able to do higher on a CX based card. I now realize that BT878 card filtered out anything higher than 640 NTSC. And since nothing analog really has a resolution higher, it makes sense.

[Arachnotron]

I wondered about the internal BT878 bandpass filter.

After all, once you have aliassing you cannot filter it out anymore with a low pass filter. An aliassed signal is a high frequency signal above the nyquist limit which during sampling is mistaken for a lower frequency signal. So once you have it, it is low frequency and will pass a low pass filter.

Then I found that my old Hauppauge BT878a based card also has an external low pass filter. I suspect a two step approach:

first, filter out anything above 0.5 * (raw sampling rate of the card) with an external filter. This avoids anything being aliassed into the digital samples before they are being further processed.

second, do a programmable filtering described by Trevlac to get rid of all high frequency noise not needed because of source / target bandwidth limitations.

As a comparison, a SAA7113 based device I opened up did not have a external low pass filter, which you would expect since it has an ANALOGUE build in anti-alias filter.

[vhelp]

@ trevlac,

So you could make a dvd with the picture as a still, (or buy the test disc to assure all the png/mpeg compression is not invalidating the results).

So, you saying that I need to basically find an app that'll take .BMP
files and make an .AVI file out of them (if select a given pattern, I
can then stream (or copy/paste) each .BMP several time or enought to
work with. And then encode this w/ highest bitrate, and then finally,
pfew.. capture it w/ any given test capture device ??

If the above is true, that's a lot of work - don't know where to get
an .BMP to .AVI app, but still. It proves very interesting a project
and I would love to try this out on all my capture devices :P


@ Arachnotron,
Can you explain what those "Alias Noise" look like in an image
from a video still ??
I'm curious to see what exactly you are talking about. I used to think
that "Alias" was another way of saying "saw-tooth" or "stairs" hehe..

No rush guys.., enjoy the day everyone :)

-vhelp

[Arachnotron]

@vhelp

You only need avisynth and a one line script.

use the imagereader command.


ImageReader("c:\folder\pic.bmp", 0, 3000, 30, false)
result is 10 sec 30 fps RGB24 AVI, so you may need to convert to YUV for some encoders.


Feed the avs script to your DVD encoder.
Maybe you need a second line to change the colorspace if CCE.


As to the alias noise: I was talking theoretical. I don't have an image for this. The term aliassing when used with sampling refers to to what happens of you have higher frequencies in your analogue signal then half the samplingrate.

edit
so if you have a smooth curve (= high frequency) sampled with a low frequency 2D sampling grid (=the pixels). The smooth curve is now mistaken for a series of low frequency blocks and stripes (the staircase)

look

here (http://www.snellwilcox.com/knowledgecenter/books/books/ecomp.pdf) for some explainations (especially page 18-22)

The staircase is a special example of a general principle in sampling.

Have a great Cristmas everybody !!!! :) :)

[Wilbert]

So, for NTSC VHS on the BT878.

The max resolution of the card is 640. This is because the chip filters NTSC to a -3db cutoff of 6MHz. It starts working before 640 and really doesn't stop at 640, but -3db is the standard point of measure. If any analog noise (or good signal) was above that point, it would be gone if the filter worked.
Interesting that this bt878 filters noise (I have to look that up for my SAA87108 chip, but my captures are very noisy, so I guess they don't filter). Where in the specs of bt878 can I find this -3dB?

Btw, why the comment "it would be gone if the filter worked". You think it doesn't work?


So in theory, a noisey PAL VHS capture with the optional filter at 352, should contain less noise than one at say 720. Of course, as I mentioned to start, if it is easier to post process a larger picture, the story may change. I really don't know about this, but I'm learning.

I think it is easier. But we should be able to do some tests ...

But I don't really understand this. I would say that it is logical that a capture at 720x576 contains more noise than at 352x576, simply because the size is larger. Of course, if the image is resized to 352x576 (either by you or internally by the chip), the images is also smoothed. So, it contains less noise.

At 360, it looks like the optional filter is turned on for NTSC. It looks to start killing frequencies at 2.5MHz and reaches -3db at 3MHz. This means it effectively removes any noise but it also removes signal (it may be debatable that a VHS has much signal at 3MHz). (...)
So in theory, a noisey PAL VHS capture with the optional filter at 352, should contain less noise than one at say 720. (...)
I guess I have some reading to do when I'm back. This optional filter isn't applied when the width is larger than 360? That's another reason why 352 contains less noise than 720 (at least for bt878)?

[Arachnotron]

Interesting that this bt878 filters noise (I have to look that up for my SAA87108 chip, but my captures are very noisy, so I guess they don't filter). Where in the specs of bt878 can I find this -3dB?

You make the assumption that ale noise you see is aliassed high frequency noise. An anti-alias filter(low pass) would do nothing for low frequency noise (any noise with a frequency under the cut-off frequency of the filter)

By the way: the -3dB point is just a general convention in elecronics. Since no filter has a sharp cut-off but allways changes slowly with frequency, you plot thye filter response as Db against frequency and define the cut-off point as the point where the signal has decreased with 3 dB.

It's christmass. We really need to get a life :D

[vhelp]

hay Arach..


ImageReader("c:\folder\pic.bmp", 0, 3000, 30, false)
result is 10 sec 30 fps RGB24 AVI, so you may need to convert to YUV for some encoders.


I'm excited :) hehe.. I got it to work. However, that 3000, is calc'ing
to 1min, 4sec's, (not 4 sec)

I changed to 300 (10 seconds) and encoded w/ 8000 CBR in TMPG. I'll
burn as an xSVCD (720 x 480) w/ 4:3 aspect ratio. I'd like to burn
as a standard DVD compliant disk, but I haven't connected my new
DVD Writer yet. I"m lazy and have lots of many fun stuff to do :P
.
.
But, i can't wait to try out some of my cards. I'll let you all know
how it goes (when I get to this juncture)

Thanks Arach.. and cheers everyone,
-vhelp

[Arachnotron]

I'm excited hehe.. I got it to work. However, that 3000, is calc'ing

Sorry, my mistake. the 3000 should be the number of frames, so 100 sec. at 30 fps. Why you end up with 1min4sec I don't understand. (I'm an avisynth novice) But if it works, don't change it :)

[vhelp]

Why you end up with 1min4sec I don't understand.

probably because I fed the .AVS script inside vdub, and it reported
that it was 1:40 in length. perhaps there is a bug, or perhas not :)

But, it works, and I'm greatful :)

cheers
-vhelp

[trevlac]

Originally posted by Wilbert
Interesting that this bt878 filters noise (I have to look that up for my SAA87108 chip, but my captures are very noisy, so I guess they don't filter). Where in the specs of bt878 can I find this -3dB?

Btw, why the comment "it would be gone if the filter worked". You think it doesn't work?


You have a saa87108 ? What is that in? I can't find it. Here is a link that lists the video adc chips. http://www.semiconductors.philips.com/catalog/219/282/31111/31571/index.html#31571


As far as the filter noise, Aracnotron is right. The card may also have a 'low pass filter'. This could be part of the chip or on the card before the chip. The easy way to know is to test with a pic. Vhelp has the right idea. Even SVCD can hold a 704 image, so you could crop the one I provided and make an SVCD still.

You can find the 3MHz optional filter on page 18 figure 7 of this (http://www.conexant.com/servlets/DownloadServlet/100119a.pdf?FileId=542). The filter response graphs start on page 20. Find the -3db point and it shows the frequency. As arachrnotron pointed out, a filter starts before it's target value and ends after. -3db is the standard if a given frequency is stated. This also why I say 'if it worked'. I'm not clear on this, but due to the 'gradual' effect, one would assume some noise gets thru.




But I don't really understand this. I would say that it is logical that a capture at 720x576 contains more noise than at 352x576, simply because the size is larger. Of course, if the image is resized to 352x576 (either by you or internally by the chip), the images is also smoothed. So, it contains less noise.

There are 2 kinds of noise here. Analog and digital (aliasing). If the analog noise frequency is above the filter point, it would be removed. This is likely, because we generally think of 'snow' as analog noise. I'd say this has a high frequency. Digital noise is created because when a signal is sampled, there are higher frequencies than can be correctly sampled. This I believe is seen as morie patterns, such as what a vertical stripe shirt shows on TV.

By the way, aliasing has existed as long as TV. The kinds were due to not enough scan lines or a too small frame rate. Both are 'digital' representations. We are now just talking about horizontal aliasing due to ADC sampling. The shirt example is aliasing along the vertical. A pal signal will aliasing if there is more than 576/2=288 vertical lines in the entire screen height. Because a shirt does not take up the entire height, you may see the problem.



I guess I have some reading to do when I'm back. This optional filter isn't applied when the width is larger than 360? That's another reason why 352 contains less noise than 720 (at least for bt878)?
I'm just (guessing) when the filter is applied, because it may be different for different drivers. I can watch the BT878 registers with a little tool I found. For the BTwincap driver, it seems to be turned on at 360 (as I recall), however, there appears to be a lot of aliasing at 366, 364, & 362. At 368 things look good.

So in the end, if there is a filter up front, it removes analog noise (really for the purpose of not creating digital noise). If you reduce the size without filtering, you will introduce digital noise. This can not be effectively removed. (Actually, I think adding 'random' noise limits the effect of digital noise).

Trev

[trevlac]

Originally posted by vhelp

Can you explain what those "Alias Noise" look like in an image
from a video still ??
I'm curious to see what exactly you are talking about. I used to think
that "Alias" was another way of saying "saw-tooth" or "stairs" hehe..


I believe aliasing shows as a moire pattern. http://www.exploratorium.edu/snacks/moire_patterns.html

This makes sense if you take the definition of moire pattern as "When you overlap materials with repetitive lines, you create moire patterns." Because 2 frequencies are being combined when aliasing takes place. You can see these patterns in the test picture, especially as you adjust the capture size. BTW, aliasing has always been around. That's because 480 (NTSC) is the number of 'samples' across the height of the picture. AKA scan lines. So anything with > 240 lines would alias (show a moire pattern) on good old analog tv. Frame rate is also 'digitizing' the picture. So the often used 'wagon wheels' example says that if the spokes move faster than the frame rate (30fps NTSC), then they don't appear to move correctly (they go backwards). I say to point out that aliasing does not 'destroy' the picture or anything terrible. :)

The 'saw-tooth' is caused by the 'bandwidth' limit of digital, namely bit depth or 8-bit. After sampling, the value must be turned into a number. For 8-bit the number must be an integer between 0 and 255 (or 2 to the 8th different values). When there is a sharp contrast (black/white lines), that is at an angle, the transition between the contrast is too fine detail and is lost in the quantization. (Turning the sample reading into a 0-255 number). Ironically, this is worst in a clean signal. Dithering is the act of adding noise so as to blur the sharp contrast. Lowering contrast may also help, but this reduces the resolution of the picture.

PS: I'm just learning this stuff, so don't quote me. :D

@Arachnotron

You know you could make a test pattern. There is also a 'sweep' pattern that is just vertical lines of changing grey level and frequency. I'll post it when I get a chance. Using you're 'dvd emulator', checking out these 'professional' patterns, and making your own would really help someone master the topic. I may just try.

On another note: I've read that 17.72MHz sample rate is used for comosite video because it is above nyquist and the color frequency (4.43MHz) is a factor. What this means is it is easier to decode the composite signal if the samples line up with the color signal. What this means is that the sampling must sync with the signal. These cards do sync with the 'burst' signal. I quote video engineering by Inglis: "For PAL, the sampling points are at 0, 90, 180, and 270 degree points of the burst waveform."

[Wilbert]

Ehhh, that was a typo ... It should be saa7108:
http://www.semiconductors.philips.com/pip/SAA7108.html

I will read the rest tomorrow ...

[Arachnotron]

On another note: I've read that 17.72MHz sample rate is used for comosite video because it is above nyquist and the color frequency (4.43MHz) is a factor. What this means is it is easier to decode the composite signal if the samples line up with the color signal. What this means is that the sampling must sync with the signal. These cards do sync with the 'burst' signal. I quote video engineering by Inglis: "For PAL, the sampling points are at 0, 90, 180, and 270 degree points of the burst waveform."

Hmm... That would mean that the Philips cards (13.5 MHz) would have problems with color. (And DV devices also). Besides, you must digitize first before you can align anything.

I think at this point you are still digitizing at 35.5 / 27 MHz, and well above the nyquist limit for 4.43 MHz. This goes in the comb filter, and results in the target samplerate you need. Since you separate at high frequency, there is no problem aligning.

Notice that in the BT878 and CX23881 specs, the comb filters are described with graphs at different target sampling rates. There is
even an 13.5 MHz optimized comb filter version.

edit
I re-read your quote, and now get it :). Syncing with the color burst would indeed make things easier. But in order to do it, you would need to sample at a much higher sample rate than the simple cards we use. I read somewhere the latest digipure stuff samples at 54 MHz. Who knows....

[trevlac]

Originally posted by trevlac
I believe aliasing shows as a moire pattern. [url]

I wanted to correct myself. I just read in "Handbook of Image and Video Processing" that aliasing can show as a 'stair-step' pattern.

So, Vhelp is on to something. It of course may be that this pattern is due to both aliasing and bit depth.


Edit

I wanted to point to another misconception I may have. Although 'noise' appears to me as a high frequency event. (Little spots), it appears that it is generally accepted that noise is in all frequencies. This makes sense, because even small frame size caps have noise.

[vhelp]

yeah, I guess I refer to "stair-stepping" as "saw-tooth" as well as
"alias" :)

But, there is another for of "alias" too (in addition to mine, and
Arachnotron's explanaa)
I'm refering those that are cause by poor "imetation" to resizing or
16:9 'ing (the technique imployed by DV cams to fake 16:9 sources)
.
.
In my experience w/ my Sony TRV-22 cam, it (if I may use harsh words)
sucks horses butt in 16:9 mode. This mode is the 1.77777778 (or 1:178.1)
aspect ratio standard for 16:9 tv sets. The issues I suffer when shooting
in this mode is color-artifacts - - mostly in the greens. If you were
to look at some of my Florecent Light footage, you'd see thick green
bars (like it blead something bad) For newbies blind to quality, they
won't notice this. But for someone like myself, I do.
.
.
I resulted in a rather great comprise in my DV ultimatum of 16:9 encodes.
Shoot 4:3 mode, and crop top/bottom 60 pixels respectivly and get perfect
smooth video images. Including horizontals. There are no artifacts in
this areas. There are other advantage to obtaining even better (improved)
video quality that I've learned w/ my TRV-22, but this isn't the time
or place to discuss it here :) anyways..

As I was saying, "Aliasing" shows up in many forms, and I TRUELY believe
that it has something to do w/ the "Aspect Ratio/Video Image" of the
given source that causes this phenomina.

Definately something to think about here.
-vhelp

[vhelp]

Here is something else interesting.. should fit the topic. Anywyas..

Has anyone actually burned a really good quality Pattern, say a good one
minutes worth to a DVD disk (forget SVCD) and then output'ed it to their
VCR and recorded it, to see what the results would be.

Perhaps a standard should be instilled upon this idea and use throughout.

* Encode 720 x 480 pattern to DVD disk
* play via dvd player
* output to (S-Video) a VCR and record it to
...Standard VHS - SP Mode to tape
...Standard SVHS - SP mode to tape

.
.

Then, the next level would be to use their capture card/device and see
what results they get :)

Can (or has) anyone done this yet ??

I'd be interested in hearing your findings.
-vhelp

[trevlac]

I did a little test to see if there was a difference in cap at 368 vs cap at 712 and resize to 368. I also threw in a cap at 356. At this size, my BT878 and BTwincap combo turn on a filter. This seems to not only limit the horizontal, but it also messes with the vertical.

Method
I capped 712, 368, & 356 on my BT878 card using the BTwincap driver. I set the capture filter settings to the driver default. I used amcap (uncompressed) to capture from my dvd player via s-video to my card. I played the 'resolution' image I had posted before. I used virtualdub to copy a frame to Photoshop. I resized (down sized) the 712 image to 368 using photoshop bicubic resize. All samples were saved with the same settings to png from photoshop. To my eye, the png files are real close to the original bmps.

Results

http://pics.trevlac.us/img.htm?712.png
http://pics.trevlac.us/img.htm?368.png
http://pics.trevlac.us/img.htm?356.png

The 'downsized' 712 image clearly has less horizontal resolution than the 368 cap. If you look at the vertical wedges and the 4.18 circle you can see this. The 356 image suffers a big hit on vertical resolution. This can be seen in the horizontal wedges. However, it may have more horizontal resolution than the resized 712. Another thing to note is that the 712 seems to have a lower contrast than the other images. On the 3.0MHz circle, it's lines are more grey. The 368s lines are sharp white and black.

Conclusion
I'm not sure. It may be photoshop, or something I did. Biliner has the same result. The resized image is smoothed. This may actually 'look better'.

edit
I added a nearest neighbor resize just for kicks. And guess what! It keeps the contrast up. It's not quite as good as the 368 cap, because it makes some parts of the picture more blocky and is not as smooth as the 368 cap.

http://pics.trevlac.us/img.htm?712NN.png

Now this may all make sense. The little I do know about bilinear and bicubic is that they average across a number of pixels. This should smooth the image.

Very interesting ....

[vhelp]

Test scenario:

* Pattern: "Resolution.png"
* Prep: AVS script line: ImageReader("h:\Resolution.bmp", 0, 300, 30, false)
* Time: 10 sec .AVI file, frameserved into TMPG for encoding
* TMPG: encoded to DVD / 720 x 480 / 4:3 AR / CBR: 8000k
* DVD authored: MyDVD -- straight burn to DVD, as is.
* DVD player: Apex AD-1500
* Capture card: ATI-TV Wonder pci / s-video

The .avi capture were at various resolutions (widths * 480)
I loaded each .avi file in vdub to copy (Ctrl+1) a frame to clipbrd and save as
a .png file.

Please note, my ATI card does exhibit Line Noise, though you might not notice
it in these pics.

DOWNLOAD my test results here:

* ati_tv_wonder_svideo_apex_ad-1500.zip (http://www.westnet.com/~vhelp/ati_tv_wonder_svideo_apex_ad-1500.zip)

-vhelp

[Wilbert]

The 'downsized' 712 image clearly has less horizontal resolution than the 368 cap. If you look at the vertical wedges and the 4.18 circle you can see this. The 356 image suffers a big hit on vertical resolution. This can be seen in the horizontal wedges. However, it may have more horizontal resolution than the resized 712. Another thing to note is that the 712 seems to have a lower contrast than the other images. On the 3.0MHz circle, it's lines are more grey. The 368s lines are sharp white and black.
Very interesting. This would show that the internal resizer of the chip/driver is much better than "bicubic resize". I don't know anything about photoshop's bicubic resize. Maybe you can try several resizers of AviSynth (bicubic and bilinear)?

1) Could you post the original 712 image?

Now this may all make sense. The little I do know about bilinear and bicubic is that they average across a number of pixels. This should smooth the image.
Yup.

2) Could you do the same test with a normal capture (from a broadcasting, one which has noise)?

There are 2 kinds of noise here. Analog and digital (aliasing). If the analog noise frequency is above the filter point, it would be removed. This is likely, because we generally think of 'snow' as analog noise. I'd say this has a high frequency. Digital noise is created because when a signal is sampled, there are higher frequencies than can be correctly sampled. This I believe is seen as morie patterns, such as what a vertical stripe shirt shows on TV.
I wanted to point to another misconception I may have. Although 'noise' appears to me as a high frequency event. (Little spots), it appears that it is generally accepted that noise is in all frequencies. This makes sense, because even small frame size caps have noise.
What's the difference between low and high frequency noise (visually, when looking at your capture)?

[Arachnotron]

@Trevlac, Wilbert

From Trevlac's data, I get the impression the card does more than a simple interpolation, but instead consideres all 'raw' samples withing the window of te target pixel. So High frequency data is considered when constructing the low frequency pixel.

But in a re-size, there is nothing above 712 left to consider. This data is already lost.

Does that make sense? :)

As to noise:

You have to make a distinction between noise, interference and aliassing. Those are not the same thing.

Equipment noise would be the hiss you hear from an amplifier when you short out the inputs. It is a background of random frequencies. It need not have an even frequency distribution.

This is the random noise always present in any analogue equipment.

Signal noise you see in an TV grab is noise in the capped signal. Also random, caused by all kinds of things, BUT external to the TV card. It is really there in the signal you grab. Again, most probably a random distribution of frequencies, though not neccesarily an even distribution.

Interference is also incorrectly discribed as noise, but is caused by outher signals from other sources ending up in the signal you are interested in. Cell phones, electric motors, computers etc. etc.
Mostly not random, often it has a pattern to it in the cap

Aliassing is not noise at all, but a sampling artefact. It is caused by high frequency signals mistakenly ending up in low frequency samples. The cause of the high frequency components in the signal signal may truly be noise, but may also be a legitimate component of the analogue signal (capping a DVD signal at low res without low pass filter). Not noise at all, but an artefact.

Things like sawtooths and rainbows are aliassing artefacts, but not noise at all. You are trying to describe highly detailed pictures using a low frequency sampling rate, and because of this you get regular patterns (the saw tooth, the moiree effect) which have a mathematical basis and can be predicted (though not by me :D )

The essence of noise is that it is random.

The true noise you see in a cap has two sources, which you cannot distinguish: Aliassed high frequency random noise and true low frequency noise.

[trevlac]

@Vhelp

Interesting pics. You have nice results, very clean captures. I'll take a stab at what I see, with the idea that I'm quite new at this. :)

The 712 pic looks like the limit of the card is about 6MHz or 640x480. I get that by 'guessing' that the vertical wedges measure about 480. 480 *1.33 = 640. 640/80=6MHz. Also, the 6.75MHz circle shows detail, but is not sharp. I'd say the limit for the card is 640. But you are unlikely to have any source that comes close to that. :)

The 368 to 360 are very interesting. The 368 has much more horizontal detail than the 360 considering there is only an 8 pixel difference. The results of the 360 look the same as my photoshop resizes! Maybe that is what ATI does. BTW, my 360 is crap compared, because the card messes with the vertical even though I don't want to change that size.

@Wilbert, Arachnotron

On Noise:

I think Arachnotron is more clear on this than me. I am using the term noise for aliasing because for digital, aliasing is in effect noise, and bit depth is the bandwidth limit. These are not the same thing as analog noise and analog bandwidth limits.

I do not know enough about noise to really comment more. I may try to turn my recent findings into a practical matter, what size to capture AND deal with analog noise. But I have a bunch more reading to do in order to understand that. :D

On The Resize:

I will try some avisynth tests and post the orignial pic. Some things to note. The card does resize the samples where as the software resizes the pixels. I did cap at 754 and the test results are the same as 712, so I'm not really sure about the card having more info. I think it just does a more sophisticated resize based on a signal. I've been trying to read about this, but there is too much math that I do not get. :D

I am going to hold off on the 'noisy bcast captures' test. I need to know a bit more to even attempt to read any results. Moving from theory to practical may be a big jump.

You should be able to do a test with an SVCD still. You can take the 720 pic I posted and crop to 704. Do you have s-video? That might be a problem, but rca results may be what you want if that is what you generally do.

BCast is an interesting case. I get very different results depending on what I use as a tuner. My BT878 (Aver) card has a philips tuner (I think). It does a great job at filtering the noise. If I use my vcr as a tuner, the picture is sharper but with a bunch of grain.

Trev

[trevlac]

@Wilbert

I did the tests in avisynth. Here is the script I used.

AVISource("D:\Caps\Res712.avi")
#BilinearResize(368, 480)
#BicubicResize(368, 480)
#BicubicResize(368, 480,0,.75)
LanczosResize(368, 480)
#PointResize(368, 480)


The top 4 are about the same as the photoshop pic I posted (712.png). PointResize is the same as nearest neighbor. Here is the full 712 pic so anyone can do an easy compare.

http://pics.trevlac.us/img.htm?712Full.png


I've been reading a bit about filters. Here is what the BT878 spec says it does:

The Bt879 implements horizontal scaling through poly-phase interpolation. The Bt879 uses 32 different phases to accurately interpolate the value of a pixel.This provides an effective pixel jitter of less than 6 ns.


I'm not sure how to relate that back. I believe what the chip is doing is not filtering and resizing. The bicubic/bilinear are filters. I think the point resize does not filter but is not as good as the chip. The chip clearly has morie patterns, so perhaps this is the result of aliasing due to no filter.

I believe it must be a tradeoff between sharpness and aliasing.

Here (http://www.dspguide.com/filters.htm) is an excellent writeup on filters. The entire book can be found for free at http://www.dspguide.com . It seem well worth the read.

I am going to play with writting a vdub filter for resize to try my hand at understanding this stuff. That might make it come together better. It looks like with 'filter factory' that I don't even need a compiler. :D

[vhelp]

@ trevlac,

The Bt879 implements horizontal scaling through poly-phase interpolation. The Bt879 uses 32 different phases to accurately interpolate the value of a pixel.This provides an effective pixel jitter of less than 6 ns.

I believe what the chip is doing is not filtering and resizing.

Me too. But, here is what I'm braining around with.. Remember the
term, "scanline" ?? The word "scaling" seems to be pointing in that
direction. Weather the source is VCR or Cable or Satellite or DVD
or whatever, you (we all) have to think in terms of "scanline" and
not resolution, because as Arachnotron has share w/ us on this important
fact, this is the focus we have to reflect upon when dealing w/ what
Noise is, or Capture Quality etc etc. ..the mechanisms that bring
video into our computers.. is through the scaling/scaline'ing, not
rows of pixels, from one point to another (2 dementional array)
.
.
I'm sure that Arachnotron could explain better :)

-vhelp

[Wilbert]

poly-phase interpolation
I'm wondering since a long time, what this exactly means.

Some links:

http://cnx.rice.edu/content/m10431/latest/ (requires MathML, which I don't have installed)

http://www-nt.e-technik.uni-dortmund.de/Papers/fr_spie_01.pdf

http://www.cs.tut.fi/kurssit/83080/Polyphase.pdf

The last one seems interesting. But it's too late to read anything. I will look at it later this week.

[vhelp]

@ trevlac,

Interesting pics. You have nice results, very clean captures. I'll take a stab at what I see, with the idea that I'm quite new at this.

The 712 pic looks like the limit of the card is about 6MHz or 640x480. I get that by 'guessing' that the vertical wedges measure about 480. 480 *1.33 = 640. 640/80=6MHz. Also, the 6.75MHz circle shows detail, but is not sharp. I'd say the limit for the card is 640. But you are unlikely to have any source that comes close to that.

The 368 to 360 are very interesting. The 368 has much more horizontal detail than the 360 considering there is only an 8 pixel difference. The results of the 360 look the same as my photoshop resizes! Maybe that is what ATI does. BTW, my 360 is crap compared, because the card messes with the vertical even though I don't want to change that size.

you are correct. I agree w/ you on this. I ran a test of all the pics
w/ the use of a magnifier (app) and I would clearly see a contiguous
pattern, while the other remaining patters (resolutions) were either
broken patterns or inconsistant (so to speak) The 640x480 seems to be
this cards sweet-spot :)

My only problem w/ this is that I would not get the kind of results I
would get w/ a full frame capture of 720 (when making widescreen projects
requiring 720) Unless I'm missunderstanding something here :confused:

-vhelp

[trevlac]

@Vhelp

I'm just saying that the most resolution you can get is 640. There are other reasons to go higher. I'm not sure I'd use 720, but 704 makes sense to hit dvd spec. As far as wide screen goes, the resolution is worse. That is because the pixels are spread across a wider scan line. I'd say again 704 is what I'd use if you did an analog capture. For DV, I'd use 720.


@All

I did Vhelp's VHS test, just to bring this back to some of my original points. I ran my dvd player resolution chart via s-video into my JVC HR-S3911U deck. I recorded about 1 min of the chart on a new TDK T-120HSBH tape. The package says premium quality, but honestly, I don't know much about vcrs. :) I recorded at SP. I then cap'd the recording uncompressed, s-video out, etc. (same as I did from the dvd player), at 712x480. Copied a frame using virtualdub and saved as png with photoshop.

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

As you can see, VHS has very little resolution. The horizontal comes in around 240 which = 240*1.33 = 320 pixels wide. See the vertical wedge for that. Also, you can see that the vertical is just as good as DVD, so call it the full 480. So, in 4:3 frame size terms, VHS is 320x480 as expected. :D

I don't think it matters much how you resize, except that a 352 cap on my BT878 will mess with the vertical which is the only good thing about vhs. On my card, I'd cap at 368.

I don't have any SVHS tapes, so someone else can test that. But it is my understanding that most everything is plain old VHS.


@Wilbert

I wish I understood Digital Signal Processing, but I don't. I'm learning, and I hope some practice with a sample filter will help. But for now, your last link goes over my head. :confused:

[vhelp]

@ trevlac,

shucks.. you beat me to the VHS step. Actaully, we have very similar
VCRs. your "JVC HR-S3911U " again my JVC HR-S391OU"
..but I disabled all my vfw drivers on my 2nd pc which has my other
capture cards (ie, DC10+ and Osprey-210) - - now I gotta go and straighten
them all aout :confused:

So, then you burned a DVD test pattern for maximum accuracy ??
I'm using an actual DVD, and 720 (and your pattern) as my test tempate.

I'd like to try the same test you produced above, to see what results
I get. Gosh.. this is all very interesting and exciting too. I noticed
a hint of color rainbow in your pic's top left circle. I'm wondering
if you turned off your capture apps "preview" mode. In my first test,
I used vdub w/ "preview" mode on. TIP: But, you have to press the "S"
key to waik up the colors mode else you'll end up w/ partial B/W color.
.
.
Why I use vdub for capture test ??
Because it has greatre flexibility w/ its resolutions and color spacing
setups.
Oh, by the way, I use the YUV 411 Raw v1.00 mode (codec) and
Y41P - YUV 4:1:1 planar in my first test above. This mode gives me the
maximum output quality in resolution and colorspace, and
is easier on the capture's resources (IMO) - - I believe that this is
an ATI-only codec. anyways..

-vhelp

[trevlac]

@Vhelp

I own the original Avia dvd that contains the test pattern. I used my 'backup' version for the test. You can buy this at many stores. Also, the video essentials dvd probably contains the same stuff and is cheaper.

I cap at 712 because this is the about the size my BTwincap actually captures for 13.5MHz pixels. 720 would be stretched. You should probably cap at either 714 or 704 on an ATI. These numbers depend upon your driver and are given in some other threads here. Look for capture size. :)

I also captured uncompressed using a very simple wdm capture program that comes as an example with the directX SDK. AmCap.exe


I'd love to see your results. Overall, I've been trying to work out what is a good framesize to capture VHS. The more examples the better.

Trev

[vhelp]

Hi trevlac,

yeah, I'll try and get to the VHS test scenario soon. Today (this
evening) is gonna be a tough one though. Can you guess why ?? hehe..
umm.. maybe the new year, and I wanna see if Dick Clark is still
looking young :) though you can see his hair receipting :) Anyways..

EDITED by vhelp. I think I was a little off-topic here, so I'm
just snipping unecessary items :)

At this juncture, I'm doing VHS work. I've ben working on it for over
a year now, and have it very close to nailed (quality'wise) IMO.

As for my reason of vdub.., its a simple one. I'm still under Windows 98 gold
and using VFW support. But, I'm more than fine w/ "segmentated" capturing under win98.


I'd love to see your results. Overall, I've been trying to work out what is a good framesize to capture VHS. The more examples the better.

I'll see what I can do between now and next year hehe :p
-vhelp

[vhelp]

@ trev,

Couple of more questions.

Do you have any other Patterns that are 720 x 480 you can U/L, and
also other sizes like 352 x 480, etc. ??

And, I am curious about something. If I had a 352 x 480 pattern,
and performed the same capture setup, I'm wondering what my results
would be (good or bad) if you factor in my previous samples how the
other capture resolutions looked - worse. I'm wondering if I cap
a 352 x 480 pattern, and cap it at the same 352 x 480, would I get
smooth results, or would I get just as bad results :confused:

-vhelp

[Arachnotron]

I was looking at the resolution testpic Trevlac posted, especially at the wedges. I am trying to roll my own, and stumbled on an interesting factoid :)

When you want to create frequencies using a 13.5 MHz pixel grid, you cannot create all frequencies.
The ones you can create exactly are:

length(pixels), frequency (MHz), Horizontal lines of res
2 6.75 533
3 4.50 355
4 3.38 267
5 2.70 213
6 2.25 178
7 1.93 152
8 1.69 133

Now look at the vertical wedges in the original testpic and especially at the moire pattern. The pattern looks like a series of semi-circles of increasing sizes. At certain interfals, the circles touch, creating 4 pointed stars / diamonds.
Now look at the lines of resolution marks at the places the centers of the stars are located:

The first set runs from 533 to 355. The second set runs from 355 to 267. Further sets are no longer visible, probably because by now the frequency has gone down by more than a factor two, and you are below Nyquist.

What I think is happening: The testpic, which is a digitized analogue pic, is already aliassed. Using a 6.75 MHz sampling rate, you cannot accurately display frequencies between 6.75 and about 3.4 MHz. Anything around this range gets aliassed, which in this case (I think? ) means they become summaries of other, lower frequencies. The moire effect is caused by the interference patterns of these frequencies.

Which means that when you use a testpic with a sample rate of 6.75 you have to be very carefull about conclusions you draw about the 3.4-6.75 MHz range. The exeptions are 6.75 and it's lower harmonics of 6.75.

edit I'm not sure if you can use the term harmonics here. :(

[Arachnotron]

I also tried out my own Terratec Cinergy TV 600, a SAA7134 based card.

I used the first version of my own testpic.

712x480 NTSC from DVD (http://www.arachnotron.nl/temp/Cinergy_600_NTSC_from_DVD.png)

As you can see, while there is some aliassing(?) in the 6.75 MHz strip, you can still see the separate stripes. So it does do full 720x480 :p

I'll try some lower res caps and a test of my VHS next. It's 2 am now, time for some sleep :p

[trevlac]

@Arachnotron, @VHelp


Here are some other patterns for your pleasure. From what I've read, they were never analog and they display no moire patterns. (Unless you stare at them too long. :D ) They cover .5 to 5.0MHz I believe.

http://pics.trevlac.us/img.htm?Sweep.png
http://pics.trevlac.us/img.htm?MultiBurst.png

Here is a good writeup on the entire disc.
http://www.itccomp.nl/htwebf/Documenten/PDF/AVIAobscura.PDF

Here are some comments on using the resolution charts and the Avia disc. The first uses the disc extensively to test displays and players. They also use a scope with the patterns I just posted. :)
http://www.hometheaterhifi.com/volume_7_3/dvd-benchmark-part-1-video-9-2000.html
http://www.dvdfile.com/tech/review/processors/homepc.html


@VHelp

Sorry no 352 images. A resize would effect the pattern.


@Arachnotron
I assume you still think this testing process is still valid? The links above imply that others do. :) I'm glad you are making a pattern. I've been distracted with vdub filters. I'll put a C++ book under my pillow tonight and see if it's all clear in the morning.

@All
My provider does not seem to like too much activity on a given image. I changed the name of the orignial http://pics.trevlac.us/img.htm?Resolution1.png to Resolution1.png, to give people another chance to see it. I encourage anyone to buy the disc. There are over 180 patterns on the disc. It also covers audio.

[Arachnotron]

@trev

I assume you still think this testing process is still valid? The links above imply that others do. I'm glad you are making a pattern. I've been distracted with vdub filters. I'll put a C++ book under my pillow tonight and see if it's all clear in the morning. I just realized my mistake: the sampling rate is not 6.75, it's 13.5. So anything below 6.75 is below the Nyquist treshhold. I'm still a bit uncomfortable with using something with aliasing artefacts in the source as a reference, but I suppose if it works, don't knock it :)

The nodes in the moire pattern do match the point where you can exactly match pixels to the frequency. I wonder if you can use that to filter them out?

But in general, I never take anything I find on the web at face value. Always kick it a few times to see if it comes apart. :D

By the way: I just tested my VCR, a JVC HRS7950 (sleep, who needs sleep? :) )

The 2.7 MHz strip comes trough clearly, the 3.4 MHz strip very very faintly. It is hard to see because of color interference patterns (the same that were in your caps in the 3 MHz circle)
I'll do some extra strips between 2.7 and 3.4 to narrow it down.
VCR pic (http://www.arachnotron.nl/temp/vcr_cutout.bmp)

Of course, my VCR is PAL, so it sounds about right, 354 lines.
The question is, where is the limit? During recording, in the tape format or during playback.

Happy new year, and bugfree dreams

[trevlac]

Originally posted by Arachnotron

The 2.7 MHz strip comes trough clearly, the 3.4 MHz strip very very faintly. It is hard to see because of color interference patterns (the same that were in your caps in the 3 MHz circle)
I'll do some extra strips between 2.7 and 3.4 to narrow it down.
VCR pic (http://www.arachnotron.nl/temp/vcr_cutout.bmp)

Of course, my VCR is PAL, so it sounds about right, 354 lines.
The question is, where is the limit? During recording, in the tape format or during playback.


Well, I don't know much about VCRs, but your comments made me do some research. It looks like the manual for a HRS7950 says it does 250TVL for VHS. So I'm guessing when you say 354 you mean the full width of 4:3 pixels, not TVL. 354 would still be about 265 TVL, so you seem high. What do the wedges tell you in the Avia resolution pic?

Also, the tape does not limit the resolution. My machine seems to be able to record SVHS on a VHS tape. It's called JVC Extended Technology or something like that. After some searches, it seems people have been turning VHS tapes into fake SVHS tapes for some time, so, I'd say there is not much to the JVC ET thing.

Some other things to note: (I can't really confirm, but this is generalized from info I've read)

- VHS is a seperate thing from PAL and NTSC. It does not have the color and luma mixed. It's called 'color-under' format. Frame rate seems to be the only real difference.

- Different VCRs have better resolution. A low number given for luma resolution is 2.5MHz. This was in a video engineering book. I could not find a high VHS number, but 3.4 may be it. 5MHz is almost always given for SVHS.

- As I mentioned above, you can record SVHS on a VHS tape. Also it's interesting to note that a PAL tape moves slower (due to the frame rate difference).

[FredThompson]

Originally posted by trevlac Sampling Theory says "A signal can be reconstructed from its samples without loss of information, if the original signal has no frequencies above 1/2 the sampling frequency. (Nyquist)". Without loss of information. The converse of this is that a higher sampling frequency gets you nothing. In practice there are a number of problems. 1st is that if you do have frequencies above 1/2 the sampling frequency, you introduce aliasing or digital noise. This is where a higher frequency blends with a lower frequency at a given place in the picture.

The MHz bandwidth limits of a number of formats are as follows: vhs=3, NTSC broadcast=4.2, SVSH=5, PAL broadcast=5 to 6, DVD/DV=6.75In a word, no.

Nyquist is so incorrect an assumption that it's amazing anyone who has ever drawn a sine wave would consider it valid. Properly sampling an analog wave requires samples of at least 4x the sampled frequency. Even 2x is insufficient.

Draw a simple sine wave and put a dot at one of the places where it crosses the Y axis. Congratulations, you just simulated sampling at 1x to yield a value of 0. Acording to Nyquist, this is an accurate representation of the wave. Now put a second dot at the other place where the wave croses the Y axis. Now you've simulated sampling at 2x to yield an "accurate" representation with a value of 0.

That's all irrelevant for video capture unless you're doing the capture in the frequency domain. Your Brooktree chip doesn't allow you get get that type of data.

Also, analog recordings are not segmented into pixel-friendly clocked segments. They are continuous analog signals. All those statements about the X resolution of some form of analog recording are "best-fit" approximations. Television is not a giant X-Y graph like a computer monitor, it is a stacked set of analog signals. Specs which describe how a particular analog recording type should behave are representations of general behavior in the X-dimension. It follows, therefore, that the X dimension is best sampled with as many values as possible.

Throwing out the incorrect assumptions about fitting analog information into a digital domain, your real question is the performance characteristics of a particular Brooktree device. To minimize distortion, you should capture in such a way that you are using the actual summary values from the sampling hardware with a 1:1 sampling in the Y axis corresponding to the recorder's output, not something extrapolated from them. THAT is your real question.

Ivo can give you exhaustive information wrt the performance of Brooktree devices. Look for him at Everwicked or neuron2's site. IIRC, he's working on an article about capture with Wilbert. He's got tech specs for Brooktree devices.

[Arachnotron]

@ trevlac: the number is for the whole 52 µs. And the result is very faint, so the cut-off is probably somewhere lower.


@FredThompson

I have wondering about this for some time too. I am new to this, so please be gentle :)

I have been trying to replicate some test patterns for DVD by mapping the value of a sinus as an 8 bit greyscale in a 720x480 grid, at various frequencies and been failing miserably whenever I came above about 3.4 MHz.

Look here ( http://www.arachnotron.nl/temp/vcr_test.rar) for a RAR file with a BMP with strips at 6.75, 6.33, 5.92 .. 0.92 MHz (6.75-0.92 in 15 steps) and the interference patterns you get when you get near 6.75 MHz. 6.33 looks like a 6.75 signal with (6.75-6.33) MHz superimposed.

Nyquist is so incorrect an assumption that it's amazing anyone who has ever drawn a sine wave would consider it valid. Properly sampling an analog wave requires samples of at least 4x the sampled frequency. Even 2x is insufficient.

I went back to some articles (the math is still beyond me :( ) and came up with this:

Nyquist is correct, but only under very strict circumstances AND only for a whole analogue-digital-analogue cycle, so including the reconstruction of the analogue signal before playback:

1. You must filter out anything above the sampling frequency /2 (avoid Pre-aliassing);
2. The samples must be 'spikes', so no averaging the signal over a short time interval;
3. when you reconstruct the signal, you must use a perfect low pass filter/sinc function(?), (avoid post-aliassing).

In the real world, none of those conditions are ever met, so you must go much higher in sampling rate. When determining the sample rate, you must also consider the mechanism used to reconstruct the signal on playback.

My test pic may result in a correct analogue signal when played back on a DVD player, provided it reconstructs it right. (It uses something that looks line a sinc function. I still have to try this, I'm not completely sure).
But when you zoom in on a computer screen, you are effectually breaking the chain and stay in the digital domain. You could say you are reconstructing using a square pulse, and all sorts of horrible interferences result (even apart from wat the screens pixel grid does). A software DVD player will probably filter for things like this to some extend.

Interesting question: does this mean the sampling rate requirements for devices that will play back to TV (i.e. reconstruct the analogue signal first) are lower than for files that you will watch directly on a PC?

In any case, from your comments the optimum sampling resolution for my 27 MHz SAA7134 will be 712x480 since at that res the sampling clock is 'in sync' with the generated pixels.

edit
On monday I have access to an oscilloscope once more. I'll burn my testpic to DVD and see what kind of signal I get back and where it stops being a perfect sinus. I'll post the resulting screendumps here.

[Wilbert]

Ivo can give you exhaustive information wrt the performance of Brooktree devices. Look for him at Everwicked or neuron2's site. IIRC, he's working on an article about capture with Wilbert. He's got tech specs for Brooktree devices.
No, I'm not working on an article with Ivo. I'm working on an article with the people participating in this thread. So, feel free to jump in ...

Btw, I'm working on a smoother comparison (noisy sources) with Ivo. This project is delayed quite a bit due to AVSEdit.

[trevlac]

Fred,

Thanks for your post, and your invite to neuron2.net. I'm not a programmer, but have been having some fun with the vdub filter tutorial. I truely want to learn digital signal processing, and what better way than by writing some filters?

You must forgive me, I am just learning the sampling topic. Unfortunately, I do not follow your arguments. You have left gaps I can not jump. I will try to read posts at neuron. I am also trying to tackel EE books. Maybe they are too much theory. :)

Originally posted by FredThompson

Premis
Nyquist is so incorrect an assumption that it's amazing anyone who has ever drawn a sine wave would consider it valid.

Conclusion
Properly sampling an analog wave requires samples of at least 4x the sampled frequency. Even 2x is insufficient.

Support?
Draw a simple sine wave and put a dot at one of the places where it crosses the X axis. Congratulations, you just simulated sampling at 1x to yield a value of 0. Acording to Nyquist, this is an accurate representation of the wave. Now put a second dot at the other place where the wave croses the X axis. Now you've simulated sampling at 2x to yield an "accurate" representation with a value of 0.

Support?
That's all irrelevant for video capture unless you're doing the capture in the frequency domain. Your Brooktree chip doesn't allow you get get that type of data.

I don't see or follow your support for your premis or conclusion.
Here (http://www.broadcastpapers.com/testmeasurement/TektonixDTSystems&Meas202.htm) is a link to what seems to be a reasonable source that talks as if Nyquist is valid. As I tried to state, Nyquist seems to 'fail' (if you want to call it that), because one generally needs to filter the signal to go from A to D and D to A. Easier filters seem to be the reason for higher rates. The BT878 does not filter 1st, but super samples (28MHz NTSC) so it does not have to filter 1st. It then uses a digital filter and decimation to get to 4fc (14.32 NTSC). It is really the filters that 'fail' because they are not sharp enough. Nyquist is valid. Super samples have nothing to do with more information, but with less aliasing.



Also, analog recordings are not segmented into pixel-friendly clocked segments. They are continuous analog signals. All those statements about the X resolution of some form of analog recording are "best-fit" approximations. Television is not a giant X-Y graph like a computer monitor, it is a stacked set of analog signals. Specs which describe how a particular analog recording type should behave are representations of general behavior in the X-dimension. Conclusion It follows, therefore, that the X dimension is best sampled with as many values as possible.

Well, you make many statements but I'm not clear what's valid and how they fit your conclusion. Here I'd like to adjust the discussion a bit and talk about the mighty analog signal. An analog signal represents life already sampled along the y(height) and z(time) axis. There are a discrete number of scan lines and a discrete frame rate. Appearently these are good enough and where picked as a trade off of bandwith and the value you get from higher sampling rates. There are limits to what your eye can see, and what your brain preceives. These limits were considered when a 59.97 field rate and 480 scan lines were selected. So I don't yet understand the 'as many as possible' conclusion. Y and Z are limited from 'real life'. We are just talking about x which has a limited bandwidth of information anyway.


your real question is the performance characteristics of a particular Brooktree device. To minimize distortion, you should capture in such a way that you are using the actual summary values from the sampling hardware with a 1:1 sampling in the Y axis corresponding to the recorder's output, not something extrapolated from them. THAT is your real question.

I'd like to generalize, but I would say one should know their equipment. There is no doubt that differences can be vast. As far as a 1:1 sampling, I don't see how this is practical. A BT878 samples at 14.32MHz for NTSC. This must be decimated to reach any sort of display standard. If you mean interpolation by the chip is better than on pixels, I'd say yes for the BT and no for an ATI, from some simple tests, but why is then my question.

I'm sticking with my conclusions, but am trying to learn more every day.


Cap > 640x480 gets nothing xtra for NTSC on a BT878. Except maybe a nice size for DVD.

No analog source even gets close to 720x. The best is about 640x576 for China, Uk is about 590x, most of West Europe is 540x (about SVHS), and US is 450x480

VHS is a rotten 320x

Resolution results very much depend upon knowing your equipment



Again, thanks for telling me I am wrong. It will force me to better understand the topic, I may have been getting lazy but Arachnotron generally keeps me on my toes. I don't expect you to teach me, but I hope a newbie such as myself is welcome at neuron2. :)

[FredThompson]

I thought this would happen. It can be difficult to discuss things like this without pictures. I'll try to keep this brief. If you want more explanation, let me know and I'll work on something more comprehensive.

wrt Nyquist:

my comments have to do with sample rates. Let's walk through the example and I'll try to explain. First, some background.

Schmidt triggers are the building block of digital storage. When data is read from a drive, it is actually an analog signal determined by the magnetic charateristics of the area being read, right? Those signals, in a time-regulated manner, go through an electrical filter (Schmidt trigger) which decides if they represent a 0 or a 1. There's a dedicated amount of time from which the sample is to be interpreted but multiple ways to make the decision. It could be based on the lead-edge, tail edge, some form of average or another manner. Hope I didn't just lose you. The point is there are many ways to make a time-sliced evaluation of an analog signal.

OK, let's take a look at a basic sine wave with the first part being the positive "hump." Suppose this sine wave perfectly matches the length of the time slice. (Sample time is based on highest source frequency.) There are 3 points in time where the value fo the wave is 0. The average value is also 0. If the evaluation of the wave is taken at any of those points or as an average, the result will be 0 which is obviously a false evaluation. Likewise, if we take a single instananeous value at any time within the time slice we will get a false evaluation. However, if we take 4 instantaneous samples at equidistant timing within the time slice we get four values which show an actual representation of the curve. (How that data is interpreted is another matter; square-wave, triangle-wave, etc.)

There's another discussion of this concept here: http://www.digitalprosound.com/Htm/SoapBox/soap2_Apogee.htm

OK, back to your video capture. There most certainly is a sync used to establish when a particular scan line starts. That's a hard signal coming from the playback device. Your capture card's hardware must recognize that signal. However, at that point, the length and position of the time slices which repesent horizontal travel of the analog signal is determined by the capture card. The playback device is not clocked in such a way, it sends a continuous analog signal. For a tape-based device, the content of that horizontal signal will vary based on the signal on the tape, how accurately it is retrieved and the instantaneous position of the tape as it moves through the playback device. Take a good look at a non-TBC non-digitally-stabilized analog playback. Stationary vertical elements move around the screen and they do this variably by scan line. The result is your digital capture device generates a time-based valuation of a temporaly-variable data source.

I hope you understand what I just tried to explain.

You are correct that the amount of information available per scan line can vary depending on the source. However, remember, it is an analog signal. Finite evalution of "pixels" per scan line is only a guidline representation, especially given the lack of horizontal sync.

OK, so back to how the capture hardware works. IIRC, the Brooktree does a 2x horizontal oversampling. However, that data is not available. Please check with Ivo on this: I think the Brooktree ALWAYS samples with the same resolution and feeds data back after doing internal resizing. Therefore, you would be far better off to retrieve the resolution which matches the actual capture, do your processing, and do whatever resizing you want as a last step. (Some people do resizing then process a little more to reduce visible artifacting from resizing.

640x480 is indeed 4:3 for square pixels. Analog video doesn't use square pixels. It doesn't really use "pixels" anyhow but that's another issue. It uses rectangular elements. The digital video resolutions are based on their analog predecessors. 720x480 more accurately represents the analog signal. The benefit of horizontal capture resolution of 720 or 704 (720 minus overscan) is not that the source can provide that resolution, it is the added benefit of more samples of an analog signal for a given timeframe and accurately reflecting the samples your hardware is actually making.

wrt ATi: I'm not sure which chipsets they are using. The early All-in-Wonder devices had Brooktree components which ATi modified because they said there was a hardware bug in the Brooktree device. OmegaDrive creates modified versions of the ATi drivers. Maybe those would give better results. His drivers do allow video resolutions like 720x480 which are better mapped to analog out.

edit: OK, I just read the beginning of the link you posted. It says 2x highest frequency. That's a very common misconception. Only sampling at 2x could yield the case where both reading catch the wave crossing the 0 point. It depends on how the sampling is done. Frankly, I'm not sure which trigger timing the Brooktree uses. Ask Ivo. My comments about Nyquist were more general, not specific to the Brooktree digitizing process.

[Arachnotron]

Brooktree devices (BT878 and CX2388x) sync on the midpoints of the falling edges of the horizontal sync pulse.

[FredThompson]

So it's triggered at some point during the later half of the time dedicated to take a sample, does that twice horizontally and yields a combined result from the 2, correct?

Didn't Ivo (or was it you) mention there is stretching happening if you try to get 720x480 from the Brooktree devices? It's not actually taking the 8 on either side, correct?

[Arachnotron]

So it's triggered at some point during the later half of the time dedicated to take a sample, does that twice horizontally and yields a combined result from the 2, correct?

I'm not sure if I understand your question. I just quoted from the spec sheets.

According to SMPTE 170M, the rise time for sync is 140 ns. In this time, a BT878 sampling at 28.63636 takes about 4 samples. ( actually about 5 since rise time is from 10% to 90%). I'm not sure why two samples would be needed for triggering. It should be able to trigger with 35 ns variation. Or is this total nonsense ? :)

Didn't Ivo (or was it you) mention there is stretching happening if you try to get 720x480 from the Brooktree devices? It's not actually taking the 8 on either side, correct?

Correct. Both me and Trevlac did. I did a small page on how to determine this window,here (http://www.arachnotron.nl/videocap/site/capture_area2.html)

The exact window is set by the driver. It looks like drivers that are derived from the conexant reference drivers use a window of about 51 µs for NTSC, but the BTWincap driver uses about 52.7 µs. Any resolution you request is a scaling from this window. The same goes for Philips and ATI devices (but with other window sizes), from tests done by other forum members it looks like a standard capture device issue.

edit I thought a BT simply triggers on the first sample below 50% of Hsync ?

[trevlac]

@FredThompson,

I don't mean to be rude, but you seem to jump around a bit. It may however, be my lack of knowledge. :) It seems you have 3 main points:

Nyquist is invalid, a sine wave requires 4 samples to recreate.
Variable line length is a problem for capture
"Therefore, you would be far better off to retrieve the resolution which matches the actual capture, do your processing, and do whatever resizing you want as a last step. "


I'd like to try to address these.

#1- Nyquist is invalid, a sine wave requires 4 samples to recreate.

Can 2 samples of a sine wave properly represent an analog signal? The answer is yes, because no other sinusoid, or combination of sinusoids, will produce this pattern of samples. These samples correspond to only one analog signal, and therefore the analog signal can be exactly resconstucted. AKA, you need to sample at 2x the highest frequency.

A very clear explination of this starts on page 39 of this document. The Scientist & Engineer's Guide to Digital Signal Processing (http://www.analog.com/Analog_Root/static/technology/dsp/training/materials/pdf/dsp_book_Ch3.pdf) You can also get an updated version from amazon. "Digital Signal Processing: A Practical Guide for Engineers and Scientists". Here (http://www.amazon.com/gp/reader/075067444X/ref=sib_dp_srch/103-1528009-6849462?v=search-inside&keywords=proper+sampling) is a link to page 39 on amazon.

With respect to your link.

1st

I believe aliasing in audio is a big problem. The frequency of an audio wave is what is important. Since aliasing misplaces and overlaps frequency components, it directly destroys information encoded in the frequency domain (audio). For video, the shape of the wave is important. A picture can and does withstand aliasing artifacts. So, drawing conclusions from audio may not be valid for video.

2nd

Your link seemed to think Nyquist was valid. It's two points seem to be that 'oversampling' was done so filters would work (as I suggested), and so that frequencies higher than audible range could be mixed to an audible range. Therefore, it would be nice to capture them for post processing.

#2 - Variable line length is a problem for capture
I would completely agree. I havn't really pondered this, but Brooktree seems to do something they call 'Ultralock' to address this problem. You can read about it on page 13 of this (http://www.conexant.com/servlets/DownloadServlet/100119a.pdf?FileId=542) conexant document. They seem to guarantee that you will get synced lines if you ask for pixels that correspond to the shortest line length.

#3 - "Therefore, you would be far better off to retrieve the resolution which matches the actual capture, do your processing, and do whatever resizing you want as a last step. "

Ironically, Arachnotron convinced me otherwise, based upon #2 above. The active line length for NTSC would be 14.32MHz*52.66usec=754 pixels. Using the BTwincap driver, one can actually cap NTSC at 754. However, if there is an active line shorter than 52.66usec, you may be in trouble.

In addition, testing (in this thread) clearly shows that for VHS source a capture size of 368 is overkill. This makes sense because of the bandwidth limits I've mentioned.

Another interesting point is that for the BT878, a 368 capture keeps quite a bit more resolution than a 720 capture and a last step resize. I'm waiting for Wilbert to tell me why. :)

---------------------------------

Anyhow, it appears we don't sync up on this stuff. That's ok, because sampling may be a minor item compared to post capture filtering. I'd say, getting the brightness, contrast, and color saturation correct has a much bigger effect on PQ than our differences on capture. :D

Feel free to correct me on any of the above. Maybe I'll 'get it', or it will help someone else.

[trevlac]

Originally posted by FredThompson
Didn't Ivo (or was it you) mention there is stretching happening if you try to get 720x480 from the Brooktree devices? It's not actually taking the 8 on either side, correct?

Actually, due to the open source drivers of the BT, there are some nifty ways to read the registers of the chip and see exactly what it is doing. I found it to be quite cool, but I'm a bit of a geek. :D

Arachnotron is being too modest about his 'little page'. It's a great piece of work. I didn't know it was done. :)

[Arachnotron]

@trevlac and Fred

I think I am beginning to see where Fred is driving at. Please correct me if I am wrong.

Note my previous post in this thread about the conditions which have to be fulfilled for Nyquist to apply.

The two samples per sinus breaks down if your sample is no longer a sampling point, but instead has a time window which approaches the wavelength of the signal you are sampling. If this is the case, it depends on what happens in this time window. If the voltage is followed in this window, and the final value is stored there is no problem.

But if either the highest value in the window is stored or the average value is stored you run into problems since you in effect introduce a second wave function over the one you are sampling (= sampling function ?).

So, what does the sampling function of real world ADC's look like?

Please note I am writing this without any knowledge about the actual workings of ADC's :)

As to hitting zero crossings and Nyquist: This happens only if the samplingrate is exactly 2 * source frequency.

But is this frequency the last frequency to work or the first to fail? I.E. are we dealing with a limit approaching sampling rate/2 ?

[trevlac]

Originally posted by Arachnotron
The two samples per sinus breaks down if your sample is no longer a sampling point, but instead has a time window which approaches the wavelength of the signal you are sampling.
One day I hope to be able to say something like that and think everyone will understand what the heck I'm talking about...:D You're going to get that EE degree someday. The hell with Fourier transforms.

Anyway, so you mean "2. The samples must be 'spikes', so no averaging the signal over a short time interval;" and what happens when we don't/can't use spikes?

Well I'll have to hit the books to understand this. You keep distracting me from my projects. ;)

As for #1 and #3, I'd say the aliasing we may encounter is not as bad as we think. After all, the cards oversample and filter no matter what you do. The question is, do you get more info from a bigger size for your VHS? Do you damage the picture due to aliasing if you do 1/2D1 vs D1? For both of these, I'm guessing no. I'm also trying to back my guess with tests. You keep getting in the way. :D

Funny thing is that I wanted to grab 754 pixels a few months ago. You got me straight on that. Have I gone too far the other way? ;)

[Arachnotron]

Anyway, so you mean "2. The samples must be 'spikes', so no averaging the signal over a short time interval;" and what happens when we don't/can't use spikes?

Yep, that's it. Its 4:30 am over here, so my communication skill's have died on me a few hours back :D

#3 is only an issue on (incorrect) playback, but may be mistaken for the result of incorrect sampling.

Tomorrow (monday) Ill play back some of my 6.xx MHz teststrips and see if the resulting signal is indeed a perfect sinus on the scope. Should settle the issue if it is, but doesn't prove it if it isn't.

[North2Polaris]

Originally posted by trevlac
Funny thing is that I wanted to grab 754 pixels a few months ago. You got me straight on that. Have I gone too far the other way? ;)

@trevlac,@Arachnotron,and Wilbert,

I thank you for the quality of the discussion in this thread. I suspect that we may see more of the senior members adding their perspectives to this discussion.

@trevlac,

As for as going too far the other way, some of your conclusions are starting to sound like some of the advice given at:

http://www.triuneweb.com/sites/lordsmurf-com/capture/software-resolution.htm

On this site, 352x480 is the recommended capture resolution for VHS,"if your software and hardware will give good results at that resolution".

Note the comment about the BT8x8 chipset on this site, "you're pretty much forced to use the maximum resolution of the cards, typically 720x480, if you want to maintain decent quality".

Capturing VHS at 368x480 is a bit heretical.

What next steps are needed to keep this discussion moving forward?

[FredThompson]

It's midnight and I'm having a little trouble following all the twists and turns of this thread. I think I might be coming down with the flu. Please keep that in mind.

yes, I know what I've typed seems jumpy. This would be so much easier to discuss if we were sitting togehter with paper and pen.

Yes, the example showing a null sample value from a 1x or 2x sampling frequency was an extreme example. Yes, also, to the bit about the characteristics of how the samples are generated is very important. When you boil it down, the capture hardware is measuring an analog voltage in a discreet amount of time, right? ok. Any time analog is converted to digital, there is an aspect of how a sample value is calculated for a given sample period but also how small those sample periods are.

Take a step back from the text or numbers of the theorems and draw a picture of a waveform. Mark some periodic sample points on the drawing then draw horizontal lines to represent that sampled value over time until the next sample is taken. That's what the hardware is doing, right? It's basically taking a sample and holding that value for a period of time. The collection of these samples is to represent the analog waveform. The more frequent the samples, the smaller the time they represent, the more accurately the samples as a set will represent the analog waveform.
Can 2 samples of a sine wave properly represent an analog signal? The answer is yes, because no other sinusoid, or combination of sinusoids, will produce this pattern of samples. These samples correspond to only one analog signal, and therefore the analog signal can be exactly resconstucted. AKA, you need to sample at 2x the highest frequency.Can 2 samples of a sine wave properly represent an analog signal? The answer is yes, because no other sinusoid, or combination of sinusoids, will produce this pattern of samples. These samples correspond to only one analog signal, and therefore the analog signal can be exactly resconstucted. AKA, you need to sample at 2x the highest frequency.No. Think of how active noise cancellation works by generating an opposite wave. Thus, there are multiple combinations to reach any value with a common sampling method if you have multiple concurrent waves. For single waves, you could identify commonality similarly to what you suggest here but not recreate unless you are working with pure frequency modulation. If amplitute is different, 2 unique waves could return the same instantaneous samples but be very different.

Think about how NTSC composite comb filters work. Because of domain overlap, it's impossible to separate the signals properly, right?

wrt, variable length lines. I was trying to communicate the lack of enforced horizontal clock creates a slight randomization of the analog stream as it relates to the actual subject it is supposed to represent. If you shoot VHS footage with a tripod of a perfect vertical edge then capture it via analog playback, the samples within each scanline which are supposed to line up exactly, won't. The same thing can happen with pure digital video depending on the resolution of sampling but it's not as pronounced. Think of high-end audio cassette decks like the Nakamichi Dragon. It's got all kinds of controls to normalize the position and movement of the tape because distortion is introduced by every analog aspect of the information transfer. The same thing happens with video tape. Maybe the tape is a little off-position, maybe a spindle binds just slightly for a second, maybe some of the carrier fell off the tape, maybe there's a kink in the tape, etc.

All this discussion is interesting but irrelevant if the Brooktree's really do only capture at one resolution and scale everything after that. Frankly, that would be the smart way to create the circuitry. It would be less expensive. If that is indeed the case, the least lossy way to do your capture would be to use that resolution, ensuring the drivers don't modify it.

[trevlac]

@North2Polaris

I've had some discussions with LordSmurf. He writes well, but seldom backsup what he has to say with any reference. He almost exclusively uses ATI cards and software for DVD. His comments on the BT8x8 are not based on in depth knowledge. So, I might agree with some of his conclusions, his basis is unknown. He generally just says 'he knows'. I am trying to match a basis to test results. :)

As far as 352 vs 368, the BTwincap driver turns on a filter when you drop the resolution below 362. This can be observed with some tools that read the registers of the chip. This filter effects the vertical resolution even though you are not changing that. So, LS is correct that 352 is 'worse' than 720 even for VHS. This is because VHS has the full 480 resolution and the BT with the filter on does not. Horizontal resolution for the BT with the filter on is still better than VHS. :)

368 is no more 'odd' than 712. 712 is a good number to use for the BTwincap because is matches the captured line length. 368 cropped to 352 will give a bit of a stretched picture, but you don't have to resize after (which oddly enough seems to give less resolution). The stretch is not as much as you might think. 712/2=356, so it's 12 pixels not really 16.

As far as moving forward, my inital intent was to see where I am wrong. My proposition seems very reasonable. I intend to take a good look at Fred's comments. From a quick read, his latest post might be what I was looking for. :)

Thanks


@FredThompson

I can relate to the not feeling well. I had a terrible headache most of yesterday. I appreciate you sticking with me. I need to think about your latest post a bit. I will do some reading to make sure I am following you, before I respond to your latest.

An interesting point about what 'the cards' do is that most all probably capture a 1 resolution and scale to what you ask. Probably for the economic reason you pointed out. :D

I'd guess this is the case for new ATI chip cards, BT8x8, CX cards, and (consumer) Philips based cards and DV devices. I'd have to read more about Philips specs to comment on them. I don't own one of them.

[Arachnotron]

As far as 352 vs 368, the BTwincap driver turns on a filter when you drop the resolution below 362. This can be observed with some tools that read the registers of the chip. This filter effects the vertical resolution even though you are not changing that. So, LS is correct that 352 is 'worse' than 720 even for VHS.

As I understand it, teh BT878, fusion878 and the CX23881 all have this feature. It is controlled by the SCLOOP register in the 878's and the HFILT register in the CX23881. It is not a smooth transition, but changes at certain resolutions.

00(1) = Auto Format. If you select auto format when horizontally
scaling between full resolution and half resolution, select
no filtering. When scaling between one-half and
one-quarter resolution, use the CIF filter. When scaling
between one-quarter and one-eighth resolution, use the
QCIF filter; and at less than one-eight resolution, use the
ICON filter.
01 = CIF
10 = QCIF (Required for SECAM)
11 = ICON

The Philips SAA71xx do something similar (at least those with a scaler) controlled by the AAF register.

The
filter depth of the anti-alias filter adapts to the scaling ratio,
from 10 taps horizontally for scaling ratios close to 1 : 1, to
up to 74 taps for an icon sized video picture.

Unfortunately, the description of the AAF register is in the User manual (not the Data Sheet) which I have been unable to find. So I have no idea if this filter works continuosly as a function of resolution or swithches at certain fixed resolutions as the BT878 seems to do.

Anyone, please ??? :D

[trevlac]

@Arachnotron


Interesting quote from the manual. As I understand it, CIF and QCIF are 1/2 and 1/4 in both directions. It suggests turning the filter on regardless if you are doing vertical.

As far as the time of the impulse used to sample (#2 in your prior post), the best as I can tell is that the length does effect the signal, possibly by changing the phase. This seems to be taken care of when the DAC takes place. Can you give a link to where this is pointed out as a problem? Most of the sources I can find gloss over this. I'm assuming with current electronics this is not a problem. I was looking at the BT spec to see what they do about it.


@Fred

It seems we have a fundamental difference. My statement "Can 2 samples of a sine wave properly represent an analog signal? The answer is yes, because no other sinusoid, or combination of sinusoids, will produce this pattern of samples." Was basically a quote from the source I posted. You seem to disagree with this source, saying that streight lines are used to recreate a signal from samples (not sine curves). If streight lines were used, I'd suppose that the more samples the better. However, It is my understanding that based on work by Fourier, sampling theroy continues that most waves can be modeled as the summation of sine waves. And that given 2 samples per wave, only 1 wave fits this pattern.

However, It does seem we have gotten off track a bit. :D I'd like to restate my premise and reasoning.


Analog video signals have limited information/bandwidth/resolution.

Few signals contain more information than a 640 frame size can contain.

BT chips don't capture any information above a 640 frame size


Reasons

Analog signals have a (generally known) limited bandwidth. This can be directly equated to TVLines which is a measure of resolution. TVL can be directly related to pixel frame size.
BT specs say it filters frequencies above 6MHz
Nyquist is an interseting way to look at this. If you believe pixels are samples, and that reducing the number of pixels reduces the effective sample rate, then you can also talk about required frame sizes from maximum frequencies using nyquist. I fully admit that this ignores the problems of syncing vertical lines and filtering high frequencies. However, the effect of these problems maybe outside of anything we can do, because the cards and drivers either take care of them or don't.


I have posted quite a few sources and will organize them if anyone wants. If you could give sources that I could read that would be great. The one you posted didn't seem to back what you were saying. It is however, difficult to go into much depth in a forum.

line timing
Arachnotron understand this better than me. But this is what the BT doc says:

UltraLock accommodates line length variations from nominal in the incoming video by always acquiring more samples, at an effective 4 × Fsc rate, than are required by the particular video format and outputting the correct number of pixels per line. UltraLock then interpolates the required number of pixels in a way that maintains the stability of the original image despite variation in the line
length of the incoming analog waveform.

So maybe we are just talking about Nyquist for different purposes. I'm interested in what happens after ultralock. Namely, asking for a smaller frame size, because there is no more information in 720 pixels than in 368 pixels for a VHS tape. This is in effect asking for a lower sample rate after nasty things like syncing lines and filtering high frequencies.

As anyone can see, the practical implications is much more interesting than the theory. :D Hopefully the discussion I center around a BT878 can be applied to other chips and cards.


@Arachnotron / @Fred,

I really want to thank you for your feedback. I do tend to try to simplify. You've forced me to read some really good references quite a few times. Each read removes the clouds about Digital Signal Processing. On my next read I may fully understand convolution. (And filter) :D

I do want to print quite a few pdfs to make for easier reading. Here is a great pub you can get for free:
http://www.dspguide.com/pdfbook.htm

That's the full chapter list of the one I mentioned you can get from amazon for about $50 IIRC.

[FredThompson]

@trevlac, I'm really quite sick right now and can't think through your last post. However, I think I now see what's happening.

Your comment about 2 points representing a sine wave relates to plugging those values into a function, doesn't it? Your capture card doesn't derive or return functions. There's no f(x) return from the card, you get a set of values.

[Arachnotron]

@everyone: long post alert, sorry! :eek:

@Fred,
Get well soon :) The fact that you are even bothering to post is greatly appreciated.

@Trevlac,

I could not find the site again. They were PPT slides from some sort of university course. But this this (http://www.usna.edu/Users/ee/cameronc/EE462/ExtractsOnADConversionForLecture.pdf) link gives a nice summary of things that can go wrong with ADC's.

@Trev, Wilbert and Fred,

I don't know the first thing about filters. The comments below are based only on my limited experience with curve fitting. Is what I propose technical possible? Or my use of the terms phase and taps? :confused:

In the course of this discussion I have gained more understanding of the operations of capturing devices. I want to have a final stab at painting a simplyfied picture of how I think a BT878 works and the concequences for capturing. Some of it is pure speculation though.
To do that, I first have to explain a bit about how I think interpolation works. I will try to keep the math to a minimum.
To quote Trevlac: this is what I believe today :)

Interpolation
-------------
As an example I'll try to explain polynomial curve fitting, the most simple case (and the only one I have ever used :D )

suppose you have a set of 7 luma values plotted against time,( sampled at 7 MHz). You want to resize them to 4 values (4 MHz). These 4 values would fall somewhere between the original 7 values, on different times. But at these timepoints you have no samples.

The simplest way to do this would be to drop three samples, but this would cause everything to shift horizontally and ruin aspect ratio.

The next thing to try would be to connect the points using straight lines and look up the luma values in the resulting graph for the 4 timepoints we are interested in. As long as you are resizing in small steps, this would work but for big re-sizes you would base an interpolated luma value only on it's two neighbours in the original samples and ignore some of the other samples. Also, if one luma sample were to have an extreme value compared to the rest, it would be over represented in the scaled luma points. Try plotting this to see what I mean.

The third option would be to use something like polynomial regression.
Suppose you have a function A +Bx +Cx^2 +DX^3 + EX^4 +FX^5 (= 6th order polynomial)
x is the time in this equation, A-F are constants that you can calculate by curve fitting this equation to the 7 datapoints. Once you have done this (how is not important for this story), you have values for A-F. Fill in the values in the equation and you have a function which describes a smooth line that touches all points and generates a luma value for each timepoint between the original samples. By filling in this equation you can calculate a luma value for every timepoint you want.
Also, this function will be smooth and have no sudden changes in direction but is flexible enough to be able to touch all 5 points.
Now take away the last component, FX^5, and fit again to the 7 points. The resulting function is less flexible, and will follow the trend of the 7 points and even touch some of them but if one of the 7 points has a really different value from the others it will not be able to reach it.

The more components you take away, the more rigid the line becomes untill finally it is a staight line. See this link (http://www.availableengineers.com/id38.html) for a calculator with plotting you can play arount with. n is the number of components on this page.

What is the netto effect of this?
1. it allows you to calculate luma values for timepoints you have no samples for
2. it allows you to filter out single extreme luma values. In effect, you create a band-pass filter! The less components you put in the equation, the more inflexible the line becomes and the more it follows only the general trend of the luma values while ignoring fine detail.
3. it allows you to base a single interpolated point on many different samples. This becomes important when you are downscaling extremely, say to icon size. You could take 40 samples, fit an extremely inflexible low order polinomial to it and use it to calculate only a single pixel.

A real world capture device will not use polynomial regression ( to much calculations, prone to oscillations), but some other algorithm (= calculating method). But the basic principle is the same: use a function which is a summary of components (polyphase?). By decreasing the number of components (phases?) it becomes more rigid and will not be able to change rapidly enough to follow certain frequencies (low pass filter). It will be fitted to a window containing a certain number of samples (Taps?) and can be used to calculate interpolated samples (re-sizing!)

Back to the BT878
-----------------
The BT878 samples at 28.6 MHz. This gives on average 28.656 MHz *63.555 µs = 1820 samples per scanline. It has 4 filter algorithms to use at different frequencies. The basic one for high frequencies is a fairly flexible one and will accommodate changes up to 5 MHz. When the resolution drops below CIF, a second one is used. this one is less flexible, and cannot follow luma changes faster then 4 MHz. Etc. etc. The number of taps has to go up as the frequency goes down. At icon size, an extremely inflexble curve is fitted to a large number of sample points (50-100?).

So when you request 712x480 with BTwincap, the following happens: the resolution is above CIF, so the most flexible interpolation filter is used. 712 pixels per active window means 856 pixels per complete line. (this is set by the HSCALE register) so using this filter, and moving along the line TAP number of pixels per calculation, 856 pixels are interpolated from the original 1820. Any luma fluctuations above 5 MHz ale lost at this point.
HDELAY gives the number of pixels that have to be cropped from the left, and HACTIVE=712 gives the number of pixels after that that. Those are send to the PCI bus.

This is an oversimplification of the reality; in the real world, combfiltering also takes place in this step.

Ultralock
----------
Ultralock keeps track of the number of samples between to successive Horizontal sync pulses. Because of mechanical variations, this number will vary slightly with line length from line to line. If the number of samples is lower or higher then 1820, the interpolation is adjusted in such a way the 856 pixels are interpolated from however many samples are there.
There is a catch however: the number of requested pixels per line MUST be lower than the number of samples/2, or ultralock will fail.

The result of this is that you can never aligh your pixels with the original samples, since this number varies from line to line!

Final conclusions
-----------------
- capping slighly above CIF resolution will give more detail than slightly below, because below CIF, higher frequencies are no longer taken into account by the filter when interpolating. Some of this detail may be noise or aliassing, I am not sure about that.

- since the pixels are always created by interpolation, capping near the original sampling rate does not offer any special advantages.

-Capping directly at 356 will be more accurate than capping at 712 and resizing. At 356, each pixel is based upon TAP * the original luma samples surrounding it (and also upon some of the neighbouring scanlines because of the comb filter). If you cap at 712 and re-size, you have already reduced the amount of information available to 712 pixels.
Once again, this is not considering the resolution needs of post-processing filters.

Philips chips
-------------
I believe the basic operation is the same, only at 27 MHz. I have no documentation about the actual implementation of the filters used, apart from the fact that the number of TAPS for horizontal scaling varies from 10 at high res to 74 at icon size.

The algorithms used are probably different, since at least the SAA7134 will re-size above sampling rate/2.

Some conexant trivia
--------------------
the Luminance horizontal scaling filter of the BT878 is 6 tap, 32 phase interpolation , for the CX23881 it is ? tap, 64 phase.

Phew! Got that off my chest :D

[Wilbert]

The third option would be to use something like polynomial regression.
Suppose you have a function A +Bx +Cx^2 +DX^3 + EX^4 +FX^5 (= 6th order polynomial)
x is the time in this equation, A-F are constants that you can calculate by curve fitting this equation to the 7 datapoints. Once you have done this (how is not important for this story), you have values for A-F. Fill in the values in the equation and you have a function which describes a smooth line that touches all points and generates a luma value for each timepoint between the original samples. By filling in this equation you can calculate a luma value for every timepoint you want.
Ok. But I still don't understand how this works. In the specs they talk about a 6 tap, 32 phase interpolation filter. I don't know what the number of tabs stands for.

If you look at:
http://www.cs.tut.fi/kurssit/83080/Polyphase.pdf

They define L to be the exponent of the filter H, or

L = downsampling / upsampling ratio (which is apperently 5 for the luma component here)

and then

H(z) = A + Bz^(-1) + Cz^(-2) + Dz^(-3) + Ez^(-4) + Fz^(-5)

If I understand it correctly you can define a m-phase decomposition as:

H(z) = H0(z) + z^(-1)*H1(z) + ... + z^(-(m-1))*H(m-1)(z)

Note that m=6 at maximum here (in that case Hj(z)=constant). As for the name phase: applying a delay, alters the phase of your process. Thus z^(-0), z^(-1), ..., z^(-(m-1)) gives m different phases, hence the name polyphase filter. But, I'm just guessing here.

What I don't understand is, how you can have a 32-phase interpolation filter here? Or does the m=6 indicates the maximal number of taps.

It's late, I have to go to bed :(

[trevlac]

@Arachnotron, Wilbert

You people make me stay up too late and think too hard. How can I sleep with so many questions in my head? :)

Here is my take. Forgive me if this is too basic. I am really just tackling the subject of Digital Signal Processing.

Background

FIR filters - Are a general class of 'filters' that basically are a matrix of fractions (coefficients) whose sum is generally 1. For example, a 1 dimensional mean filter would be 1/4,1/4,1/4,1/4. A 1 dimensional Gaussian filter would be 1/4,1/2,1/4. Both are FIR filters.

TAPs are the number of coefficients used , OR the 'order' of the filter + 1, OR the number of pixels/samples needed where some are 'delayed' (aka, to work on pixel #3 with 3 taps, we need pixel #3, #4, & #5). For example, the above mean filter uses 4 taps, and the Gaussian uses 3 taps. I quote "more taps means more stopband attenuation, less ripple, narrower filters" this (http://www.dspguru.com/info/faqs/fir/basics.htm) great description.

Convolution is the process of `multiplying together' two arrays of numbers. When you convlute a FIR filter with a set of pixels, you are in effect adjusting the pixels by a weighted average of themselves and their neighbors. The weights are the coefficients (taps) of the filter.

The above filtering can be lowpass, highpass, ect., based upon the coefficients. You look in the frequency domain with a DFT to get the filter response, but I'm not to clear on that. :) The Gausian and mean filters are low pass.

Here (http://www.dai.ed.ac.uk/HIPR2/convolve.htm) is a good link on this stuff. Also, the vdub filter sdk tutorial gives a nice example and some more detail.

Polyphase decimation

-- Now, here I'm guessing a bit -- :D

Since a FIR filter it's self is a wave form, it can be decomposed into multiple parts or phases. What this looks like I'm not sure. It may be the full 6 taps of the base filter, or just 1 tap.

For say 1/3 decimation, every third sample is then feed into 3 of the avaliable 32 phases. I assume the other phases do not contain any parts of the filter, and the 3 used phases have filters. I'm not sure if these are different filters that act on different frequencies or what. After convolution, the values are summed to get the resulting 1 sample.

For say 2x interpolation, 2 of the possible 32 filter banks are used. One is feed the known sample values, and the other is feed zeros. The results are again summed.

For non integer decimation, say 2/3, the samples are 1st interpolated at 2x and then decimated as 1/3. From this I'd say that 32 phases gets you the flexibility to do non integer sizes that 'fit' into 32 up and down sample phases.


------------------
Now I need some sleep.......:)

Edit
I cleaned up a few things.

I want to make it clear. I don't fully comprehend Arachnotron and Wilberts posts. It seems we have different prespectives and are circling the same subject 'how the heck does a resize of samples work, and what does it mean?'

More edits, fixed the def of Taps abit.

[Arachnotron]

@Trevlac and Wilbert:

I feel a general principle emerging: DSP is detrimental for your beautysleep :)

Thanks for the replies! The math is, as usual way beyond me but your links enabled me to verify if at least some of my conclusions were correct. I love this forum :)

First, low pass /anti alias filtering and interpolation/decimation are indeed sides of the same coin. If or how the number of Taps and Phases control this is beyond me, but nevertheless the basic conclusion is correct. The BT878 aparently ads a notch to the low-pass filter every time the resolution drops below the Nyquist limit i.e. is reduced by two. the divisions would be 28/14/7/3.5MHz but to avoid problems around the switchpoint the first filter has a lower cut-off, 5 MHz instead of 7.

Second, since all pixels are filtered, even when you choose a resolution which is in phase with the original unfiltered samples, there is indeed no point in trying to match this resolution as Fred suggested.

Third, the ultralock process is also connected to this interpolation step. When I re-read the BT878 datasheet, I found the following line hidden on page 18:
Horizontal scaler: A + BZ^-1 + CZ^-2 + DZ^-3 + EZ^-4 + FZ^-5 with the note: Z-1 refers to pixel delay in the horizontal direction, and a line delay in vertical direction. The coefficients are determined by Ultralock and the scaling algorithm.

According to Trevlac's link, this is a 6-tap FIR filter (point 2.2.1) and ultralock does also infuence it.

As to the integer/non-integer decimation: Both the SAA7114 and the BT878 datasheets mention a two step approach with prefiltering for anti-alias reduction. The Phillips datasheet however does both an integer resize and an anti-aliassing in the prefilter step and a second fine resize if needed afterwards. Both steps are 6 bit phase = 64. If the BT878 does the same is not clear.

About Trevlacs remark about how the number of phased determines how accurately you can position your interpolated sample (= pixel jitter): A roundup of datasheets produces this:

BT878, 6 tap 23 phase, jitter < 6ns (p19)
CX23881, 6 tap 64 phase, jitter < 4 ns (p2-96)
SAA7134, "the phase accuracy of the re-sampling process is 1/64 of the original sampling distance or less than 1 ns"
SAA7114, which is very similar, mentions a 6 bit phase accuracy and 1 ns jitter, and 10 tap 64 phase elsewhere in the sheet

If so, the number of phases alone does not determine jitter. Perhaps it is phases and taps both?
Why the SAA7134 mentiones a variable number of taps between 10 and 74 while the others seem to have a fixed number of taps (even the saa7114) is also something I dont get. Maybe they intended phases?


In any case, I can recommend the datasheet of the SAA7114 here (http://www.semiconductors.philips.com/acrobat/datasheets/SAA7114H_1.pdf) for a blow-by-blow description of the SAA scaling process. I don't understand a word of it, but it looks impressive :D. No other SAA71xx datasheet contains this info. See page 37-49.

From it I get the impression that the Philips can be programmed to use a sliding approach to anti-aliassing, in contrast to the stepped approach used by conexxant. This may account for the smooth look reported by some SAA users.

[trevlac]

Here is some more info.. Maybe someone else can put it together.

Originally posted by Arachnotron
When I re-read the BT878 datasheet, I found the following line hidden on page 18:
Horizontal scaler: A + BZ^-1 + CZ^-2 + DZ^-3 + EZ^-4 + FZ^-5 with the note: Z-1 refers to pixel delay in the horizontal direction, and a line delay in vertical direction. The coefficients are determined by Ultralock and the scaling algorithm.
....
In any case, I can recommend the datasheet of the SAA7114 here (http://www.semiconductors.philips.com/acrobat/datasheets/SAA7114H_1.pdf) for a blow-by-blow description of the SAA scaling process. I don't understand a word of it, but it looks impressive :D. No other SAA71xx datasheet contains this info. See page 37-49.

The equation is the 'transfer function' of the filter.

A, B, C, etc are the coeffiecients. For example, for the Gausian filter 1/4,1/2,1/4 ABC = 1,2,1 with no gain (they add to 1). I believe coeffiecients are given in the Philips spec you posted on page 43.

Z^-1 is a reference to the pixel/sample 1 before the current pixel.

See This (http://www.dsptutor.freeuk.com/digfilt.pdf) excellent guide.



About Trevlacs remark about how the number of phased determines how accurately you can position your interpolated sample (= pixel jitter): A roundup of datasheets produces this:

BT878, 6 tap 23 phase, jitter < 6ns (p19)
CX23881, 6 tap 64 phase, jitter < 4 ns (p2-96)
SAA7134, "the phase accuracy of the re-sampling process is 1/64 of the original sampling distance or less than 1 ns"
SAA7114, which is very similar, mentions a 6 bit phase accuracy and 1 ns jitter, and 10 tap 64 phase elsewhere in the sheet

If so, the number of phases alone does not determine jitter. Perhaps it is phases and taps both?

I'm not sure about jitter. Maybe I should try to figure this out :)


Why the SAA7134 mentiones a variable number of taps between 10 and 74 while the others seem to have a fixed number of taps (even the saa7114) is also something I dont get. Maybe they intended phases?
....
From it I get the impression that the Philips can be programmed to use a sliding approach to anti-aliassing, in contrast to the stepped approach used by conexxant. This may account for the smooth look reported by some SAA users.


Here is an interesting quote I found.

For linear phase filters under a fixed impulse response length equal to N, it is only possible to realize (N-1)/2 different cutoff frequencies.

N is the order of the filter, or Taps - 1 , or # of coefficients - 1.

The above basically says you get steps of frequencies based on taps. I assume using different coefficients gets you different frequency steps.

Perhaps Philips uses a non-linear filter, or changes the coefficients.

----------------------------

@All

For any humans out there trying to follow this (such as myself), I found an great short summary of Digital Signal Processing. It contains very little math and is almost in english. :D

http://www.bores.com/courses/intro/index.htm

[Arachnotron]

.... and dsp does terrible things to your printer too.. :)

@Trevlac,

Thanks for yet another set of great links.

I have been studying them, but I think I have gone as far as I can go in understanding this without actually doing the math, programming a filter and looking at the responses. which I fully intend to do, once I can find the time for it :(

For now at least these discussions have given me a good general idea about how capture devices operate. And made me apreciate the SAA7134 more (this forum tends to be a bit biased towards the BT878 :D )

I'll post my oscilloscope pics in this thread as soon as I have them to add some empirical data to the theoretical one about Nyquist limits.

[FredThompson]

Time for me to bow out. Haven't done this kind of math in 15 years.

[jggimi]

Well, I've been follow these math and electronics threads, with interest but without any comprehension whatsoever.:scared:

I'm hoping when all of you finally figure it out, you make it simplistic and easy-to-understand for the ordinary capture card owner.
:thanks:

[Wilbert]

Time for me to bow out. Haven't done this kind of math in 15 years.

Fred, it's not about the math. But about the meaning of the filters and other things. Understanding the math makes it just a tiny bit easier for me :)

I want to make it clear. I don't fully comprehend Arachnotron and Wilberts posts. It seems we have different prespectives and are circling the same subject 'how the heck does a resize of samples work, and what does it mean?'
Yeah. I also don't comprehend our posts fully :)

In this link you posted:


Tap - A FIR "tap" is simply a coefficient/delay pair. The number of FIR taps, (often designated as "N") is an indication of 1) the amount of memory required to implement the filter, 2) the number of calculations required, and 3) the amount of "filtering" the filter can do; in effect, more taps means more stopband attenuation, less ripple, narrower filters, etc.)
IOW, indeed the number of coefficients.

Ok, let's consider decimating:


For say 1/3 decimation, every third sample is then feed into 3 of the avaliable 32 phases. I assume the other phases do not contain any parts of the filter, and the 3 used phases have filters. I'm not sure if these are different filters that act on different frequencies or what. After convolution, the values are summed to get the resulting 1 sample.
Part of my problem is that I don't understand the meaning of those 32 phases.

You are probably correct, but I'm trying to connect it to the stuff they say in the links. On page 4 of the link above

http://www.cs.tut.fi/kurssit/83080/Polyphase.pdf

"So in the i-th branch, the input signal is delayed by z^(-i), downsampled by L, and filtered using Hi(z)."

Those Hi(z) are convoluted, as illustrated in the diagram on page 5:


-->

H0(z^3) --> H0(z) ------------->
z^(-1) --> H1(z^3) --> H1(z) -->
z^(-2) --> H2(z^3) --> H2(z) -->

--> convolution -->


I hope the diagram is clear. Note L=3, and i=0,1,2 in this example. Note that they use the word "branches" instead of "phases".

Are you saying that there are 32 of those brances (thus 32 coefficients Hj(z^3))? In that case your have at least 32 constant coefficients instead of 6. Unless the six coefficients: A,B,C,D,E,F are not constant and depend on z (as in the diagram)?

On page 1 they give the advantage of the polyphase interpolating/decimating stuff:

"(...), the idea in the polyphase structures is to splite the related filtering into L parallel stages operating at the _lower_ sampling rate."

"In the traditional approached, the decimating/interpolation filters operate at the _higher_ sampling rate, i.e., before down-sampling or after up-sampling."

So, I guess the use of _polyphase_ decimators/interpolators is only a speed issue.

Back to a comment of Arachnotron:

-Capping directly at 356 will be more accurate than capping at 712 and resizing. At 356, each pixel is based upon TAP * the original luma samples surrounding it (and also upon some of the neighbouring scanlines because of the comb filter).
I also don't understand this. You are saying that no information is lost here? I thought you are also decimating in this case, i.e. throwing away half of the samples?

[QUOTE]If you cap at 712 and re-size, you have already reduced the amount of information available to 712 pixels.
True, of course.

[Arachnotron]

@Wilbert:

I posted:

-Capping directly at 356 will be more accurate than capping at 712 and resizing. At 356, each pixel is based upon TAP * the original luma samples surrounding it (and also upon some of the neighbouring scanlines because of the comb filter).

You replied:
I also don't understand this. You are saying that no information is lost here? I thought you are also decimating in this case, i.e. throwing away half of the samples?

I posted:
If you cap at 712 and re-size, you have already reduced the amount of information available to 712 pixels.

I am not sure my use of the term TAP was correct in this case. I suspect it was not :)

I think decimating through interpolation is not throwing away information. I't more condensing of information. It differs from simply dropping every second sample.

But - and this is 'gut feeling' without any mathematical basis - once you have locked the original information in 712 samples, you loose some information (freedom?). Also, there is always an uncertainty, an error in interpolation which is added to those 712 samples. So you enter the second round, the re-size to 356, with some extra errors and somewhat less information then you would have if you scaled the 356 samples directly from the original samples.

All in all a rather confused story, but then I don't understand the math :(

Edit I'm not sure if I am replying to a comment made by Wilbert or Wilberts comment on somebody else's comment.:confused:

[trevlac]

@Wilbert

I think you understand the math better than me. But as this continues, I think I 'get' a little more every day. I'm glad you brought some life back into this, because I too am a little burned out. :)

Please understand, I am trying to put the pieces together. A lot of what I say are guesses. Here are some items to make my guesses clear. They my however be incorrect guesses. :D Note that some of this may be a futher stretch of what I said before.

Originally posted by Wilbert
Ok, let's consider decimating:


Part of my problem is that I don't understand the meaning of those 32 phases.

You are probably correct, but I'm trying to connect it to the stuff they say in the links. On page 4 of the link above

http://www.cs.tut.fi/kurssit/83080/Polyphase.pdf

"So in the i-th branch, the input signal is delayed by z^(-i), downsampled by L, and filtered using Hi(z)."

Those Hi(z) are convoluted, as illustrated in the diagram on page 5:



I hope the diagram is clear. Note L=3, and i=0,1,2 in this example. Note that they use the word "branches" instead of "phases".

Are you saying that there are 32 of those brances (thus 32 coefficients Hj(z^3))? In that case your have at least 32 constant coefficients instead of 6. Unless the six coefficients: A,B,C,D,E,F are not constant and depend on z (as in the diagram)?


I'm saying that given a 720 sample line you 1st 'decimate' it by seperating out every 3rd sample. So now you have 3 240 sample lines. Next you take your great filter and seperate it into 3 parts. If it had 6 taps, you now have 3 2 tap filters. Next convolute the 'lower sampling rate' lines with the parts of the filter. Finally, sum the 'filtered' sample lines to get your 720 sample line decimated and filtered to 240.

So, in this case you only use 3 of your 32 phases/banks. If you want to use all 32 phases/banks because you have a strange ratio 'like going from 754 to 368', AND you only have 6 taps to your filter, you use zero as the coefficients in the xtra 'taps'. This of course implies that you don't actually calculate anything for more than 6 banks.

Now this is a bit of guessing on my part, but it is based on the idea that a FIR filter is finite because the 'ends' past the given coefficients are assumed to be zero.


On page 1 they give the advantage of the polyphase interpolating/decimating stuff:

"(...), the idea in the polyphase structures is to splite the related filtering into L parallel stages operating at the _lower_ sampling rate."

"In the traditional approached, the decimating/interpolation filters operate at the _higher_ sampling rate, i.e., before down-sampling or after up-sampling."

So, I guess the use of _polyphase_ decimators/interpolators is only a speed issue.


It is clear that it is a speed thing, but does this allow for a better filter to start? Also, do the coefficients change base upon the size you are going for? They seem to hint that there are other advantages, but I can't really fathom them.

I wish I could just whip up a vdub/avisynth resize filter and do some tests. :D But this tread keeps pulling me away from C++.


On Arachnotron's comment

It does seem like a resize from 'all of the samples' to say 368 DOES use the info in all of the samples, vs what a resize from 712 does. Also, the cutoff of the coefficients may be higher than that of a bi-linear resize. Aliasing may infact be taking place.


What do you think ?

[Wilbert]

I'm saying that given a 720 sample line you 1st 'decimate' it by seperating out every 3rd sample. So now you have 3 240 sample lines. Next you take your great filter and seperate it into 3 parts. If it had 6 taps, you now have 3 2 tap filters. Next convolute the 'lower sampling rate' lines with the parts of the filter. Finally, sum the 'filtered' sample lines to get your 720 sample line decimated and filtered to 240.

I think this is correct. Depends how those 32 phases come into play though.

A few small comments:

So, in this case you only use 3 of your 32 phases/banks. If you want to use all 32 phases/banks because you have a strange ratio 'like going from 754 to 368', AND you only have 6 taps to your filter, you use zero as the coefficients in the xtra 'taps'. This of course implies that you don't actually calculate anything for more than 6 banks.
What do you mean with banks here? What I called "branches" in the previous post?

Let's consider these two questions:

Also, do the coefficients change base upon the size you are going for?

I think so.

Given a size, do the coefficients change base upon the pixel you consider.
Both you and Arachnotron think that they are constant. I'm not totally convinced however. The answer is trivial if we know what "6 tap, 32-phase interpolation" means (especially the latter part).

Let me ask a simple question, which is easier to answer:

What is the maximal decimate ratio you think the filter can use. Is it 6, because of the 6-tap filter? What would be the corresponding capture size? If not, how could the filter decimate by 10 for example?

[Arachnotron]

What is the maximal decimate ratio you think the filter can use. Is it 6, because of the 6-tap filter? What would be the corresponding capture size? If not, how could the filter decimate by 10 for example?

Maybe I am interfering in a discussion I no longer understand, but what the hell..

Since icon is a valid resolution (32x32), more than 6 must be possible.

What do you mean with banks here? What I called "branches" in the previous post?

Could this simply be related to Fifo space? I remember reading in the SAA7114 sheet that the scaler has a "FIFO, 32 bit wide, with 64 pixel capacity in YUV formats". This scaler is 64 phase. Coincidence?

[Wilbert]

Since icon is a valid resolution (32x32), more than 6 must be possible.
Yeah. Decimating with 10 for example, can be obtained by decimating twice: first by two (6-tap and 4 coefficients zero) and then by five (6-tap and 1 coefficient zero). I guess decimating by 7 is impossible for example.

Could this simply be related to Fifo space? I remember reading in the SAA7114 sheet that the scaler has a "FIFO, 32 bit wide, with 64 pixel capacity in YUV formats". This scaler is 64 phase. Coincidence?
What's fifo space? I'm at work now, so I can't look it up. What does the bt 8x8 say about this? I didn't realise it, but they call it "32 phase interpolation". So, it has something to do with interpolation :)

@trevlac,

I changed my mind. The coefficients are always constants. Doesn't depend on the size you are going for, i.e. indepedent of the decimator factor.

What changes however, are the coefficients of:
If it had 6 taps, you now have 3 2 tap filters.
the 2 tap filters. Decimating with 2 gives you for example 2 3 tap filters, with (obviously) different coefficients as the 2 tap filters.

[Arachnotron]

What's fifo space? I'm at work now, so I can't look it up. What does the bt 8x8 say about this? I didn't realise it, but they call it "32 phase interpolation". So, it has something to do with interpolation

First-in-first-out. Sort of an intermediate storage space for things that "flow' continuously.

a chip like the BT878 has several of them for different purposes. They limit the amount of data that can be stored at one operation. There are other ones to buffer between the chip and the PCI bus; those must be able to hold one line (or one frame?) at max resolution.


Apparently, the scaler of the 7114 is able to store a maximum of 64 pixels per calculation pass.

[trevlac]

@Wilbert

I'm limited on time, so I will post some more info later.

There might be 2 Things mixed in the statement "32 poly phase interpolation", and our discussion.

Phases==Banks<>Branches:

Are these just holding places/registers on the chip/memory? I'm not sure what the 32 means right now. I'll look at the BT spec. (Again :) )

Maybe the process works like this:

If you resize by a non-integer, you must interpolate up 1st and then decimate down. Going from 16 to 5/8 of 16 would require you to go up to 16*5=80 and then convolute down to 80/8=10. For 16*5 you get 1 real value followed by 4 zeros: ie 128,0,0,0,0,134,0,0,0,0 ... Then when you decimate using a 6 tap convolution, you seperate out every 8th pixel into 8 rows of 10. Now if you only have 6 taps, you only calculate the new pixel value using the 1st 6 rows. This implies you have to hold 48 values at a given time. If you use 4 taps, I guess you only need 32 values at once. The problem with this is that unless maybe you convolved the interpolation step, I'd think you'd get zero values for some pixels.

Maybe for big ratios, it happens multiple times as you mentioned.

For simple decimation, I have worked out a few samples and they work the way I think.


Convolution:

I would like to go over this so everyone can follow, because you can manually calculate what the card is probably doing. Below is a link to a convolution calculator.

http://www.softintegration.com/chhtml/lang/lib/libch/numeric/CGI_Conv.html

For now, it looks like using .25,.5,.25 taps on a 12 pixel line of say (0.1,0.2,0.3,0.4 ... 1.2) gives you the same results if you convolute 1st and then decimate OR if you break the coefficients and lines up as (0.1,.5,.9)*.25 + (.2,.6,1.0)*.5 + (.3,.7,1.1) * .25. This example is a decimation by 1/4. 12-->3 samples. Notice, that we just ignore the 4th row or 3 samples.

I will post a clear explination so that @Anyone can follow. :D

[trevlac]

Originally posted by Arachnotron
Maybe I am interfering in a discussion I no longer understand, but what the hell..


Please don't stop the comments. You add tremendously to what I am beginning to understand.

Convolution 1st, then DFT. :confused:

[Arachnotron]

To go back to an earlier part of this discussion about Nyquist:

I just finished some tests with my DVD player and an oscilloscope.

I slapped together a Basic prog to produce strips of grayscale values from a sin function at certain frequencies and sampled at 13.5 MHz.source (http://www.arachnotron.nl/temp/wedge.bas) which produced this (http://www.arachnotron.nl/temp/MHz.png) picture

I made a DVD out of it and played it back in my DVD player, hooked up to an oscilloscope. This pic shows the signal from alternating black and white pixels. A 6.75 MHz sinus. No surprise there.
6.75 MHz (http://www.arachnotron.nl/temp/675_sin.jpg)
6.75 MHz part line (http://www.arachnotron.nl/temp/675_full.jpg)
This is what you get from 6.46 MHz:
6.46 MHz (http://www.arachnotron.nl/temp/646.jpg)

The large oscillation has a Frequency of 6.75 - 6.46 = 0.29 MHz
near the zero crossings the frequency is 6.46 MHz
near the peaks, the frequency is 6.75 MHz

This is the situation you get from a reconstruction function that does not do low pass filtering at 6.75 MHz. Post-aliassing.
Look at here (http://www.bores.com/courses/intro/basics/1_antia.htm) for an explanation.

As the frequency increases, the oscillation in amplitude slowly decreases and the frequency approaches the sampled frequency untill at around 6.75/2 you get a normal sinus again.

3.23 MHz (http://www.arachnotron.nl/temp/323_sin.jpg)

Originally, I wanted to grab this signal at 704x576 and 352x576, encode to DVD en analyze those on the scope. But since the source is already aliassed this became difficult. I have to re-do those sometimes.

But I noticed an interesting side effect: at 352x576, the 3 MHz sample became aliassed (amplitude oscillation as above). If this is the reconstruction filter, or the effect of the SAA7134 anti-alias filter still being at 6.75 MHz I do not know.

Tentative conclusion:

Nyquist is correct BUT you need a perfect reconstruction filter.

The part of the re-construction filter is played in this experiment by the DVD encoder + DVD player;
if you look at the dvd on the PC you also see interference patterns. You could say the filter now is
DVD encoder + PowerDVD + screendriver + graphics card

And neither of those (or any other real world playback system I suspect) is a perfect low bandpass filter limited reconstruction filter according to Nyquist!

So:

To get back your original signal on a real world system without aliassing, you must sample at 4 x the frequency!! Fred was right!

This does not mean you cannot go higher. Only, aliassing at playback will increase as you go up. If this is a problem depends. There is a trade-off between aliassing and detail. I suspect Manga and cartoons and sequences with lots of texture are better of at higher cap resolutions, even if the source is VCR.

So to stay the closest to the original VCR signal, I should sample at 704x576, do my filtering and STAY at 704!

By the way: I also discovered PowerDVD contains some sort of anti-alias filter.

[trevlac]

@Arachnotron

Interesting post. I must say, I can't completely follow. I do have some questions though..


This is the situation you get from a reconstruction function that does not do low pass filtering at 6.75 MHz.

But doesn't a dvd player do a low pass filter? I thought that was what DAC was about?



But I noticed an interesting side effect: at 352x576, the 3 MHz sample became aliassed (amplitude oscillation as above). If this is the reconstruction filter, or the effect of the SAA7134 anti-alias filter still being at 6.75 MHz I do not know.

I can't follow this. :)


Nyquist is correct BUT you need a perfect reconstruction filter.

The part of the re-construction filter is played in this experiment by the DVD encoder + DVD player;
if you look at the dvd on the PC you also see interference patterns. You could say the filter now is
DVD encoder + PowerDVD + screendriver + graphics card

And neither of those (or any other real world playback system I suspect) is a perfect low bandpass filter limited reconstruction filter according to Nyquist!

What I don't get here is 1) Isn't your 6.46MHz cap example supposed to look like that? Isn't that what your link said? 2) Isn't the DAC supposed to fix that? Why did it not?



To get back your original signal on a real world system without aliassing, you must sample at 4 x the frequency!! Fred was right!

You know, I can't really dispute this, because I can't really say why Nyquist is correct. :) I don't understand enough yet.

Also, I don't follow your logic. What is in your sample is not aliasing correct? The DAC is supposed to remove it correct?



This does not mean you cannot go higher. Only, aliassing at playback will increase as you go up.

You get more aliasing with a higher sample rate? I'm lost. Typo?


Good stuff though. I assume I should see the same thing in the Avia ramp. Can you post the 'raw' file. I couldn't get Basic to work.

Edit
Another question... If you should cap VHS at 704 to avoid the problem you describe, what do you have to cap a DVD at, and how do you keep it that size? AKA, can you cap a DVD if you must keep it at 4x 6.75? This does not make sense to me.

[trevlac]

I wanted to sum up a bit:

1) I said that you can cap at 2x the frequency of the source.

2) I did some tests, and it seemed like the BT878 did a better resize than a post cap resize. This got us side tracked as to why.

3) Arachnotron seems to have shown that if you cap at 2x your source, some frequencies between x and 1/2x get messed up. He concludes you need to cap at 4x and keep it at 4x.

I'd like to give some more info on #2, but it's time may have passed due to #3. :D

The story goes like this (I think):

1) I did some tests and It looks like a BT cap at 368 is better than cap at 720 and resize to 368. The direct cap has more resolution.

2) WHY?

The BT spec says: "The Bt879 implements horizontal scaling through poly-phase interpolation. The Bt879 uses 32 different phases to accurately interpolate the value of a pixel. This provides an effective pixel jitter of less than 6 ns. In simple pixel- and line-dropping algorithms, non-integer scaling ratios introduce a step function in the video signal that effectively introduces high-frequency spectral components. Poly-phase interpolation accurately interpolates to the correct pixel and line position providing more accurate information. This results in aesthetically pleasing video as well as higher compression ratios in bandwidth limited applications. ... Horizontal scaling is implemented with a 6-tap interpolation filter"


3) We tried to figure this out. Wilbert gave a link to a paper that talks about polyphase structures for decimation. Here is my current take.

6-tap filter means something like this: "1/14, 2/14, 4/14, 4/14, 2/14, 1/14". That is the kernel to a filter. A filter is a signal. To filter 1 signal with another signal you convolute them together.

32-phase interpolation means given 2 sample points, you create 31 points in between them. Then you 'run a filter' over them. This give you a bigger picture. To get a smaller picture, you throw away samples. To do an odd resize like 2/3 vs 1/2, you first go up, then down. Arachnotron gave a link to a nice paper on polyphase stuff. Here (http://www.snellwilcox.com/knowledgecenter/whitepapers/papers/digital_arc.pdf). Unfortunately, I got lost in the last two paragraphs (which seem important).

Banks/Branches/Phases ... These are the same. When you do this polyphase stuff for decimating, you can break up your filter and your samples and work on them as seperate sets, and then add them together.

I don't think 32 has to do with limited memory 'banks'. On page #122 of the BT spec it talks about memory limits. Here it is talking about the number of full lines you are limited to for a vertical scale. It appears to support about 2 1135 pixel lines. For horizontal, we are probably never talking about more than 200 pixels involved in any 1 calculation. These would all be from the same line.

Some conclusions
The BT does not really do a 'better' resize because of the polyphase stuff. That just makes it faster? It is all about the filter it uses. When it filters, it uses a different kernel than say a vdub resize. The BT's kernel seems to have a cutoff at a higher frequency. This may be a bad thing. There may be interferance in the resulting picture.


Convolution as promised

I'm just picking this up myself. I'd thought I'd review how I think this works so maybe somone would have some insights. :)

Convolution is a math operation like addition. Addition takes 2 numbers and produces a third. Convolution takes 2 signals and produces a third. For filters, you simply convolve your input picture with the filter kernel. This gives you a 'filtered' output. Basically, the process weights pixels with its neighbors.

The kernel for a simple Gausain blur is (.25, .5, .25). This is a low pass filter that (a big guess on my part) reduces the highest frequency to half.

To convolve a row of white, black, white, black pixels (1,0,1,0,1,0,1,0) together with the above filter, you:

1) front pad the pixels with zeros for filter coefficients -1. In this case 2 zeros -->> 0,0, 1,0,1,0,1,0,1,0

2) align the 2 signals like this:

0, 0, 1 ,0,1,0,1,0,1,0
.25,.5,.25


3) Multiply down and add across. This give you the answer for the 1st filtered pixel. In this case .25

4) Move the filter over by 1 like this:

0, 0, 1 ,0 ,1,0,1,0,1,0
.25,.5,.25


5) Repeat until you get all of your new pixels.

In this example the in and out lines are the same length due to how we padded and started. I think you are also supposed to pad the end a bit and keep going, then chop off some from the front and end. Due to the way the calculator link I gave seems to work, for it, you need to chop off 1 from the end and filter kernel lenght -2 from the front.

The whole reason for this chopping/padding is because the pixel line is a finite length, and signals are not. So you pad with dummy value and chop because the ends are not really meaningful because dummy values come into play.

An interesting note about how this works is say you have a black border around your source, and you bilinear resize down. The border will 'bleed' into the picture, and the edges of the picture will be a little off, because they are not really a valid signal.

-------------
If anyone wants to know how to use the calculator I posted, let me know. I ran some simple sample cases thru and found that doing a polyphase decimation (decimate then convolute) seems to give the same results as convolute then decimate. Basics on the calculator are: use real values; order = line/filter size -1. Enter your values and the filter kernel.

I just think the BT resize uses a different kernel than bilinear in avisynth.

Edit
I wanted to point out that the Philips spec that Arachnotron pointed out here (http://www.semiconductors.philips.com/acrobat/datasheets/SAA7114H_1.pdf) lays out all of their filter details (about page #45). The implementation is as always up to the driver. :) . Note that the way they do it is provide the coeffieients as whole numbers, which has the effect of increasing the 'gain' (brightness) of the signal. Then they 'normalize' the gain back down by dividing everything by the sum of all the coefficients. They can normalize back down by at most 128. AKA, coeeffieients can be as small as 1/128.

Also, it seems they can use up to 64+7 coefficients for their filter. Notice that they keep saying things like "The user can therewith decide between signal bandwidth (= sharpness impression) and alias." The user is the driver, and it decides the coefficients used in the filter.

I think I understand about 1 out of every 20 words in these docs now. :D

[Arachnotron]

@Trevlac

The source is in powerbasic, I just posted it as an illustration of how I made the teststrips. The raw strips are here (www.arachnotron.nl/temp/vcr_test.zip)

Another attemp to explain what I think:

There are two processes which result in aliassing in the final signal or picture.

The first is pre-aliassing. This is caused by sampling a signal which contains frequencies above half your sampling speed. For my Phiilips chip, this would be 13.5 MHz/2 = 6.75 MHz. This is prevented by adding a low pass filter before sampling. Since with pre aliassing the resulting low res signal will be in your samples, it is difficult to filter out afterwards.

The second is post-aliasing. To reconstruct the original sample the reconstruction function must not contain any frequency above sample rate /2. Again, in this case,6.75 MHz. But if the reconstruction filter DOES contain frequencies above this, you get aliassing again.
It will show up as moiree effects or rainbowing.

A good way to illustrate this is to look at my sample BMP file. It contains strips of greyscale lines at 6.75, 6.46, 6.16, 5.87, 5.58, 5.28, 4.99, 4.7, 4.4, 4.11, 3.82, 3.52, 3.23, 2.94, 2.64, 2.35, 2.06, 1.76, 1.47, 1.18 and 0.88 MHz.

If you open it in paint, you see the interference patterns clearly. If you zoom in, a single samplepoint is represented by a square; this is NOT a perfect reconstruction filter. Now open it in the Windows print and fax viewer. Zoom in. This program uses a re-size filter to zoom; different reconstruction filter, the interference pattern is different. Now make an MPG2 out of it and open in powerdvd. Play both in a window and ful screen. Again, different interference patterns!

Played back on my player (Pioneer DV535,not high end, but not cheap either) you again see interference patterns in the analogue signal.
But doesn't a dvd player do a low pass filter? I thought that was what DAC was about? Yes, The DAC should fix that. But for some reason didn't. There might have been a problem with my program (that is why I posted the source) but I don't think so since your avia test shows similar banding.

Now, the banding patterns differ depending on the reconstruction method used. But the result is the same: only the last 10 teststrips, 3.5 MHz to 0.88 MHz, are free of interference.

So, all these reconstruction methods are not perfect??

Back to my saa7134:

The highest frequency I can capture without pre-aliassing is 6.75 MHz
But the highest frequency in this capture I can play back without post-aliassing is 3.4 MHz. Any frequency in the cap beyond that will be increasingly distorted by aliassing on playback.

What happens if I cap at 352x576?
I suspect this chip at this point is still using the higher resolution low pass filter. So I have samples up to 6.75 MHz, which are being scaled down to 352 samples without low pass filtering. Probably, if I go a bit lower, the CIF filter kicks in and the banding disappears. This is pre-aliassing by the way.

Now suppose the cap at 352 was low pass filtered correctly, and the samples contain nothing beyond 3.4 MHz. If played back on the DVD player, the signal might be ok. I am not sure of that, still depends on the reconstruction filter.
But on an PC screen, when blown up to square pixels without any filtering, again you will get aliassing and interference patterns. Only now, going down to 1.7 MHz. If your software VCD player has filters, and the screen resolution is high enough for them to operate the post aliassing may be avoided.

What does al this mean:
With a 13.5 MHz sample rate
The lowest frequency you can sample without pre-aliassing is 6.75
The lowest frequency that will display without post aliassing is 3.4 MHz
Between 3.4 Mhz and 6.75, frequency (detail) increases and will display, but at the cost of post-aliassing.

Is this a problem? Depens on the scene. With a normal movie, the increased resolution is probably more valuable than the increase in aliassing.
But with stuff like stripes, patterns, etc. you see the aliassing. By using single frequency strips the effect becomes very visible. But real world film rarely contains stuff like that.

Real world example:
video with a striped shirt in it, sampled at 13.5 MHz and put on DVD

3.4 MHz shirt stripes: visible, no moire / rainbow
5 MHz shirt stripes: clearly visible, but some moire/rainbow
6.7 MHz stripes: just visible, heavy moire/rainbow.

3 MHz shirt on tape, capped at 704: visible, no moire
3 MHz shirt on tape, vapped at 352: visible, but moire??

Try it with the BT878 and my testpic. My prediction:
at 368 : more detail, but aliassing
at 354: less detail, but less or no aliassing

All in all, everything you do in digital video is a compromise between aliassing and detail. I really would like to look at different DVD players to see if some models have better reconstruction filters. But that might be a bit difficult. I'll try askin in a shop and see what answer I get :)

[trevlac]

@Arachnotron

Great explaination! I will try to test on my DVD player with your pic (your capture). The 2nd line of your capture clearly shows the larger wave that matches what you show on the scope (and what that bores link shows).

I'm not sure why the problem is between X and 1/2X (aka not at 6.75). I'd have to think about this an test. I remember reading something about how a TV works also comes into play for the reconsturction. Wont that be strange. If you watch on PC do A. If you watch on TV do B. :D

"Trade off between aliasing and sharpness" That's exactly what the Philips spec says also.


@Wilbert

There is a good short discussion of the filter kernels used in Avisynth Here (http://forum.doom9.org/showthread.php?s=&threadid=46648). I'm not sure what all of the flavors mean. The kernels don't seem to be as long as the 6taps used by the BT (or 64+ taps on a philips).

It does look like you could do a horizontal resize and mimic what a chip does by doing:

GeneralConvolution(...)
Levels(....)
PointResize(...)

GConv applies the filter out to 5 taps
Levels reduces the gain (Brightness) because the GC sounds like it does not work correctly and you can't get it to not boost gain. This might not work because the gain might go off the scale before you can fix it.
PointResize just decimates.

This is an educated guess, but if you talk avisynth, that is what a BT resize is doing. :). The BT may of course use a longer filter, and it also probably uses a different filter for chroma and luma (which may or may not matter because GC is RGB).

Do I make any sense? :confused:


edit
The best part of that thread is 'steady'. See this "All the others will interpolate by simultating a curve connecting the points." Does the perfect filter simulate the perfect curve, and reconstruct the signal? "The Lanczos resize is a 6-tap windowed sin c".

[Arachnotron]

The Lanczos resize is a 6-tap windowed sin c

I wonder: can you up-size with these filters too?

If so, a re-size of my 6.46 MHz strip to say 7200x XXX should yield a perfect sinus.

[Wilbert]

For now, it looks like using .25,.5,.25 taps on a 12 pixel line of say (0.1,0.2,0.3,0.4 ... 1.2) gives you the same results if you convolute 1st and then decimate OR if you break the coefficients and lines up as (0.1,.5,.9)*.25 + (.2,.6,1.0)*.5 + (.3,.7,1.1) * .25. This example is a decimation by 1/4. 12-->3 samples. Notice, that we just ignore the 4th row or 3 samples.
Sorry, I'm very low on time and didn't read the last couple of posts. This will be a math post, I hope it doesn't scare you away :)

I bet that your observation has something to do with the following:


from: http://www.dspguru.com/info/faqs/fir/props.htm

2.2.1 What is the Z transform of a FIR filter?
For an (N+1)-tap FIR filter with coefficients h(k), whose output is described by:

y(n) = h(0)x(n) + h(1)x(n-1) + h(2)x(n-2) + ... h(N)x(n-N),

the filter's Z transform is:

H(z) = h(0)z^(-0) + h(1)z^(-1) + ... h(N)z^(-N)


A very nice thing is that the Z-transform of a convolution of y and w is the product of the Z-transform of y and the Z-transform of w. Note that the convolution of y and w is given by

w(n) = g(0)x(n) + g(1)x(n-1) + g(2)x(n-2) + ... g(N)x(n-N)

(w*y)(n) = g(0)h(n) + g(1)h(n-1) + ... + g(n)h(0) = sum_s g(s)h(n-s)
where s runs from 0 to n, and * denoted the convolution (sometimes a cross with a circle around it, can't do that with ascii :) ).

Multiplying the Z-transform of y and Z-transform of w gives:

Z(y).Z(w) = (h(0) + h(1)z^(-1) + ... + h(N)z^(-N)).(g(0) + g(1)z^(-1) + ... + g(N)z^(-N)) = h(0)g(0) + (h(1)g(0)+h(0)g(1))z^(-1) + ... + h(N)g(N)z^(-2N)

Z-transform of y*w gives:
Z(y*w) = (y*w)(0) + (y*w)(1)z^(-1) + ... + (y*w)(N)z^(-N)
= g(0)h(0) + (g(0)h(1)+g(1)h(0))z^(-1) + ...

Iow, they are equal.

I'm sure your example fits into this somehow.

[Arachnotron]

I wonder: can you up-size with these filters too?

To answer my own question: yes, you can and no, you cannot recover the original sinus function using them.

Stands to reason: a filter that can do this must have an option somewhere to set the cut-off frequency. At least the included filters in Vdub cannot do this, and a quick scan of Warpenterprises and neuron2 did not uncover anything. (but I may have missed it of course)

Does anyone know if such a beast exists?

a re-size/interpolation filter that let's you set the cut-off frequency that is.

[trevlac]

@wilbert

[about math]
I'm not particularly scared of math. I simply view it as a symbolic language where the symbols have complex definitions. Unfortunately, like my German, I am quite weak at math. :(
[htam tuoba]

I however have been able to put together that
Z^(-N) is a reference to a time delay (an appearent property of Z transforms.

h(0) is a reference to a given coefficient of a filter.

And I do know that a z transform is (possibly) a special case of a Fourier transform, so that is why convolution of two signals = multiplication then z transform of 2 signals, because convolution in the frequency domain = multiplication in the time domain.

But unfortunately I 'don't quite speak the language'. I am really just learning, the DSP definitions help me understand the math more than the other way around.

So, because I don't really know what a Fourier transform is, I don't really follow, and I can't compare back to my sample as proof.

You on the other hand seem to speak many languages.... :D

Edit

Here is the intro to a chapter. I believe it describes how a chip uses a long kernel to filter, and is also what Wilbert is showing in math.


This chapter presents two important DSP techniques, the overlap-add method, and FFT convolution. The overlap-add method is used to break long signals into smaller segments for easier processing. FFT convolution uses the overlap-add method together with the Fast Fourier Transform, allowing signals to be convolved by multiplying their frequency spectra. For filter kernels longer than about 64 points, FFT convolution is faster than standard convolution, while producing exactly the same result.

http://www.spectrumsdi.com/ch18.pdf

Edit again Well I fully read that and can say it has nothing to do with what Wilbert posted nor the topic at hand. Not a bad read for 9 pages. Sorry for the confusion (on my part) :confused: .


@Arachnotron

Unhelpful answer
See this (http://www.dspguru.com/info/faqs/fir/props.htm)

2.2.3 Can I calculate the frequency response of a FIR using the Discrete Fourier Transform (DFT)?
Yes. For an N-tap FIR, you can get N evenly-spaced points of the frequency response by doing a DFT on the filter coefficients. However, to get the frequency response of the filter at any arbitrary frequency (that is, at frequencies between the DFT outputs), you will need to use the formula above.

:D :D


Maybe useful info
http://www.spectrumsdi.com/ch16.pdf

Discusses windowed sinc filters. I am also interested in this and here is what I think today. ;)

Filters in programs are limited to a very small number of coefficients (due to speed)
A sinc filter is simply a plot of the sinc wave the trick is you have to plot this using very few coeffieients (-5,40,128,40,-5) would be an example I just made up.
Filter cutoffs are measured as a % of the sample rate
A sharp cut off would probably have the center point go near the max on the scale (0-255) and might cutoff at .4 of the sample rate
You could probalby find a filter calculator. I have not seen one that lets you put the coefficients in. But the seem to allow input of cutoff


I believe the parameters for the Bicubic resize effect blur and ringing. Ringing occurs when the sinc is too high and is truncated at it's ends. This is in effect due to not enough taps (points in the graph). For example not using the -5s in my example. The blur makes the sinc wider and ineffect moves the cutoff to a lower frequency. I have no doubt that there is a calculation for the coefficients given a value for b and c.

GeneralConvolution directly accepts a kernel. Bicubic in effect also does.

Here is an idea That philips doc you posted had kernels defined and had graphs of their cutoffs. You could look at that and maybe use the GeneralConvolution.

[trevlac]

@Arachnotron,

What are your conclusions to the question "Capture Resolution - Are you sure?"



Also, I found a good way to show what these 'coeffieients' are doing.

Go to the philips doc Here (http://www.semiconductors.philips.com/acrobat/datasheets/SAA7114H_1.pdf). Page #46. Look for prescale ratio 1/2 at the top of the table. Go to 'High Bandwidth' side of table. If you set the registers as mentioned 'XCAL=1' 'XC2_1=0' you get a kernel like (1 1)x1/2 which is .5, .5. For lowbandwith the kernel is (1 2 1) or .25,.5,.25. 'XCAL=2' 'XC2_1=1'. Go to page #45 and look at the graph. Line (1) is the highbandwidth kernel. Line (2) is the lowbandwidth kernel.

How to read the graph (for others reading this post). If your sample rate is 13.5MHz, the filter's effect can be calculated by multiplying 13.5 by the numbers along the bottom. For 13.5MHz, a filter effects bandwidths between 1.35MHz (13.5 * .1) and 6.75MHz(13.5 * .5). The vertical scale is exponential effect. The standard way to give 1 number for the filter is to say what the value is at -3. This graph shows the effects down to -42.

The high bandwidth line hits -3 at about 1/2 the scale (3.375MHz). This makes sense because we are talking about a 1/2 decimation.

NOW

Go to this (http://www.digitalfilter.com/fircalwav/fircalwav.html) calculator. Go to the top of the coefficient list and change the values to .5, .5 and zero for all others. Change Fs= to 13.5. Change GainRng= to 42. Hit 'Read Coeffs'. The graph should match what is in the Philips doc. Change the 42 to 3 to get a better idea where the filter hits -3db.


After having done all of that, you could actually calculate what the chip is doing using the convolution calculator I linked, and a row of 1010101010 pixels.

Now if I could only understand page #42.


Anybody follow this ramble? It's my attempt to decipher what a philips chip is doing to resize from 720 samples to say 352 samples.

conclusion
If you capture at 352 AND your driver choose a 'low bandwidth' resize, then, even VHS will loose resolution. VHS ~ 3MHz. Low bandwidth filter ~ 2.5MHz. If your driver picks 'high bandwidth', you will not loose resolution.

I'm not clear what happens if you go from 720 to say 368. That seems to be on page #42

[Wilbert]

For now, it looks like using .25,.5,.25 taps on a 12 pixel line of say (0.1,0.2,0.3,0.4 ... 1.2) gives you the same results if you convolute 1st and then decimate OR if you break the coefficients and lines up as (0.1,.5,.9)*.25 + (.2,.6,1.0)*.5 + (.3,.7,1.1) * .25. This example is a decimation by 1/4. 12-->3 samples. Notice, that we just ignore the 4th row or 3 samples.
I looked at this more closely. It had nothing to do with I said, I'm very sorry :)

But, the reason that this is true, is actually quite simple. I will use symbols, so that you see the generalization very easily:

You have a 3 taps filter:

g = (g0,g1,g2) = (1/4,1/2,1/4) or G(z) = g0 + g1*z^(-1) + g2*z^(-2)

A sampled signal (12 samples):

h = (h0,h1,...,h11) = (0.1,0.2,...,1.2) or H(z) = h0 + h1*z^(-1) + ... + h11*z^(-11)

Let y be the convolution of h and g, i.e. y(n) = (h*g)(n), gives

n=0: h0*g0
n=1: h1*g0 + h0*g1
n=2: h2*g0 + h1*g1 + h0*g2
n=3: h3*g0 + h2*g1 + h1*g2
...
n=11: h11*g0 + h10*g1 + h9*g2

Decimating by 4, and keeping every third sample (like you did in your example) gives:

n=2: h2*g0 + h1*g1 + h0*g2
n=6: h6*g0 + h5*g1 + h4*g2
n=10: h10*g0 + h9*g1 + h8*g2

Rewriting this gives

y = (h2*g0 + h1*g1 + h0*g2, h6*g0 + h5*g1 + h4*g2, h10*g0 + h9*g1 + h8*g2) = (h2,h6,h10)*g0 + (h1,h5,h9)*g1 + (h0,h4,h8)*g2

this is exactly how you broke up the coefficients and lines.

[trevlac]

@Wilbert

I follow you completely. Thanks for the translation. So, decimate-->filter = filter-->decimate. Therefore, this gives a speed increase if the level of decimation is 'longer' than the number of taps in the filter. You may also achieve an increase if you are doing a non-interger resize, because when you interpolate up, you will get lines of zeros.

Anyways, it's the taps that are important.

---------------------------------

It appears to me that the 'perfect' capture frame size depends upon the resolution of your source, and the filter that is applied by your card/driver. You can determine source resolution by generalizing or by testing a specific VHS machine. The next question is how do you know what an 'unpublished' driver is doing?

How about this:
1) Make a test pic like Arachnotrons, with high frequencies
2) Capture it at a given size
3) feed the capture and the orignial pic into a deconvolution filter

This should give the signal of the filter used by the card/driver at the choosen size.

http://www.wam.umd.edu/~toh/spectrum/Deconvolution.html

Doing this is quite beyond me, but it sounds good. :) I'm sure things like noise and using RCA connections would cause trouble. Plus the cards may apply 2 filters. But theoretically, this process is just DFT(Original) * DFT(Filter) = IDFT(Capture)
therefore
DFT(Capture) / DFT(Original) = IDFT(Filter)

Where DFT is the Fourier Transform and IDFT is the inverse.

Anyone up to the task ?

[FredThompson]

It appears to me that the 'perfect' capture frame size depends upon the resolution of your source, and the filter that is applied by your card/driver.
If you're using Brooktree, it captures at one resolution. Pull the full-sized raw capture and filter in a controllable method. NO run-time filter can compare to what you can do offline. A particular algorithm may not have a freesource equivalent in which case you can duplicate it. You'll have the same raw data set used by the Brooktree.

You're close but incorrect about the performance of a particular VCR. Tape is variable, as are the recording characteristics, even throughout the tape.

[trevlac]

Originally posted by FredThompson
NO run-time filter can compare to what you can do offline. A particular algorithm may not have a freesource equivalent in which case you can duplicate it.

But that's the rub. You may be able to, but I can't duplicate what those damn EEs at BT did. Their resize filter appears to do a better job with the resolution than off line filters. Hey, but what do I know? I'm just a newbie to DSP. Anyone for a 64 tap butterworth? :)


BTW: You can't get the 'full sized raw file' unless you can write a driver. :D

[FredThompson]

But that's the rub. You may be able to, but I can't duplicate what those damn EEs at BT did. Their resize filter appears to do a better job with the resolution than off line filters. Hey, but what do I know? I'm just a newbie to DSP. Anyone for a 64 tap butterworth? :)maybe, maybe not. Keep in mind, you're probably going to use some form of data compression which will throw away some chroma details, right?BTW: You can't get the 'full sized raw file' unless you can write a driver. :D [/B]Hav eyou contact I4004 as I suggested?

[Wilbert]

About Nyquist, theory and practice, there is a thread in hydrogenaudio about it:

http://www.hydrogenaudio.org/index.php?showtopic=8177&st=0&

It's over my head, but maybe it contains something interesting for this thread :)

[trevlac]

@Wilbert

Great find!

2dbDecided seems to really have it down. He describes exactly what Arachnotron shows in his test pic. If you sample near the Nyquist frequency you get what appears as amplitude modulation. Arachnotron posted a link that shows a picture of this. It also shows in his test resolution pic. I'm not sure why 6.75 does not show the problem. From what I understand, you have to actually be under 1/2 the sampling frequency. 6.74 is. 6.75 is not under 1/2 of 13.5. Fred did try to point this out I think. This is because samples at 0 and 0 could be 2 different waves.

Anyway, the filter used to do the DAC is important, as Arachnotron has pointed out. I'm hoping he figures out what are good ones and why, and then tells me. :)

I did want to point out this comment on audio vs video filters.

Though the best compromise is vastly different in image processing. Images look OK with the kind of aliasing that would sound terrible in audio. Conversely, audio sounds OK with the kind of ringing that would look awful in images!


This implies that aliasing is better in video, but ringing is not. Aliasing happens if you don't sample >2x your highest frequency. Ringing occurs at frequencies just under 1/2 sample frequency if any filter used has a sharp cutoff. So to use a sharp filter, sample higher and hope there are no frequencies near your filter cutoff, or use a gentel filter and damp the frequencies past your intended cutoff. Maybe you can also sample, gentel filter, decimate (resample). This might remove/dampen posible 'ringing' frequencies before you get to a smaller size.

In the end, it seems your frame size should be a bit higher than your highest frequency. This would allow the ADC to have a more gentel cutoff without ringing. How much higher? Surely not 2x. What is the highest frequency in your source?

Edit: I do believe more taps/coefficients means less ringing. And more processing time. As I said in another post, I think the BT uses 32x6=196 taps.

[Wilbert]

Another interesting point is that for the BT878, a 368 capture keeps quite a bit more resolution than a 720 capture and a last step resize. I'm waiting for Wilbert to tell me why.
Got some news. i4004 did some test for me with his bt8x8:

http://virtualdub.everwicked.com/index.php?act=ST&f=3&t=5525&st=15&#entry22839

capped at 368x576 enlarged to 768x576:

http://i4004.bizhosting.com/cgi-bin/i/bt-resizer_/368x576resizedto768x576[precisebicubic-vdub].jpg

capped at 768x576 resized to 352x576 (avs: pointresize) enlarged back to 768x576:

http://i4004.bizhosting.com/cgi-bin/i/bt-resizer_/768x576to352x576(avs-pointresize)to768x576(vdubprecbicubic).jpg

Difference is very clear, even with avs's pointresize :)

Other pics:
http://i4004.bizhosting.com/bt-resizer_/

Are you sure you did your tests correct (on page 3)? You didn't swap any pics or so?

[trevlac]

@Wilbert

Thanks. I will post on the Vdub forum when I get a chance. I guess I'll offer to re-do any tests, if anyone cares. :D

I'll like to try some pics with text.

[vhelp]

Trevlac and others..

I thought this page might serve some additional feed for digest and
whatnots. Mostly math stuff to use in your resarch and things.

** White Papers **
** Video Compression Math (http://www.drastictech.com/vidmath_wp.html)

-vhelp

[Arachnotron]

I'm dragging up this old thread, because I finally was able to determine what the analogue filter circuits on my Hauppauge BT878 and CX23881 based cards do.

I used a 1-11 MHz signal generator, fed a 1 V top-top sinus to the Y input, and measured both Vin and Vout using an oscilloscope.
db = 20*log(Vout/Vin)

As I suspected, they are indeed low-pass pre-filters. But for the CX23881, the cut-off is a lot lower than I expected.

http://www.arachnotron.nl/temp/WinTV_662_input_filter.jpg

This filter has the 3 db point at about 9 MHz. I am not absolutely sure about this, since the input voltage also dropped with frequency (?). I suspect the input impedance of the card was to low for the signal generator to handle, but I'll have to test further.

http://www.arachnotron.nl/temp/WinTV_747_input_filter.jpg

This is a classic 6.75 MHz cut-off low pass filter. The input voltage is also reduced by half, I suspect to bring it better within the range of the ACG of the CX23881.

This also explains why some cards seem to get cleaner caps then others; the signal may already be low-pass filtered by components added by the manufacturer before it reaches the capture chip itself.

[trevlac]

I wanted to let you know I found your pics to be great. This shows one must really compare cards not chips. In addition, drivers also make a difference, not to mention cables, signal, ect...

Unfortunately, know your source/equipment and know it well....

[Arachnotron]

Unfortunately, know your source/equipment and know it well....

Amen to that! :)

Just found out in off-forum discussions with i4004 that the reason the BT878 seems to look sharper then some SAA7134 cards is that some BT drivers enable a sharpening filter. So Phillips does not blurr the cap more than a BT878 does as some people have claimed in the past. The Philips just stays closer to the source. With a sharpening filter the outcome is identical (according to Ivo)

Now if only manufacturers could be bothered to document their products....

[Edit] Ivo did not agree with my quote. see this (http://virtualdub.everwicked.com/index.php?act=ST&f=6&t=5896&st=60&#entry24277) thread on everwicked for the gory details.....

[trevlac]

Originally posted by Arachnotron
Just found out in off-forum discussions with i4004 that the reason the BT878 seems to look sharper then some SAA7134 cards is that some BT drivers enable a sharpening filter. So Phillips does not blurr the cap more than a BT878 does as some people have claimed in the past. The Philips just stays closer to the source. With a sharpening filter the outcome is identical (according to Ivo)

Now if only manufacturers could be bothered to document their products....

The default for the BTwincap is to NOT use the sharpening filter.

The following is something I posted at VCDhelp when this came up a little while ago. This is in regard to the BTwincap driver... :D

.....................................


Well, the sharpness is 'implemented' in the chip. It effects a horizontal filter that is turned on. ... basically, if you pick 'auto' the text below explains. If you pick something else, a specific filter option is set.

"BT Spec Page #116, HFILT"
These bits control the configuration of the optional 6-tap Horizontal
Low-Pass Filter. The auto-format mode determines the appropriate
low-pass filter based on the horizontal scaling ratio selected. The
LDEC bit in the CONTROL register must be programmed to 0 to
use these filters.
00(1) = Auto Format. If auto format is selected when horizontally
scaling between full resolution and half resolution, no filtering
is selected. When scaling between one-half and
one-quarter resolution, the CIF filter is used. When scaling
between one-quarter and one-eighth resolution, the
QCIF filter is used, and at less than one-eight resolution,
the ICON filter is used.
If the PEAK bit is set to logical 1, the HFILT bits determine which
peaking filter is selected.
01 = Max full resolution peaking
10 = Min Cif resolution peaking
11 = Max Cif resolution peaking
00 = Min full resolution peaking


"BTwincap src, scaler.cpp"

// Adjust filters!
if (m_sharpauto) {
if ( m_ptrVideoIn->AutoHFilter )
fieldHFILT = HFilter_AutoFormat;
else // SECAM
if ( hActive < DWORD(m_ptrVideoIn->Clkx1_HACTIVE) / 7 )
fieldHFILT = HFilter_ICON;
else
fieldHFILT = HFilter_QCIF;
fieldPEAK = 0; // Peaking (1 = On)
fieldLNOTCH = 0; // This can be disabled to get full Black/White bandwidth (0 = On)
fieldLDEC = 1; // Reduces bandwidth of luma. (0 = On)
fieldCOMB = 1; // Averages color to reduce artifacts (1 = On)

} else {

/* LNOTCH -> Color subcarrier elimination
LDEC -> use or not filter LP or PEAK
PEAK -> Select between peak and filtering
COMB = CromaComb: Use this to average chroma components of next lines

PEAK/HFILT LDEC PEAK COMB
ICON 11 ON(0) OFF(0) ON(1)
QCIF 10 ON OFF ON
CIF 01 ON OFF ON
- OFF(1) OFF ON
11 ON ON(1) ON
10 ON ON ON
01 ON ON ON
00 ON ON ON
ICON 11 ON0 OFF0 OFF
QCIF 10 ON OFF OFF
CIF 01 ON OFF OFF
- OFF OFF OFF
11 ON ON OFF
10 ON ON OFF
01 ON ON OFF
00 ON ON OFF */

ULONG val = m_sharpness - 18; // Get value of horizontal sharpness
BYTE PeakHFilt = BYTE((~(val >> 4)) & 3); // Bits 54
BYTE Peak = 0; // Peak = Off
// Allow PEAKing only in Full Size in Bt848A or better.
if (hActive > DWORD(m_ptrVideoIn->Max_Pixels) / 2 && pisces->HasPEAK() ) {
Peak = BYTE((val >> 3) & 1); // Bit 3
}
BYTE LDec = (PeakHFilt || Peak) ? 0 : 1; //
BYTE Comb = BYTE((~(val >> 2)) & 1); // Bit 2

fieldHFILT = PeakHFilt;
fieldPEAK = Peak;
fieldLDEC = LDec;
fieldCOMB = Comb;
fieldLNOTCH = 0; // This is a MUST to avoid color interference!
}



For non-programmers, (like ivo and me), it is easier to read the chip register values as you set various options in your app, then translate them to english (croatian) using the spec.

[Arachnotron]

Quickly reading these quotes, I get the impression this is about low pass cut-off points.
Which part is about increasing sharpness (I mean something warpsharp like, which is not the same as decreasing the amount of detail filtered out, which again is what changing the low-pass filter cut off does ).

Could you perhaps point me to the place in the specsheets? (not doubting you, just interested where to find this) :)

In general, I just ment my remark as an illustration that "it looks sharper" does not neccecarily mean a card actually is capping more detail.

[trevlac]

Originally posted by Arachnotron
In general, I just ment my remark as an illustration that "it looks sharper" does not neccecarily mean a card actually is capping more detail.

Look for PEAK or Peaking page 23 starts the info. Page 116 is how the registers are set. The BTwincap has a sharpness setting that translates to values 0 to 3.

http://www.conexant.com/servlets/DownloadServlet/100119a.pdf?FileId=542


And I am 100% behind you on the "it looks sharper" thing. Actually, at some point, it is really a preference thing. I prefer zero sharpening. As you know, I am now focusing on brightness/contrast/color. Contrast, for example makes a huge difference in the detail of the picture. Basically, if there is a lot of detail that is almost the same color, you are not going to see it. :)


I did some compares on sharpness for ivo (bt vs cx). I'm not sure he ever looked at them. Just concluded he liked the cx better. At some point, the 'better' tool depends on the job and how you use it.

[Arachnotron]

Thanks!

If I understand this correctly, the peak filter amplifies higher luma frequencies relative to the lower frequencies. Judging from the curves, this would also result in an overall brighter picture. Yuk!! :)

I did some compares on sharpness for ivo (bt vs cx). I'm not sure he ever looked at them. Just concluded he liked the cx better. At some point, the 'better' tool depends on the job and how you use it.

I think he did, he did mention them in off-forum mails to me. He told me he pulled a SAA7134 cap through a sharpening filter, after which it looked identical to a BT cap.

For me the choice is SAA7134/Terratec, simply because the Hauppauge BT and CX cards don't have a decent PAL60 mode. (PAL60 mode in BTWincap is broken) As you said, it depends on the job you need it for. :)

[trevlac]

Originally posted by Arachnotron

If I understand this correctly, the peak filter amplifies higher luma frequencies relative to the lower frequencies. Judging from the curves, this would also result in an overall brighter picture.

Only the fine detail would be brighter. Edge sharpen kind of thing I'd guess. The Avisynth gurus could tell us....

[Arachnotron]

Only the fine detail would be brighter.

Yes, but since the whole filter curve with peaking is higher than with peaking = 0, average brightness is up compared to an unfiltered pic.

[fberreth]

This was a long thread and somehow I have the feeling there was no real conclusion for dummies like me.

I just wanted to mention that I think i4004 had the picture blurred at 368x capture because he captured PAL and bt8x8 kicks in the additional filter on PAL earlier than on NTSC (PAL you need to be >= 400x). Yes? So I think trevlac's theory/pictures I think are 'real' for NTSC capture.

So the horizontal resize in the chip is superior because it takes samples into account that SW doesn't see. Problem is just that the resolution you have to capture is non-standard and you have to resize in SW or crop again. What is then better? To capture full (say 712x) and resize to say CVD or capture 368x for NTSC and resize to CVD (or crop)?

Hope I made myself clear - I'm still trying to digest all the information :)

[trevlac]

Originally posted by fberreth

So the horizontal resize in the chip is superior because it takes samples into account that SW doesn't see. Problem is just that the resolution you have to capture is non-standard and you have to resize in SW or crop again. What is then better? To capture full (say 712x) and resize to say CVD or capture 368x for NTSC and resize to CVD (or crop)?



That is what I would say. And 712x vs 368x only matters if you want to save space on a disc. If not, 712 is better because the AR is better. Also, 368 is better assuming that 368 can be compressed better than 712 (which btw, I'm not sure is as self evident as it seems ... because a DTC transform changes pixels into frequency numbers and the 368 should have more detailed but fewer blocks ... I'd guess 368 compresses better but i'm not sure this is true).

-----------
In the end, I was beaten down by these other folks into so many if's and and buts that I now like to be vague and say "test with your source/process/hardware and see which picture and process you like the best".

For example, a comment on Nyquist .... Nyquist (and Shannon) gave a minimum mathimatical sample rate. In practical terms, a digital representation of an analog image can never be recreated back to the original analog. This is not only due to sample rate, but also due to sample precision (bit depth), the algorithums used to muck with the color representations, what the hardware can physically do to recreate the analog from the digital ... yada yada ...

So at some point ... you just have to compare pictures on your destination display.

[Arachnotron]

Some cards have vertical resizers that kick in at lower resolutions that can do horrible things to your captures. For devices like that, capping high even when the final format is low res remains the best.

But with vcd slowly dying out as a final format, what cards do at lower resolutions is becoming a moot point. Nowadays, if you really need low resolution, your priority is not quality anyway.

So the only consideration left is to avoid any unneccesary resizing steps. Since no matter what you do your capture device will resize anyway you might just as well let it resize to a final resolution that has the correct PAR and pad/crop to the final resolution of your target format and avoid any further resizing.

What this capture resolution is depends on the device/drivers in question, so there is no one-size fits all answer for that, but the capture guide has a few chapters on this.

For my SAA7134 card, I cap at 704x576 since that gives me DVD sized samples. For my Hauppauge CX23881, I cap at 696x576 and pad later for the same reason.

[zilog jones]

So, is 696x576 the optimal resolution for the CX23881 in PAL then? Does going higher just make it worse? I've just got one recently, and so far I've just been messing around with it and trying to get my PC to work right when recording higher resolutions (see my recent thread). I have noticed that there seems to be more noticebale ghosting if I go up to 768x576 from 720 or 704, but maybe that's just DScaler?

Could someone give links to some of these test cards again (preferably a PAL one)? The links from earlier in this thread all seem to be dead.

[Arachnotron]

Could someone give links to some of these test cards again (preferably a PAL one)? The links from earlier in this thread all seem to be dead.
See chapter 10 of the analog capture guide. The links in there are ok. This chapter also explains the why of all this.

Dscaler is a separate issue, since Dscaler approaches the hardware directly instead of going through the drivers.

[zilog jones]

So is 696x576 optimal for the CX23881? And by padding, do you mean resizing or just adding borders to make it 720? Wouldn't that make the aspect ratio a bit wrong?

[Arachnotron]

So is 696x576 optimal for the CX23881? And by padding, do you mean resizing or just adding borders to make it 720? Wouldn't that make the aspect ratio a bit wrong?
If your target is DVD, adding borders to 720 (or 704 depending on your encoder) would result in a DVD with correct aspect ratio.

[edit]
And it is not so much correct for the CX23881 as correct for the drivers/cx23881 combo I tested this with. It might be that your drivers use another active window (though so far most seem to use 696). That is where the test DVD comes in.

[acrespo]

I am very confusing about the resolutions.
I have a Compro Videomate Gold+ (SAA7134) TV Card.
My source is PAL-M (combination of NTSC and PAL, because fps and resolution the same of NTSC but colour of PAL).
I am assuming that NTSC is valid to me, then I am capturing at 640x480, because my needs is Xvid AVI to watch in computer.
My feelings are right?
Can I capture with a low resolution (example 320x480) and up to 640x480 with avisynth (lanczos4) and don't lose details or doing noise problems?

[Arachnotron]

Assuming your source is tape, I would suggest capping at 480x480 to get the last bit of detail out of it. Most of this stuff is in the capture guide. Any other source, cap directly at the final resolution.

Read chapter 16 of the guide. Follow the examples for the Terratec Cynergy, since that is a SAA7134 card too. Assuming you have the same capture window , you have a capture window width of 52.168 µs or 704 DVD pixels.

First, determine the IAR of your card (chapter 16.3). This value is fixed for your card/driver and does not change unless something is changed in the driver. Luckily, example 2 applies to your card too.

Example 2: Terratec Cinergy 400:
When capping a NTSC signal, this card has a capture window width of exactly 52.148 µs. This makes the Image Aspect Ratio of this device:

IAR = (4 / 3) * (52.148 µs / 52.6555 µs) / (480/486) = 1.3370

This is slightly wider than the standard NTSC active window.

Next, calculate how to resize. Since you cap 480 lines, you only need to resize horizontally. That is in chapter 16.4.1. Assuming you capture at 480x480:

Source: 480x480, PAR = IAR * [vert]/[hor] = 1.3370 x 480 / 480 = 1.3370
Target: 640x480, PAR = 1 (= square pixel for on-screen divX)

1. calculate target [ver]/ source [ver] = 480 / 480 = 1
2. calculate source [hor] * (source PAR)/ (target PAR) = 480 x (1.3370/ 1) = 641.76
3. multiply with multiply number from 2 with number from 1 = 1 * 641.76 = 641.76 = 642 pixels (round to nearest multiple of 2)
4 crop or pad to target: crop of 2 pixels at the left or the right.

So, if you want to have it exactly right, cap at 480x480, resize to 642x480 and crop back to 640x480

Personally, I would not bother with the cropping and resize to 640x480 directly since the error is minute. (you captured about 0.3 % too much). You won't notice the difference anyway.

And to keep it really simple, why not cap directly at 640x480 and don't do any resizing or cropping at all. :)