🚀 go-pugleaf

In article <21388@cup.portal.com> FelineGrace@cup.portal.com (Dana B Bourgeois) writes:
>Amiga Transactor had an article along these lines awhile back and at one
>point the author pointed out that while the human eye cannot distinguish
>16 million different colors, at least that many are necessary for lifelike
>images because when color range is limited, a wide range of grayscale
>is needed to keep the image realistic...

>OK, doesn't this mean that the ultimate system would be 8 or more pixels
>of RGB?  24 bits of color, 8 of alpha, 8 of direction (or one for HAM) is
>still too many for a system in the Amiga market...

No, what this means is that we need more control over the greyscale content
of the colors we do have.  Staying within practical limits and todays
technology of cost verses performance, I will describe my ideal video system.

First use a 8 by 32 bit color register.  This will allow the user to choose
from a pallete of 8 each RGB and 8 alpha.  While 8 bit video D/A's are
practical, expecting DMA and memory support for 24 bitplanes is impossible.
Needs a very hefty (>$20k ?) pricetag.  256 simultaneous colors should cover
all technical/presentation/CAD applications.

Second, improve the extra half brite mode to three bits.  Using 5 color bits
and 3 intensity bits should cover most semi-realistic animation.  This allows
32 separate colors with 8 shades _of each color_.

Third, add software support for dithering.  32 colors on a 640 pixel line
would appear to the eye as 1024 colors (32 real plus 32x31 pseudo).  The
software should let the user think he has a pallate of 1024 colors and
the graphics library should map these into dithered colors.  Special
algorithms will be needed to do this right.  Given a 4 pixel series, abcd,
colors ab, bc, and cd are all virtual to the eye.  We can't treat this as
2 pairs of virtual colors ab and cd and ignore the effect of bc.  This would
turn our 640 pixel line into 320 virtual pixels, destroying the realizm.  Now
I think 1024 colors at 8 shades of each colors would be TV level life like
realism, even for stills. 

Fouth, add hardware support for simple edge enhancement and averaging
techniques.  For example, turning on averaging for the alpha bits may prevent
some picket fence effects in genlocks when two pixels with drastically
different alpha values are side-by-side.  (An example would be 25 % previous +
50 % current + 25 % next alpha values added together.)  Turning on edge
enhancement for the intensity bits would allow detail in a picture to stand
out while preserving the color purity.  (An example would be -25 % previous +
150 % current - 25 % next pixel.)  Turning on averaging for the intensity
bit would provide a pastel like effect.  Either of these effect would cause an
32 virtual levels of shade for 1024 virtual pixels.  Needs a five position
barrel shift on each of the 8 RGB outputs.

Finally, throw out HAM as we know it today.  A waste of ASIC real estate. :-)
As Dana pointed out, the eye readily sees changes in intensity, but tends to
average color content together.  But HAM, to do an intensity change, requires
three pixels causing massive color fringing where there is simple changes in
intensity of a given color.  Actually, change HAM to use three control plus
5 data bits (8 bitplanes).  The three control bits would select the color
register of 32, change one of the three colors, change an intensity
multiplier, change the alpha field, or two other features.

Of coarse, this whole discussion assumes 8 bit planes at a 640 pixel line
resolution.  Also assumes 8 bit video D/A's.  Tough, slightly expensive,
possible with todays technology, and as realistic to the human eye as we will
ever need.

>                                                        ...But someday all
>computers will have relistic color images in the Amiga price range.  Even 
>I*M!
>
>Dana

No, the I*M never will, it would have to be upward compatible with their
current primative offerings.  This is impossible :-).

---------- Lawrence W. Esker ----------  Modern Amish: Thou shalt not need any
\  *        *             *  *******  /  computer that is not IBM compatible.
 \  *        *     *     *  *        /
  \  *        *   * *   *  *****    / Sr. Hardware/ASIC Design Engineer
   \  *        * *   * *  *        /  Allen-Bradley Communications Div.
    \  *******  *     *  *******  /   Work: (313)668-2500  Home: (313)973-8561
     -----------------------------    Compuserve: 76337,2524
UseNet Path: __!uunet!mimsy!rutgers!citi!itivax!abaa!esker