Path: utzoo!utgpu!cs.utexas.edu!sdd.hp.com!elroy.jpl.nasa.gov!lll-winken!bu.edu!shelby!husc6!paperboy!meissner From: meissner@osf.org (Michael Meissner) Newsgroups: alt.sources.d Subject: Re: Compressing pictures (LONG) Message-ID: Date: 31 Aug 90 14:53:22 GMT References: <1990Aug29.155925.17597@zorch.SF-Bay.ORG> <6873@milton.u.washington.edu> <1990Aug31.034936.18954@mlb.semi.harris.com> Sender: news@OSF.ORG Organization: Open Software Foundation Lines: 38 In-reply-to: del@thrush.mlb.semi.harris.com's message of 31 Aug 90 03:49:36 GMT In article <1990Aug31.034936.18954@mlb.semi.harris.com> del@thrush.mlb.semi.harris.com (Don Lewis) writes: | In article <6873@milton.u.washington.edu> wiml@milton.u.washington.edu (William Lewis) writes: | > * Taking differences is probably much, much better than XORing, | >since the point is to take advantage of the vertical continuity of | >the image. The problem is that it doubles the number of values the | >compressor will have to deal with -- from max->min to min->max, which | >is 2*(max-min) values. The obvious solution is to wrap around, ie, | >use modulo(max-min) arithmetic, except that this overlays some of the | >least frequently used values (the extremes) on the most frequently used | >ones (small values), making the huffman/arithmatic coder less | >efficient. | | I don't think this is a problem. Think of the differences as signed | twos-complement values. There should be a nice symmetric peak in | the histogram around zero. The relatively few difference values | that get aliased in with the common difference values will just | get just as efficiently encoded as the common values. On the other | hand, since we are encoding the data anyway, we might look at encoding | n+1 bit differences anyway if that happens to be more efficient (due | to the greater skew in distribution). If you are dealing with color, I think you might get better results by separating out the RGB (red, green, blue) lines into separate copies. Thus instead of 24 bits of pixel data, you would have a 8 bit red pixel plane, a 8 bit green pixel plane, and a 8 bit blue pixel plane. Thus you would probably get smaller differences by subtracting two adjacent red pixels, then when the pixel is one 24 bit integer particularly when you change colors. Of course, if this is already done, just ignore this message. I've not dealt with any graphics formats at the bit level..... -- Michael Meissner email: meissner@osf.org phone: 617-621-8861 Open Software Foundation, 11 Cambridge Center, Cambridge, MA, 02142 Do apple growers tell their kids money doesn't grow on bushes?