[opendtv] Re: New Chips Improve Color TV Dramatically
- From: jeroen.stessen@xxxxxxxxxxx
- To: opendtv@xxxxxxxxxxxxx
- Date: Mon, 28 Jun 2004 09:36:49 +0200
Hello all,
Henry Baker wrote:
> I've heard that the _original_ color gamut for color TV was
> actually larger than the current color gamut for (analog, stddef)
> TV's, and that the reduction was made because the TV manufacturers
> couldn't come up with good enough phosphors.
> Does anyone know the facts on this?
Poynton in his "Gamma Sutra" (Digital Video and HDTV algorithms
and interfaces) writes on page 236: 'But phosphors changed over
the years primarily in response to market pressures for brighter
receivers, and by the time of the first videotape recorders the
primaries actually in use were quite different from those "on
the books".'
My interpretation: some gamut was sacrificed for brightness...
Tom Tcimpidis wrote:
> That is correct. The original NTSC 1953 red and green primaries were
> further out on the CIE chromaticity diagram than what we use today.
> Green was significantly purer at x .21, y .71, z .08
It is interesting to know that this old green primary has been
reincarnated in the "Adobe RGB" standard ! It means that a larger
gamut can be encoded before any of the signals clip.
It does not necessarily mean that the old slow green phosphor
will be used in CRT monitors again. More likely adapted LCD
monitors will be used for viewing "Adobe RGB" images natively.
But a wide-gamut coding standard can also be enjoyed without
having a monitor that can actually display all of the gamut.
It is simply a means of not throwing anything away too early.
See below.
> (today for SD we use .31, .595, .095)
There is a decent overview of colour spaces on:
http://www.brucelindbloom.com/index.html?WorkingSpaceInfo.html
I have also consulted Poynton's "Gamma Sutra":
1 NTSC 1953: R=(0.670,0.330) G=(0.210,0.710) B=(0.140,0.080)
2 SMPTE RP145: R=(0.630,0.340) G=(0.310,0.595) B=(0.155,0.070)
3 EBU T.3213: R=(0.640,0.330) G=(0.290,0.600) B=(0.150,0.060)
4 ITU R.709: R=(0.640,0.330) G=(0.300,0.600) B=(0.150,0.060)
5 (e-)sRGB: R=(0.640,0.330) G=(0.300,0.600) B=(0.150,0.060)
6 AdobeRGB: R=(0.640,0.330) G=(0.210,0.710) B=(0.150,0.060)
Line 1 is the original NTSC standard, which has been OBSOLETE
for many years now ! Line 2 is its successor for "480i" (SDTV),
also known as "SMPTE C". Line 3 is its European counterpart,
also referred to as "PAL/Secam". Line 4 is the USA standard
for HDTV, which takes the red and blue from EBU, and the green
is an average of SMPTE and EBU green. Note that the primaries
vary only insignificantly between these 3 standards! (There are
differences in other aspects, e.g. the coefficients of the luma
function, causing different RGB->YUV and YUV->RGB matrices.)
Line 5 is the "sRGB" standard which applies to most computers
and digital still cameras. (It differs from 709 only in the
details of the gamma function.) Line 6 is an alternate standard
for computers and still cameras. Note that it uses the red and
blue from the 3 previous standards, but the green from NTSC !
So "NTSC" is not so obsolete after all, at least not its green.
Craig Birkmaier wrote:
> As a starting point, it is important to note the differences between
> display gamuts and encoding space gamuts.
Indeed they can be completely decoupled. Although it can be so
convenient if they are equal, then an image can be displayed
without conversion.
> The traditional RGB color space that we are familiar with, thanks
> to decades of watching CRTs, has a significantly greater color
> gamut than NTSC or PAL.
That is a different story... In a composite (CVBS) video signal
the colour gamut is further limited as a function of the brightness
(the Luma signal Y). If the amplitude of the composite video signal
Y+C becomes too low or too high then the signal will be clipped.
This can occur at the bottom for blue and red, or at the top for
cyan and yellow. That is why the amplitude of the "colour bar"
reference signal is only 75%. TV transmitters can't handle 100%.
The colour bar colours are 100% saturated, but only 75% bright.
So technically this is not a limitation to the "colour gamut",
only to the maximum brightness as a function of the colour.
This limitation does not apply to components signals (YCbCr) or
"S-VHS" signals (Y/C) or MPEG signals, unless ... it is intended
to ever transcode these signals to CVBS. So in practice there
will be limits applied, because you never know when the signal
must be carried over a CVBS link, e.g. between a VCR and a TV.
(...)
> It is important to note that there is
> not a single unique RGB color space for computer graphics; the color
> space will vary based on the phosphor primaries used for the display.
> The sRGB color space has come to dominate the computing landscape.
It is a de-facto standard, if only because most CRT monitors will
support it without requiring any adaptations. Very convenient..
> This was an unfortunate turn of events, based in large part on the
> use of cheap CRT displays re-purposed from TV manufacturing lines.
That may have applied for CGA displays, but in those days you could
not even display a photo if you wanted to ! All VGA displays come
from different manufacturing lines than TV displays, but it is still
convenient to use the same (good !) phosphors. And, the sRGB space
is not so bad. It covers most of the colours that you see around you.
There is still not much reason for anything else. Some professional
cameras are now offering Adobe RGB space. And then there's "e-sRGB"
coming. That should make you very happy. It shows that the gamut
size does not have to be related to the choice of the 3 primaries.
IF you allow negative signal values for RGB, then you can make an
arbitrarily large gamut. e-sRGB uses the same colour primaries as
sRGB. Then it defines 10-bits RGB signals, with black at 384 and
white at 894. It also defines an extended gamma curve for the signal
values below black and above white. Then in the linear-light space,
each signal can go from -50% to +150%. This means that the actual
gamut triangle is twice as large in both directions, i.e. it has an
area that is 4 times larger than sRGB. This includes ALL colours
that the human eye can ever see. There exists NO display that can
show them all, so it must be that gamut mapping is an essential
function before an arbitrary e-sRGB signal can be properly displayed.
> With color wheels and color filters, almost any primaries can be
> used. I have seen many demonstrations of the improved color gamuts
> that are possible.
As always: at the cost of efficieny. But at least is is possible.
> Bottom line, there's a world of color out there ready to exploit,
> if we choose to. sRGB is a poor choice if we want to take full
> advantage of that world.
sRGB is easy, because most (VGA) displays accept it natively.
e-sRGB goes far beyond that, it but can not be implemented without
gamut mapping. Gamut mapping changes colours, so unless you have
a truly spectacular wide-gamut display you can never be certain
that what you see is what you had. That's the problem...
Regards,
-- Jeroen.
|-----------------------------+---------------------------------------|
| From: Jeroen H. Stessen | E-mail: Jeroen.Stessen@xxxxxxxxxxx |
|-----------------------------+---------------------------------------|
| Building: SFJ-5.22 Eindhoven| Philips Digital Systems Laboratories |
|-----------------------------+---------------------------------------|
| Phone: ++31.40.27.32739 | Visiting & mail address: Glaslaan 2 |
|-----------------------------+---------------------------------------|
| Fax: ++31.40.27.32572 | NL 5616 LW Eindhoven, the Netherlands |
|-----------------------------+---------------------------------------|
| Pager: ++31.6.6513.3818 | Visit us: http://www.pdsl.philips.com/|
|-----------------------------+---------------------------------------|
----------------------------------------------------------------------
You can UNSUBSCRIBE from the OpenDTV list in two ways:
- Using the UNSUBSCRIBE command in your user configuration settings at
FreeLists.org
- By sending a message to: opendtv-request@xxxxxxxxxxxxx with the word
unsubscribe in the subject line.
Other related posts:
