Re: [9fans] why is image(6) compression so poor?

Re: [9fans] why is image(6) compression so poor?

[rog]

> 72+5996*7+3446 = 45280.

serves me right for not doing some simple arithmetic!

actually, it's interesting to observe that for small files
image(6) compression is sometimes better than gif.

overall though, its files seem to average about 50% bigger
(at least that's what the font images average).

it's probably worth it when the compression and decompression
routines combined come to only 272 lines!

Re: [9fans] why is image(6) compression so poor?

[Russ Cox]

> i recently observed that when writing a 500x500 all-white RGB24 image
> in image(6) format, compressed, the resulting file is 45295 bytes.

          The compression block is a string of variable-length code
          words encoding substrings of the pixel data.  A code word
          either gives the substring directly or indicates that it is
          a copy of data occurring previously in the pixel stream.

          In a code word whose first byte has the high-order bit set,
          the rest of the byte indicates the length of a substring
          encoded directly.  Values from 0 to 127 encode lengths from
          1 to 128 bytes.  Subsequent bytes are the literal pixel
          data.

          If the high-order bit is zero, the next 5 bits encode the
          length of a substring copied from previous pixels.  Values
          from 0 to 31 encode lengths from 3 to 34 bytes.  The bottom
          two bits of the first byte and the 8 bits of the next byte
          encode an offset backward from the current position in the
          pixel data at which the copy is to be found.  Values from 0
          to 1023 encode offsets from 1 to 1024.  The encoding may be
          `prescient', with the length larger than the offset, which
          works just fine: the new data is identical to the data at
          the given offset, even though the two strings overlap.

Each line in the image is 1500 bytes.  The first byte in a
compression chunk will be raw data (1 byte code word + 1 byte data).
After that each 34 bytes will store as 2 bytes of code word.

The first line in each chunk will have one raw byte
and then reference data, so it will be 2+(1499/34)*2 = 92 bytes.
A fully compressed line will be (1500/34)*2 = 90 bytes.

Each chunk stores at most 6000 compressed bytes,
so you can fit 66 lines = 92+90*65 = 5942 bytes in a chunk.
Each chunk header is 24 bytes, for a total of 5966 bytes.

The image is 500 lines, so you'll have 7 such chunks
and then a partial chunk for the last 38 lines.
That last chunk will be 92+90*37+24 = 3446 bytes.

There is a 72 byte header on a compressed image.

72+5996*7+3446 = 45280.

You said 45295.  I don't know where the other 15 bytes are.

Russ

[9fans] why is image(6) compression so poor?

[rog]

i recently observed that when writing a 500x500 all-white RGB24 image
in image(6) format, compressed, the resulting file is 45295 bytes.

gif compression, on the other hand, gives a file of 1689 bytes...

is this a bug, or a limitation of the compression scheme?