We found out that run length is much better than huffman coding (JAVA) considering compression ratio. Is it true for all cases?
2 Answers
Of course not. Consider ABABABAB
, it will compress better with huffman than run-length encoding.
Run length will only work for data that have repeated values; that's not guaranteed in images.

- 2,327
- 16
- 23

- 45,717
- 10
- 93
- 143
-
considering huffman compression on jpeg , gif,png causes EXPANSION of images. but it works well for bmp images. is there any specific reason for that? – sharma May 01 '12 at 06:14
-
1most image formats already include compression. when huffman is used with compressed data it often makes things slightly bigger. my guess is that your bmp files are not compressed (it's optional, according to wikipedia, for that format) – andrew cooke May 01 '12 at 13:28
-
can we get any images that arent compressed in the web? if so please provide details. – sharma May 01 '12 at 15:52
-
simply because of the way jpg images are designed, they are always hard to compress harder. gifs are almost always compressed, but don't need to be. i think it's most likely you will find png images without compression. but i don't know of a source. your best method might be to generate them yourselves using a library that has the option to compress or not. – andrew cooke May 01 '12 at 17:25
-
Trying to compress any compressed image format is going to be a waste of time - they're already compressed. Further, images don't compress well with general purpose compression algorithms, which is why there are special-purpose ones. – Nick Johnson May 02 '12 at 01:02
RLE generally works well for things like charts and graphs that have large areas of identical colors.
It tends to work poorly (often causes expansion) for things like photographs that almost always exhibit at least minor differences between pixels, even in areas that look like a solid color.
Although the same general idea tends to apply to Huffman as well, it tends to work better across a wider variety of inputs. In theory it can cause expansion as well, but about the only times I've seen that happen was trying to use it on data that was already compressed.

- 476,176
- 80
- 629
- 1,111