jmdavis@cbnewsd.ATT.COM (j.michael.davis) (08/09/89)
Just got finished reading Chuck's note about why 24bit graphics
are economically unfeasable on the Amiga. Good note.
There are some additional points I want to bring up for discussion,
namely HDTV and the future of HAM.
1) HDTV - Chuck pointed out that most people can't tell the difference
between 15 bit graphics and 24 bit graphics when declaring "good
graphics" == "TV quality". While true with our TV, engineering a
future Amiga to have 15 bit graphics seems to be under engineering
it wrt HDTV. I know the HDTV specs aren't final, but you can rest
assured the image quality will be vastly improved, and it may be
improved enough to tell the difference between 15 and 24 bits.
2) NEW HAM MODES - HAM is not a hack! I really thought it was at first, but
there are some things that are good about it. While I haven't (yet)
programmed a HAMmer I imagine that deciding how to represent a color
(given that you can represent them all) is an easier problem than
deciding which colors to keep and which to throw away as in other
systems where the table is 256 out of a possible 256K or so. But
the biggest advantage I see HAM having is that the machine can
DIRECTLY DISPLAY A COMPRESSED IMAGE!!!!
Granted, in the HAM image compression information is lost, but these
images are 1/2 the size of the full 4096 color images, they load twice
as quickly, you can store twice as many of them, they animate quicker,
etc. All this because we have a chip that allows us to directly view
the compressed image.
The new idea for amiga graphics (following Chuck's wish to see articles where
someone suggests something evolutionary and economically feasible) is to
really goose up the HAM modes, possibly put a DSP in there. For example,
why not ALSO include Jay Miner's original HSV HAM? (Where instead of changing
the R or G or B values you change the H or S or V values.) This can be done
without changing the non HAM modes. Of courese, this mode won't work in nonHSV
HAM Amigas, but wait, there is more. At 8 bits per pixel, a HAM mode will be
able to DISPLAY 256K COLORS AT ONCE, with a base register table of 64 colors.
(I know there are 256K pixels on a 512x512 screen, but you get the idea.)
ALSO,
If a DSP is fast enough (and I suspect it is), why not allow direct display
of a Run Length Encoded picture? This one, at least could be made to work
(partially) with existing Amigas that don't have this chip. All that's needed
is a new function that checks for the presence of this chip, and displays
the picture using the chip if it is there, and goes through the normal
uncompression if it isn't there.
These are just two ideas for directly displaying compressed images. THere
are many more image compression schemes out there and the advantages of
directly displaying compressed images are tremendous. Oh, yea, I almost forgot.
Yes, HAM is hard to program, so, if a DSP is going on the machine, why not
build it to help in the HAMming process?
SUMMARY:
If evolved properly, HAM in many forms, is here to stay. Image production may
need to be done in more "conventional" means but with the use of new chips to
help generate the compressed images as well as displaying them, the Amiga can
continue to realize the many benefits of this mode while other machines suffer
from performance problems when displaying their top end graphics modes.
--
----------------------------------------------------------------------------
I am just about fed up | Mike Davis
and I will only take it | ..!att!ihlpm!jmdavis
a few more times. |bartonr@jove.cs.pdx.edu (Robert Barton) (08/11/89)
jmdavis@cbnewsd.ATT.COM (j.michael.davis) writes: > At 8 bits per pixel, a HAM mode will be able to DISPLAY 256K COLORS AT ONCE, > with a base register table of 64 colors. (I know there are 256K pixels on a > 512x512 screen, but you get the idea.) With 8 bits per pixel you would also need 18-bit color registers. This won't work with the current 16 bit register size. A 7-plane mode would work if you had 5-bit video DAC's. In other words: planes registers bits/reg colors n 2^(n-2) (n-2)*3 2^((n-2)*3) 6 16 12 4096 7 32 15 32768 8 64 18 262144
addison@pollux.usc.edu (Richard Addison) (08/13/89)
In article <1579@psueea.UUCP> bartonr@jove.cs.pdx.edu (Robert Barton) writes: > > jmdavis@cbnewsd.ATT.COM (j.michael.davis) writes: >> At 8 bits per pixel, a HAM mode will be able to DISPLAY 256K COLORS AT ONCE, >> with a base register table of 64 colors. (I know there are 256K pixels on a >> 512x512 screen, but you get the idea.) > > With 8 bits per pixel you would also need 18-bit color registers. This won't >work with the current 16 bit register size. A 7-plane mode would work if you >had 5-bit video DAC's. In other words: > >planes registers bits/reg colors > n 2^(n-2) (n-2)*3 2^((n-2)*3) > 6 16 12 4096 > 7 32 15 32768 > 8 64 18 262144 While we're at it, use 7 planes for HAM so that we have 5 bits per color component plus one bit for overlay for a total of 16 bits per color register. And, since it would be nice to have a real alpha channel, how about another HAM mode with 7 planes, and 4 bits per color component with the following encoding for the top 3 bits to determine to use of the lower 4 bits: Mode Meaning ---- ------- 0 0 0 Use color register n 0 0 1 Set Red component to n 0 1 0 Set Green component to n 0 1 1 Set Blue component to n 1 0 0 Set Alpha channel to n 1 0 1 Set Hue to n 1 1 0 Set Saturation to n 1 1 1 Set Value to n Note that this, too, uses 16 bits per color register (4 red, 4 green, 4 blue, and 4 alpha). Of course, these 4 alpha bits could be available in other video modes. Imagine the nice antialiased genlocking we could do with this! Richard Addison "Klein bottles for sale. Inquire within."
jms@tardis.Tymnet.COM (Joe Smith) (08/13/89)
In article <19144@usc.edu> addison@pollux.usc.edu (Richard Addison) writes: >While we're at it, use 7 planes for HAM so that we have 5 bits per color >component plus one bit for overlay for a total of 16 bits per color register. > <And, since it would be nice to have a real alpha channel, how about another <HAM mode with 7 planes, and 4 bits per color component with the following <encoding for the top 3 bits to determine to use of the lower 4 bits: [diagram deleted] <Note that this, too, uses 16 bits per color register (4 red, 4 green, 4 blue, <and 4 alpha). Of course, these 4 alpha bits could be available in other <video modes. What's an alpha channel? Tell us more. -- Joe Smith (408)922-6220 | SMTP: JMS@F74.TYMNET.COM or jms@tymix.tymnet.com McDonnell Douglas FSCO | UUCP: ...!{ames,pyramid}!oliveb!tymix!tardis!jms PO Box 49019, MS-D21 | PDP-10 support: My car's license plate is "POPJ P," San Jose, CA 95161-9019 | narrator.device: "I didn't say that, my Amiga did!"
addison@pollux.usc.edu (Richard Addison) (08/14/89)
In article <507@tardis.Tymnet.COM> jms@tardis.Tymnet.COM (Joe Smith) writes: >In article <19144@usc.edu> addison@pollux.usc.edu (Richard Addison) writes: >>While we're at it, use 7 planes for HAM so that we have 5 bits per color >>component plus one bit for overlay for a total of 16 bits per color register. >> ><And, since it would be nice to have a real alpha channel, how about another ><HAM mode with 7 planes, and 4 bits per color component with the following ><encoding for the top 3 bits to determine to use of the lower 4 bits: > [diagram deleted] ><Note that this, too, uses 16 bits per color register (4 red, 4 green, 4 blue, ><and 4 alpha). Of course, these 4 alpha bits could be available in other ><video modes. > >What's an alpha channel? Tell us more. The alpha channel describes the opacity of a particular pixel. Consider the following (and note that the color components I'll describe range from 0 to 1): Consider what you'd want to do if you had a pixel that was only half-filled by a bright yellow object. If the color of the pixel would have been (R,G,B) = (1,1,0) had the object filled it entirely, then the color of the pixel should be half as intense: (R,G,B) = (0.5,0.5,0). Now, what if we wanted to composite this pixel on top of some background? Since we should be able to see half of the color that was at the pixel before we composited the new yellow object on top of it, we need to mix the previous value of the pixel with the new value. Notice that there is a distinct difference between a bright yellow object that fills half a pixel and a medium yellow object that fills all of a pixel. In the former case, there is transparency, while in the latter there isn't. This is where the alpha channel comes in. A pixel that is half-filled by a bright yellow object has (R,G,B,A) = (0.5,0.5,0,0.5). A pixel that is totally filled by a medium yellow object has (R,G,B,A) = (0.5,0.5,0,1). Of course, to handle digital compositing in this manner, there is no need to have the alpha channel stored in video memory. However, if we do include the alpha channel in video memory, we can do live compositing of the computer video on top of an external video signal and have _anti-aliased_ edges! A 4-bit alpha channel would enable us to have 16 levels of transparency (or opacity, if you prefer, since opacity = 1-transparency). On the other hand, a single bit alpha channel (actually an overlay bit) signals whether of not to mix in the background video. Obviously, this is not nearly as useful. Want more info? Consult: Porter, T. and T Duff, "Compositing Digital Images," _Computer_Graphics_, vol. 18, no. 3, ACM, 1984. Richard Addison "Just because you're not paranoid doesn't mean people aren't out to get you."
thompson@savax.UUCP (thompson mark) (08/15/89)
In article <507@tardis.Tymnet.COM> jms@tardis.Tymnet.COM (Joe Smith) writes: >In article <19144@usc.edu> addison@pollux.usc.edu (Richard Addison) writes: ><And, since it would be nice to have a real alpha channel, how about another ><HAM mode with 7 planes, and 4 bits per color component with the following ><encoding for the top 3 bits to determine to use of the lower 4 bits: > [diagram deleted] ><Note that this, too, uses 16 bits per color register (4 red, 4 green, 4 blue, ><and 4 alpha). Of course, these 4 alpha bits could be available in other ><video modes. > >What's an alpha channel? Tell us more. >-- >Joe Smith (408)922-6220 | SMTP: JMS@F74.TYMNET.COM or jms@tymix.tymnet.com I would absolutely love to see some sort of alpha channel scheme included into the Amiga. It is essentially a value that describes each pixels effective coverage or opacity. It is truly invaluable for rendering antialiased images over another image be it graphically generated or genlocked video. This is otherwise known as compositing. Here is what it will do for you..... If you have some whiz-bang character generator (like broadcast titler) and you put up some antialiased fonts over a black background, they look great. But once you replace that plain background with an actual image, you'll notice a jagged dark shadow around your fonts. This is because when the antialising was performed, edge pixels had to be blended to some predefined static background color. If instead of changing the color of the edge pixel we reduced its alpha (proportionally to the amount the pixel is actually covered by the edge), then the fonts could be dynamically blended with any backgound image using something like: new pixel = background pixel color * (1-alpha) + font pixel color * alpha This allows smooth compositing with no visible edge boundries. -------------------------------------------------------------------------- | Mark Thompson | | decvax!savax!thompson Designing high performance graphics | | (603)885-9583 silicon today for a better tomorrow. | --------------------------------------------------------------------------
bdb@becker.UUCP (Bruce Becker) (08/15/89)
In article <507@tardis.Tymnet.COM> jms@tardis.Tymnet.COM (Joe Smith) writes: |[...] |What's an alpha channel? Tell us more. The amount of transparency (or opacity) of an object. For example, an object with R = G = B = 100% and Alpha = 50% would be a 50% Neutral Density filter. Cheers, -- __ Bruce Becker Toronto, Ont. w \cc/ Internet: bdb@becker.UUCP, bruce@gpu.utcs.toronto.edu `/r/-e BitNet: BECKER@HUMBER.BITNET _< \_ Does a bovine bricklayer == a mu meson? - E. Farmi
FelineGrace@cup.portal.com (Dana B Bourgeois) (08/18/89)
Instead of using the TV as a definition of what needs doing to create a lifelike picture, why not use the research on what people can see? 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. The example was imagine the color spread between yellow and red in a 4K color palette. It is probably 20 odd shades of yellow, orange and red. Now what if your object is orange and a shadow is cast upon it? pick two shades of orange and find the range available in 4K colors. It could be only 2 or 3. Because the 4K color pallete is 16 grey scale of three colors. The 16 million color pallete is 256 grey scales of three colors and so when you pick an arbitrary color (which is a combination of RGB) there will be significant grey scale left to give you a lifelike range. 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. I think that compromises will have to be made on the 3000 and perhaps on the 4000. But someday all computers will have relistic color images in the Amiga price range. Even I*M! Dana
esker@abaa.uucp (Lawrence Esker) (08/24/89)
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