Today is "burn all gifs day", how about removing gif support from Tk?
Mo
In case you don't already know, today (Fri Nov 5)
is "Burn all gifs day" (see http://burnallgifs.org).
Unisys is willing to sue you for simply using gifs
on your web pages or in your programs. Tcl/Tk
includes .GIF support which means using a GIF
in Tcl/Tk could open you up to legal liability.
How about we remove all .GIF support from Tcl
and replace it with .PNG. PNG is a much better
format for many reasons, including the fact that
it is not patent protected like .GIF.
What do you think?
Mo DeJong
Thomas Andrews
>Hi all.
>
>In case you don't already know, today (Fri Nov 5)
>is "Burn all gifs day" (see http://burnallgifs.org).
>Unisys is willing to sue you for simply using gifs
>on your web pages or in your programs. Tcl/Tk
>includes .GIF support which means using a GIF
>in Tcl/Tk could open you up to legal liability.
>
The only part of GIF which Unisys claims is the compression algorithm,
so any uncompress and display algorithms are okay.
Basically, as long as you are not writing GIFs you are okay.
--
Thomas Andrews tho...@best.com http://www.best.com/~thomaso/
Brian V. Smith
|> The only part of GIF which Unisys claims is the compression algorithm,
|> so any uncompress and display algorithms are okay.
|>
|> Basically, as long as you are not writing GIFs you are okay.
Bzzt! Wrong!
Read the Unisys license information about GIF:
(http://corp2.unisys.com/LeadStory//lzwfaq.html)
The first sentence says:
"More and more people are becoming aware that the reading and/or writing of
GIF images requires a license to use Unisys patented Lempel Ziv Welch
(LZW) data compression and decompression technology, including United
...
Notice that it says *reading* in addition to writing GIF images.
--
--------------------------------------------------------
Brian V. Smith (bvs...@lbl.gov) http://www-epb.lbl.gov/BVSmith
Lawrence Berkeley National Laboratory
I don't speak for LBL; they don't pay me enough for that.
Check out the xfig site at http://www-epb.lbl.gov/xfig
To the optimist, the glass is half full. To the pessimist, the
glass is half empty. To the engineer, the glass is twice as big
as it needs to be.
Jeffrey Hobbs
>
> In article <38232e20$0$2...@nntp1.ba.best.com>, tho...@best.com (Thomas Andrews) writes:
>
> |> The only part of GIF which Unisys claims is the compression algorithm,
> |> so any uncompress and display algorithms are okay.
> |>
> |> Basically, as long as you are not writing GIFs you are okay.
>
> Bzzt! Wrong!
>
> Read the Unisys license information about GIF:
>
> (http://corp2.unisys.com/LeadStory//lzwfaq.html)
>
> The first sentence says:
>
> "More and more people are becoming aware that the reading and/or writing of
> GIF images requires a license to use Unisys patented Lempel Ziv Welch
> (LZW) data compression and decompression technology, including United
> ...
>
> Notice that it says *reading* in addition to writing GIF images.
It was also pointed out in a long thread that if the GIF was written
with any software that paid Unisys for the patent, it was OK. Tk
doesn't have GIF writing capability, so you can't go wrong there, and
the few it has in the archive were all created with "OK" software.
It is also possible to create GIFs with a different runtime encoding
that somehow is not LZW, but works nearly the same. For the nuances
of this, you'll have to go back in the newsgroup.
I actually asked Jan about this point, wondering whether it was
possible to have GIF written without use of LZW, but I haven't heard
back yet. We don't have PNG support in the core, and aren't likely
to include it to prevent code bloat (although it should be soon
available in brain dead binary form).
--
Jeffrey Hobbs The Tcl Guy
jeffrey.hobbs at scriptics.com Scriptics Corp.
Donal K. Fellows
<env...@epb1.lbl.gov> writes
>In article <38232e20$0$2...@nntp1.ba.best.com>, tho...@best.com (Thomas Andrews)
>writes:
>|> The only part of GIF which Unisys claims is the compression algorithm,
>|> so any uncompress and display algorithms are okay.
>|>
>|> Basically, as long as you are not writing GIFs you are okay.
>
>Bzzt! Wrong!
>
>Read the Unisys license information about GIF:
>
>(http://corp2.unisys.com/LeadStory//lzwfaq.html)
>
Two points:
1: Do they really have the patent to back it up (i.e. please quote the
relevant patent number,) or are they trying to get licenses for
technology they don't in fact control? And does that patent apply
outside the US? The USPO has a long and illustrious history </sarcasm>
of granting over-wide patents for software, and if it doesn't apply
anyway, I fail to see why I should be penalised for what would be a
purely US Domestic problem...
2: On a completely separate note, how do you propose to deal with:
a) the large number of existing Tk installations that already have a
GIF reading algorithm (including all the installations of the Tcl
plugin), and
b) the large number of GIF images that form part of existing
applications and where simply ripping out GIF support would lead to
a great many "customer" moans!
3: Does anyone think that Unisys are going to bill anyone in the Tcl
community on this matter before 2003 anyway?
Donal (yes, I am sometimes a resident wet blanket...)
--
Donal K. Fellows (at home)
--
FOOLED you! Absorb EGO SHATTERING impulse rays, polyester poltroon!!
Chang LI
I remember the GIF patent is only apply to write a GIF format and
not to read a GIF format. So it is only for encode not decode.
Am I wrong?
lvi...@cas.org
According to Brian V. Smith <env...@epb1.lbl.gov>:
:Notice that it says *reading* in addition to writing GIF images.
Actually, the latest stuff on the Unisys site refers to the fact that if
you store even one GIF on your web site it needs to have be created by software
which was licensed to use the LZW algorithm or you have to pay a $5000 license
fee.
PLEASE Scriptics - let's move GIF code out of Tk and move in support for
PNG and MNG (does Img support MNG yet? If not, that's something that
probably should be addressed).
--
<URL: mailto:lvi...@cas.org> Quote: Pikachu, I choose you!
<*> O- <URL: http://www.purl.org/NET/lvirden/>
Unless explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.
Chengye Mao
env...@epb1.lbl.gov (Brian V. Smith) wrote:
> In article <38232e20$0$2...@nntp1.ba.best.com>, tho...@best.com
(Thomas Andrews) writes:
>
> |> The only part of GIF which Unisys claims is the compression
algorithm,
> |> so any uncompress and display algorithms are okay.
> |>
> |> Basically, as long as you are not writing GIFs you are okay.
>
> Bzzt! Wrong!
>
> Read the Unisys license information about GIF:
>
> (http://corp2.unisys.com/LeadStory//lzwfaq.html)
>
>
> "More and more people are becoming aware that the reading and/or
writing of
> GIF images requires a license to use Unisys patented Lempel Ziv Welch
> (LZW) data compression and decompression technology, including United
> ...
>
>
> --------------------------------------------------------
> Brian V. Smith (bvs...@lbl.gov) http://www-epb.lbl.gov/BVSmith
> Lawrence Berkeley National Laboratory
> I don't speak for LBL; they don't pay me enough for that.
> Check out the xfig site at http://www-epb.lbl.gov/xfig
>
> To the optimist, the glass is half full. To the pessimist, the
> glass is half empty. To the engineer, the glass is twice as big
> as it needs to be.
>
Could we solve this problem once and ever by donating the required
$5000 to Scriptics? How many Tcl users/developers are there?
How about donating $5 or $10 from each?
GIF is a popular image format and should not be abandoned by TclTk.
I propose to call a donation in Tcl Comnunity to solve this problem.
--
http://www.geocities.com/~chengye
Sent via Deja.com http://www.deja.com/
Before you buy.
Jonathan Guyer
<che...@bellsouth.net> wrote:
> Could we solve this problem once and ever by donating the required
> $5000 to Scriptics? How many Tcl users/developers are there?
> How about donating $5 or $10 from each?
It wouldn't cost _that_ much more to have the entire corporate "leadership"
of Unisys... um... "disappeared". And it would be _so_ much more
satisfying.
--
Jonathan E. Guyer
Jan Nijtmans
> does Img support MNG yet?
No, it doesn't. But libpng-1.0.5 has a new function which
should allow it to be used with MNG as well, so it indeed
shouldn't be too difficult to implement it. Anyone
interested to help?
--
Jan Nijtmans, CMG Arnhem B.V.
email: j.nij...@chello.nl (private)
jan.ni...@cmg.nl (work)
url: http://purl.oclc.org/net/nijtmans/
Jan Nijtmans
> Actually, the latest stuff on the Unisys site refers to the fact that if
> you store even one GIF on your web site it needs to have be created by software
> which was licensed to use the LZW algorithm or you have to pay a $5000 license
> fee.
The solution is easy: just (re-)create the (pseudo-)GIF file with
Img, and distribute the new file. It's bigger than before, but
doesn't violate any patents. That's what I did with Img itself,
even though in Europe software algorithms such as LZW cannot
even be patented.
Regards,
Slaven Rezic
>
>
> According to Brian V. Smith <env...@epb1.lbl.gov>:
> :Notice that it says *reading* in addition to writing GIF images.
>
> Actually, the latest stuff on the Unisys site refers to the fact that if
> you store even one GIF on your web site it needs to have be created by software
> which was licensed to use the LZW algorithm or you have to pay a $5000 license
> fee.
Is this really true for gifs using run length encoding?
>
> PLEASE Scriptics - let's move GIF code out of Tk and move in support for
> PNG and MNG (does Img support MNG yet? If not, that's something that
> probably should be addressed).
>
The gif code is important --- I think too many scripts depend on this.
Regards,
Slaven
--
use Tk;$c=tkinit->Canvas(-he,20)->grid;$x=5;map{s/\n//g;map{$c->create('line'=>
map{$a=-43+ord;($x+($a>>3)*2=>5+($a&7)*2)}split//)}split/!/;$x+=12}split/_/=>'K
PI1_+09IPK_K;-OA1_+K!;A__1;Q!7G_1+QK_3CLPI90,_+K!;A_+1!KQ!.N_K+1Q!.F_1+KN.Q__1+
KN._K+1Q!.F_1+KN.Q_+1Q__+1!KQ!.N_1;Q!7G_K3,09Q_+1!K.Q_K+1Q!.F_1+KN.Q_';MainLoop
Jeffrey Hobbs
> Could we solve this problem once and ever by donating the required
> $5000 to Scriptics? How many Tcl users/developers are there?
> How about donating $5 or $10 from each?
>
The last sentence definitely is a key point. GIF reading support
cannot be abandoned, as that would be a MAJOR backwards incompatibility
issue. However, I'm working with Jan Nijtmans to see if we can get
true RLE support for writing of GIFs, which would be patent free.
I'm not sure what the issue is with reading and the current state of
GIF support in Tk with regards to the patents. I won't make any
public statements from a Scriptics account on Unisys and GIF, but
************* [censored] *********** [bleep] ***********.
Adding support for PNG is a nice idea, but further large scale Tk
code bloat isn't. I haven't even heard of MNG...
Iain B. Findleton
>
> Hi all.
>
> In case you don't already know, today (Fri Nov 5)
> is "Burn all gifs day" (see http://burnallgifs.org).
> Unisys is willing to sue you for simply using gifs
> on your web pages or in your programs. Tcl/Tk
> includes .GIF support which means using a GIF
> in Tcl/Tk could open you up to legal liability.
>
> and replace it with .PNG. PNG is a much better
> format for many reasons, including the fact that
> it is not patent protected like .GIF.
>
> What do you think?
> Mo DeJong
I remember looking into this when it first became an issue in the early
90s. The Welsh (W in LZW) patent is an improvement to the LZ algorithm,
which itself is a trick form of RLE. As I recall, the GIF format for the
file is a Compuserv copyright, and is independant of the LZW issue. I
think that Compuserv is now someone else, and I don't know what that
corporate entity is now saying.
So...
RLE -> Compression
LZ -> Better compression
LZW -> Slightly more better compression
but
JPG -> Much better compression
so I dumped GIF nearly a decade ago.
I do think, however, that much of the problem associated with dumping
gifs is the ".GIF" extension, which directs a lot of software to a LZW
decoder. I would suspect that the file format can be seperated from the
compression scheme, something that I would be surprised if the lawyers
failed to achieve early on in any legal battle. Once that happens, then
I would think the problem will disappear by just changing to some
ppublic domain compressor. Back at the dawn of the decade, people were
pandering LZH (H = Huffman), but I never say that go anywhere visible,
even although gaggles of code to do it was made available.
So, perhaps the goal should be to save the file format (The Compuserv
layout and features) while removing at least the W from the compression
algorithm.
As to the "read versus write" issue, the decoder is as much the LZW
algorithm as is the encoder, so I would tend to discredit any claims
that only the encoder is covered by the patent. Unisys might turn a
blind eye to the decoders, but that has to be a marketing strategy. A
lawyer would, I am certain, not grant the distinction.
--
Iain B. Findleton
http://pages.infinit.net/cclients
custom...@videotron.ca
(514)457-0744
lvi...@cas.org
According to Chang LI <cha...@neatware.com>:
:I remember the GIF patent is only apply to write a GIF format and
:not to read a GIF format. So it is only for encode not decode.
:Am I wrong?
Yes, you are wrong.
There is no "GIF patent" - there is a compression algorithm. Any software
which uses that LZW algorithm is expected to license the algorithm.
D. Richard Hipp
>
> Chengye Mao wrote:
> >
> > GIF is a popular image format and should not be abandoned by TclTk.
>
> The last sentence definitely is a key point. GIF reading support
> cannot be abandoned, as that would be a MAJOR backwards incompatibility
> issue.
Agreed. You can't abandon GIF support. But it would be nice
to have a configure option (--disable-gif) that would omit
the GIF code. That would make it much easier for people who
don't want to risk picking a fight with Unisys.
--
D. Richard Hipp -- d...@acm.org -- http://www.hwaci.com/drh/
Paul Duffin
>
> Could we solve this problem once and ever by donating the required
> $5000 to Scriptics? How many Tcl users/developers are there?
> How about donating $5 or $10 from each?
>
>
If I had $5000 to spare I would not donate it because I do not believe
that Unisys deserve it. Even so the $5000 figure only covers the use
of GIFs on websites which have not been created with a licensed
application. It does not cover the use of the decompression algorithm
in Tk itself. Unisys would probably charge Scriptics a lot more than
$5000 and would probably require some royalty on each copy they ship.
Unisys may also require the user of Tk to pay them too.
Having said that it is up to Unisys to prove that the GIF that you are
using does use LZW compression and also has not been produced with a
licensed application. Depending on whether licensed applications have to
mark the GIF with some special watermark, either application name, or
some check sum generated in an application specific manner, this task
would either be very hard or very trivial.
It would be relatively trivial for Scriptics to convert their GIF files
from LZW compressed to RLE compressed. In fact it would be cheaper to
buy a new disk drive (if they needed) to handle the increased storage
than it would be for them to pay Unisys.
--
Paul Duffin
DT/6000 Development Email: pdu...@hursley.ibm.com
IBM UK Laboratories Ltd., Hursley Park nr. Winchester
Internal: 7-246880 International: +44 1962-816880
Paul Duffin
>
> In article <7vvc86$9s...@overload.lbl.gov>, Brian V. Smith
> <env...@epb1.lbl.gov> writes
> >writes:
> >|> The only part of GIF which Unisys claims is the compression algorithm,
> >|> so any uncompress and display algorithms are okay.
> >|>
> >|> Basically, as long as you are not writing GIFs you are okay.
> >
> >Bzzt! Wrong!
> >
> >Read the Unisys license information about GIF:
> >
> >(http://corp2.unisys.com/LeadStory//lzwfaq.html)
> >
>
>
> 1: Do they really have the patent to back it up (i.e. please quote the
> relevant patent number,) or are they trying to get licenses for
I am farely sure that they do have the US patent on LZW compression. If
they didn't someone would have shouted by now.
> technology they don't in fact control? And does that patent apply
> outside the US? The USPO has a long and illustrious history </sarcasm>
> of granting over-wide patents for software, and if it doesn't apply
> anyway, I fail to see why I should be penalised for what would be a
> purely US Domestic problem...
As far as I know it does not apply in Europe, and apparently IBM also
have a US patent for LZW compression which was granted by the USPO after
(not sure how much) the Unisys one was granted.
>
> 2: On a completely separate note, how do you propose to deal with:
> a) the large number of existing Tk installations that already have a
> GIF reading algorithm (including all the installations of the Tcl
> plugin), and
> b) the large number of GIF images that form part of existing
> applications and where simply ripping out GIF support would lead to
> a great many "customer" moans!
>
> 3: Does anyone think that Unisys are going to bill anyone in the Tcl
> community on this matter before 2003 anyway?
>
As far as I know Unisys have not bothered too much about the reading
of GIFs, they have concentrated on the distributors (web sites) of GIFs.
The one thing that Unisys could do to ensure that GIFs (or at least LZW
compressed ones) were killed as fast as possible would be to start
charging applications which read GIFs (web browsers) a fee. This would
in my opinion encourage web browser vendors to work with web sites to
move to other better formats such as PNG and discard all GIFs.
As soon as web browsers have good support for PNG web sites will move
away from GIFs (apart from a couple which say where to get the latest
versions of various browsers from) to PNG very quickly. The harder
Unisys push the faster this will happen.
laurent....@cgi.ca
>
> lvi...@cas.org wrote:
>> does Img support MNG yet?
>
> No, it doesn't. But libpng-1.0.5 has a new function which
> should allow it to be used with MNG as well, so it indeed
> shouldn't be too difficult to implement it. Anyone
> interested to help?
>
What's MNG? Web page?
L
--
Penguin Power! Nothing I say reflects the views of my employer
Laurent Duperval mailto:laurent....@cgi.ca
CGI - FWFM Project Phone: (514) 350-3368
Art Haas
> On 6 Nov, Jan Nijtmans wrote:
> >
> > lvi...@cas.org wrote:
> >> does Img support MNG yet?
> >
> > No, it doesn't. But libpng-1.0.5 has a new function which
> > should allow it to be used with MNG as well, so it indeed
> > shouldn't be too difficult to implement it. Anyone
> > interested to help?
> >
>
> What's MNG? Web page?
>
There is a link to this page from the PNG page as well. For
those needing that page ...
--
###############################
# Art Haas
# (713) 689-2417
###############################
lvi...@cas.org
According to Paul Duffin <pdu...@mailserver.hursley.ibm.com>:
:application. It does not cover the use of the decompression algorithm
:in Tk itself. Unisys would probably charge Scriptics a lot more than
:$5000 and would probably require some royalty on each copy they ship.
:Unisys may also require the user of Tk to pay them too.
Agreed
:Having said that it is up to Unisys to prove that the GIF that you are
:using does use LZW compression and also has not been produced with a
:licensed application. Depending on whether licensed applications have to
Unfortunately, it would still require time and effort on someone to
'cooperate' with Unisys in the discovery process - probably resulting in
more time lost than paying them the license fee. Which is, I suspect,
the entire purpose...
:It would be relatively trivial for Scriptics to convert their GIF files
:from LZW compressed to RLE compressed. In fact it would be cheaper to
:buy a new disk drive (if they needed) to handle the increased storage
:than it would be for them to pay Unisys.
But it would be even almost as trivial to just plug in the existing PNG
support that Img already has, deprecate the GIF support, and convert the
images to PNG. That way there is no concern about future issues. This
thing with Unisys can only get worse before it gets better.
Gawain Lavers
> JPG -> Much better compression
>
> so I dumped GIF nearly a decade ago.
Correct me if I'm wrong (because I spout this all the time) but I
believe that jpegs are "lossy" compression, which means the pixels you
compress won't be exactly the pixels you decompress, which is
unacceptible/inconvenient in certain circumstances. Also, I'm not aware
of being able to make transparent pixels with jpegs.
I'm intrigued by PNG's though.
Gawain Lavers
>
> > Could we solve this problem once and ever by donating the required
> > $5000 to Scriptics? How many Tcl users/developers are there?
> > How about donating $5 or $10 from each?
>
> of Unisys... um... "disappeared". And it would be _so_ much more
> satisfying.
>
> --
> Jonathan E. Guyer
>
> <http://www.his.com/~jguyer/>
Where do I send my $5?
Darren New
>
> Iain B. Findleton wrote:
> > JPG -> Much better compression
> >
> > so I dumped GIF nearly a decade ago.
>
> Correct me if I'm wrong (because I spout this all the time) but I
> believe that jpegs are "lossy" compression,
Well, JPEG is for photograhs. (Joint Photograph Expert Group, see.) GIFs
compress line art much better than JPEG does. JPEG compresses photographs
much better than GIFs. If you take a photograph and turn it into a GIF,
you'll get much worse results lossiness-wise because you have to pick out
256 colors to start with. JPEG is designed to lose information that you
don't visually notice being lost anyway.
GIF and JPEG are both lossy for anything with true colors to start with.
Stuff with smooth gradients (like photos) will do much better with JPEG.
--
Darren New / Senior Software Architect / MessageMedia, Inc.
San Diego, CA, USA (PST). Cryptokeys on demand.
Java leads to JavaScript,
JavaScript leads to Flash,
Flash leads to ... Suffering.
Pascal Bouvier
>
> According to Chang LI <cha...@neatware.com>:
> :I remember the GIF patent is only apply to write a GIF format and
> :not to read a GIF format. So it is only for encode not decode.
> :Am I wrong?
>
> Yes, you are wrong.
> There is no "GIF patent" - there is a compression algorithm. Any software
> which uses that LZW algorithm is expected to license the algorithm.
Does someone know about GNU utilities gzip/gunzip ?
(I believe I've read GNU has its own enhanced version of LZH)
--
Pascal
Donal K. Fellows
> According to Chang LI <cha...@neatware.com>:
>: I remember the GIF patent is only apply to write a GIF format and
>: not to read a GIF format. So it is only for encode not decode.
>: Am I wrong?
>
> Yes, you are wrong. There is no "GIF patent" - there is a
> compression algorithm. Any software which uses that LZW algorithm
> is expected to license the algorithm.
So Tk doesn't need a license since it doesn't include the compression
algorithm. A suitable decompression algorithm is important though,
since there are many existing GIFs that it would be a good idea to
continue to support, and there are also jurisdictions where the LZW
algorithm is *not* under patent anyway (algorithms are not patentable
in Europe so far as I'm aware, much to the irritation of the likes of
Unisys...)
Donal.
--
Donal K. Fellows http://www.cs.man.ac.uk/~fellowsd/ fell...@cs.man.ac.uk
-- The small advantage of not having California being part of my country would
be overweighed by having California as a heavily-armed rabid weasel on our
borders. -- David Parsons <o r c @ p e l l . p o r t l a n d . o r . u s>
Robin Becker
...
>So Tk doesn't need a license since it doesn't include the compression
>algorithm. A suitable decompression algorithm is important though,
>since there are many existing GIFs that it would be a good idea to
>continue to support, and there are also jurisdictions where the LZW
>algorithm is *not* under patent anyway (algorithms are not patentable
>in Europe so far as I'm aware, much to the irritation of the likes of
>Unisys...)
>
>Donal.
Fixed period software license keys were also declared illegal in the EU,
but that doesn't mean that US companies don't use them. I'm not a
lawyer, but the US has declared that it will enforce at least some laws
anywhere in the world. I don't think Unisys can get the USN to bring a
cruise missile to bear, but who knows.
--
Robin Becker
lvi...@cas.org
According to Donal K. Fellows <fell...@cs.man.ac.uk>:
:So Tk doesn't need a license since it doesn't include the compression
:algorithm. A suitable decompression algorithm is important though,
Here's the scoop from Unisys:
<URL: http://www.unisys.com/unisys/lzw/>
License Information on GIF and Other
LZW-based Technologies
More and more people are becoming aware that
the reading and/or writing of GIF images requires
a license to use Unisys patented Lempel Ziv
Welch (LZW) data compression and
decompression technology, including United
States Patent No. 4,558,302, Japanese Patent
Numbers 2,123,602 and 2,610,084, and patents in
Canada, France, Germany, Italy and the United
Kingdom. Since January of 1995, Unisys has
entered into almost two thousand license
agreements for use of GIF and other LZW-based
technology.
followed by lots more verbage covering the various topics...
Note that they DO have european patents apparently...
Iain B. Findleton
>
> Gawain Lavers wrote:
> >
> Well, JPEG is for photograhs. (Joint Photograph Expert Group, see.) GIFs
> compress line art much better than JPEG does. JPEG compresses photographs
> much better than GIFs. If you take a photograph and turn it into a GIF,
> you'll get much worse results lossiness-wise because you have to pick out
> 256 colors to start with. JPEG is designed to lose information that you
> don't visually notice being lost anyway.
>
> GIF and JPEG are both lossy for anything with true colors to start with.
> Stuff with smooth gradients (like photos) will do much better with JPEG.
Good point. Actually, with the move to 32 MB video cards into the < $100
range, along with "standard" IDE disks of > 20GB, I sort of wonder who
is even worrying about compression. Once you see non-indexed format
images, you don't want to go back.
As for "line art", there is always G3 Fax or G4 if you decide that
quality and lossless compression are needed.
Andreas Kupries
Pascal Bouvier <pas...@prologianet.univ-mrs.fr> writes:
> lvi...@cas.org wrote:
> > Yes, you are wrong.
> > There is no "GIF patent" - there is a compression algorithm. Any software
> > which uses that LZW algorithm is expected to license the algorithm.
> Does someone know about GNU utilities gzip/gunzip ? (I believe I've
> read GNU has its own enhanced version of LZH)
Either the documentation or the web site to gzip/zlib states that a
patent-free algorithm is used. 'algorithm.txt' explains it.
--
Sincerely,
Andreas Kupries <a.ku...@westend.com>
<http://www.purl.org/NET/akupries/>
-------------------------------------------------------------------------------
Jeffrey Hobbs
> Good point. Actually, with the move to 32 MB video cards into the < $100
> range, along with "standard" IDE disks of > 20GB, I sort of wonder who
> is even worrying about compression. Once you see non-indexed format
I don't think it's the local space anymore, it's the bandwidth it
takes up. This is still a big issue. For one, many are still hung
at the end of 56K or worse lines. More importantly, if everyone
just went and dumped compression, the extra clog on the net would
be *quite* significant.
Paul Duffin
>
> lvi...@cas.org wrote:
> >
> > According to Chang LI <cha...@neatware.com>:
> > :I remember the GIF patent is only apply to write a GIF format and
> > :not to read a GIF format. So it is only for encode not decode.
> > :Am I wrong?
> >
> > There is no "GIF patent" - there is a compression algorithm. Any software
> > which uses that LZW algorithm is expected to license the algorithm.
>
> Does someone know about GNU utilities gzip/gunzip ?
> (I believe I've read GNU has its own enhanced version of LZH)
>
See http://graphicswiz.com/png/pnghist.html for details on history of LZW.
I believe that gzip / gunzip use a variant of LZ77 / LZ78 which actually
does a better job of compression than LZW but is slower.
Alexandre Ferrieux
>
> More importantly, if everyone
> just went and dumped compression, the extra clog on the net would
> be *quite* significant.
Not necessarily so. Run-length plus entropy (ie FAX), or LZW, are both
pretty suboptimal for 'line art' which could be transmitted in its
native form, ie as vector graphics. The fact that no vector graphics
format has populated the Web as HTML/GIF/JPG has, is unfortunate.
In other words, I wish Unisys had claimed its IPR sooner: this way
LZW-GIF would have died quickly, and something would have filled the
gap. Of course it would have been suboptimal for Unisys...
-Alex
Andreas Kupries
> > More importantly, if everyone
> > just went and dumped compression, the extra clog on the net would
> > be *quite* significant.
> Not necessarily so. Run-length plus entropy (ie FAX), or LZW, are
> both pretty suboptimal for 'line art' which could be transmitted in
> its native form, ie as vector graphics. The fact that no vector
> graphics format has populated the Web as HTML/GIF/JPG has, is
> unfortunate.
I remember faintly that there are some XML based proposals for a
vector format flying around at the W3C.
Akos Polster
>
> Alexandre Ferrieux <alexandre...@cnet.francetelecom.fr> writes:
>
> > Jeffrey Hobbs wrote:
>
> > > More importantly, if everyone
> > > just went and dumped compression, the extra clog on the net would
> > > be *quite* significant.
>
> > Not necessarily so. Run-length plus entropy (ie FAX), or LZW, are
> > both pretty suboptimal for 'line art' which could be transmitted in
> > its native form, ie as vector graphics. The fact that no vector
> > graphics format has populated the Web as HTML/GIF/JPG has, is
> > unfortunate.
>
> I remember faintly that there are some XML based proposals for a
> vector format flying around at the W3C.
and don't forget the Plugin! It's a perfect medium to
transmit vector graphics ;-)
- Akos.
--
Akos Polster
Nokia Networks, Tampere, Finland
Extra Credit: Define the universe. Give three examples.
Brian V. Smith
|> lvi...@cas.org writes:
|> > According to Brian V. Smith <env...@epb1.lbl.gov>:
|> > :Notice that it says *reading* in addition to writing GIF images.
|> >
|> > Actually, the latest stuff on the Unisys site refers to the fact that if
|> > you store even one GIF on your web site it needs to have be created by software
|> > which was licensed to use the LZW algorithm or you have to pay a $5000 license
|> > fee.
|>
|> Is this really true for gifs using run length encoding?
No, the whole issue is based on the LZW part.
But, my gripe is that, even though it is true that one can create GIFs using run length
encoding, if you want to provide a GIF *reader* to read *existing LZW GIFs* (aka 99.9%
of most images in the world), that you have to pay royalties to Unisys.
--
--------------------------------------------------------
Brian V. Smith (bvs...@lbl.gov) http://www-epb.lbl.gov/BVSmith
Lawrence Berkeley National Laboratory
I don't speak for LBL; they don't pay me enough for that.
Check out the xfig site at http://www-epb.lbl.gov/xfig
To the optimist, the glass is half full. To the pessimist, the
glass is half empty. To the engineer, the glass is twice as big
as it needs to be.