GIF Support Returns to GD 364
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!"
Nice GD Info (Score:5, Informative)
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:
PNG is still better (Score:1, Informative)
Re:What format war? (Score:5, Informative)
Re:IBM (Score:5, Informative)
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.
Re:PNG is still better (Score:2, Informative)
Ancient software? (Score:4, Informative)
IE displays PNG's properly, with transparency, and it's still non-lossy. IE only doesnt properly support the alpha channel of PNG's.
Re:Ancient technology (Score:5, Informative)
Full alpha...here's one script [alfter.us] that implements it, and you use it something like this (assuming that you've loaded the script somewhere further up in your page):
Re:Did anyone really stop using gifs? (Score:5, Informative)
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 [ark42.com]
If your browser draws it right, it will look like this [ark42.com]
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.
Re:Nice GD Info (Score:3, Informative)
Re:Did anyone really stop using gifs? (Score:4, Informative)
Re:PHP (Score:3, Informative)
Re:Gif is only good for animation (Score:3, Informative)
IE supports 256color PNG files with a single palette transparency with no JS or special crap like is required to support the 32bit PNG's alpha channel.
The PNG is usually smaller too.
Unless you need animation, PNG is just better.
Re:Did anyone really stop using gifs? (Score:2, Informative)
Re:Digital Cams ? (Score:3, Informative)
png uses lossless compresion. It basically is a format for zipped bitmaps.(as far as the compression works, it does a whole bunch of other stuff that bitmaps don't.)
jpeg uses some lossy compression, and then goes ahead ahead and uses lossless on the output of the lossy compression stage. This yields smaller file sizes at a given image resolution(and thus better resolution at similar file size), by sacrificing some amount of quality. The reduction in quality is tunable, and using high quality settings results in images that are fine for most purposes, with the major exception being high quality print.
gif doesn't support color nearly as well as jpeg or png.
Basically, jpeg is 'good enough'(for most people, those that it isn't good enough for use stuff like raw formats or tiff+lzw), and already widely supported/in use.
for more info, check out http://www.photo.net/learn/jpeg/
it is a decent summary of jpeg and the issues involved with its use.
screw gd, use imlib (Score:2, Informative)
Re:Gif is only good for animation (Score:2, Informative)
You can display PNGs with full alpha transparency, both as backgrounds of a block element and inline with an image tag, without using any javascript, behaviors, or a second image.
The following CSS and html code shows how:
For background:
For inline:
Of course you'll want to put the proprietary code within IE comment conditionals [link here [microsoft.com]]. You can remove the expression syntax from background if you put it within the IE conditional. Fix any obvious errors in the above code that /. introduced.
Re:Did anyone really stop using gifs? (Score:1, Informative)
well only poser web developers say that.
a good web dev will build pages that will correctly display on ANY browser. some older and portable browsers built into hardware like cellphones and pda's as well as the first LG fridge or the 3com audrey as well as other web appliances dont render CSS right. so you need ot position with a 1x1 transparent gif. it's smaller, loads damned faster than the css code and is across the board compatable.
only posers that code only for the bleeding edge pan the old tricks.
do you get the point I am making?
Re:Digital Cams ? (Score:3, Informative)
PNG doesn't handle photographs well. The compression in PNG comes from the zlib compression library. It is based on detecting repetitive patterns. In a photograph there do not tend to be repetetive patterns, because of the nature of the scene being photographed, and because of noise in the camera's light detecting instrument, which tends to break up any patterns.
PNG has a set of predictive filters which can be applied to an image to attempt to increase the compression effectiveness. However, these are simplistic and are designed to be optimal for non-photographic images.
Looks to me like PNG would typically provide better image resolution for a similar filesize. Maybe I am wrong.
Yeah, wrong, but that's okay :-)
And also, is GIF an option now that it is free again?
No. GIF is an indexed-mode format, and only supports 8-bit palettes. In other words, a GIF can only have 256 colors. Nobody would ever want to store photographs in such a format.
Re:PNG and non-metric resolution? (Score:4, Informative)
See this portion [libpng.org] of the PNG spec. The image resolution is stored in the PNG file as an integer number of pixels per meter.
There are 39.3700787 inches in a meter. Thus, a 300 pixels-per-inch image is 11811.02361 pixels-per-meter. However, the PNG can only store an integer number of pixels per meter. Thus, 11811.02361 gets rounded to 11811.
Convert back to inches. What is 11811 / 39.3700787? Why, it's 299.9994 pixels-per-inch!
That's why 100 pixels per centimeter works perfectly. It's in metric.
Stop using this silly "inch" things, and your problem will vanish.
Re:PNG Software support (Score:4, Informative)
(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.
They didn't have to (Score:2, Informative)
I may owe you an apology... (Score:5, Informative)
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.)
Re:Answer to the inevitable PNG Slashbots (Score:3, Informative)
This is purely subjective, and FUD. On a modern CPU, with a modern graphics card, both GIF and PNG should take the same amount of time to "render." The process of rendering includes taking the data, decompressing it, and writing the pixels to the display device.
It's quite possible that some web browsers may have a very broken PNG rendering engine, but that's not a fault of the file format. PNG was designed to render progressively as it's downloaded, just like GIF. (I should know, I'm one of the specification co-authors for PNG.) PNG also has a much cooler interlacing scheme than GIF, which has made it a favorite for many set-top box developers (think next generation cable boxes).
Re:Did anyone really stop using gifs? (Score:4, Informative)
> this is precisely what PNG-8 is for?
Dude, that's what I'm _saying_. Many people don't realize that, and thus save their images with a higher palette than is necessary, and then complain that PNG doesn't compress as well as GIF. Photoshop doesn't tell you that when you save your file - you have to check the colour depth and change yourself. These same people also don't seem to use the post-creation compression tools to get the real compression benefit that can be had with PNG.
> At least 30% of the website icons I create are smaller as GIFs.
Are you compressing your PNGs with pngout or pngcrush? (pngout usually works much better) What kind of colour depth are we talking here?
Re:About time! (Score:1, Informative)
The patent has just expired worldwide (i think the last holdout was Canada). Now the tool can be distributed worldwide without the author being worried about being taken to court or being extorded for license fees.
*bzzzt* WRONG! (Score:2, Informative)
Re:Did anyone really stop using gifs? (Score:3, Informative)
Re:Did anyone really stop using gifs? (Score:1, Informative)
I realise I will get excommunicated by the
***INTERNET EXPLORER*** DISPLAYS BOTH IMAGES PERFECTLY TOO
(leastways, it does on my system - Windows XP, IE6.0.2800)