1

I've done a bit of fiddling around with PNGs over the last couple days and I am upset with my findings. I'm concluding that the majority of my results deal with compression. So this weekend I'm going to dive into advanced compression articles. I wanted to share my findings so far. To see if anyone has any advice on achieving my goal and to maybe point me in the right direction.

I am currently working on a project where I need to obtain the smallest possible file size within a window of less than 15 seconds.

The majority of the images I am working with are PNG-8bpp with a full 256 color palette. Most of these images I could represent accurately with 5bpp (32 colors).

PNG indexed however only supports 1,2,4, and 8bpp. So my idea was to strip the PNG format to the minimal information I needed and write an encoder/decoder to support IDAT sections with 3,5,6, or 7bpp.

Test 1:
Original File: 61.5KB, 750 * 500, 8pp Palette, 256 colors, No tRNS
After Optimizations (Reductions to 4bpp, Strip Anx Chunks, & PNGOUT): 49.2KB 4bpp, 16 Colors
Human Interpretation: I can see 6 distinguishable colors.

Since I only need six colors to represent the image I decide to encode the IDAT using 3bpp to give me a max palette of 8 colors. First I uncompressed the IDAT which results in a new file size of 368KB. After applying a 3bpp to IDAT my new uncompressed file size is 274KB. I was off to what seemed to be a good start... Next I applied deflate to my new IDAT section. Result... 59KB.

10KB larger than using 4bpp.

Test 2:
Original File: 102KB, 1000 * 750, 8bpp, 256 Colors, tRNS 1 fully transparent color
After Optimization: 79KB, 8bpp, 193 colors, tRNS 1 full transparent color
Human Interpretation: I need about 24 colors to represent this picture.

24 colors can be represented in 5bpp at 32 colors. Using the same technique above I was able to achieve much better results over uncompressed but again I lost at compression. Final size compressed... 84KB. Then I tried at 6,7bpp... same result poorer compression that at 8bpp.

Just to be sure I saved all the uncompressed images and tried several other compression algorithms... LZMA, BZIP2, PAQ8... same result smaller compression size at 8bpp than at 5,6, or 7bpp AND smaller size at 4bpp than at 3bpp.

Why is this occuring? Can I tweak/modify a compression algorithm to target a PNG like format that uses a 5,6, or 7bpp format that beast 8bpp compression? Is it worth the time... and yes saving another 10KB would be worth it.

Almost Famous
  • 569
  • 1
  • 6
  • 19

2 Answers2

2

What you're seeing is that by using odd pixel sizes, your effective compression decreases because of the way PNG compression works. The advantage of PNG compression over just using straight FLATE/ZIP compression is the filtering. PNG compression tries to exploit horizontal and vertical symmetry with a small assortment of pre-processing filters. These filters work on byte boundaries and are effective with pixel sizes of 4/8/16/24/32/48/64 bits. When you move to an odd size pixel (3/5/6/7 bits) you are defeating the filtering because identically colored pixels won't "cancel each other out" horizontally when filtered on 8-bit boundaries.

Even if the filtering weren't an issue, the way that FLATE compression works, reducing the pixel size from 8 to 7 or 6 bits won't have much effect either because it also assumes a symbol size of 8-bits.

In conclusion...the only benefit you can achieve by using odd sizes of pixels is that the uncompressed data will be smaller. By breaking the pixels' byte boundary symmetry, you defeat much of the benefit of PNG compression.

GIF compression supports all pixel sizes from 1 to 8 bits. It defines the symbol size as the pixel size and doesn't use any pre-filtering. An 8-bit GIF image, if compressed as 7-bit pixels, wouldn't suffer less compression, but also wouldn't benefit because the compression depends more on the repetition of the pixels than the symbol size.

BitBank
  • 8,500
  • 3
  • 28
  • 46
  • The filtering byte will always be zero before each scanline. From what I've read filtering is often not beneficial in indexed images. Therefore I've also stripped the filter byte to save space. I also don't have to use deflate to compress the IDAT section... I'm still testing other compression algorithm settings to see if I can target less bpp. – Almost Famous Feb 27 '12 at 03:54
  • Filtering can be beneficial for indexed images; it depends on the image. As I said above, you're hurting both the benefit of PNG filtering and FLATE compression looking for repeating bytes (not pixels). If you have continuous tone (photo-type) images, you're not going to get much better compression than JPEG. For cartoonish or line drawings, LZW (GIF) could do better for you for odd pixel sizes. – BitBank Feb 27 '12 at 04:24
  • In no test I conducted was GIF file size smaller at 5-7bpp than a PNG8 with the same reduced palette. I was able to achieve better compression using 6bpp and padding the last two bits with a pattern than the initial PNG8. I wonder if there is a way to set a compressor to look for patterns every x amount of bytes? So for 6bpp I would like every 3 bytes for a pattern. I'm going to try to play around with LZMA and the lc lp p switches. – Almost Famous Feb 28 '12 at 14:31
  • 1
    FLATE (PNG) compression is an improvement over LZW (GIF) if you stick with the correct symbol size. It makes sense that padding to 8bpp would work better. My point was about using odd (3/5/6/7) sizes. – BitBank Feb 28 '12 at 14:33
0

DEFLATE compression used by PNG has two main techniques:

  • finds repeating byte sequences and encodes them as backreferences
  • encodes bytes using Huffman coding

By changing pixel length from 8-bit you're out of sync with byte boundaries and DEFLATE won't be able to encode repeating pixel runs as repeated bytes.

And thanks to Huffman coding it doesn't matter that 8-bit pixels have unused bits, because the coding will encode bytes with variable-width codes assigning shortest ones to most frequently occurring values.

Kornel
  • 97,764
  • 37
  • 219
  • 309