gif/lzw algorithms and code

[JohnF]

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/682627-malcolms-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,

 

[Malcolm McLean]

בת×ריך ×™×•× ×—×ž×™×©×™, 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.

 

[JohnF]

JohnF:

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,

 

[Malcolm McLean]

בת×ריך ×™×•× ×—×ž×™×©×™, 16 ב×וגוסט 2012 09:35:36 UTC+1, מ×ת JohnF:

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.

 

[JohnF]

JohnF:
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.

 

[JohnF]

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.

 

[BGB]

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/

I also have my own code to encode and decode PNG and JPEG images, but it
is not off-hand in any conveniently downloadable location for them.

no GIF or similar support though.


if-interested:

BTW, the code is contained within this program:
http://cr88192.dyndns.org:8080/2012-08-14_bgbtech_mini.zip

which is a copy of my game project...
(with more minimalistic data, basically, so that it is a 115MB download
rather than a 2GB download...).


the codec code is hidden in there, and if will allow use of the image
codec code under "do whatever you want with it" terms (actually, check
the "tools/awal" directory for a version that is more-or-less standalone).

note: the project source as a whole is currently proprietary (it is
in-progress, but I hope to develop the project sufficiently that I can
rightly ask money for it, so that I can support myself and similar,
rather than just mooching off my parents...), albeit much of the data is
from GPL or LGPL sources, although work may be needed WRT having proper
license-attributions in place for these cases.


the main difference between "jpg1.c" and "jpg2.c" in that directory, is
that "jpg2.c" has a lot of extensions (and a few bug-fixes):
an experimental "lossless" version of JPEG, which uses an alternate DCT
transform (SERMS RDCT) and a colorspace known as RCT;
support for multiple "component layers" in an image, basically,
extensions to support things like normal-maps, luma-maps,
alpha-blending, ... (mostly intended for specialized game-related uses,
namely textures and specialized MJPEG AVIs for animated textures, ...);
experimental/incomplete support for lossy limited-range floating-point
textures.

otherwise, the standard version of JPEG supported is "baseline" with
JFIF-like rules.


or such...

 

[Jean-Marc Lienher]

JohnF a écrit :

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.

Hum, well. Yes, gif.c is by far easier to read than stb_image.

The only thing that is more readable in stb_image is the
copyright status of the file (public domain).
I never use code which doesn't contain an explicit copyright
notice or a public domain dedication.

 

[Jean-Marc Lienher]

BGB a écrit :

if-interested:

BTW, the code is contained within this program:
http://cr88192.dyndns.org:8080/2012-08-14_bgbtech_mini.zip

which is a copy of my game project...
(with more minimalistic data, basically, so that it is a 115MB download
rather than a 2GB download...).

Yes I'm interested, but 115MB for jpeg and png image encoding/decoding
source code is not what I call "minimalistic";-) I started to download
your file, but I droped when I seen that it would take 44 minutes to
complete.

the codec code is hidden in there, and if will allow use of the image
codec code under "do whatever you want with it" terms (actually, check
the "tools/awal" directory for a version that is more-or-less standalone).

What do you mean by "do whatever you want" ?
Public domain? BSD, GPL, LGPL, MIT, Zlib, BSL licence... ?

 

[Malcolm McLean]

בת×ריך ×™×•× ×—×ž×™×©×™, 16 ב×וגוסט 2012 11:01:36 UTC+1, מ×ת JohnF:

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.

Thanks. That was why O'Reilley rejected it, because it was too much
a grab-bag of things that I'd done and thought might be useful, and not
sufficiently focused. They also said that they couldn't sell books
written in C.
But going the Lulu route I can sell a printed copy for half the price that
you'd need to charge otherwise, and the electronic copies can be made
avialable for a nominal fee. So I've got a bit of an audience. The book
could do with an edit, however.

 

[BGB]

BGB a écrit :

Yes I'm interested, but 115MB for jpeg and png image encoding/decoding
source code is not what I call "minimalistic";-) I started to download
your file, but I droped when I seen that it would take 44 minutes to
complete.

well, there is the whole rest of the game project with it.
the game is basically an FPS (first person shooter) style game.

What do you mean by "do whatever you want" ?
Public domain? BSD, GPL, LGPL, MIT, Zlib, BSL licence... ?

basically, what it says.

practically, it is the same as "I will let people use it as if it were
public domain, and put it under whatever license they want".


or, like, "as the author of the code, I can selectively give people the
right to disregard the assigned license terms for particular pieces of
code", which in this case, is a proprietary license, but I have not yet
commercialized the project, and I will probably make the source code
available anyways once it is being marketed (just, people will not have
the free right to redistribute it or create independent derived works is
all).


or such...

 

[JohnF]

JohnF:
Thanks. That was why O'Reilley rejected it, because it was too much
a grab-bag of things that I'd done and thought might be useful, and not
sufficiently focused. They also said that they couldn't sell books
written in C.

Wow. That's some commentary about the current status of C.
Didn't O'Reilly used to be the "goto" publisher for C (and
many other) computer books? (I've got an old copy of "Unix
Systems Programming for SVR4" still on my shelf, but my
other O'Reilly books are long gone.)
Maybe explicitly organize the book in three Parts, with
a separate intro at the front of each Part. For example, that
"Maths Functions" (where'd you British pick up that trailing
"s" from?) section might be better as a separate intro
to Part III, not dropped between the "Stacks" and "Memory"
and "Hash Tables" sections, where it seems out-of-place.

But going the Lulu route I can sell a printed copy for half the price that
you'd need to charge otherwise, and the electronic copies can be made
avialable for a nominal fee. So I've got a bit of an audience. The book
could do with an edit, however.

Yeah, the "syntax police" will certainly take every opportunity
to ticket you otherwise, a la that bytes.com forum. I immediately
got that you wrote the preliminary intro sections specifically for
the book, and apparently never tested that code (or even cc -c'ed it),
whereby stuff like if(...]..., that Bacarisse excoriated you about,
crept in (for some reason, I found that particularly funny).
But the meat-and-potatoes sections contain code you'd seriously
written and actually use, so that stuff mostly just works.
Nobody (in the forum) seemed to comprehend that distinction.
Of course, they're right that if one of the book's purposes is
as a "primer", then you should take care to get the syntax right.
And a reviewer's comment that "the 1st edition has many typos"
would be fair. But to stop there (like they mostly did) and not
take in the "big picture" would be unfair. For example, that
very first remark about your sqrt implementation completely
ignored your very interesting comparison of newton-raphson to
a divide-and-conquer (a la binary search) technique. I'd never
thought about it (or seen it discussed) that way. (Note: though
okay for sqrt, that analogy isn't always correct. Newton-raphson
isn't guaranteed bounded; I've had it run away on me in a
price/yield calculator for fixed-rate bonds, in a very embarrassing
situation.)

 

[JohnF]

JohnF a ecrit :

Hum, well. Yes, gif.c is by far easier to read than stb_image.

Thanks, that's what I thought you'd say.
I'm looking for source that's pretty much in one-to-one
correspondence with the algorithm it implements, i.e.,
not a whole bunch of housekeeping-and-other-ancillary stuff,
so I can cut/paste/modify/rewrite/etc it to suit my own style
and purposes. And that includes an argument list with all the
expected inputs and outputs, and nothing else, so the (expected)
behavior as a function f:input_domain-->output_domain can be
easily recognized. McClean seems to understand that audience,
and mostly code accordingly.

The only thing that is more readable in stb_image is the
copyright status of the file (public domain).
I never use code which doesn't contain an explicit copyright
notice or a public domain dedication.

Yeah, you'll note I mentioned that to MM in preceding post.
While the usual "ianal" applies, my dad/brother/ex are (is
there an acronym for that one?), so I'm pretty sensitive to
this kind of issue. But note that both MM and BGB made
subsequent public statements in this thread (that will be
archived somewhere for eternity) which pretty much releases
their stuff to public domain. Should the matter come under
dispute, and you introduce those statements in an american
court, I'm pretty sure they wouldn't stand a chance of
prevailing. And that's too bad -- I'd guess they both spoke
without much forethought, and without recognizing the permanent
and irreversible implications, should they ever have second
thoughts.

 

[BGB]

Thanks, that's what I thought you'd say.
I'm looking for source that's pretty much in one-to-one
correspondence with the algorithm it implements, i.e.,
not a whole bunch of housekeeping-and-other-ancillary stuff,
so I can cut/paste/modify/rewrite/etc it to suit my own style
and purposes. And that includes an argument list with all the
expected inputs and outputs, and nothing else, so the (expected)
behavior as a function f:input_domain-->output_domain can be
easily recognized. McClean seems to understand that audience,
and mostly code accordingly.


Yeah, you'll note I mentioned that to MM in preceding post.
While the usual "ianal" applies, my dad/brother/ex are (is
there an acronym for that one?), so I'm pretty sensitive to
this kind of issue. But note that both MM and BGB made
subsequent public statements in this thread (that will be
archived somewhere for eternity) which pretty much releases
their stuff to public domain. Should the matter come under
dispute, and you introduce those statements in an american
court, I'm pretty sure they wouldn't stand a chance of
prevailing. And that's too bad -- I'd guess they both spoke
without much forethought, and without recognizing the permanent
and irreversible implications, should they ever have second
thoughts.

well, there is a difference between "I am giving permission (to
particular people) to use some particular code as if it were public
domain" and "I am giving a right (to everyone) to use all of my stuff
(for now and into the future) as if it were public domain".

otherwise, I would have to go and classify all of the code under which
parts are usable under which particular license terms, which is "not
particularly worthwhile" if a project is large (for an MLOC range
project, it ceases to be worthwhile to individually worry about the
license terms for several kloc for encoding/decoding an image).



but, yeah, I may do and formally make some more stuff public-domain or
MIT-licensed (I am already using the MIT license for my Script-VM stuff).

this is partly opposed to my 3D Engine stuff, which is mostly intended
to be proprietary for now, despite the general availability of source code.


this is partly as I don't actually believe source code really needs to
be kept secret, especially when there is functionally-similar code off
in GPL land (and, at most, they will just use that code instead). in the
scenario where there is a FOSS analogue, it doesn't really make as much
of a difference whether another person is using ones' own source code,
or the analogous code off in GPL land.

decided to leave out an attempt at a more detailed
explanation/justification.

actually, FWIW, taken further, a developer could also go and help
facilitate the piracy of their own software, which could actually work
out in the favor of the vendor (as opposed to the usual assumption that
every pirated copy == lost-revenue or similar...).


or such...

 

[JohnF]

well, there is a difference between "I am giving permission (to
particular people) to use some particular code as if it were public
domain" and "I am giving a right (to everyone) to use all of my stuff
(for now and into the future) as if it were public domain".

Well, that's your personal interpretation, and not necessarily
a court's. I'd personally agree with you, but there's a whole
matter of whether a "broad" or "narrow" interpretation of your
statements should apply to a particular "fact pattern" in a
civil procedure, etc, etc, etc. Better to choose an open source
license you're happy with, trust its authors to have done their
legal homework, and carefully follow all their instructions.
For example, I like the gpl, and include the following comment
block at the very top of every program file,
/****************************************************************************
*
* Copyright(c) 2002-2012, John Forkosh Associates, Inc. All rights reserved.
* http://www.forkosh.com mailto: (e-mail address removed)
* --------------------------------------------------------------------------
* This file is part of mimeTeX, which is free software. You may redistribute
* and/or modify it under the terms of the GNU General Public License,
* version 3 or later, as published by the Free Software Foundation.
* MimeTeX is distributed in the hope that it will be useful, but
* WITHOUT ANY WARRANTY, not even the implied warranty of MERCHANTABILITY.
* See the GNU General Public License for specific details.
* By using mimeTeX, you warrant that you have read, understood and
* agreed to these terms and conditions, and that you possess the legal
* right and ability to enter into this agreement and to use mimeTeX
* in accordance with it.
* Your mimetex.zip distribution file should contain the file COPYING,
* an ascii text copy of the GNU General Public License, version 3.
* If not, point your browser to http://www.gnu.org/licenses/
* or write to the Free Software Foundation, Inc.,
* 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
* --------------------------------------------------------------------------
* and lots more comments about the program itself usually follow...
* ...
****************************************************************************/
The gpl instructions tell you to include a copyright statement and mailto
address, so there it is up top, followed by the boilerplate stuff they
provide. Note the 3rd paragraph, "By using mimeTeX,...", which I actually
added upon advice from a real contract lawyer. The gpl guys seem to have
missed a beat there. Technically, that "possess the legal right and ability"
precludes people under 18yo from using mimeTeX, since they can't enter
into license agreements/contracts.
My whole, and really only, point is that you're better off deciding
your license approach beforehand. Even if you're just "giving it away",
you still want that "warranty of merchantability" disclaimer to cover
your "elbow". Suppose you've got a bug in your code, and somebody relies
on it based on your off-the-cuff say-so, and then they suffer real damages.
You really want to be worrying about that sort of thing? All the usual
open source licenses have clauses to handle that, and handle lots of other
stuff you probably haven't thought about (and probably don't ever want to).

 

[BGB]

Well, that's your personal interpretation, and not necessarily
a court's. I'd personally agree with you, but there's a whole
matter of whether a "broad" or "narrow" interpretation of your
statements should apply to a particular "fact pattern" in a
civil procedure, etc, etc, etc. Better to choose an open source
license you're happy with, trust its authors to have done their
legal homework, and carefully follow all their instructions.
For example, I like the gpl, and include the following comment
block at the very top of every program file,
/****************************************************************************
*
* Copyright(c) 2002-2012, John Forkosh Associates, Inc. All rights reserved.
* http://www.forkosh.com mailto: (e-mail address removed)
* --------------------------------------------------------------------------
* This file is part of mimeTeX, which is free software. You may redistribute
* and/or modify it under the terms of the GNU General Public License,
* version 3 or later, as published by the Free Software Foundation.
* MimeTeX is distributed in the hope that it will be useful, but
* WITHOUT ANY WARRANTY, not even the implied warranty of MERCHANTABILITY.
* See the GNU General Public License for specific details.
* By using mimeTeX, you warrant that you have read, understood and
* agreed to these terms and conditions, and that you possess the legal
* right and ability to enter into this agreement and to use mimeTeX
* in accordance with it.
* Your mimetex.zip distribution file should contain the file COPYING,
* an ascii text copy of the GNU General Public License, version 3.
* If not, point your browser to http://www.gnu.org/licenses/
* or write to the Free Software Foundation, Inc.,
* 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
* --------------------------------------------------------------------------
* and lots more comments about the program itself usually follow...
* ...
****************************************************************************/
The gpl instructions tell you to include a copyright statement and mailto
address, so there it is up top, followed by the boilerplate stuff they
provide. Note the 3rd paragraph, "By using mimeTeX,...", which I actually
added upon advice from a real contract lawyer. The gpl guys seem to have
missed a beat there. Technically, that "possess the legal right and ability"
precludes people under 18yo from using mimeTeX, since they can't enter
into license agreements/contracts.
My whole, and really only, point is that you're better off deciding
your license approach beforehand. Even if you're just "giving it away",
you still want that "warranty of merchantability" disclaimer to cover
your "elbow". Suppose you've got a bug in your code, and somebody relies
on it based on your off-the-cuff say-so, and then they suffer real damages.
You really want to be worrying about that sort of thing? All the usual
open source licenses have clauses to handle that, and handle lots of other
stuff you probably haven't thought about (and probably don't ever want to).

there is a difference between not having any license, and having a
general license and selectively making exceptions to it for particular
people at particular times.

then they reuse the code under one set of terms, and the original author
has their own copy retained under their own terms.

it is not too much different from someone "licensing" some code:
they individual have rights to use the code which are different from
those of the general public.

(except for the parts which are marked as MIT licensed, then it is "take
it or leave it"...).


but, anyways, for example:
Quake started out proprietary;
Valve licensed it, and made Half-Life and later Half-Life 2 and Portal
and friends, based on a modified version of the source;
id Software also later released Quake as GPL.

however, the existence of similar code in both the GPL'ed Quake engine
and Half-Life does not mean that the existence of the GPL'ed Quake
engine also applies to the same code as it exists in the Half-Life
engine (or the Source Engine). (say, people trying to use this claim to
strong-arm Valve into making Half-Life or the Source engine open-source).


otherwise, reasons not to use GPL for a proprietary project:
stickiness property (it wants to apply itself over everything);
it is not possible (legally) to limit redistribution (or market it, say,
under per-seat licensing terms);
....


for example, although I would be giving away the code either way, there
would be a difference regarding who would have redistribution rights,
and in other aspects of the terms-of-use.

or, IOW, Open-Source, but not Free-Open-Source.


technically, it would be more like the SDKs offered by both Valve and
Microsoft for their products. they give away the SDK source, but this is
not the same as saying that everyone has full rights over said SDK source.

for example, Valve only allows using their SDKs in association with
their own products, and generally MS only allows using the code on
Windows, and forbids using the SDK code in open-source projects, ...


in this latter case, the engine source is basically itself a big SDK for
the engine. people can use it to make mods or similar (be creative), but
may not gain the rights to make their own derivative works and sell or
resell them independently of the original project, absent the permission
of the original author (say, granted at a fee, like, say, $75 or
similar, and 5% of sales revenue, if their project is commercial).

this wouldn't be for snippets though, but rather for people reusing
either the whole 3D engine, or significant portions thereof (say, the
whole renderer).


granted, yes, a person could be sneaky, and reuse the renderer without
telling anyone, but given they could just as easily rip off a similar 3D
renderer from some or another FOSS project and not tell anyone (say,
they go and rip off the renderer from the GPL'ed Doom 3 or from the
DarkPlaces engine or similar), and in this case it doesn't really matter
where they got the renderer from.

IOW: keeping the source secret is only really relevant if there is
actually something worth keeping secret (IOW: where doing so would offer
competitive advantage).

 

[88888 Dihedral]

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/682627-malcolms-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,

I think the LZW patents of Unysis and the arithmetic coding patents
of IBM are all expired long time ago.

Those are not too difficult to implement in C for a lossless
data compression in 199X.

I got paid well for those trivial easy jobs from my old image processing
library with those technitians who can't even write a 64 bit by 64 bit
integer multiplication in the 80386 instructin set.

It's kind of slow and boring except the pay in the small scale casino park.

Google and Facebook proved that the US Hi-tech casinos are much more
well paid for the funders.

 

[BGB]

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/682627-malcolms-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,

I think the LZW patents of Unysis and the arithmetic coding patents
of IBM are all expired long time ago.

the LZW patent expired in 2006 IIRC.

I think many other forms of arithmetic coding are also in the clear as
well. the main downside of AC though is that it generally isn't as fast
as Huffman, so it is more a small gain in compression for a loss in speed.

although, it isn't that bad, for example, the H.264 / MPEG-4 AVC codec
successfully uses arithmetic coding.

Those are not too difficult to implement in C for a lossless
data compression in 199X.

I got paid well for those trivial easy jobs from my old image processing
library with those technitians who can't even write a 64 bit by 64 bit
integer multiplication in the 80386 instructin set.

It's kind of slow and boring except the pay in the small scale casino park.

Google and Facebook proved that the US Hi-tech casinos are much more
well paid for the funders.

still annoyingly hard to get paid as a programmer though.
"the money" is always far away and one lives life generally being
regarded as useless by any potential employers.

this is partly why I am looking into trying to develop and market
something myself...

 

[88888 Dihedral]

BGBæ–¼ 2012å¹´8月22日星期三UTC+8上åˆ9時01分49秒寫é“：

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/682627-malcolms-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,

I think the LZW patents of Unysis and the arithmetic coding patents

of IBM are all expired long time ago.

the LZW patent expired in 2006 IIRC.



I think many other forms of arithmetic coding are also in the clear as

well. the main downside of AC though is that it generally isn't as fast

as Huffman, so it is more a small gain in compression for a loss in speed..



although, it isn't that bad, for example, the H.264 / MPEG-4 AVC codec

successfully uses arithmetic coding.

Professional fast and fine tuned LZW and Arithmetic compression codecs not
violating any patent to be used in a specific hardware platform
,e.g., some smart phone, in sw should be paid much better
nowadays due to the markete environment and the IP status now
than the era in 199X.

Professional programmers have to solve non-trivial problems as young as
possible in order to be paid at the right time.

 

[88888 Dihedral]

BGBæ–¼ 2012å¹´8月18日星期六UTC+8上åˆ12時14分42秒寫é“：

there is a difference between not having any license, and having a

general license and selectively making exceptions to it for particular

people at particular times.



then they reuse the code under one set of terms, and the original author

has their own copy retained under their own terms.



it is not too much different from someone "licensing" some code:

they individual have rights to use the code which are different from

those of the general public.



(except for the parts which are marked as MIT licensed, then it is "take

it or leave it"...).





but, anyways, for example:

Quake started out proprietary;

Valve licensed it, and made Half-Life and later Half-Life 2 and Portal

and friends, based on a modified version of the source;

id Software also later released Quake as GPL.



however, the existence of similar code in both the GPL'ed Quake engine

and Half-Life does not mean that the existence of the GPL'ed Quake

engine also applies to the same code as it exists in the Half-Life

engine (or the Source Engine). (say, people trying to use this claim to

strong-arm Valve into making Half-Life or the Source engine open-source).





otherwise, reasons not to use GPL for a proprietary project:

stickiness property (it wants to apply itself over everything);

it is not possible (legally) to limit redistribution (or market it, say,

under per-seat licensing terms);

...





for example, although I would be giving away the code either way, there

would be a difference regarding who would have redistribution rights,

and in other aspects of the terms-of-use.



or, IOW, Open-Source, but not Free-Open-Source.





technically, it would be more like the SDKs offered by both Valve and

Microsoft for their products. they give away the SDK source, but this is

not the same as saying that everyone has full rights over said SDK source..



for example, Valve only allows using their SDKs in association with

their own products, and generally MS only allows using the code on

Windows, and forbids using the SDK code in open-source projects, ...





in this latter case, the engine source is basically itself a big SDK for

the engine. people can use it to make mods or similar (be creative), but

may not gain the rights to make their own derivative works and sell or

resell them independently of the original project, absent the permission

of the original author (say, granted at a fee, like, say, $75 or

similar, and 5% of sales revenue, if their project is commercial).



this wouldn't be for snippets though, but rather for people reusing

either the whole 3D engine, or significant portions thereof (say, the

whole renderer).





granted, yes, a person could be sneaky, and reuse the renderer without

telling anyone, but given they could just as easily rip off a similar 3D

renderer from some or another FOSS project and not tell anyone (say,

they go and rip off the renderer from the GPL'ed Doom 3 or from the

DarkPlaces engine or similar), and in this case it doesn't really matter

where they got the renderer from.



IOW: keeping the source secret is only really relevant if there is

actually something worth keeping secret (IOW: where doing so would offer

competitive advantage).

For a commercial sofware team to be competitive, it is necessary that
the programs can be proved to be developed ground up by the team in various
computer languages or cpus or OSes if necessary.