1:01 p.m.
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
--
Andres Petralli
In der Wässeri 43
CH-8047 Zürich
andres(a)petralli.com, +41 43 3218066, +41 78 8353537
ICQ: 4685081, MSN: apetralli(a)msn.com, FAX: +41 43 5349810
1:29 a.m.
On Sat, 26 Jun 2004 04:01, Andres Petralli <apetralli(a)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?
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
4:30 a.m.
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
6:24 a.m.
On Sat, 26 Jun 2004 19:30, Andres Petralli <apetralli(a)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?
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
6:52 a.m.
On Sat, 26 Jun 2004 21:24:37 +1000, Russell Coker <russell(a)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.
10:38 a.m.
Hi Russel,
On 26.06.2004, at 13:24, Russell Coker wrote:
On Sat, 26 Jun 2004 19:30, Andres Petralli
<apetralli(a)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
10:53 a.m.
On Sat, 26 Jun 2004 17:38:32 +0200, Andres Petralli
<apetralli(a)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).
--
Ben Steeves
ben.steeves(a)gmail.com
GPG ID: 0xB3EBF1D9
http://www.metacon.ca/
11 a.m.
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).
4:34 a.m.
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 ?
--
Julien Olivier <julo(a)altern.org>
5:58 a.m.
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
7:15 a.m.
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...
--
Regards,
Doncho N. Gunchev Registered Linux User #291323 at counter.li.org
GPG-Key-ID: 1024D/DA454F79
Key fingerprint = 684F 688B C508 C609 0371 5E0F A089 CB15 DA45 4F79
9:18 a.m.
Russell Coker wrote:
On Sat, 26 Jun 2004 04:01, Andres Petralli
<apetralli(a)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
7233
days inactive
7239
days old
12 comments
9 participants
participants (9)
-
Andres Petralli -
Ben Steeves -
Brian Gerst -
Doncho N. Gunchev -
Julien Olivier -
Luciano Miguel Ferreira Rocha -
Mike Barnes -
Rui Miguel Silva Seabra -
Russell Coker