[Coco] GIF

[Roger Taylor]

At 12:39 AM 12/20/2003 -0500, you wrote:
>In a message dated 12/19/03 2:55:45 PM Eastern Standard Time,
>rtaylor at bayou.com writes:
>
> > I will be glad to give a tutorial on how to decode or encode GIFs so I can
> >  get my mind of these crazy web server issues.
> >  The only part of the file that is complex is the LZW algorithm, and even
>it
> >  is quite simple once you visualize how it works.
>
>Roger, the LZW I could sort of figure out.  But what I meant is that the doc
>you forwarded to me did not tell exactly how the bits were packed, so I could
>not use it as a basis for writing a program to decode GIF.
>
>Anyway, I suspect that BMP would be a better place to start.
>
>What I really need is some sort of RLE (Run-Length Encoding) which is most
>efficient for black-and-white music scores.  Thanks, Mike K.


I actually have my own RLE decoder and encoder routines.  I never put the 
encoder into P-3.  This is the Compuserve RLE format.  Lord knows there's 
plenty of new formats by the same name now.

Robert Gault wrote a BMP decoder for P-3 which works great.  He has more 
hands-on experience with the low-levels of this format.  I was too busy 
trying to squash my GIF encoder bug that showed up somehow over the past 
year, so I didn't play too much of a part in the actual BMP decoding stuff 
in his driver.

BMP files are not compressed, to the best of my knowledge.  :(

I can forward my RLE stuff to you but the commenting is poor.  It's pretty 
short code, though.  Oh!! What about the ColorMAX format?  That's a rather 
simple 16-color RLE format, and might be the best choice for your project.

Even the .RAT format is fairly simple, based on run-length.


----------
Roger Taylor


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://five.pairlist.net/pipermail/coco/attachments/20031219/fbdcae79/attachment-0001.html>