ken@turtlevax.UUCP (Ken Turkowski) (12/06/84)
> Depending on the complexity of image, runlength coding produces worse > compression than a straight byte storage. A mixture of the two is > helpful: > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| run length | color | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+ > |1|vector length| color0 | color1 | ... | color n-1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+ > > I have called this a "sparse vector" type of representation. The runs > are of length 128 (instead of 256) max, because the most significant > bit is used to switch between runs and vectors. > > Depending on the measure used, the break-even point is a run of 3, 4, > or 5. > -- In a C-type syntax, the vector format is something like: struct pixvect { char veclength; /* Ignoring the MSB for now */ char vector[veclength]; }; Suppose that we have the numbers: 311 014 000 200 151 014 000 200 175 014 000 200 243 014 000 200 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 350 016 000 200 360 016 000 200 370 016 000 200 000 017 000 200 There are obviously no runs in the first or last lines, but there is a run of 16 in the middle line: char spvect[] = { 0x80 | 15, /* Vector of length 16 */ 311,014,000,200,151,014,000,200,175,014,000,200,243,014,000,200, 15, /* Run of length 16 */ 0, /* Run value = 0 */ 0x80 | 15, /* Vector of length 16 */ 350,016,000,200,360,016,000,200,370,016,000,200,000,017,000,200 }; If a pure runlength technique were used, the two vectors would be encoded with 32 bytes each instead of 17. -- Ken Turkowski @ CADLINC, Menlo Park, CA UUCP: {amd,decwrl,nsc,spar}!turtlevax!ken ARPA: turtlevax!ken@DECWRL.ARPA