Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

SHilbert

SERIOUS compression idea (For Handheld PC's)

This topic is 6930 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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/

Share this post


Link to post
Share on other sites
Advertisement
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.

Share this post


Link to post
Share on other sites
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**

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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/

Share this post


Link to post
Share on other sites
Maybe you can make a special case where if the decompressor comes across the maximum length, it doesn''t switch color.

Share this post


Link to post
Share on other sites
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
------------------------------------------

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!