[Libdlo] libtubecable 0.1.1

[Florian Echtler]

> > But this still is a hack nevertheless.. especially when considering that
> > this code doesn't yet support images shorter than the screen width.
> I've tried writing a small routine to support just that, but there are
> quite a lot of pixel errors in the result. I've included it anyway, in
> case someone might have an idea why that happens. Most likely it has
> something to do with all the weird adjustments you have added in your
> dl_huffman_compress() and which I have removed - all that is probably
> necessary but it is not quite clear why.
Hello Henrik,

yes, the device is very picky about compressed data. Unfortunately, I
won't be able to put much work into this in the next weeks, but I'll
give it a try later.

>     // this loop generates sub-blocks of max. 248 pixels
>     for ( pixel = 0; pixel < pcount; pixel++ ) {
>         thispix = pixels[pixel];
>         dl_huffman_append( cs, thispix - prev );
>         prev = thispix;
>     }
Why did you change it to 248? I think your routine will return
significantly less than 508 bytes of data in most cases, which confuses
the decoder. It's absolutely mandatory to have 508 bytes of compressed
data (with headers), followed by AF20FFFF for a total of 512 bytes.

Florian
-- 
0666 - Filemode of the Beast