Path: utzoo!utgpu!cs.utexas.edu!usc!apple!vsi1!zorch!xanthian From: xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) Newsgroups: alt.sources.d Subject: Re: Compressing pictures (LONG) Message-ID: <1990Aug31.131326.16671@zorch.SF-Bay.ORG> Date: 31 Aug 90 13:13:26 GMT References: <6873@milton.u.washington.edu> <1990Aug31.034936.18954@mlb.semi.harris.com> Organization: SF Bay Public-Access Unix Lines: 30 I don't at all see the advantage of differences over XOR. The color values exist in three space, and a one bit shift in the color that happens to map to the most significant bits of your pixel when considered for differencing is going to map far away in difference space from the origin. XOR has the "advantage" that it treats all bits as of equal significance, probably a "better" thing to do for minimizing the impact of noisy image data on the compression efficiency. Is there something (quite likely) that I'm not seeing here? The previously menitoned color table ordering problem (again, trying to linearize three space data) only further complicates the problem of making differencing work well. (It may not do a lot for the XOR solution either, on first guess.) (A solution, perhaps not the best, to the color table problem is to make keys from the eight bit per gun true color data that is the color table's output value (say, for a high quality system), then interleave the color bits like: r0g0b0...r7g7b7 with r0 the red m.s.b., etc., and then sort these keys and use that as the new order for the color table. This way the subtle changes are down in the r7g7b7 bits, and sort close together, while the blatant changes are in the r0g0b0 bits, and sort far apart. This will help a lot, though the choice of red for most significant bit is still arbitrary.) Kent, the man from xanth.