Når en Rulletekst skal rulle og se godt ud imens den gør det
The problem with interlace and roll 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, disort, 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:
1) 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.
2) 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", "critters", 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. Inscriber CG, for example, offers an excellent and very controllable softness setting for its text rendering, which helps quite a bit (for both codec conniptions and bandwidth control).
