PDA

View Full Version : Note: To Toaster CG R&D



David
09-25-2003, 05:57 AM
Character Generators & Titling:

"I spent almost four years writing software for the Abekas A72 in the early ’90's; I learned a lot about what works and what doesn't work when putting text on a video screen.
Doing good CG in interlaced video is trickier than you might think. Doing it right in compressed interlaced video (such as DV) is even harder. With interlace, you can have problems of line twitter on static or moving text, as well as roll-induced "crawlies" and distortions. With compression, you add problems of codec pathologies. And there are always pitfalls associated with colors and bandwidth.

Line twitter occurs when you have fine, single-line detail that appears in one field but not in the other. The detail so rendered will flicker at the frame rate, while the rest of the image updates at the field rate. The frame rate (29.97 Hz in 525-line NTSC; 25 Hz in 625-line PAL) is slow enough that your eye notices the flicker, and it's very annoying.

First, make sure that the fonts you use don't have fine, single-line horizontal strokes that will show up as line twitter. Look at heavier fonts in the same family: instead of light or roman, look at bold, extrabold, or black variants. But bear in mind that instead of using Coronet or Script Light, you might have to switch to Helvetica or Times Bold. Often I find that the delicate typefaces I prefer in print work just won't translate properly to video, and I have to find something else instead.

If you're dead-set on using a fine, light typeface, try building a font that thickens up the strokes: use outline, soften, glow, or extrusion (solid drop shadow) effects in a similar color or brightness. Sometimes a soft drop shadow in a similar color with a minimal offset can be used — even Premiere 4.2's limited text capabilities will give you that much!

The problem with interlace and rolls is that as the text moves up the screen, its position with respect to each field's line structure can either change, or stay the same. If it stays the same, your text will look as good moving as it does when it's still. If it changes, the text will lose resolution and may flicker, distort, and crawl around as it rolls.

Imagine characters in a screen font with a height of 10 lines. When placed on a page at its starting position, the even scanlines in the character all fall on the even video field, while the odd scanlines fall on the odd field. As the text sits there, the even fields show lines 2, 4, 6, 8, and 10 in the text, while the odd fields show lines 1, 3, 5, 7, and 9. All ten scanlines in the text are seen over the course of any two fields.

Now start a roll. Any decent CG updates the roll on a field basis; after one field is displayed, the text is moved up a certain amount for the next field, up the same amount for the next field, and so on.

Let's say that the director wants a nice, slow roll, to kill some time. You've selected 60 lines/second (CGs that allow you to set the roll rate usually use scanlines per second as the measure, and in NTSC-land the 59.94 Hz field rate is rounded to 60 Hz to keep operators from getting bogged down in fractional math. If you're in PAL-land, assume you're rolling at 50 lines/second for this example), and pushed the "go" key on the CG.

Now in the first even field, character scanlines 2, 4, 6, 8, and 10 are shown. Next the text is moved up one scanline because at a nominal field rate of 60 Hz, one scanline per field results in 60 lines per second. So when the odd field is displayed, the text, being up one line from its even-field position, has lines 2, 4, 6, 8, and 10 displayed again — and lines 1, 3, 5, 7, and 9 don't get put onscreen! The next vertical interval comes along, and the text is moved up one line again, so that the even scanlines once again appear in the even field. The next vertical interval arrives, and up goes the text again — one line! — so that the next odd field, like all the even and odd fields before it, shows the even scanlines of the text. The odd scanlines in the text never appear onscreen!

The result is half-vertical-resolution text that looks awful. Thin horizontal strokes will either appear about twice as thick as they should, or twice as thin, depending on your luck (sometimes you get the evens, sometimes the odd scanlines, depending on the CG you're using, the initial position of the text, and the field timing when you press the "go" key).

Now go back and double the roll speed, to 120 lines/second (or 100 lines/second if using a 625/50 CG). Now, the first even field shows the even scanlines. Come the vertical interval, the text is moved up two lines (two lines per field times 60 fields per second gives 120 lines per second); the relative positioning of the text with respect to the field structure remains the same, since the even scanlines are moved up two lines to the next higher even scanline, while the odds are moved up to the next higher odd line. When the odd field is displayed, the odd scanlines in the text are shown, just as they should be! The full vertical resolution of the text remains.

You may have noticed a pattern here. When the roll rate (in lines/second) was the same as the field rate (in fields/second), the roll looked awful. When the roll rate was twice the field rate, things looked fine. As it turns out, this relationship holds for all integer multiples: roll rates that are odd multiples of the field rate look awful. Even multiples look great. Thus for 525/59.94 (or 525/60, more or less) video, good roll rates are 120, 240, 360, and the like. In 625/50, the good ones are 100, 200, 300, 400, and so on.

Unfortunately, in 525/59.94 the only two decent rates that are slow enough to be read are 120 and 240 (and the latter only on a good day!). 625/50 video is better — not only are the roll rates about 20% slower, there are almost 20% more active scanlines in a frame, so in 625 you can roll at 100, 200, and 300 lines/second without straining any eyeballs.

What about roll rates that aren't integer multiples of the field rate? As you might guess, as the text moves, its positional relationship to the field structure no longer follows an integral structure, but changes on a field-by-field basis. This leads to two things:


Unless the CG you are using offers sub-pixel positioning, the roll won't be able to execute smoothly, and the text will stutter or judder up the screen.
The roll motion will "beat" with the field structure, as the scanlines themselves appear to roll through the text (at a rate proportional to the difference between the roll rate and the nearest integral multiple of the field rate), causing time-dependent rippling distortions of the text (the "crawlies") that look really horrible.
What real CGs do to avoid this is to offer only the “good” rates by default; extra work is required to set arbitrary roll rates. When you select timed rolls (the total time is set, rather than the speed), better CGs will fiddle things to wind up with a good rate. Some may just pick the rate that comes closest to meeting the desired time; some Chyrons run part of the roll at one rate, then “shift gears” to finish at a different rate to get the desired total duration; the A72 (and probably the Texus) “adaptively spaces” the text in the roll, stretching or compressing the vertical line spacing to allow a good roll rate to be used and still meet the time target.

What crummy CGs offer in the way of speed control is none at all. For example in Premiere 5.0, where they've finally understood that folks want to roll credits, there are no tools for setting or even reporting roll rates in the titler: one just has to adjust things by trial and error. This stinks: if you're stuck with such a CG and need to produce for interlaced video, complain loudly to the vendor about their lousy non-video-aware tools, and then go look for a CG that does things right ( Inscriber Technology's CG is one of the few that does; you might also check out Pinnacle's TypeDeko on the PC, McRobert's Comet CG on the Mac, and Boris Graffiti on PC or Mac. These may offer proper controls... and there may be others out there as well. Let me know what you come up with and how well it works — or doesn't).

Codec Pathologies Most titlers in nonlinear editors render nice, sharp text. That's just fine for display on a computer screen, but it's too sharp for either bandwidth-limited broadcast or for compression: DV, M-JPEG, MPEG, or the like. This is true whether or not the text is antialiased; even antialiased text can have sharp vertical, horizontal, and diagonal transitions with significant energy in spatial frequency bands outside the codec's comfort range.

Overly sharp text stresses the codec; in DCT-based codecs this results in “mosquito noise” or “feathering” artifacts that cause visual noise scattered around the immediate vicinity of the text. Moreover, the character of this noise varies depending on the relationship of the stressing image to the DCT block boundaries, which means that as your text moves (in a roll, crawl, or scroll) the mosquito noise surrounding the text will “fly around” just like a flock of hungry mosquitos. It's very annoying.

The trick is to prefilter the text so as to avoid these problems. Running a simple soften or blur filter over the text will make it look a lot worse on the computer screen — but it will actually improve its appearance going through the codec. Not a lot of softening is necessary, but a little bit almost always helps.
...................."

http://www.adamwilt.com/Tidbits.html

Copyright (c) 1998-2002 by Adam J. Wilt.

Maybe you guys should hire this guy or someone like him!!!

Norman
09-25-2003, 02:41 PM
Very interesting reading and thanks for posting it and the web address for Adam Wilt. I added it to my favorites list and I'm sure I'll visit there often. That text ought to be in the documentation for the CG, even though most will never read it.

ScorpioProd
09-25-2003, 09:30 PM
Yup, that explains why the CG scroll speeds have suddenly become VERY limited.