W3C home > Mailing lists > Public > public-tt@w3.org > March 2015

RE: [WebVTT] It's not easy being green

From: Michael Dolan <mdolan@newtbt.com>
Date: Wed, 18 Mar 2015 07:39:40 -0700
To: <public-tt@w3.org>
Message-ID: <02ee01d06189$5e9f5ae0$1bde10a0$@newtbt.com>
The paper title gives it away I think :)


I’ve conferred with several TV manufacturers knowledgeable about caption and text overlay hardware and all were of the opinion that CEA “green” should be 100% brightness.  Further, there was an opinion that there was no difference intended between “green” and the other primaries.  The latter point is also supported by the required minimum color table in CEA 708-E page 91, even although the optional extended color table on page 92 (not typically supported) muddles the issue by defining “green” to be ½ brightness.


So, I would conclude it should indeed be 00FF00, and thus should be “lime” and not “green”. With this one change, I don’t think there is really a need to create more mapping tables to the RGB values – these tables already appear in SVG and CSS3, and are already replicated in TTML1 and TTML2.


Thanks to Silvia and Dave for pointers to the brief discussion in the CG since I do not participate in that.  Apparently the version of the WebVTT spec I reviewed the other day was not the latest? Apologies.


I agree that this has no impact on TTML1, TTML2, IMSC1, SDP-US (given the answer of FF), and in WebVTT (resolved earlier to the same conclusion).  In general it only impacts specifications mapping “green” into another color space.  I’ll post a summary of this consensus in SMPTE and get ST2052-10 corrected – FYI.






From: Nigel Megitt [mailto:nigel.megitt@bbc.co.uk] 
Sent: Wednesday, March 18, 2015 2:58 AM
To: Michael Dolan; public-tt@w3.org
Subject: Re: [WebVTT] It's not easy being green


That would be Michael Borthwick I guess? His presentation is available in video at http://michaelborthwick.com.au/closed_captioning_online_streaming_video_dfxp_webvtt.html if anyone wants to look at it for themselves (withoutl being negative, I just want to be clear that's a pointer not a recommendation).


This issue applies also to conversion from Teletext. "Green" in Teletext, according to ETS 300 706 is a "full intensity" colour, in 4 bit RGB it's {0, 15, 0}, so it maps to {0, 255, 0} in 8 bit RGB, also known in CSS colours as "lime". There's also Teletext "Half green" which is {0, 7, 0} which maps to CSS "green" {0, 80, 0}.


I believe this is a conversion constraint and there's no change needed to any of our specification documents.


Kind regards,





From: Michael Dolan <mdolan@newtbt.com <mailto:mdolan@newtbt.com> > Date: Tuesday, 17 March 2015 00:03
To: "public-tt@w3.org <mailto:public-tt@w3.org> " <public-tt@w3.org <mailto:public-tt@w3.org> >


I received an email from someone studying SMPTE-TT and WebVTT who wrote and presented a paper about 18 months ago titled, “'It's not easy being green - a closed captioning for web case study'”.  Among other things, he observed that we map CEA 608 “green” to SVG/CSS3 “green”.


FYI, the SVG/CSS3 RGB value of “green” is 008000, not 00FF00 you might expect (which is the color “lime”):


Note in contrast that “red” and “blue” are both full brightness.


Of the various 608 mapping documents….SDP-US uses only RGB values (no color names) and explicitly defines “green” to be 00FF00.  However both SMPTE-TT (RP2052-10) and WebVTT say to map 608 “green” to TTML “green” which is minimally inconsistent with SDP-US. The same would be true for 708 mappings, of course.


Of historical note, CSS1 says the color palette came from the “Windows VGA palette”, which seems to have come from the CGA text color palette:


(although the above  defines the brighter green as “light green”).


We could assume it is supposed to be maximum brightness like “red” and “blue” (i.e. 00FF00), but on the off chance that “green” text overlay is actually handled differently in the billion TV’s out there I’ll ask a couple of set manufacturers….







Michael A DOLAN

TBT, Inc. PO Box 190

Del Mar, CA 92014

(m) +1-858-882-7497

Received on Wednesday, 18 March 2015 14:40:13 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:43:46 UTC