OK, I have a serious *image* compression idea for handheld PC''s. It seems pretty simple... First off, those screens are usually black & white LCD''s, so that means black is a 1 (because the liquid crystal is turned on) and white is a 0. Now, most things you''d draw in a handheld PC (the Palm III kind) are on a white background - letters, notes, and doodles. So, why don''t you just do an RLE-type of compression, but forget about compressing the black because there''s so little of it? The idea would be this (ignoring the header of the file, width, height, author, etc.): The code would read the first bit from the file, and if it''s a one, it would translate into black, and it would read the next bit from the file just as it read this one. If the first bit was a zero, though, it would read an integer from the file that would specify the length of the run. (This could be any number of bits the programmer chooses - whatever works best.) This would translate into a run of white n pixels long. This process of checking a bit and reading an integer if necessary would repeat until the end-of-file is reached, and it should build up the image. (BTW, that was how you read it, but you can guess how you''d compress it in the first place.) It seems like this would seriously help compress handheld PC''s image storage capabilities. Does anybody have any ideas to improve this, or is there something obviously wrong with it? (P.S. I''ll put up a REAL demo if necessary.) [ L N T A K I T O P I ] http://geocities.com/guanajam/

I don''t know much about compression, but it sounds pretty good in theory. I don''t know what kind of compression they already have for palm computers, so i don''t know if they have already thought of this or not .
I agree with your reasoning, however.

Thanks... I was hoping the idea wasn''t too vague

Does anyone know if Palm''s do use internal compression on everything??

[ L N T A K I T O P I ]
http://geocities.com/guanajam/

That''s half of standard RLE encoding - like implemented in PCX and RLE BMP files.


#pragma DWIM // Do What I Mean!
~ Mad Keith ~
**I use Software Mode**

How about this? Just put the length of the run in each time, with maybe a bit at the front to determine whether black or white starts. Read the length, switch color, read the length, switch color, etc. No need to tell which color comes next, it's always the opposite of the previous color!

Any more B&W compression ideas?

Edited by - CobraA1 on 4/27/00 4:32:49 PM

Hey! That sounds cool! Good thinking.


Lack

Christianity, Creation, metric, Dvorak, and BeOS for all!

Or even better, if the image is mostly black or mostly white, it would use my algorithm, and if it was 50-50, use CobraA1''s!

(The only problem, CobraA1, is what if the run is greater than the size of the byte/word/int you use?? Not trying to be critical, just thinking...)

"The wise make proverbs, and fools repeat them." -- ISAAC D'ISRAELI

lntakitopi@aol.com
http://geocities.com/guanajam/

There''re ways around that.


Lack

Christianity, Creation, metric, Dvorak, and BeOS for all!

Maybe you can make a special case where if the decompressor comes across the maximum length, it doesn''t switch color.

How ''bout just doing it like PCX does it?!?
Just have multiple runs which are back to back. easy, huh?

FReY

------------------------------------------
The world is queer my friend, ''cept for me and thee. But yes, even thou art oft freaked
------------------------------------------