LZW compressiom

Question

0.00/5 (No votes)

See more:

Hi all

i'm developing LZW image compression and my code works will

my program compress the image as list of integers, but I have probelem when I saved the compressed stream in file. The file size is larger than the original image size

What can I do??

Please help

Thanks in advance

Posted 16-Jan-11 12:21pm

mesho

Add a Solution

3 solutions

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Espen Harlinn · Answer 1 · 2011-01-16T12:28:00

Solution 1

I'm guessing here and "image as list of integers" may be your problem - you need to think of the compression result as a stream of bits - not a sequence of integers.

Regards
Espen Harlinn

Posted 16-Jan-11 12:28pm

Espen Harlinn

Comments

Sergey Alexandrovich Kryukov 16-Jan-11 18:48pm

Espen,

Well, I can really appreciate your note on stream of bits (well, a 5), but I would not be sure about the inquirer.

I tried to write some elementary explanation (maybe, not elementary enough).

Sergey Alexandrovich Kryukov 16-Jan-11 18:49pm

Could you or anyone decrypt the abbreviation "OP" for me?

fjdiewornncalwe 16-Jan-11 23:09pm

I hate to write it here, but I believe OP stands for "Offending Party", however the connotation is quite negative that way, so it is probably better that it be kept in acronym form. :)

Sergey Alexandrovich Kryukov 16-Jan-11 23:16pm

Thank you; it explains a lot :-)
I started to hate acronyms after I worked in several US companies. I found people use too many acronyms, including those created in the company; the meaning is often completely forgotten; asking about the real meaning is a way to earn good enemies because those people feel intimidated :-)

Espen Harlinn 17-Jan-11 9:11am

Ouch :)

Dylan Morley 17-Jan-11 10:18am

OP = Original Poster :)

Sergey Alexandrovich Kryukov · Answer 2 · 2011-01-16T12:45:00

What do you consider an image size? If you hope that this is a size of integer multiplied by the number of points; and your persistent presentation would match it, then you hope in vain. The persistent size will always be more -- for a good reason.

If you save using any kind of text-based formatter like XML, it's apparently takes more space, but not because of tags, new line characters, etc. -- mostly because most of the characters of the output could fit in just 4 bits (hex digits along occupy only 4 bits, decimal even less), but physically they occupy 8-16 bits per characters (depending on UTF). For example, text representation of byte "F1" takes two bytes compared to binary 1 byte. (Sorry if it seems too trivial for you -- explaining just in case. I don't really think you're working with texts.).

If you're using (any kind of) binary formatter, it takes more room due to less trivial reason: the persistent presentation contains good amount of meta-data. This meta-data is very important and is needed for reliability -- I would never sorry for extra space.

Surprize! LHW compression will not allow for an essential gain over binary formatted representation. Even less compression you can get over text stream when compared to binary, because text redundancy is well compressed, but not eliminated completely.

The problem is that you're trying to create lostless (of cource) image compression using general-purpose methods, not specific to images.
To get and idea of lost-less image compressions, experiment with available compression methods used in TIFF -- they are useful (a must to have, anyway) but not very effective.

mesho · Answer 3 · 2011-01-17T04:10:00

Thank you all for reply

Thanks SAKryukov for explanation

as you know LZW is character based compression, and the image must be represented as string to compress

I'm using hash table for building the dictionary as follow:
Map<string,integer> dictionary = new HashMap<string,integer>;();

The image is compressed as list of integers but the stream is saved in the compressed file as bytes (I convert every int to array of bytes)

I tried to use Byte instead of integer in the hash table but it dosen't work, because when the dictionary grow, the integers more than 256 will need more than one byte

Any idea?

LZW compressiom

3 solutions

Solution 1

Solution 2

Solution 3

Add your solution here

Preview 0