The image is mainly text with some line art. Thinking about it there is probably not that many runs of white between the letters of text, however on the blank white lines between their obviously will be. Maybe I should think about having some sort of code for a white line?? I think one of my major constraints at the minute is that I am compressing in real time as my 4mb ram has to take the whole A4 page at 200dpi. This means the main requirement of the algorithm is simplicity which Ian`s seems to have. I mean a 50% compression would be fine, I`m not looking for massive gains at the minute, just something that works before I have to hand my project in!!! I`ve even managed to muck up the coding of Ian`s suggestion!! Probably something to do with my 34 seconds of sleep in the last few days. Any suggestions appreciated.. >From: Roland Andrag >Reply-To: pic microcontroller discussion list >To: PICLIST@MITVMA.MIT.EDU >Subject: Re: Image Compression Algorithm >Date: Tue, 25 Apr 2000 10:16:29 +0200 > >Ian: > > > >10 250 0 250 15 17 > > > > > >which would mean 10 white, 500 black, 15 white, 17 black. > > > > > > That seems over complex. > > Have you thought instead how about 8 bit numbers, first bit of each >represents > > the colour, then the rest is a 7bit representation of how many pixels >are >that > > colour. > > > > So black=0, white=1 > > image has 3 black 10 white 1 black 250 white, 50 black would give this: > > 00000011 {3 black} > > 10001010 {10 white} > > 00000001 {1 black} > > 11111111 {127 white} > > 11111011 {123 white, making this row total 250} > > 00110010 {50 black} > > > > This is more efficient than your suggested method, as you are only >marking > > changes and sections longer than 127 pixels, and not having a byte user >even if > > the colours did not change. > >Not so! Check the original sequence (10 white, 500 black, 15 white, 17 >black) with your 1+7 bit encoding, and you will see that you need more >bytes >than the simpler alternating algorythm. You are looking in the right >direction though. In general, simply alternating between colours when run >length encoding a black and white image is most efficient. Depending on >how >often the colour changes it may be better to use more or fewer bits at a >time (larger or smaller words). For example, if the image changes colour >on >average each 16 pixels, alternating colour after 4 bits would probably be a >good choice. Very dependent on the image though. > >Roland ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com