Slashdot Mirror
GIF Support Returns to GD
g_adams27 writes "Legions of geeks and developers owe a debt of gratitude to Tom Boutell and his "gd" library, which powers the drawing and graphic-generating tools used by dozens of open-source projects. And now, with the expiration of the last Unisys patent on the GIF format, support for GIFs has finally been reinserted in gd. The GIF/PNG/MNG wars may continue, but having more options is good!"
var_dump(gd_info());
Some nice soul posted a comment on PHP.net that has what appears to be a great function that does the same thing, but could be used in install scripts and hacked to get it working the way you want:
The dangers of knowledge trigger emotional distress in human beings.
Beware of Geeks bare in GIF's.
The only thing gif does better than png is animation. Okay, on some rare occasions, gif compresses better. But most of the time, you have no reason to use gif instead of png.
The usual crowd of nincompoop Slashbots are going to crow "They should just leave it out! Everyone should use PNG anyway!!"
... GIF is still the only available option.
Let me answer that in advance by reminding everyone that GIF is a useful format. Everything can read it and display it. It's been around for two decades and is now a completely open and unencumbered standard.
And let's not forget that when you need to display an image that is non-lossy, and supports transparency, and displays properly in Internet Explorer (shame on you for using Internet Explorer in the first place, but we'll accept that a lot of people still do)
Tired of FB/Google censorship? Visit UNCENSORED!
Not complete lack of support, but IE's PNG support is partly broken. Mostly in that it doesn't support alpha transparency, though all other major browsers do. And that's a real shame because it's a very nice feature. This alone would give PNG a clear advantage over GIF if it wasn't for the fact that the only major browser that doesn't support it happens to account for over 90% of the user base.
Since it's a duplicate patent and should never have been issued in the first place, IBM would be idiotic to let it get anywhere near a courtroom.
Why is it that the proponents of "one nation under God" are so eager to get rid of "liberty and justice for all"?
For 'many' of the uses? Hardly. If you save a PNG as 24-bit, even though it has 8-bit or fewer colours, even pngcrush (or the better such program, pngout) can't help much. Saving a PNG properly, THEN using pngout will almost always produce a smaller filesize than GIF. It's _exceedingly_ rare that you'd have a smaller GIF - usually only when you're using a 1 pixel transparent GIF for a web site spacer graphic, which you _should_ know how to avoid doing by now, anyway, if you're anything resembling a well-informed web developer.
Bah. A pox on GIFs!
Now if only Adobe could get off their lazy crappy-programmer asses and put proper PNG compression in Photoshop so we wouldn't _need_ programs like pngcrush & pngout.
Full alpha...here's one script that implements it, and you use it something like this (assuming that you've loaded the script somewhere further up in your page):
20 January 2017: the End of an Error.
GIF may be indexed color, but since the animation extension is supposed to allow for multiple palettes that DO NOT overwrite the previous palette, as well as the ability to have each frame render a small piece of a larger picture with mostly transparent background, you can "draw" a true color GIF.
See gif-with-32697-colors.gif
If your browser draws it right, it will look like this
Note that the GIF is 180K and the PNG is 14K, but they are both truecolor.
Unfortunately, many non-animated programs will only display the first frame, so you only see the upper left corner, and some will improperly overwrite the palette of every frame with the current frame's palette, causing the image to pulse widely as it draws and end up in the wrong colors.
Morphing Software
Unless you know the business internals and license agreements of those companies, you have no idea whether they respected the patents or not. However, all major graphics program vendors (Adobe, JASC, etc.) have LICENSED the gif compression algorithm, and used it in their programs. Those who paid to use those programs have the right to create gifs.
These commercial softwares did not disrespect "IP-rights," they meticulously followed the law by doing exactly what's required to use the patented algorithm. They showed respect for the patent by paying to use the algorithm. Free software respected the same rights by not using what they hadn't paid to use (because they either couldn't or weren't willing to).
-Dan
(a) It was actually only a couple of months after Unisys announced its patent and its intent to enforce, before the PNG format was finalized. It was really an example of lightning-speed format development. google "png history"
(b) the worldwide patents on LZW have not yet expired! It's arguable whether the following patent is valid, but IBM was issued a patent on *the same algorithm* covered by the Unisys patent -- and IBM's patent is good for another two years:
United States Patent No. 4814746 issued in 1989.
I used to work for a company named Mastersoft, which was acquired by Frame, the makers of Frame Maker (the now-discontinued DTP app); Frame was subsequently acquired by Adobe.
While at Mastersoft, I developed an implementation of a PNG reading and writing library for use in various file format conversion products; these reading and writing libraries were also licensed to OEMs for inclusion in other commercial products, so they're in a lot of places. The libraries I wrote used Jean-Loup Gailly's (sp?) zlib (since I didn't want to reinvent the wheel and debug a compression library), but did not rely on the pnglib reference implementation in any way.
I was very proud of the fact that my libraries were the first commercial implementation of PNG, as far as I can tell. However, due to time constraints and some performance requirements, the compression done by my PNG writer libraries wasn't the best. Specifically, I avoided using any scanline filter type other than Paeth for my PNG writing library; most modern PNG writers will try all 5 filter types on each scanline, and see which compresses the best. My choice had the virtue of saving time in writing a PNG file to disk, but doesn't necessarily produce the smallest PNG files. I also used a relatively small PNG chunk size; since each chunk has some overhead, more chunks means larger PNG files. Lastly, the version of zlib that I used was current as of the drafting of the original PNG specification; subsequent versions of zlib were released which were slightly more efficient, and a few nasty bugs were stomped out.
I don't know if Adobe is using my PNG writing code in Photoshop, but since Adobe purchased the IP of Mastersoft in the Frame acquisition, it's not inconceivable that they used my code rather than writing their own. If they used my code, then it's quite possible that I'm to blame for Photoshop saving out crappy PNG files that are too big.
In my defense, though, I should say that many people did manage to compress existing GIF files using my PNG library (which shipped as part of the Mastersoft File Utilities by Adobe, a product that unfortunately didn't last long); one magazine reviewer specifically used this software suite to convert a bunch of GIFs to PNGs, and concluded that in most cases, the PNGs were indeed smaller.
As soon as you start dealing with non-indexed color images, though, PNG is no better than TIFF. Some folks might incorrectly try to take a 24-bit source image and save as PNG, then take the same source and save as GIF, and will note that the GIF is way smaller -- as it should be, since GIF doesn't support 24 bpp images, whereas PNG does. To save a 24-bit source image as GIF, you have to first reduce the color space and convert to an indexed color image, since that's the only type of image that GIF can store. With PNG, the bit depth of the original is preserved. (And since PNG supports up to 16 bits per channel, and supports up to four channels -- R, G, B, and Alpha -- you can see how a PNG image can get obscenely large. This is where it pays to manage your expectations and understand the features and limitations of the file format.)
> only posers that code only for the bleeding edge pan the old tricks
> do you get the point I am making?
Yep, I do. People like YOU are posers. CSS is hardly 'bleeding edge.' People like YOU are what's holding back 4-year-old standards from becoming requirements. The point you're making is that you're a shortsighted idiot with little real comprehension of the impact of the things you do.