gif/lzw algorithms and code

Discussion in 'C Programming' started by JohnF, Aug 16, 2012.

  1. JohnF

    JohnF Guest

    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,
    --
    John Forkosh ( mailto: where j=john and f=forkosh )
    JohnF, Aug 16, 2012
    #1
    1. Advertising

  2. בת×ריך ×™×•× ×—×ž×™×©×™, 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, Aug 16, 2012
    #2
    1. Advertising

  3. JohnF

    JohnF Guest

    Malcolm McLean <> 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: where j=john and f=forkosh )
    JohnF, Aug 16, 2012
    #3
  4. בת×ריך ×™×•× ×—×ž×™×©×™, 16 ב×וגוסט 2012 09:35:36 UTC+1, מ×ת JohnF:
    > Malcolm McLean <> 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, Aug 16, 2012
    #4
  5. JohnF

    JohnF Guest

    Malcolm McLean <> wrote:
    > JohnF:
    >> Malcolm McLean <> 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: where j=john and f=forkosh )
    JohnF, Aug 16, 2012
    #5
  6. JohnF

    JohnF Guest

    Jean-Marc L. <> 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: where j=john and f=forkosh )
    JohnF, Aug 16, 2012
    #6
  7. JohnF

    BGB Guest

    On 8/16/2012 5:47 AM, Jean-Marc L. 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/
    >


    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...
    BGB, Aug 16, 2012
    #7
  8. JohnF a écrit :
    > Jean-Marc L. <> 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.
    >


    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, Aug 16, 2012
    #8
  9. 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... ?
    Jean-Marc Lienher, Aug 16, 2012
    #9
  10. בת×ריך ×™×•× ×—×ž×™×©×™, 16 ב×וגוסט 2012 11:01:36 UTC+1, מ×ת JohnF:
    > Malcolm McLean <> wrote:
    >
    > 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.
    Malcolm McLean, Aug 16, 2012
    #10
  11. JohnF

    BGB Guest

    On 8/16/2012 2:15 PM, Jean-Marc Lienher wrote:
    > 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.
    >


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


    >> 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... ?
    >


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

    >
    BGB, Aug 17, 2012
    #11
  12. JohnF

    JohnF Guest

    Malcolm McLean <> wrote:
    > JohnF:
    >> Malcolm McLean <> wrote:
    >>
    >> 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.


    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.)
    --
    John Forkosh ( mailto: where j=john and f=forkosh )
    JohnF, Aug 17, 2012
    #12
  13. JohnF

    JohnF Guest

    Jean-Marc Lienher <> wrote:
    > JohnF a ecrit :
    >> Jean-Marc L. <> 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.

    >
    > 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.
    --
    John Forkosh ( mailto: where j=john and f=forkosh )
    JohnF, Aug 17, 2012
    #13
  14. JohnF

    BGB Guest

    On 8/16/2012 9:49 PM, JohnF wrote:
    > Jean-Marc Lienher <> wrote:
    >> JohnF a ecrit :
    >>> Jean-Marc L. <> 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.

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



    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...
    BGB, Aug 17, 2012
    #14
  15. JohnF

    JohnF Guest

    BGB <> wrote:
    > JohnF wrote:
    >> Jean-Marc Lienher <> wrote:
    >>> JohnF a ecrit :
    >>>> Jean-Marc Lienher <> wrote:
    >>>
    >>> 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.

    >
    > 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:
    * --------------------------------------------------------------------------
    * 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).

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


    --
    John Forkosh ( mailto: where j=john and f=forkosh )
    JohnF, Aug 17, 2012
    #15
  16. JohnF

    BGB Guest

    On 8/17/2012 9:40 AM, JohnF wrote:
    > BGB <> wrote:
    >> JohnF wrote:
    >>> Jean-Marc Lienher <> wrote:
    >>>> JohnF a ecrit :
    >>>>> Jean-Marc Lienher <> wrote:
    >>>>
    >>>> 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.

    >>
    >> 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:
    > * --------------------------------------------------------------------------
    > * 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).


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

    >
    BGB, Aug 17, 2012
    #16
  17. On Thursday, August 16, 2012 1:51:01 PM UTC+8, JohnF wrote:
    > 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,
    >
    > --
    >
    > John Forkosh ( mailto: where j=john and f=forkosh )


    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.
    88888 Dihedral, Aug 21, 2012
    #17
  18. JohnF

    BGB Guest

    On 8/21/2012 2:16 PM, 88888 Dihedral wrote:
    > On Thursday, August 16, 2012 1:51:01 PM UTC+8, JohnF wrote:
    >> 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,
    >>
    >> --
    >>
    >> John Forkosh ( mailto: where j=john and f=forkosh )

    >
    > 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...
    BGB, Aug 22, 2012
    #18
  19. BGBæ–¼ 2012å¹´8月22日星期三UTC+8上åˆ9時01分49秒寫é“:
    > On 8/21/2012 2:16 PM, 88888 Dihedral wrote:
    >
    > > On Thursday, August 16, 2012 1:51:01 PM UTC+8, JohnF wrote:

    >
    > >> 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,

    >
    > >>

    >
    > >> --

    >
    > >>

    >
    > >> John Forkosh ( mailto: where j=john and f=forkosh )

    >
    > >

    >
    > > 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, Aug 22, 2012
    #19
  20. BGBæ–¼ 2012å¹´8月18日星期六UTC+8上åˆ12時14分42秒寫é“:
    > On 8/17/2012 9:40 AM, JohnF wrote:
    >
    > > BGB <> wrote:

    >
    > >> JohnF wrote:

    >
    > >>> Jean-Marc Lienher <> wrote:

    >
    > >>>> JohnF a ecrit :

    >
    > >>>>> Jean-Marc Lienher <> wrote:

    >
    > >>>>

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

    >
    > >>

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

    >
    > > * --------------------------------------------------------------------------

    >
    > > * 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).
    >
    >
    >
    >
    >
    > >> 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...

    >


    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.
    88888 Dihedral, Aug 22, 2012
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. hb
    Replies:
    6
    Views:
    9,121
  2. Jim Melton

    LZW decompressor

    Jim Melton, Sep 30, 2005, in forum: Python
    Replies:
    0
    Views:
    2,145
    Jim Melton
    Sep 30, 2005
  3. Beauregard T. Shagnasty

    Re: filename.gif or filename.gif.jpg?

    Beauregard T. Shagnasty, May 30, 2008, in forum: HTML
    Replies:
    1
    Views:
    745
    Jonathan N. Little
    May 30, 2008
  4. Bergamot
    Replies:
    0
    Views:
    450
    Bergamot
    May 30, 2008
  5. Ahmad Azizan
    Replies:
    2
    Views:
    250
    Brian Candler
    Mar 22, 2010
Loading...

Share This Page