Timothy Miller wrote:
I thought I might talk a little about bits of precision in video data.
 There's been discussion on it, and someone brought up in private
email the question about why we don't do more than 10 or why some
image formats support 16 per channel.  I'm no expert on this, but I
have some knowledge about human visual perception.  In particular, I
developed the gamma calibration software for Tech Source medical
imaging products.  (I've also been to some of Poynton's lectures, but
there are some who would say that isn't necessarily a good thing.)

There is a standard called DICOM (Digital Imaging and Communications
in Medicine), and I have here "Part 14:  Grayscale Standard Display
Function".  A gentleman by the name of Barten did research into human
perception of grayscale.  One of the results of his work was a
mathematical representation of the human perception of luminance,
which is summarized in a table of 1023 "just noticable differences". They are so-named, because they were based on what humans were able to
distinguish at various luminance levels.  This table spans from level
JND 1 at 0.0500 cd/m^2 up to JND 1023 at 3993.4040 cd/m^2.  Human
luminance perception is not linear; the difference between JNDs 1 and
2 is 0.0047, while the difference between JNDs 1022 and 1023 is
25.857.

Many of you are familiar with gamma curves and how a gamma of 2.2 is
typically used for graphic displays.  When you plot the Barten model
on the same graph as a 2.2 gamma curve, you'll see that the gamma
curve is only a crude approximation of human perception, although it's
not so bad if you throw away the lower end of the spectrum.  Gamma is
a conversion from luma (perceived brightness) to luminance (physical
brightness), where luminance = luma^2.2.  Based on this, you can see
that if you have a 50% gray pixel, what you actually get is a pixel
that emits only about 20% as much light as a white pixel.  This is why
antialiased lines look like ropes at certain angles.  The programmer
is assuming that two 50% gray pixels next to each other is the same as
one white pixel, while in actual fact, you're only getting 40% as much
light as you're supposed to.  Applying a gamma correction to this
cleans it right up, making two "half covered" pixels each 73% in luma
space.  (Relatedly, if you dither down from 8-bit to 1-bit, and you
don't account for this nonlinearity, your results will be horrid; in
the case of GIMP, they certainly are.)

Let's apply what I said about about JNDs to monitors.  I believe my
LCD monitor's brightest pixel has a luminance of 350 cd/m^2 (JND 653).
 Based on what I recall from characterizing medical monitors, I
believe the "black" pixels were around about 1.0 cd/m^2, due to
backlight leakage through the LCD (JND 71).  This gives us a range 583
JNDs, so to be able to view images without any visible contour lines,
you'd need just over 9 bits of precision (in luma space; lots more in
luminance space).  CRTs may be able to produce brighter white pixels
and darker black pixels, but I haven't encountered a CRT whose white
pixel is over 4000 cd/m^2, so I think it's a safe bet that we have an
upper bound of 10 bits of precision necessary to ensure smooth images
on the screen (or smooth gamma curves in any event).

IIUC, a 10 bit DAC (and therefore 10 bit wide palate RAM) would be sufficient because if we had 11 bits that a Human wouldn't be able to tell the difference between adjacent codes when displayed on the screen.

One thing to consider is that within a year or two, we will probably have small DLP monitors. These will probably be able to display almost the full range of JNDs. When they get down to 27 inches (16:9), the prepress people will probably start using them.

Naturally, ink on paper will never manage the color gamut of even an LCD screen, and matching that is what prepress needs to do.

--
JRT
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)

Reply via email to