From albanycs!leah:rsb584 Mon Jan 11 03:38:37 1988 Received: by albanycs.albany.edu (5.54/4.8) id AA16877; Sun, 10 Jan 88 22:34:00 EST Date: Sun, 10 Jan 88 22:33:57 EST From: albanycs!leah:rsb584 ( Raymond S Brand) Received: by leah.Albany.EDU (5.58/1.1) id AA29070; Sun, 10 Jan 88 22:33:57 EST Message-Id: <8801110333.AA29070@leah.Albany.EDU> To: albanycs:beowulf!rsbx >From awpaeth@watcgl.waterloo.edu Fri Jan 8 17:41:45 1988 Path: leah!uwmcsd1!bbn!rochester!udel!gatech!ufcsv!codas!burl!clyde!watmath!watcgl!awpaeth From: awpaeth@watcgl.waterloo.edu (Alan W. Paeth) Newsgroups: comp.graphics Subject: Re: Advanced Dither Needed Keywords: dither Message-ID: <2863@watcgl.waterloo.edu> Date: 8 Jan 88 22:41:45 GMT References: <3703@ames.arpa> <2741@masscomp.UUCP> Reply-To: awpaeth@watcgl.waterloo.edu (Alan W. Paeth) Distribution: na Organization: U. of Waterloo, Ontario Lines: 44 A comment on dither - the "quick and dirty" approach to uniform division of the color space (so that R, G and B can be treated separably) very often slices up 8 bit pixels as 3 bits for red and green, 2 bits for blue (where the eye is least sensitive). This is an unnecessary oversimplification that leaves blue with only two mid-range intensities. It suggests itself because we tend to think in terms of "bits" per color at the hardware level, not "discrete number of intensity steps". This approach is further suggested because the pixel channels for R G and B can be written separably through the proper setting of the write mask, but in practice, the pixel is normally written as a single byte anyway, not as three consecutive "inking" passes. One useful property of this approach is that there are a number of "greys" in the color space, as the channel precisions are all multiples of each other. A better approach is to form a color table containing a Cartesian product of intensites on a range that is not necessarily a power of two. For example, if we take red = [0..5], green = [0..6], blue = [0..4] (suitably normalized to represent intensities on the range [0.0..1.0] then there are 6*7*5 = 210 color table entries, and noticibly better representation in blue. Our Graphics Lab takes this approach for writing on our VAX GPX's under X. We must use a uniform space, because many simultaneous image (windows) might be on the display, and each would have a different histogram (if Heckbert's approach were used), potentially overflowing the color table. In our case, the X-write IM tool takes color images of arbitrary precision and Floyd-Steinberg converts them into this space of 6,7,5 steps, and thus all color images share identical entries within the color table (which is a consequence of how X manages requests for color table entries). B/W images typically allocate a 32 level grey ramp which can co-exist within the remaining space, leaving 14 (256=210+32+14) entries for use by other applications, should they require colors other than saturated yellow, blue, white, etc. On GPX's with smaller color tables, the same approach is used. Once again, ~3/4 of the hardware color table is allocated, giving 12 free color entries, which the program divides as 2*3*2 in RGB. Other useful sets have been 6*6*6, which gives the largest uniform allocation in 256 entries, thus allowing for exact greys, and 6*7*6, which uses 252 out of 256 colors and is much better overall than the 8*8*4 set which is used implicitly when one allocates using the old "three bits red and green, two for blue" scheme. /Alan Paeth Computer Graphics Lab University of Waterloo