Red subtitles vs white subtitles

I'm using FCP 5.0 on an Intel Mac.

We want to lay in some simple subtitles. We've tried both the text and outline text tool.

We are using Lucinda Grande (though we've tried several others) and they look great using white letters (outlined or not). BUT if we change the letters to another color such as yellow or especially red, the letter get chunky especially with diagonals like a "y" or capital "A".

Why does this occur with all colors except white? I know it must have something to do with anti-aliasing but how do we get great looking yellow subtitles without using AE or PS?

Thanks!

Both Text and Outline Text don't look all that great. Try Boris Title 3D. Also, one common curse is that people try a very "spaghettini" font style and size -- such as the default, Lucida Grande, a horrible, random-looking font. Yeah, you can fit more text into one card that way, but your titles will look shite. Switch to Helvetica Bold and see a difference. Yellow is the most visible subtitle colour. Make sure you take advantage of the Outline and Shadow options in Title 3D.


www.derekmok.com

Boris titles are the best for most applications. However, lower third Text titles work fine for me when I'm in a hurry or doing a lot of titles. Two things are necessary to use Text titles, (1) simple titles, like arial, helvetica, etc. (2) use wire-frame to move them around and spaces (space bar) to position the upper and lower titles on the page.

As for Boris, I never seem to get shadow or outline in Boris, why is that? Do you have to have a light background to see that? Or is there a way to change the shadow and outline colors?

Thanks for the advice. We will give that a try.

But that still begs the question: why do the white slanted letters look great whereas red slanted letters and yellow slanted letters look staircase-like (chunky)?

Try dropping a 1px gaussian blur on them. Then see what they look like. Red and yellow dont get along with video.

Michael Horton
-------------------

Nobody's been able to do red titles in standard television since they turned the first transmitter on.

You have two things working against you. The quality of the color channels and the character of red.

The luminance value of red--that is the black and white value you would get if you turned "red" into black and white, is 30%. That's it. If you watched your show on a black and white TV, your red titles would never get any brighter than a sick dark gray.

Then there is the way NTSC (or PAL, or SECAM) transmits color. In order to save data and TV channel spacing, the sharpness of a colored object is, on average, *seven* times fuzzier than the same object in black and white. Black and white objects are created with a 00 fine camel's hair paintbrush, colored objects are created with a can of Krylon spray paint.

This works because it's easy to fool your eye with tricks like that.

Digital TV doesn't suffer from a lot of these problems, but conventional television does. Blame the guys who figured out how to create color television without having to throw all the black and white TVs out.

Koz

NTSC...Never The Same Colour.

Or, even better: New Type Sh*t Colours.


www.derekmok.com

Please. It's "Never Twice the Same Color."

It's the cheapest compatible color TV system and it was first. Yes, yes. I know the FCC authorized the CBS system first just before WW2, but then everything froze and in the meantime all those nasty black and white TVs got sold. We can't throw them all out, the viewing public would burn Washington to the ground.

I do like how PAL got around the problem. Their reference rainbow reverses every other scan line. Purple people on scan line one turn into green people on scan line two and cancel out. Rather than give you wrong colors, PAL will elect to give you no color, although it hopefully never gets that bad. Later TVs did all the calisthenics electrically and invisible to the user.

If you believe the technical writeups, SECAM doesn't need either Phase or Color controls. Although SECAM only has half the color sharpness top to bottom, It's electronically impossible to mix the colors up. If this is scan line 27, this must be red. Couldn't be anything else. The system is also pretty impervious to transmission errors, too, so there's no such thing as pastel colour on Canal Deux and vivid colour on Canal Quatre.

Pretty much perfect, right? Well, no. The signal is so robust (how robust is it?) it's so robust that you can't ever take it apart. It's impossible to fade between two SECAM cameras or do any visual effects at all.

That'll put a hitch in your production plans.

Koz

We can even see the horrific stairstepping problem on the 23" 1920x1200 Apple Cinema HD Display we are using to edit with.

I was watching "Night Watch" tonight and they did some red subtitles here and there to pretty good effect. I believe they used Fire or Flame though.

Quote
RG
But that still begs the question: why do the white slanted letters look great whereas red slanted letters and yellow slanted letters look staircase-like (chunky)?

Quote
Michael Horton
Red and yellow dont get along with video.

'Just 5 years late. RG's problem hit me today. The explanations given in the old strand including Michael Horton's suggestive statement don't get to the bottom of it. The various chroma transmission problems with analog video don't pertain to the digital video we're using. With digital video the chroma is cleanly coded with as many bits as the luma, except that there may be chroma subsampling.

I believe the problem RG noted with jaggy red letters is a particular problem that 4:2:2 video can cause with nearly vertical edges between, for example, red and black.

Vector fonts are described by outline curves, not pixels. Where the curve slices through a pixel there must be partial font color in the pixel. Thus there are grey pixels around white letters and dark red pixels around red letters. In order to handle text-on-image, the partialing of the pixel is in an alpha value and one minus the alpha value is used for the background. The alpha value can be the fraction of the sliced pixel within the outline of the letter. But other anti-aliasings using other alpha values can look better than this simplest one. Photoshop offers four choices of anti-aliasing, two of which treat colored letters differently from white letters. I don't know the quality of FCP's text generator, but this is a minor issue for understanding RG's problem. You can import Photoshop-made red-on-black subtitles into FCP and still get the jaggy red v, w, x, A, etc. as RG described.

The edges of fonts need to look good on the display. In my opinion the text generator's alpha values can't be properly applied to the R'G'B' (and certainly not to the Y'CbCr) but only to the final RGB. In other words, where you have Y'CbCr for font body and some other Y'CbCr for the background, and alpha for the font edge pixels, first compute R'G'B' from each Y'CbCr, then compute RGB from each R'G'B', then apply alpha to font RGB and (1-alpha) to background RGB and add the two, then convert back to R'G'B', then convert back to Y'CbCr. It's one big fat algorithm that a high-class effects engine will use for this simple action. I don't know how FCP's font generator deals with gamma. We can largely avoid this precious subject in the following because we're considering strong red letters on black backgrounds.

Render an originally smoothly anti-aliased "v" to ProRes HQ and examine the results at 800%. The dark red pixels along the edges have joined into blocks to become jaggy. Some pixels have even become magenta instead of red. How did those get in there?

The red text trouble occurs not in the 4:2:2 coding per se but in a later chroma interpolation step. You can't see 4:2:2 video without there being such a step. (A pixel in a signal or in a file can have just a luma value, but no pixel in a display can have just a luma value.) I believe the red text trouble is due to use of a foolish method for chroma interpolation.

Each horizontal row of pixels crossing an edge of an anti-aliased "v" has exactly one transition (greyed) pixel. Different rows will have different degrees of greying in that pixel, accomplishing the anti-aliasing. Consider five pixels on a horizontal line through the letter's left edge: black; black; dark red; red; red. Suppose the R'G'B' values for the five pixels are:
(0,0,0); (0,0,0); (50,0,0); (255,0,0); (255,0,0).
The five pixels are coded into Y',Cb,Cr according to BT.709 as:
(16,128,128); (16,128,128), (25,122,149); (62,102,240); (62,102,240).
4:4:4 video would have those values for the five pixels. Since the BT.709 coding is reversible, except for tiny rounding errors, nothing in the anti-aliasing is lost in 4:4:4 video.

4:2:2 video lacks chroma values for every other pixel in a row. So in 4:2:2 video the five pixels are coded, depending on where the letter lies along the line, like so:

Case 1: (16,128,128); (16); (25,122,149); (62); (62,102,240)

Case 2: (16); (16,128,128); (25); (62,102,240); (62)

Some software or hardware must interpolate some chroma values here. I'd guess the interpolation is done in two steps: first produce the missing chroma values in Y'CbCr; then decode all the Y'CbCr to R'G'B'.

I will just illustrate how a problem can occur for the middle pixel in Case 2. The simplest kind of chroma interpolation averages the chroma values from the two neighbor pixels. This makes the Y'CbCr middle pixel in Case 2 (25,115,184). This is a poor approximation to the (25,122,149) we lost from the 4:4:4 video. (25,115,184) is a tad bluer and much redder, and this makes its luma impossible. (Y' would need to be at least 40 to have those chroma values.) (25,115,184) would convert to R'G'B' (110,-17,-17). This must be truncated to 110,0,0). So the pixel that was R'G'B' (50,0,0) in the original has become R'G'B' (110,0,0), much too light, after passing through 4:2:2 video. If the original pixel were R'G'B' (200,0,0) it would have become (142,14,14), rather too dark. In fact in Case 2 the middle pixel brightness is always middling, hardly responding to the original brightness. This causes the jagginess.

Averaging the chroma values from the two neighbor pixels is not the only way to interpolate the missing chroma values. Another simple way avoids the ugliness in both Case 1 and Case 2. Prorate the neighbor pixel's chromas according to how the Y' value fits between the neighbor pixel's Y' values. (I.e., if the Y' is fraction f of the way from the left neighbor's Y' to the right neighbor's Y', make the Cb fraction f of the way from the left neighbor's Cb to the right neighbor's Cb; likewise the Cr.) With this kind of interpolation, 4:2:2 video achieves the smoothness of 4:4:4 video for the red-on-black letters. [See note of correction following December 29 post.]

Transcoding often involves changing between chroma subsamplings. We should begin to pay attention to how different software and hardware deals with 4:2:2 -> 4:4:4 interpolation. I hope better software and hardware avoids foolish methods of interpolating Cb and Cr that ignore Y'. Where 4:2:2 video gives just a Y' value, without Cb and Cr, that Y' value constrains the possible Cb and Cr for that pixel, and at sharp color boundaries the foolishly interpolated Cb and Cr may fall outside the constraints. Such foolish interpolation methods rest on a common misunderstanding that Cb and Cr are independent of Y'. (Even Charles Poynton makes this mistake.) In fact Y' contains a lot of R'. Cr is based on R'-Y'. So as a red is darkened not only does its Y' decrease but also its Cr decreases.

According to the above, RW's question has a clear answer. For white-on-black text, the anti-aliasing can only be grey. At every pixel Cb = Cr = 128 (in 8-bit video). With 4:2:2 video the Cb and Cr are missing at every other pixel, but any method of interpolation recaptures the Cb = Cr = 128. For red-on-black text the anti-alias pixels must have various darkenings of the red. With 4:2:2 video the Cb and Cr are missing at every other pixel, and a certain foolish method of interpolating the missing Cb (respectively Cr) from the neighbor pixels' Cb (respectively Cr) does not recapture the appropriately darkened appropriate red. Instead, really dark reds in the anti-aliased edge become too light and really light dark reds in the anti-aliased edge become too dark, all tending toward the middle. Thus they block up, defeating the anti-aliasing and making a jaggy edge.

Whether generated in FCP or imported from Photoshop, red-on-black text looks beautifully smooth when rendered in a R'G'B' codec like Animation or None and jaggy when rendered in a 4:2:2 codec like Uncompressed or ProRes422(HQ). But when I rendered them in ProRes4444 they also displayed jaggy which seemed to defeat my whole explanation. I believe FCP is implementing ProRes4444 properly and the 4:4:4 video makes the text as smooth as R'G'B' video. The nastyness I saw seems to be due to my graphics card interpreting 4:4:4 video as 4:2:2! I made a tiff for experimenting within FCP itself, avoiding display. The tiff makes the R'G'B' transition ... (0,0,0); (0,0,0); (0,0,0); (50,0,0); (255,0,0); (255,0,0); (255,0,0)... twice, with a horizontal displacement of an odd number of pixels. For 4:4:4 video, or for R'G'B', the two transitions should be exactly alike. For 4:2:2 the two transitions will represent Case 1 and Case 2 described above and be different. The tiff is just 64 pixels wide so the Parade scope in FCP shows individual pixels nicely. Result: when rendered as 4:2:2 video, Parade showed Red transitioning 100% to 26% to 18% to 0% for Case 1 and transitioning 100% to 78% to 0% for Case 2. When rendered as either 4:4:4 video or R'G'B', Parade showed Red transitioning 100% to 26% to 0%. This shows that FCP does some foolish interpolation of 4:2:2 video for the sake of it's scope. It's not exactly the foolish interpolation detailed above -- I don't know how it produces two, rather than three, transition pixels in Case 1 -- but there are resemblances. In another experiment I imported the tiff into an FCP sequence, rendered, exported as a .mov file, reimported that to the sequence, and then exported a single frame as a tiff. ProRes4444 returned a tiff with the exact same transition values as the original tiff's. ProRes422(HQ) returned a tiff confirming the mess shown in the Parade scope.

I shouldn't fault FCP7 for the foolish interpolations of 4:2:2 chroma if it is obeying an industry standard. But is there a such a standard? Are editors using i/o cards (to go straight from the 4:2:2 video file to a broadcast monitor) seeing the same jaggies in red-on-black titles?

If you must have small red-on-black text, as my director insists, then the best plan might be to output the whole project as ProRes4444. But there is no guarantee that it will stay in 4:4:4 or even that the 4:4:4 will everywhere be displayed correctly.

Dennis Couzin
Berlin, Germany

>>If you must have small red-on-black text, as my director insists, then the best plan might be to output the whole project as ProRes4444. But there is no guarantee that it will stay in 4:4:4 or even that the 4:4:4 will everywhere be displayed correctly.
<<

Or reduce the chroma and brightness, as we have always said.

Quote
Jude Cotter
Or reduce the chroma and brightness, as we have always said.

Sure, there's a continuum between bright red text which looks jaggy on slant letters and white text which looks fine. Using the FCP title generator, the director wants text color H=0; S=80; B=70 which looks jaggy. Making the saturation less and less, at around S=40 the text looks fine. But this is not at all the right color.

In the days when video meant analog television we might have been stuck with such limitations. Not now. If Y'CbCr video is not to become a very poor relative to R'G'B' video or to X'Y'Z' electronic cinema we must understand Y'CbCr video better and must figure out how to beat, rather than accommodate, its weaknesses.

What intrigued me most about this question about red-on-black text is that 4:2:2 video does a perfect job with it if the interpolation method used to reconstruct the missing chroma is an unfoolish one. Now reading the Wikipedia page on chroma subsampling I fear an unfoolish one is never used.

Dennis Couzin
Berlin, Germany

It's chroma subsampling, as you guessed, DCouzin. There are differences- eg. Decompress XDCAM EX to Uncompressed and compare that to the raw XDCAM EX file in After Effects. But that's still 4:2:2, and the conversion from 4:2:2 to 4:4:4 is done in the monitor.



www.strypesinpost.com

The fact that red-on-black "v", "W", etc. look much less jaggy when rotated 90° is a strong clue that 4:2:2 chroma subsampling is involved. But if I'm right that the problem is due solely to the reconstruction -- conversion from 4:2:2 to 4:4:4 -- rather than the 4:2:2 itself, then we might look at how different hardware and software do that. When FCP shows 4:2:2 video in its Parade scope or when it exports a bitmap from a frame of 4:2:2, FCP seems to be doing it itself, and in a somewhat funny way. If different graphics cards and displays, or different i/o cards and broadcast monitors, reconstruct 4:2:2 video differently for display, that would be interesting.

Again I'm suggesting that a good interpolation for the pixel having just Y'2 and situated between a (Y'1, Cb1, Cr1) pixel and a (Y'3, Cb3, Cr3) pixel will make:
Cb2 = (Y'3-Y'2)/(Y'3-Y'1)*Cb1 + (Y'1-Y'2)/(Y'1-Y'3)*Cb3
Similarly for Cr2, so the weighting factors only have to be calculated once.

Dennis Couzin
Berlin, Germany

Note added Jan 4: Oops! This formula blows up if Y'1 = Y'3. So maybe this:
If Y'1=Y'2=Y'3, make Cb2 = (Cb1 + Cb3)/2
Otherwise make Cb2 =(|Y'3-Y'2|*Cb1 + |Y'1-Y'2|*Cb3) / (|Y'3-Y'2| + |Y'1-Y'2|)

I just now changed the Wikipedia article on chroma subsampling to reflect my viewpoint. Let's see how long it lasts.

Dennis Couzin
Berlin, Germany