Hi Everyone, I'm interested in knowing when GIF support will be re-included into packages like PHP, ImageMagick and other image processing and generation tools. GIF, as you might know was covered by patents until the 20th of June 2004. The patents are now expired worldwide and gif code could be easily re-activated in libs like GD and PHP. It was always there, it was just not included into the packages because of the patent problems. So, are there any plans to include gif libs into any packages? It would be great if someone could give me some feedback on this.
Thanks,
Andres
On Sat, 26 Jun 2004 04:01, Andres Petralli apetralli@icu.unizh.ch wrote:
I'm interested in knowing when GIF support will be re-included into packages like PHP, ImageMagick and other image processing and generation tools. GIF, as you might know was covered by patents until the 20th of June 2004. The patents are now expired worldwide and gif code could be easily re-activated in libs like GD and PHP. It was
GIF is not suitable for photos (doesn't compress well at today's color depth). PNG makes a file of comparable size to GIF for generated graphics or other situations where you want non-lossy compression.
So what does GIF offer? In the past it offered compatibility with older software but that shouldn't be an issue now.
Adding it to specialised image processing tools may be good for compatibility, but is there a real need to add it to every program that supports writinga graphics file?
Hi Russell,
On 26.06.2004, at 08:29, Russell Coker wrote:
GIF is not suitable for photos (doesn't compress well at today's color depth). PNG makes a file of comparable size to GIF for generated graphics or other situations where you want non-lossy compression.
I know, but GIF is still the graphic format of choice when it comes to web graphics. This does not mean it is suitable for photos.
So what does GIF offer? In the past it offered compatibility with older software but that shouldn't be an issue now.
It is still an issue for web developers, believe me! Even though it has been technically surpassed by PNG, how many websites are using PNG instead of GIF? 1% or maybe rather 0.1%? There are not many...
Adding it to specialised image processing tools may be good for compatibility, but is there a real need to add it to every program that supports writinga graphics file?
No, not every program, but applications and libraries like GD, PHP and ImageMagick should be able to handle GIF. Also, as I wrote before, GIF support is not difficult to add. Simply dig out those removed code lines there have been before they were removed because of those patent issues.
Greets,
Andres
On Sat, 26 Jun 2004 19:30, Andres Petralli apetralli@icu.unizh.ch wrote:
So what does GIF offer? In the past it offered compatibility with older software but that shouldn't be an issue now.
It is still an issue for web developers, believe me! Even though it has been technically surpassed by PNG, how many websites are using PNG instead of GIF? 1% or maybe rather 0.1%? There are not many...
I checked two Squid logs for the number of hits matching "jpg", "png", and "gif":
GIF PNG JPG 57.3% 8.7% 34.1% 69.9% 1.4% 28.7%
Of course this is only a small sampling, and it didn't catch files with different names, host names matching strings (I used simple grep's), etc.
Not that it means much. Often people will just use the easiest format to get the job done, I inspected some of the .gif entries in my Squid logs and determined that some of them have not changes for years (some appeared to be over 5 years old). So I think that a large cause of the use of gifs on the web is the fact that they were created (or created with tools which were written) before the patent issue came about.
Adding it to specialised image processing tools may be good for compatibility, but is there a real need to add it to every program that supports writinga graphics file?
No, not every program, but applications and libraries like GD, PHP and ImageMagick should be able to handle GIF. Also, as I wrote before, GIF support is not difficult to add. Simply dig out those removed code lines there have been before they were removed because of those patent issues.
ImageMagick makes sense, it's good for tools like that to have as many options as possible.
But for PHP I can't see the point. What would adding GIF creation support give to a PHP user? When you use PHP you want to create a web page, does it matter to you whether the web page is comprised of .gif or .png files?
On Sat, 26 Jun 2004 21:24:37 +1000, Russell Coker russell@coker.com.au wrote:
But for PHP I can't see the point. What would adding GIF creation support give to a PHP user? When you use PHP you want to create a web page, does it matter to you whether the web page is comprised of .gif or .png files?
Just to give a quick example - I have a little content management system I wrote for one of my sites a while back. One of the things it _used_ to do was accept image uploads and just do a little cropping and resizing of images. Once GIF support went out the window, I dropped that functionality - could still do it with JPEG and PNG images, but I didn't want to have to tell users that they could only use that bit of the management tools with two out of the three main image types they'd likely be uploading.
To be honest, I think re-enabling GIF support in applications where it's easily done is a no-brainer.
Hi Russel,
On 26.06.2004, at 13:24, Russell Coker wrote:
On Sat, 26 Jun 2004 19:30, Andres Petralli apetralli@icu.unizh.ch wrote:
GIF PNG JPG 57.3% 8.7% 34.1% 69.9% 1.4% 28.7%
I'm sorry, but the numbers are completly irrelevant. The sampling is way too small to give a representative view of the general usage on the web. Mind that your squid proxy might serve people who are more tech savy than the people who use the web on a proxy like one of i.e. Aol and that those people visit more tech savy sites than others.
Not that it means much. Often people will just use the easiest format to get the job done, I inspected some of the .gif entries in my Squid logs and determined that some of them have not changes for years (some appeared to be over 5 years old). So I think that a large cause of the use of gifs on the web is the fact that they were created (or created with tools which were written) before the patent issue came about.
No, the point most web developers still choose gif over png is that they want compatibility with most browsers and handheld web devices. It's a fact that png is not or only partially (i.e. no alpha on IE) supported by certain browser, most relevantly by MSIE. It's also a fact that many web browsers on handheld devices or mobile phones only support jpeg, wbmp and maybe gif, but certainly not png. You can still tell those developers IE or any other browser is to blame, but they will not care because they have to deliver an impecable site to their customers without flaws on the most common web browser (95%+ IE on a non OSS related site). That's the main reason to choose gif over png.
ImageMagick makes sense, it's good for tools like that to have as many options as possible.
That's a must for ImageMagick to put it clear. For the netpbm package it would be too.
But for PHP I can't see the point. What would adding GIF creation support give to a PHP user? When you use PHP you want to create a web page, does it matter to you whether the web page is comprised of .gif or .png files?
PHP uses picture generation routines with support from the GD library. These routines are very popular in WCMS (web content management systems) for which php is a strong framework. For the reasons I have explained above I think it's crucial that PHP, while being a scripting language for the web and thus used in many CMS tools for dynamic picture creation of navigational elements and others, includes gif support. Actually, it's not php which needs to include it, it's the GD library used by php which needs it (and also had before version 1.4).
Sorry, but I think you are misguided by your technical view of the things. I agree that png would be supperior, but it's still the user (the web developer here) who dictates what he needs. I'm sure that there would be a huge demand for gif support especially in PHP applications! Also, I really don't want to argue with you wheter to use png or gif, my original question simply was, wheter those libraries for gif will be re-included into future packages.
Greets,
Andres
On Sat, 26 Jun 2004 17:38:32 +0200, Andres Petralli apetralli@icu.unizh.ch wrote:
It's also a fact that many web browsers on handheld devices or mobile phones only support jpeg, wbmp and maybe gif, but certainly not png.
Um, you may want to revise that "fact". The PalmOS browser can display PNGs (with transparency).
I did not say "all of them". Many != all, ok?
On 26.06.2004, at 17:53, Ben Steeves wrote:
It's also a fact that many web browsers on handheld devices or mobile phones only support jpeg, wbmp and maybe gif, but certainly not png.
Um, you may want to revise that "fact". The PalmOS browser can display PNGs (with transparency).
GIF is not suitable for photos (doesn't compress well at today's color depth). PNG makes a file of comparable size to GIF for generated graphics or other situations where you want non-lossy compression.
So what does GIF offer? In the past it offered compatibility with older software but that shouldn't be an issue now.
Adding it to specialised image processing tools may be good for compatibility, but is there a real need to add it to every program that supports writinga graphics file?
AFAIK, the latest Internet Explorer still doesn't support transparent PNGs. So, if you want to publish transparent pictures on your website, and have them look good for 90% of your audience, you still have to use GIFs.
Or is there another solution ?
On Sat, Jun 26, 2004 at 11:34:07AM +0200, Julien Olivier wrote:
GIF is not suitable for photos (doesn't compress well at today's color depth). PNG makes a file of comparable size to GIF for generated graphics or other situations where you want non-lossy compression.
So what does GIF offer? In the past it offered compatibility with older software but that shouldn't be an issue now.
Adding it to specialised image processing tools may be good for compatibility, but is there a real need to add it to every program that supports writinga graphics file?
AFAIK, the latest Internet Explorer still doesn't support transparent PNGs. So, if you want to publish transparent pictures on your website, and have them look good for 90% of your audience, you still have to use GIFs.
Or is there another solution ?
Yes, some workarounds for ie have been developed. (like http://redvip.homelinux.net/varios/explorer-png-en.html)
Check google. :)
Still, adding gif support to image manipulation libraries and programs could only bring benefits...
Regards, Luciano Rocha
On Saturday 26 June 2004 12:34, Julien Olivier wrote:
GIF is not suitable for photos (doesn't compress well at today's color depth). PNG makes a file of comparable size to GIF for generated graphics or other situations where you want non-lossy compression.
So what does GIF offer? In the past it offered compatibility with older software but that shouldn't be an issue now.
Adding it to specialised image processing tools may be good for compatibility, but is there a real need to add it to every program that supports writinga graphics file?
AFAIK, the latest Internet Explorer still doesn't support transparent PNGs. So, if you want to publish transparent pictures on your website, and have them look good for 90% of your audience, you still have to use GIFs.
Or is there another solution ?
You might want to look at "MSIE PNG Alpha Channel Fix" http://redvip.homelinux.net/varios/explorer-png-en.html and http://www.koivi.com/ie-png-transparency/ (this one uses php to convert pages and I don't like it as much). AFAIK MSIE for mac PCs does support this without ugly hacks. I hope mozilla and probably IE will have full mng/jng support some day...
Russell Coker wrote:
On Sat, 26 Jun 2004 04:01, Andres Petralli apetralli@icu.unizh.ch wrote:
I'm interested in knowing when GIF support will be re-included into packages like PHP, ImageMagick and other image processing and generation tools. GIF, as you might know was covered by patents until the 20th of June 2004. The patents are now expired worldwide and gif code could be easily re-activated in libs like GD and PHP. It was
GIF is not suitable for photos (doesn't compress well at today's color depth). PNG makes a file of comparable size to GIF for generated graphics or other situations where you want non-lossy compression.
So what does GIF offer? In the past it offered compatibility with older software but that shouldn't be an issue now.
Adding it to specialised image processing tools may be good for compatibility, but is there a real need to add it to every program that supports writinga graphics file?
If the upstream version of the software supports GIF and that support was disabled by Redhat, then there is no reason not to reenable that support. He's not talking about adding support where it didn't pre-exist upstream in the first place.
-- Brian Gerst
devel@lists.stg.fedoraproject.org
-
Andres Petralli -
Ben Steeves -
Brian Gerst -
Doncho N. Gunchev -
Julien Olivier -
Luciano Miguel Ferreira Rocha -
Mike Barnes -
Rui Miguel Silva Seabra -
Russell Coker