Still photo, to DV AVI challenge!

[bobcat56458]

I had what would seem a good idea the other day of making a short DV AVI video clip on the computer of TV test patterns, and audio frequency & left\right tests. I wanted this so I could export this to the DV camcorder and have it at the beginning of each blank tape so I could observe how my video\audio changed after all the processing including frameserving it, filtering it with Avisynth, and finally encoding it to an MPEG2 for authoring to a DVD. I found some free JPEG\Bitmap test patterns at: http://www.execulink.com/~impact/utes_imp.htm and made one of these into a image sequence using the batch rename feature of InfanView to make a numbered sequence of 30 copies of one of the original image files. I then loaded these 30 copies of the same test pattern image JPEG into VirtualDub, and using fast recompress made a DV AVI that was one frame long. I then took this one frame and using the append feature of VirtualDub made it so it would be 15 seconds long, then saved it again this time using Direct stream copy. I did this with a few different types of test patterns so I could see how the NTSC DV format stood up throughout the whole process of camcorder, to DVD. Here is where I ran into problems, using the test pattern called “ResD1_720x480.jpg” no matter how I tried to do it, there was always a lot of flickering of the lines in the test pattern when I exported that DV AVI to the camcorder, and then copied it back to the computer. I know this is a common problem people run into while making slideshows of photos into a DVD. But I had no difficulty making this whole test patterns, and audio tests video into a MPEG2 then a DVD without flickering (shimmering lines) using the program ProShow Gold. My problem was getting this DV AVI video saved to DV tape without the flickering. I tried all the usual methods of bluring the image slightly, but this defeated the purpose of having a pristine test pattern, for testing purposes. I tried to save the DV AVI in a “Frame Based” field order and this would make it play alright on the computer, but when I exported it to the camcorder it would become interlaced again as camcorder video is natively interlaced. After trying many different combinations of settings with no luck I’ve come to this conclusion. NTSC DV 4:1:1 colorspace is just the pits! I could see color shift in the colored lines of the test pattern no matter what DV codec I tried, and even if I used an Avisynth script with ReInterpolate411, although this helped some. I never was able to solve the flickering (shimmering lines) problem also. I challenge all you DV guru’s out there to see if you have any better luck making a DV AVI with test patterns that plays back correctly after exporting it to the camcorder, and then importing it back to the computer, good luck your gonna need it!

[theReal]

DV is a lossy compression format, it compresses 5:1 a signal that is already colorspace-reduced (4:1:1 respectively 4:2:0 in PAL). It can't be perfect...

[trevlac]

I don't see how putting it on tape and then bringing it back to the PC makes a difference.

If you convert it to DV on your PC -> Copy to Tape -> Copy to PC ... is it different?

Anyway ... What parts filcker? Vertical/Horizontal/Diagonal You see flicker on a TV but not a PC?

There are a few things to consider. Vertical colored lines must be 4 pixels wide for 4:1:1. Black and white should not really have a problem. If you play DV on a TV some device must be converting it to a standard TV signal. How do you do that? What's the TV input type (svideo/rca)?

You learn a lot when you play with test patterens. They push the limits of all your equipment. DV 4:1:1 is good enough for viewing on a TV.

BTW: That jpg test pattern is also probably lossy in about the same way as DV. I believe jpg is 4:2:2 YCbCr and does IVCT stuff to it. ;)

[LocalH]

If you're converting still images to video, and the stills didn't originate from video, then you should slightly blur the images in the vertical direction to help minimize the presence of one-pixel-high horizontal or nearly-horizontal elements. Otherwise your image will flicker a lot more than an equivalent image captured on video to begin with.

If you're scanning prints and importing them into your NLE, then you could try the old trick of tacking the picture to a wall (at the station I used to work for, we would use magnets to hold the picture up on a wall so that it would be perfectly flat and straight) and then shooting it with your camera. You'll generally get good results that way as well.

[theReal]

btw. what was your control monitor? A normal tv set? To really judge the picture quality you'll need a calibrated class-A broadcast control monitor. I guess there will be no flickering (or at least much less)

[scharfis_brain]

why should the interlace-line flicker be different on a broadcast-control-monitor than on a simple TV-set?

I agree, that lumiosity, color, crispness, geometry and such things differ.
But flicker???

[mic]

FWIW, interlaced TV will not do well with anything that occupies less then 3 lines, because either odd or even is in effect dissapearing every 60th or 50th second.

Other then suggested blur, best method I know is in Vegas with eliminate flicker checked.

RE: Monitors, accuracy can vary considerably among various consumer TVs. Moving from TV to PC monitor might illustrate pro vs consumer. And FWIW, monitors & cameras can have much higher line counts -- look for this in advertised specs to get an idea -- and the more lines, the smaller the lines in relation to fixed frame size.

[LocalH]

Flicker would only differ on a monitor with high-persistence phosphors. Most professional NTSC monitors are not high-persistence, as the whole point is to see the video signal in a measurable way (and even still, no two monitors will give you the same image). "line counts" means absolutely nothing to flicker, because all NTSC monitors have a fixed amount of scanlines (525, some of which are blanking). Since flicker is the phenomenon resulting from interlace, you could have any amount of "lines of resolution" and still see flicker if the image was too different between fields.

[bobcat56458]

Well, guys it’s been two weeks from my original post on this subject. I was beginning to think no one had any luck making this work, or that it did not seem like anyone thought this a worthwhile challenge. Thereal commented that I was expecting to much from a compression format that was 5:1 but like I stated in my original post this test pattern made a fine MPEG2 video file and that had a compression ratio of at least 15:1. Others have commented on bluring the image, well as I explained in my original post that would not be something one would do with a test pattern that is used for testing, a regular photo yes. I see there are some hard hitters posting here but none of them even have stated that they have been able to accomplish this. Travlac stated: “I don't see how putting it on tape and then bringing it back to the PC makes a difference. If you convert it to DV on your PC -> Copy to Tape -> Copy to PC ... is it different?
Anyway ... What parts flicker? Vertical/Horizontal/Diagonal You see flicker on a TV but not a PC?” I did have it stop the horizontal flickering on the fine lines when I used “Frame Based” Field Order in VideoStudio and viewed it on the PC. But when I exported it back to the camcorder it was then interlaced by the hardware DV codec, so when I streamed it back to the PC the problem was still there. About a week ago I re-installed FFShow for some other reason and was trying to make this work again and I noticed that the flickering had stopped on the PC, so I tried exporting it to the camcorder again but when playing it from the camcorder to the TV by Svideo the flickering was still there. It appears that FFShow made it look right by maybe deinterlacing it on the fly. There are two distinct problems getting this test pattern to copy to a DV file. One is the color smearing (color shift) of the fine colored lines, I believe this can be attributed to the 4:1:1 NTSC colorspace issue, this one I can understand, and see how this is effected differently by using several different DV codecs. The other flickering horizontal fine line problem I have a harder time understanding why. Because when converting it to MPEG2 I do not see this problem. The bottom line is I’ve still not been able to get this to work myself, I would sure like to hear of someone that has actually done this, or tried to, and is just not theorizing on why this occurs, the challenge remains.

[mic]

Correction or addition (take your pick :)):
Info on things video is a bit chaotic on the web. :( Such is life... I want to try and better answer the original post in as few words as possible, skimming quickly over checking video quality, test pattern flicker problems, the basic effects of monitor resolution, and as an aside, NTSC specs as it was brought up.

In the original post the goal was to check degradation of video, with the problem that fine lines were not displayed properly. Because of the nature of the beast, fine lines or edges are problematic for most TVs, equipment, and processes. It works better with higher lines of resolution, and a high quality means of feeding the TV monitor a test pattern. It also works better with some video formats than others -- Adam Wilt had some good edge comparisons posted at his site. The real world application of this [edge handling] is in video titling and graphics.

To get the best line or edge display possible on the widest variety of equipment, color, saturation, and format (ie.codec) need to be considered, along with industry standard practices of adding a feathered shadow or background. The wrong values for color and saturation, particularly with NTSC DV, are extremely noticeable. This just concerns the edges really, has a lot to do with the electrical signal sent the TV itself, and is effected by the color sampling characteristics of individual codecs (one codec might work better then another, or add an amount of blur or feathering).

In practical application and for illustration, I've found that one way to gauge video distortion, degradation, and scaling of video is using snapshots, including actual pictures of TV & TV monitor display. When you overlay these pics in a photo editing prog. like P/Shop, using the difference method of blending, changes become very apparent. Developing a test pattern (with the considerations above -- color/shadow etc) and using existing video clips, I've personally had decent luck with this approach. Otherwise test patterns are used to check color calibration, quality of the picture tube, accuracy & calibration of the electron stream hitting the back of the tube, and to determine the Horizontal Lines of Resolution. More Lines of Resolution means a better picture and better line and edge display when fed a quality signal.

Besides the all around problems with edges and lines above, interlacing refreshes every other line on the display. Visually we notice change -- differences grab our attention. Watching a TV, if the horizontal line dropping out happens to be an edge or contains a line, we'll notice. More resolution, or a smaller display, can make the missing line smaller physically, and less likely to be noticed. A progressive display like a PC monitor will not normally show you an interlaced video as interlaced, instead combining the 2 fields on the fly. A program like V/Dub will allow individual field display when using filters to split them up.

On resolution:
Design & quality differences mean that a TV picture tube can have a higher possible resolution, just as the CCDs in a camera can contain more photo sensors -- basically there are more dots of color because they are closer together. In PC CRT monitors this spacing of dots is referred to as Dot Pitch. With most TV equipment you refer to Horizontal Lines of Resolution, which commonly varies from the mid 200s to 700+. With your PC's monitor you can change your desktop from 640 x 480 upwards, and the display goes from blocky to smooth, from coarse to fine. TVs and TV monitors work the same way. Big problem is a TV doesn't have it's own pixel factory. :) It's dependant on what you feed it, and if you feed it 250 lines, that's what it will show you.

On Horizontal Lines of Resolution:
Trying to be very careful using that exact term, rather then scan lines and/or just lines commonly thrown around (including by me ;)). Different devices and some specs have limits on how much data they can handle, which is also measured in HLR; you'll lose something if you try and cram 600 HLR onto a tape that only stores 400-450. I think it can get tricky when trying to visually relate HLR to a display, because a small display can force dots closer together, while a large one allows more, takes more dots to fill the screen. It sometimes helps I think, to remember that the average TV will only display a portion of the available data, so very often there's a surplus just waiting to be used; a higher resolution TV or TV monitor can look better immediately. The down side is that while this data might be available originally, if every link in the chain figures you've got a TV with an HLR less then 300, guess what they'll give you?

On NTSC spec.:
Broadcast specs refer to things electrical/electronic as they were written half a century ago, and the voltages, phases etc. don't always translate well using current, often PC based terms. The NTSC broadcast spec includes 525 Vertical Scan Lines, which also stores non-visual data (like CC), and is based on a periodic cycling in the electrical signal. The spec lists the minimum requirements for the video signal the local TV stations broadcast, so someone making TVs could be confident enough to make TVs, and not worry about it only playing channel 2. Does everything video live & work just within that spec? No. If there's a reasonable market for exceeding or not meeting broadcast spec, products have been developed.

[bobcat56458]

Mic: Thank you for the informative link, I will be shortly trying out the test patterns there. I have interest in the statement where you quoted me, and said: “"I would sure like to hear of someone that has actually done this, or tried to, and is just not theorizing on why this occurs, the challenge remains." Post your email address.” Does this imply that you have been successful in getting the test pattern I have a link to in my first post, to print to DV tape without the flickering & maybe even the NTSC 4:1:1 color smear problem? I’m not so much interested in seeing an example of this because that could be possibly faked, not that I’m implying that any of the distinguished Doom9’s forum members would do such a thing :rolleyes: . What I’m looking for is an established scientific methodology where a person would share exactly, in detail, of how they achieved the objective. This way any other interested person could reconstruct your method, given they have the same software, and hardware at there disposal, an in fact verify your results. Please forgive me if I have misconstrued what you were saying when you stated “Post your email address”. I already receive way too much spam to do that, when this can be verified using the proper scientific procedures.

[Wilbert]

"NTSC monitors have a fixed amount of scanlines (525, some of which are blanking)"

While there are NTSC standards for D1 and such that make it confusing, I have to agree to disagree on this. Easy way to show it, if I can find manual for TV I'll gladly scan & send email.
The NTSC signal has 525 scanlines (of which 486 are active). Your TV may or may not show it properly :)

[LocalH]

"NTSC monitors have a fixed amount of scanlines (525, some of which are blanking)"

While there are NTSC standards for D1 and such that make it confusing, I have to agree to disagree on this. Easy way to show it, if I can find manual for TV I'll gladly scan & send email.

Trivia, while the D1 standards etc. might specify the number of lines, that does not mean a TV will display all, nor does it mean that's the upper limit a monitor, camera, or equipment can have &/or use. Higher line count won't turn a sow's ear into a silk purse :) with regular broadcast, but then they don't rely on broadcast over air or coax in studios (they work with higher quality then broadcast standards), or between SVHS, DVD etc. & TV.
I'm not even talking about D1, I'm talking about NTSC video period, whether it be analog or digital in whatever format (SDI, DV, DVCPRO25/50, MPEG IMX, XDCAM, etc).

You're slightly confusing "lines of resolution" with "scanlines". Lines of resolution are a metric of the horizontal resolution, calculated by taking an area of the width that is equal to the height, and determining how many transitions you can make between fully on and fully off. The more of these you have, the higher your lines of resolution. "Scanlines" are fixed at 525, but no TV will "display" all of these, because some of these are blanking (0 Vpp) in order for the electron gun to return to the top, giving the end result of 480-486 visible scanlines in a 525-line signal. All NTSC monitors handle 525 scanlines, or they're not NTSC.

[theReal]

why should the interlace-line flicker be different on a broadcast-control-monitor than on a simple TV-set? I don't know why but when I compare a standard tv to a studio monitor at work (and these are not even class a, they're old and crappy monitors) it flickers much less. I guess because the monitor displays the lines more correctly than a normal tv (less electrons hitting the wrong places)

"If you convert it to DV on your PC -> Copy to Tape -> Copy to PC ... is it different?"

If you use a copier & make a copy, then make a copy of the copy, then make another copy of your 2nd copy and so on, you'll see the image start to blur and degrade. Basically it's blurring the image as suggested. That's a wrong comparison. We're talking about DV transfers via IEEE 1394, digital 1:1 transfers - there can't be any blurring and degradation because no re-compression is taking place.

The other flickering horizontal fine line problem I have a harder time understanding why. Because when converting it to MPEG2 I do not see this problem. The bottom line is I’ve still not been able to get this to work myself, I would sure like to hear of someone that has actually done this, or tried to, and is just not theorizing on why this occurs, the challenge remains. MPEG2 is a blurry mess compared to DV, that's why it won't flicker anymore. You are asking for the impossible - have you ever seen a tv station using fonts with very thin lines? They don't because the thin lines flicker on tv. Nobody theorizes on why it happens, it just happens and that's why thin lines are a no-no for tv.

[mic]

Mic: Thank you for the informative link, I will be shortly trying out the test patterns there. What I’m looking for is an established scientific methodology where a person would share exactly, in detail, of how they achieved the objective.
Sorry for earlier brevity -- being a bit short because I was tired. :( I was suggesting I could send samples if it helped.

I've taken your post seriously, and just spend a bit of time going over the basics, redoing my earlier comments. Please re-read post -- glad you like the link -- if you want more, let me know.

That said, I wanted to qualify the basic changes made to video as it moved from one stage or state to another. It is possible to quantify, & I've seen this done reviewing various formats by the DV mag (DV.com), but I don't have the software tools, and for me the visual display is more useful. The basic method I've used is as in the edited post, overlaying snapshots of the video, and yes, I've found the actual pictures of TV screens helpful to judge what something like a DVD player is actually doing, and to factor in the bulge (or opposite) of the tube.

Using the difference and other filters, I can see just how far off the picture has become, narrowing it to colors or whatever. The other day I used this method to compare some capture results and it worked there pretty well. I don't know that it would be called scientific, because I don't have a pixel by pixel comparrison.

As for the pattern itself, because if the methods I use, I simply created a grid, marked it on both sides at 704, 655, & 640 pixel width. I included some heavier squares in one version I think on all four corners. And in all I've placed a large ring of circles, like a target without bullseye, in the center. Doing overlays, I can fairly easily tell where any stretching occurs. I didn't do any fine lines because the overlay shows me edge degradation.

Color wise I tried to stay very conservative because of the way different colors can be incompletely saved, and because too much signal can cause overdrive -- more bleeding or distortion on a TV screen. I used almost an army green with pale yellow and blue. For color tests I usually grab a clip from something I'm working on, & have a 13" monitor a couple feet away from my PC monitor to compare -- I can view the source twice or whatever.

I don't go too crazy on color though, trying to always error on the side of conservative. I'm more concerned about light and dark, and usually try for boarderline, almost starting to be washed out. Then I'll go for accuracy as possible. Most TVs in the US are mis-adjusted (really), and accurate color does nothing if everything dark is a muddled mess.

Once read something that changed my whole approach... A lot of folks (pros/semi-pros etc) make the mistake of using the very highest end hardware and procedures in recording & processing audio, and forgetting that a lot of this work is actually usable only on similar hi-end equipment. Put it on a normal TV and the audio is disastrous -- too many never bother to see if it works on a cheap TV. The pro who wrote the article uses the best equipment, but he also re-listens with a cheap pair of headphones.

I've seen countless mistakes on advertisements appearing on cable, where they did the same sort of thing on both video and audio, though I'm sure it looked wonderful in their studio.

Hope this helps :D

[bobcat56458]

I wanted to do some further testing with this 720x480 test pattern. What I did was print it using a Canon Pixma P3000 photo printer. I used high resolution 8 and a half by 11 inches paper, not photo stock. I had resized it to 800x600 so that it would have the correct aspect ratio. I set the printer to its highest quality setting but nothing that would alter the color and printed it out. I took this test pattern and placed it flat against a wall and aimed my DV camcorder at it with no zoom or filters. The Camcorder was back about a foot and a half or two and recorded a clip to tape, and one directly to the computers hard drive by way of firewire using a program called Captureflux. I then imported the DV stream to the computer from the DV tape by way of firewire. I then viewed both the DV tape to computer, and the clip I had made going directly from the camcorders lens to the computers hard drive. I did this test using two different consumer DV camcorders, and the results were the same. On viewing the DV AVI’s the flickering remained, what had changed was the color smearing was not nearly as present as it was when I made a DV AVI from the original test pattern image using the computer. On the down side the colors were not as vibrant as when I had did it that way. What this reinforced in my belief was that the NTSC DV codec is not a very high quality compression standard. It also showed me that converting a test pattern image to a DV AVI (without using a camcorder) was not the problem. Thereal states in his last post: “MPEG2 is a blurry mess compared to DV, that's why it won't flicker anymore. You are asking for the impossible - have you ever seen a tv station using fonts with very thin lines? They don't because the thin lines flicker on tv. Nobody theorizes on why it happens, it just happens and that's why thin lines are a no-no for tv.” I counter with, in the past I would watch big satellite dish wild feeds. They would play a recorded TV program that was to be downloaded by affiliate TV stations. They would often start, and end, the video feed with test patterns so the stations could calibrate their playback, and broadcasting equipment. Now my point is, these test patterns were the same as the one I linked to. The fine lines and all were not flickering when I watched them on my 70’s/80’s consumer TV’s, and the resolution was as good as the TV set I was playing them on.

[trevlac]

@Bobcat

I use Vegas and have a Laird DV device thru which I can pipe an s-video signal to an old Commodore monitor. From the timeline with monitor preview ... Vegas will encode the jpg to DV using the Sony codec, send it to the Laird, which will then turn it into an NTSC signal for the monitor. The monitor is just like a TV but has a higher horizontal resolution. I'll do this tonight and tell you what I see. :)

BTW: I've done all sorts of test on various equipment and processes. Here is a resolution test I did using the chart from the avia DVD to see how 6 different capture devices did with 6.75MHz Horizontal resolution. I posted a little writeup in the capture forum when i did the test. This one was sort of the opposite of what you are testing.

Also I tested the colors. DV is NTSC 4:1:1 so it bleeds more than the 4:2:2 stuff.

http://www.trevlac.us/pics/Res.jpg
http://www.trevlac.us/pics/BarsTest.jpg

[mic]

@LocalH
That relatively simple TV signal has been analyzed to death in the digital world, with all sorts of good info online from great sources -- it would be wonderful if they could all just agree. :p This might help some folks wondering what we're talking about:
http://hometheater.about.com/cs/television/a/aavideoresa.htm

At any rate I got sloppy (thanks for keeping me honest), and in edited post to better answer bobcat56458, tried to specify the different vert. scanning lines versus horiz. lines of resolution. I took the easy way out and left horiz scanning lines & different definitions of horizontal resolution alone for the moment. :D

I apologise for mentioning D1 etc. but actually that's where I've seen the line count thing everyday. Don't usually give it much thought, as it doesn't apply to most tasks except as identification. DVD players or other equipment do the actual creating of a (hopefully) legal stream the average TV will accept. :)

I would try to get across that there are different quality TV & TV monitor picture tubes. When it comes to interlace caused flicker, the size, number, and spacing of dots doesn't change or eliminate it, but it can effect our visual perception. I hope that's helpful to anyone who wonders what's going on if it's worse on one, better on another.

There has to be differences in the total number of dots available if you will, just going from 5" to 13" to 31". I think otherwise TV would look great on my 13", and get progressively worse as the size of the TV grew, kind of like having your PC set to 640 x 480. I don't think it's correct to view the NTSC spec as other then minimum signal standards -- a TV or TV monitor might be capable of less, or more, but it will accept that signal and display something.

I've seen a lot of info about scan lines, from good sources like universities, and a lot of it contradicts in places, so I'm not going there -- rather silent then misleading. :) And other then why flicker seems worse here, better there, scanlines really don't enter into anything unless you're buying hardware or working in something like broadcast engineering.:)

[mic]

@bobcat56458
In one of my posts this afternoon I mentioned Adam Wilt's site. I think you'd really find it interesting -- if I remember correctly he has some info that applies closely to your latest testing. ;)

[mic]

@theReal

On the monitor comparison end I hope I've offered something. :)

RE: copying, I think this was what Bobcat was doing -- his purpose (as I understand it) was testing loss. Apologies if I've misunderstood his post. :)

RE: mpg2... Adam Wilt had some interesting comparisons, where he states that at the same bitrates, there isn't that much difference. In my own use that seems to be true, but I don't think you're likely to see anyone using high bit rate mpg2 outside of HD; DV edit is undeniably better. Not contradicting, just trivia. :)

[mic]

@Bobcat

I use Vegas and have a Laird DV device thru which I can pipe an s-video signal to an old Commodore monitor. From the timeline with monitor preview ... Vegas will encode the jpg to DV using the Sony codec, send it to the Laird, which will then turn it into an NTSC signal for the monitor. The monitor is just like a TV but has a higher horizontal resolution. I'll do this tonight and tell you what I see. :)
Out of curiosity, could you do a print to tape vs preview device comparison? :)

Oh, & how in the L do you still have a working Commodore monitor? Man that makes me feel old! :D

[theReal]

in the past I would watch big satellite dish wild feeds. They would play a recorded TV program that was to be downloaded by affiliate TV stations. They would often start, and end, the video feed with test patterns so the stations could calibrate their playback, and broadcasting equipment. Now my point is, these test patterns were the same as the one I linked to. The fine lines and all were not flickering when I watched them on my 70’s/80’s consumer TV’s, and the resolution was as good as the TV set I was playing them on. The test patterns from satellite were most probably more compressed than DV (today MPEG2 is used for satellite connections, mostly with bitrates like on a DVD) - that means they were more blurry than DV...

I don't think you're likely to see anyone using high bit rate mpg2 outside of HD MPEG IMX from Sony uses I-frame-only MPEG2 compression for SD video. They say it's as good as DigiBeta... at least it's better quality than DV, at the same compression rate of 5:1.
I said that MPEG2 is a blurry mess compared to MPEG2 - I was referring to MPEG2 on DVDs, with long GOP and a maximum bitrate of 8-9mbit, not to some modified I-frame only high-bitrate MPEG2 like IMX!

What this reinforced in my belief was that the NTSC DV codec is not a very high quality compression standard. Oh really? :p :D ;)
Why do you think everybody who can afford it is using DigiBeta or at least DVCPro 50?

[mic]

MPEG IMX from Sony uses I-frame-only MPEG2 compression for SD video. They say it's as good as DigiBeta... at least it's better quality than DV, at the same compression rate of 5:1
Did it wind up catching on? Know it had good reviews a few years back, but hadn't heard anything. Doing a quick google couldn't find anything really recent?

[trevlac]

Sony DV->Laird->commodore

Strike 1
Shakes like hell! :D Mainly in the diagonals. The color lines also flicker. Some pure horizontals flicker.

So ... I thought ... maybe the pattern was not properly filtered. Maybe there are some funky edges in there. A few months back, I wrote a VDub filter that does a frequency analysis of an image. There is a link on this page: http://www.trevlac.us/FilterDocs/

I compared this image I pulled from the Avia disc vs bobcat's pattern. http://www.trevlac.us/pics/Resolution1.png

Strike 2My pattern has loads more aliasing! Bobcat's is fairly clean, but certainly higher than NTSC height can support.


So ... I thought ... let's try DVD.

Foul Ball The DVD also shakes like hell! The color lines are not as bad (but they were probably (properly) blurred going to 4:2:0) I made the mpeg from Vegas which uses main concepts.

==================================
Bottom line .... I failed the challange. HOWEVER my (unproven) conclusions are different about what is to blame. I say it is the NTSC interlaced signal / monitor that is the issue. The Vertical frequencies in the pics are higher than 240 scan lines can show. It could be the mpeg/DV codecs. They effectively compress by removing high frequencies. But logic tells me that because the image is not moving, the errors should also show on a progressive monitor. They do not show for me in VirtualDub from both a DV.avi and an mpg file.

I also think DV can not be blamed when using the camera to film a chart. The camera probably pulls 2 full frames and saves the fields before the codec sees the info. I doubt anything actually low pass filters. So again the crap V rez of NTSC is the problem.

But that is all theory stuff ... :D

[trevlac]

MPEG IMX from Sony uses I-frame-only MPEG2 compression for SD video. They say it's as good as DigiBeta... at least it's better quality than DV, at the same compression rate of 5:1.

I'm as amature as they come :D So I looked up the MSW-900P at B&H. $39,000.

Oh My God! Is the 4:2:2 really worth it? How bout HVR-Z1U for a mear $4k? I'm not really up on the specs of HDV but this really seems out of wack!

:D

[mic]

@bobcat56458

Grabbed pattern from link posted by trevlac -- if this grayscale is similar to what you guys were playing with, cool. Of course it won't show color effects of compression, but maybe do some good. :)

Had some minor issues with file color space of original, but nothing that would effect anything and tried orig & conversion anyway.

Compressed to mpg2 & DV, tested losses -- while detectable, not that significant. As I mentioned earlier, and maybe it's unusual, I've done a lot more with stills then video, so that's where I'm most comfortable when not trying to measure transients. The DV format showed very slightly more degradation then mpg2, with a very, very slight shift in red which I would have expected. The biggest difference was in the vert moire to the right in both cases.

Interpreted RGB output to small TV monitor was good, though a bit limited because just plugged composite in, with a slight bit of interlace flicker on horiz. lines in upper and lower moire. DV & mpg2 showed some degradation, DV was noticably worse on pattern in left lower circle -- right lower did not display properly in amy case, but again that was expected.

DVD test to TV with 600+ Horix. Lines Res. was interesting. :) Everything checked out except 1 pixel wide horiz lines, again as expected. These would have mapped to alternate fields so moire did it's dance as I assume it was designed to with it's alternating bands of white etc., as explained here (Find the word "wedge" towards bottom of page):
http://download.microsoft.com/download/e/b/a/eba1050f-a31d-436b-9281-92cdfeae4b45/MCEVid.doc

Don't know if that helps or not...

[bobcat56458]

Thereal: Lets try keep it real, when you state: “Oh really? Why do you think everybody who can afford it is using DigiBeta or at least DVCPro 50?” It reminds me of a professional that is shooting to 16mm film looking down on a guy that shoots to video, then there is the person that works in the IMAX format that looks down at the 16mm film person, can you see where I’m going with this? I see you are working at a local TV station, and making a career in the video field, naturally this would dictate that you would gravitate towards the tools of your chosen trade. But you must remember this is the “DV” forum and the majority of members here although much more knowledgeable than your average layman are using there consumer DV camcorders to archive family events, not the news at ten. We don’t want to lug around a shoulder mounted DigiBata professional camcorder to family events. We like the portability of our mini DV camcorders. We have no problems finding ways of spending money accessorizing our $350~$1500 consumer DV camcorders. Naturally given the type of person that hangs around a forum like this, we are always looking for ways to push to the limit what we can do with these consumer camcorders. We will spend countless hours between the times we are actually shooting a family event, searching forums, trying out new techniques, in the pursuit of this hobby. Which brings us back to the point of this thread. Making a calibration test tape for our consumer DV camcorders. Can we all focus on the topic at hand.

[SeeMoreDigital]

Hi bobcat56458,

From time to time I make my own test cards too, using a little known application called JPGAvi which is available over at http://www.ndrw.co.uk

But I must admit I've not considered storing them onto DV tape!


Cheers

[bobcat56458]

SeeMoreDigital: I’ve had good results using a program called ProShow Gold for making slideshows or just MPEG2's from an image. It’s the program I used to make the MPEG2 file of my test pattern project. It made a MPEG2 that did not show any flickering, or color shift. It has an option to remove flicker that I do not see in the program JPGAvi. What ProShow can’t do is save a file as an AVI, an option that I wish it had for my project.

[SeeMoreDigital]

Are you able to provide an short MPEG-2 sample so I/we can see how bad the flicker is?


Cheers

[bobcat56458]

SeeMoreDigital: There is no flickering on the MPEG2 file ProShow produced. If you are referring to the flicker on the DV AVI’s I’ve made yes there is. However I’m on the dreaded dialup, and am in an area which has no high speed internet available. So the most I’m able to upload is about 750Kb at maximum which would not be a long enough MPEG2 file to do you any good. The DV AVI flickering problem is a minor one, but when you want to produce something for testing purposes even that is unexceptable, sorry.

[theReal]

Sorry bobcat56458, I didn't want to be rude (that's why I put a lot of smilies behind my statement). However when you say that this is an amateur DV forum (you're right), then you can't constantly demand professional standards from your amateur equipment... It appeared like this to me, so I wanted to point out you are right with your quality demands, on a professional level :)

I'm as amature as they come So I looked up the MSW-900P at B&H. $39,000.
Oh My God! Is the 4:2:2 really worth it? How bout HVR-Z1U for a mear $4k? I'm not really up on the specs of HDV but this really seems out of wack!The camcorders are in totally different leagues - the MSW-900P is a pro shoulder mounted 2/3" 3CCD. These camcorders are always horribly expensive, no matter what tape format they are. Quality differences are mostly the lenses, the 2/3" chips, the higher robustness - but almost nobody could afford something like this privately.

Did it wind up catching on? Know it had good reviews a few years back, but hadn't heard anything. Doing a quick google couldn't find anything really recent?I know that the German station WDR has just replaced all their Beta SP equipment with Sony XDCam, it's MPEG IMX on cartridged Blue-Ray DVDs. I think this one is catching on because of the tapeless recording.

[mic]

I know that the German station WDR has just replaced all their Beta SP equipment with Sony XDCam, it's MPEG IMX on cartridged Blue-Ray DVDs.
Cool :)

Wasn't being smarta... when asked earlier :D

[LocalH]

One problem is that the test card is already at video resolution, and thus the image was likely generated without taking interlace into account. Most actual professional test cards are at a much higher resolution and sampled by a camera, which will always output smooth and clean interlaced video. You could probably somewhat replicate this with a higher resolution test card that you downsample into an interlaced image. I'm not sure of a quick and easy way to get Avisynth to do this (it seems that the resize function treats the signal as progressive), but I'm pretty sure that Adobe After Effects can do such things, as I've used it quite a bit for producing local PSAs. Imported images are of excellent quality in a real-world broadcast situation, whether they be too small or of a good large size.

Basically, the best thing to do is always to use a higher-resolution image than you need and downsample to an interlaced frame. This should create the best possible results when viewed properly on an NTSC monitor, regardless of the compression used (except in an extremely bit-starved stream).

[SeeMoreDigital]

Can some of you guys try the following MPEG-4 16.9 NTSC Test Cards (http://82.2.167.237/Uploaded_Files/Doom9_Forum_files/16.9_NTSC_Test_Cards.7z) please?

One has been encoded with 720x480 pixels and includes 16:9 DAR signalling, the other has been encoded with 854x480 pixels.


Cheers

[trevlac]

@Bobcat

I was curious about your MPEG results ... and why they did not shake. So I took a look at my commercially produced Avia test TVL 200 resolution chart (I posted a copy above) using 4 different dvd players (apex,GE,Sony,Samsung) and 4 different monitors (commodore, 36" samsung, 25" GE, LCD TV). The apex and sony are s-video, the GE is composite, and the samsung is modulated with an F-connector.

All the images shake. Mainly on the diagionals as I mentioned before. The composite and F-connector introduce xtra color in the detail. The LCD actually shakes the least, but I think this is due to the bluring effect of the LCD monitor.

So ... my mpeg results don't match yours. And yours don't match a commercial test disc (no DV involved).

This of course does not meet your challange but I think it shows me that the display is the problem. Not DV.


@LocalH

"Basically, the best thing to do is always to use a higher-resolution image than you need and downsample to an interlaced frame."

I think this is good advice, but not the root of the problem. The important thing is HOW it was downsampled. If the downsampling does not lowpass filter the higher frequencies out ... the image will have artifacts. Lowpass filtering is bluring. The vertical resolution of any NTSC device is quite low. So if the downsampling blurs the vertical frequencies and then seperates the frame into fields, you might avoid the shake. This is of course theory ... guessing on my part. :)

BTW: A vertical blur probably does not reduce the value of the chart. The chart measures Horizontal resolution. Vertical resolution is the same for all NTSC devices.


@theReal

Ahh ... 2/3" CCDs. Yes i noticed that when I looked. I've wondered what depth of field tricks one could do with better CCDs. Anyway ... thanks for the comments on MPEG IMX. I never heard of that before.


@mic

Sorry I missed your comment on Tape vs Preview before. I'm not sure how I would do tape and be consistant. I'd have to play my tape from one of my cameras and I'm not sure if they are any good at making an NTSC signal. The Laird should be. I am quite sure if I copy to tape and back that there is no change.

The Commodore monitor is great. Someone on this forum gave me the tip. You can find them for about $25. I'm not sure I can fully trust it for colors, but it's resolution is way better than a TV, and I don't think it has overscan and such, so it works well as a production monitor. Much better than a TV.

[mic]

@trevlac
Not to worry about tape vs preview -- thanks for reply to it :)
Basically I was just trying to add to experience and info on overlay render from preview vs print to tape which should cause render and use of avi file.

If it helps understanding...
Any image with 1 line or pixel height should dance on interlaced TV, and if it doesn't, then either the picture's being deinterlaced or blurred to take up 2 or more horizontal lines. How noticable it is can vary quite a bit.

... All the images shake. Mainly on the diagionals as I mentioned before. The composite and F-connector introduce xtra color in the detail. The LCD actually shakes the least, but I think this is due to the bluring effect of the LCD monitor.
Earlier link:
http://download.microsoft.com/download/e/b/a/eba1050f-a31d-436b-9281-92cdfeae4b45/MCEVid.doc might help or be of interest... If I read correctly, the still posted earlier is designed for testing deinterlacing on something like HTPC or MCPC, and should dance on anything interlaced. On LCD if fed progressive shouldn't see effects at all -- so if you used progressive player, might not be working as it should.

At any rate, it's supposed to shake on a TV. If you look at the image closely, you can see the alternating bands of white in lines that are one pixel tall. As player translates these one pixel lines to fields, and as one field is not refreshed, lines go away & reappear causing moire dance. :D My wife loved it! :D
Basically, the best thing to do is always to use a higher-resolution image than you need and downsample to an interlaced frame.
Actually as far as a PC is concerned, an image is an image, whether it shows effects resulting from being interlaced or not. Rendering an image to video most NLEs will record it pretty much as is -- on playback every other line will be taken as a field, or in the case of mpg2 23.976 or 24 p, pulldown will duplicate frames. It is better to use a slightly oversized image (Adobe.com lists recomended sizes) because that will produce better results during render with resampling to DV/DVD pixel aspect ratios.

The Commodore monitor sounds pretty decent. :)
FWIW, wonder if it's a bit like the old Amiga monitors. If so, think the color models are a bit different -- If I remember correctly there still are settings in some PC software to compensate for Amiga output.

[bobcat56458]

Trevlac: I’m surprised to hear that a commercial test DVD like the Avia shows flickering of the fine lines. If you had just used one DVD player, and one TV set to view this I would have been leery of your results, but you stated you tried this DVD with multiple DVD players, and TV sets, with different types of cables. If anyone else has this disk it would be interesting to hear if their results are the same as yours. To explain why the MPEG2 I made did not flicker may attest to the quality of the flicker filter in the ProShow Gold slideshow program that I used to make the MPEG2 video clip, I just wish it could output in the DV AVI format.

[mic]

From: http://download.microsoft.com/download/e/b/a/eba1050f-a31d-436b-9281-92cdfeae4b45/MCEVid.doc

Test 18: TV tuner/capture/encoder video bandwidth test
Goal: To measure the lines of video captured and compressed with the TV tuner device to ensure that video capture is delivering a detailed and accurate image.
Test Tools required: Avia Guide to Home Theater DVD and consumer electronics DVD player with S-Video output
Test Configuration: Set Media Center TV source to STB (S-Video) and connect DVD player output to TV capture card input via S-Video cable. Connect PC via VGA or DVI to ***high-resolution progressive scan display.*** Drive fixed pixel display at native resolution. Failure to drive display at native resolution will result in false failures on this test!

"Observe the moving resolution wedge closely and watch for any breakup in a smooth image. If the resolution wedge shows clear straight lines, the **deinterlacer** is properly running in film mode and is weaving. If the resolution wedge in the image shows distortion or aliasing artifacts such as a “valve” shape where straight lines should appear, the deinterlacer is running in video mode "

[trevlac]

@bobcat

Yes ... 4 different setups. Too bad we can't see a still grabbed from that mpeg you make. Here is a filtered version of your image. It does not shake on my commodore via DV out. BUT i blurred it. Only in the Vertical direction. I was surprised that I needed to blur to about 2.5MHz. I thought around 3MHz would be ok. I basically used a truncated sinc filter so there is a bit of ringing in the image. i don't think one can see this on a TV. The image looks ok on a TV. Not as sharp as the origional, but not bad. On a PC, it is rotten. You can read the wedges and see that I blurred to around 200TVL vertical and not at all H. I sorta thought 240TVL Vertical would be ok. I'm not sure why it does not work.

http://trevlac.us/pics/bobcat.jpg


@mic

I'm not sure if your info is for me. I do not have a progressive dvd player and can't hook my LCD up via DVI. It's a bit old. The chart I was using could measure a few things. One thing I've used it for in the past is to measure horizontal resolution of capture devices. I posted a test link before.

BTW: My commodore is model 1702. Worth looking into.

[mic]

I'm not sure if your info is for me.
Well... no :D

RE: the last post with the quotes from the doc...
A lot of folks go through these threads both to fix prob & learn -- know I have & do, and often we tell people to search through them looking for a prior post &/or cure. In that sense it was directed to everyone. :)

I wanted to show, in Microsoft's words, that the purpose of the moire-like pattern you posted (http://forum.doom9.org/showthread.php?p=703371#post703371) was to dance on an interlaced screen - if you saw dancing on your hi-res progressive monitor, your setup was possibly (probably?) screwed up. :) I frankly hope to stop readers from running this test pattern and posting all over that they have a problem when they don't. And I posted the actual quotes because I wanted to make sure it was very clear: this pattern will cause interlace flicker.

There are others that are standard, go higher in terms of measuring Horiz lines of resolution, and available online. There's even a couple in the Windows Media Resource kit that most have already I think, and they do color. Perhaps a good solution for you might be to cut and paste a portion of these over the moire in your pattern? Serves no purpose on interlaced...

Anyway, thanks for the monitor info :) -- I've got someone keeping their eyes open. I also want to go through my software and see what supports the Amiga colorspace & pixel aspect (that was unique too) and if it applies. :D

[bobcat56458]

Travlac: Here is a link to a still image from the MPEG2 that I captured using copy to clipboard in VirtualDub-MPEG2. I then pasted that into Paint and saved it as a bitmap. Then I compressed it to a JPEG at 95% Quality setting using Ulead iphoto express so the image file size would match yours for a fair comparison. The MPEG2 itself was made with ProShow Gold with the default settings checked for “Desaturate image to 80%” and “Apply anti-flicker filter to video” the video bitrate was 9000kbps VBR. As you all can see my still has higher resolution visible with less artifacting on the black material, but the color is not near as good as travlac’s still photo. The DVD’s color is marginally better when viewed on the TV sets but the green color on the “5%” lettering is still very bad and blurry. I did another one leaving the Desaturate image checkbox unchecked but the color was even worse. Let me reiterate that the DVD’s I make from ProShow do not flicker on the TV’s (or computer using WinDVD) playback using a Norcent DVD player to the 5 TV’s (47 inch, to 19 inch) throughout my home, some connected with S-video, & some with composite connectors.
http://img251.imageshack.us/img251/1503/testpatternfrommpeg2screencapt.th.jpg (http://img251.imageshack.us/my.php?image=testpatternfrommpeg2screencapt.jpg)]bobcats capture JPEG from the MPEG2 [/URL]

[SeeMoreDigital]

Is this sample (http://82.2.167.237/Uploaded_Files/Doom9_Forum_files/NTSC_720x480_ACCO_Test_Card_01.7z) any better?


Cheers

[bobcat56458]

SeeMoreDigital: Very Good! Yours is the best MPEG2 so far. It reinforces what I’ve been saying all along, that it can be done in MPEG2 (DVD). The real challenge though is doing it as a DV AVI that looks as good as your MPEG2, as I stated in my original post was the objective. Please share how you achieved such a good MPEG2 with everyone in great detail, so we can learn from it, and replicate your method.