gif/lzw algorithms and code

I've been looking for algorithms/code to render gif's
from in-memory pixel rasters, and gif/rbtree from
http://www.malcolmmclean.site11.com/www/datadensity/
seems among the best. Anybody used that, have comments
or alternative/better recommendations?
My interest mostly stems from forkosh.com/lineart.html whose
C source currently uses http://shh.thathost.com/pub-unix/#gifsave
and then system()'s imagemagick convert for animations.
But I now need to render animated gif's internally, and
modify somebody's gif code for that purpose (or develop it from
scratch). The better functional decomposition of gif/rbtree
seems to make that easier for me than gifsave.
But I noticed some occasionally-nasty comments about that on
http://bytes.com/topic/c/answers/682...colms-new-book
while googling (some of them by frequent posters in this ng.
Does gif/rbtree work pretty robustly (that "looking-for-comma"
at the start of loadgif() seems a little risky, though I haven't
read the gif specification carefully yet, and wouldn't need that
half of the code, anyway)?
While testing savegif() myself, just using the embedded test
driver, I did find a trivial bug which always replaces the
savegif(loadgif(argv[1])) with an empty image. Just a "return"
at the end of if(argc==2){...}, or a guard for the empty-image
savegif() with else{...} or if(argc!=2){...} is needed.
But then my own tests worked fine, except that it occasionally
gets the background color wrong. But I haven't looked into that yet,
or even studied the code carefully. Before I start, any other
recommendations for this kind of little project? Thanks,
--
John Forkosh ( mailto: j@f.com where j=john and f=forkosh )

בת�ריך יו� חמישי, 16 ב�וגוסט 2012 06:51:01 UTC+1, מ�ת JohnF:
>
> But I now need to render animated gif's internally, and
> modify somebody's gif code for that purpose (or develop it from
> scratch). The better functional decomposition of gif/rbtree
> seems to make that easier for me than gifsave.
>
Extending savegif and loadgif to handle animated images should be on my to
do list. The code was originally written for the book Basic Algorithms and so
I didn't add animations because they didn't do anything algorithmically
interesting - it's just a case of bunging several images together into one
GIF file with no attempt at cross-frame compression. But of course it would
be nice to have the facility to handle such GIFs.

--
Basic Algorithms - GIF, BMP and JPEG formats expalained
http://www.malcolmmclean.site11.com/www

Malcolm McLean <malcolm.mclean5@btinternet.com> wrote:
> JohnF:
>>
>> But I now need to render animated gif's internally, and
>> modify somebody's gif code for that purpose (or develop it from
>> scratch). The better functional decomposition of gif/rbtree
>> seems to make that easier for me than gifsave.
>
> Extending savegif and loadgif to handle animated images should be on my to
> do list. The code was originally written for the book Basic Algorithms and so
> I didn't add animations because they didn't do anything algorithmically
> interesting - it's just a case of bunging several images together into one
> GIF file with no attempt at cross-frame compression. But of course it would
> be nice to have the facility to handle such GIFs.
>
> Basic Algorithms - GIF, BMP and JPEG formats explained
> http://www.malcolmmclean.site11.com/www

Thanks for the info, Malcolm. I tried emailing you at that "regniztar"
email on your above page, but posted here after that bounced (all I could
figure is that it's "ratzinger" backwards, but that also means nothing.
Then came across malcolm.mclean (apparently missing the "5"), and that
didn't bounce, so I guess one of your namesakes got it. I'm kind of
amazed you noticed the post here.

Among the best online explanations I came across was
http://www.daubnet.com/en/file-format-gif
http://www.onicos.com/staff/iz/formats/gif.html
http://www.fileformat.info/format/gif/egff.htm
But they're all pretty "rough around the edges" considering
how ubiquitous gif is. I'd expected some way more polished
presentations. Ditto for lzw. There's enough to get going,
all right, but you (or at least I) have to be prepared to
wade through a lot of murky discussion.
But I'll go buy your lulu pdf, and see if you've improved
the situation (don't worry -- nothing I could say could
match that thread.

By the way, two questions in the email I didn't repeat here:
Is the source gpl'ed (so I can use it in my application, which
will also be gpl'ed when ready), and does that datadensity/
directory contain the most recent source versions?
Thanks again,
--
John Forkosh ( mailto: j@f.com where j=john and f=forkosh )

בת�ריך יו� חמישי, 16 ב�וגוסט 2012 09:35:36 UTC+1, מ�ת JohnF:
> Malcolm McLean <malcolm.mclean5@btinternet.com> wrote:
>
> By the way, two questions in the email I didn't repeat here:
> Is the source gpl'ed (so I can use it in my application, which
> will also be gpl'ed when ready), and does that datadensity/
> directory contain the most recent source versions?
>
The source is freely avialable, so you can use it in any project as far
as I'm concerned, including closed source for profit programs.

Yes, there's a bug in the Basic Algorithms version which means that some readers
won't read two-valued GIF files correctly.
I think I'm going to start an image formats section of my website. People
shouldn't have to scratch around in the data density code to get image
codecs. What I'm lacking is a portable ANSI C png loader. Unfortunately the
format is very complex and it's no easy job to write one.

--
Malcolm's website.
http://www.maclommclean.site11.com/www

Malcolm McLean <malcolm.mclean5@btinternet.com> wrote:
> JohnF:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> wrote:
>>
>> By the way, two questions in the email I didn't repeat here:
>> Is the source gpl'ed (so I can use it in my application, which
>> will also be gpl'ed when ready), and does that datadensity/
>> directory contain the most recent source versions?
>>
> The source is freely avialable, so you can use it in any project as far
> as I'm concerned, including closed source for profit programs.
>
> Yes, there's a bug in the Basic Algorithms version which means
> that some readers won't read two-valued GIF files correctly.
> I think I'm going to start an image formats section of my website.
> People shouldn't have to scratch around in the data density code
> to get image codecs. What I'm lacking is a portable ANSI C png loader.
> Unfortunately the format is very complex and it's no easy job to write one.

Thanks again, Malcolm. Yes, I see from the Intro that the code
is freely usable, though exact license terms are unclear.
While I've obviously only just begun skimming it, seems like
a terrific bargain at $2.96 (don't spend it all in one place;
by the way, is that an acid-free pdf?. I'm sure it's
less than perfect (e.g., the table-of-contents page numbering
is off by seven), like everything humanr. But the unkind portions
of that thread (mentioned eralier) were clearly a load of pedantic
hogwash, by people unable to appreciate the book's scope, who
focused only on microscopic bits of coding syntax, just itching
for negative things to say.
Much of your stuff is incredibly interesting to me
(e.g., with an ms in physics, I've always meant to take a
look at simulated annealing), and "basic" only in the sense
that you're exhibiting basic techniques for not-so-basic
subjects. Almost looks like three books in one: first,
a primer on "data structures and algorithms", a la Cormen,
et al, then some compression and graphics, and finally the
"numerical recipes"-like stuff. I'm guessing it's a mash-up
of all the stuff that interests you, organized as best you
could figure out. A really excellent job. Don't let anybody
tell you otherwise. Just fix up the inevitable misprints, etc,
for the 2nd ed.
By the way, http://www.forkosh.com/json160.gif contains
an example of the bg color thing I mentioned earlier;
the reconstructed save(load(json160.gif)) gives me a different
bg color. I'm sure it's trivial (i.e., fixing is trivial once
you find the needle in haystack that needs fixing).
And, yeah, png is pretty complicated. When writing my
forkosh.com/mimetex.html I considered it, but pnglib was a
big bad bunch of code, versus Sverre Huseby's slim trim gifsave.
And, of course, no animation, which nixes it for my present
little project.
--
John Forkosh ( mailto: j@f.com where j=john and f=forkosh )

JohnF wrote:
> And, yeah, png is pretty complicated. When writing my
> forkosh.com/mimetex.html I considered it, but pnglib was a
> big bad bunch of code, versus Sverre Huseby's slim trim gifsave.
> And, of course, no animation, which nixes it for my present
> little project.

There is the stb_* public domain code which can write PNG:
http://nothings.org/stb/stb_image_write.h

And this one can load png, jpeg and gif:
http://nothings.org/stb_image.c

This one can write jpeg (but it is C++):
http://code.google.com/p/jpeg-compressor/

Jean-Marc L. <invalid@none.none> wrote:
> JohnF wrote:
>> And, yeah, png is pretty complicated. When writing my
>> forkosh.com/mimetex.html I considered it, but pnglib was a
>> big bad bunch of code, versus Sverre Huseby's slim trim gifsave.
>> And, of course, no animation, which nixes it for my present
>> little project.
>
> There is the stb_* public domain code which can write PNG:
> http://nothings.org/stb/stb_image_write.h
>
> And this one can load png, jpeg and gif:
> http://nothings.org/stb_image.c
>
> This one can write jpeg (but it is C++):
> http://code.google.com/p/jpeg-compressor/

Thanks, J-M, I browsed stb_image. Please take
a look at gif.c and rbtree.c (and appropriate .h) in
http://www.malcolmmclean.site11.com/www/datadensity/
and let me know which (these or stb_image) you feel
is easier to read.
--
John Forkosh ( mailto: j@f.com where j=john and f=forkosh )