Okay, so what the heck *are* people using in commercial embbedded systems
instead of GIF, when they need transparency control and the code
distributions for PNG and MIFF are too unwieldy?
Mike Hardwick
Decade Engineering
>Unisys owns the patent on LZW and specifically permits the use of the LZW
>in the GIF compressors and decompressors for non-commercial use only.
>Commercial use requires a license. This causes many Open Source fans to
>avoid GIF at any cost and many other people to avoid it too. It is not
>clear whether a schematic published in a public forum in GIF format can be
>'commercial use', even if it is posted by a registered firm.
It is my understanding that if the programs that produce and display the GIF
(Photoshop, for example) has the proper license from Unisys (or are
non-commercial?) then the GIF itself it freely distributable.
However, IANAL
Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)
This is correct. It is the algorithm that is patented (and therefore any
implementation of it) not the end result. Files produced using the method
are fine. Programs that _implement_ the algorithm for coding or decoding
must have the license.
Marc Reinig
System Solutions
(A registered GIF developer when there was a Compuserve)
But wouldn't any embedded system inherently have to contain the
decoding/display algo if it used GIFs?
Sean
At 06:17 AM 10/16/01 -0700, you wrote:
>This is correct. It is the algorithm that is patented (and therefore any
>implementation of it) not the end result. Files produced using the method
>are fine. Programs that _implement_ the algorithm for coding or decoding
>must have the license.
>
>Marc Reinig
>System Solutions
>(A registered GIF developer when there was a Compuserve)
It would depend on whether the system was encoding or decoding or just
storing or sending, i.e. an embedded web site that had stored images that it
sent as part of an html page would not. However, if it created the GIF's,
then it would. Likewise, if it decoded a GIF, then it would. However, if
it passed on the GIF to something else that incorporated a legal GIF decoder
then it wouldn't.
Exactimo. The embedded system I'm developing has to *display* images, which
means that it must decode the files. If they are GIFs, then my system has
to use the LZW algorithm. The best deal we could negotiate with Unisys
involved a large advance payment. We decided to make a custom file format,
but I would rather use a standard. Whatever we use, it has to support
transparency because the system uses images for video overlay. MIFF and PNG
were the best candidates I found, but their code distributions are too
massive to be useful. Any ideas?
Mike Hardwick
Decade Engineering
>It would depend on whether the system was encoding or decoding or just
>storing or sending, i.e. an embedded web site that had stored images that it
>sent as part of an html page would not. However, if it created the GIF's,
>then it would. Likewise, if it decoded a GIF, then it would. However, if
>it passed on the GIF to something else that incorporated a legal GIF decoder
>then it wouldn't.
I haven't looked at the PNG code in a while, but I suspect that if all you
want is a GIF replacement then you just need to implement a subset of the
PNG code. It shouldn't really be much larger than GIF if at all.
I don't know how it is packaged these days, but if all you really want is an
8- bit indexed palette and transparency, a subset would do it.
Try looking at the PCX format. It uses a form of RLE compression and has fairly
good results on non-photgraphic images. By that I mean images with large areas
of solid colors compress very well. Images with lots of "noise", such as photographic
images tend not to compress as well. In the past I used PCX images and designated
one of the color values as trasparent in my drawing routines.
The code for PCX decoding can be very small and uses very little ram. Likewise
it can also be very fast.
Good Luck!
Oh, yah,,,, try looking for information on the LZ compression algorythm. It is the
pre-cursor to LZW and is not protected, AFAIK. The W is the initial of the person
whom modified LZ into LZW and his company patented it. I think the W stand for
Welch. The L and Z are some strange names that I cannot spell, but phonetically
they sound like "Lem-ph" and "Zip-fell" or something to that effect. Sorry it was over
10 years ago that I worked with this stuff.
Dan
On Tue, 16 Oct 2001 10:19:41 -0700, Mike Hardwick wrote:
>Exactimo. The embedded system I'm developing has to *display* images, which
>means that it must decode the files. If they are GIFs, then my system has
>to use the LZW algorithm. The best deal we could negotiate with Unisys
>involved a large advance payment. We decided to make a custom file format,
>but I would rather use a standard. Whatever we use, it has to support
>transparency because the system uses images for video overlay. MIFF and PNG
>were the best candidates I found, but their code distributions are too
>massive to be useful. Any ideas?
>
>Mike Hardwick
>Decade Engineering
>
>>It would depend on whether the system was encoding or decoding or just
>>storing or sending, i.e. an embedded web site that had stored images that it
>>sent as part of an html page would not. However, if it created the GIF's,
>>then it would. Likewise, if it decoded a GIF, then it would. However, if
>>it passed on the GIF to something else that incorporated a legal GIF decoder
>>then it wouldn't.
>
>--
>http://www.piclist.com hint: The PICList is archived three different
>ways. See http://www.piclist.com/#archives for details.
>
>
>
That's similar to the solution we adopted... The source images have low
complexity. We translate GIFs supplied by the customer to BMP format, using
the 8-bit RLE option, with a standard translation tool. Then we extend the
BMP files to include a field for the color specified as transparent in the
original GIF files. The resulting morphodite image format is used
exclusively in our system. It's working okay now, but I still wish we
didn't have to use this odd-ball file format...
Mike Hardwick
Decade Engineering
>Try looking at the PCX format. It uses a form of RLE compression and has
fairly
>good results on non-photgraphic images. By that I mean images with large
areas
>of solid colors compress very well. Images with lots of "noise", such as
photographic
>images tend not to compress as well. In the past I used PCX images and
designated
>one of the color values as trasparent in my drawing routines.
>
>The code for PCX decoding can be very small and uses very little ram.
Likewise
>it can also be very fast.
>
>Good Luck!
>
>Oh, yah,,,, try looking for information on the LZ compression algorythm.
It is the
>pre-cursor to LZW and is not protected, AFAIK. The W is the initial of the
person
>whom modified LZ into LZW and his company patented it. I think the W stand
for
>Welch. The L and Z are some strange names that I cannot spell, but
phonetically
>they sound like "Lem-ph" and "Zip-fell" or something to that effect. Sorry
it was over
>10 years ago that I worked with this stuff.
> Oh, yah,,,, try looking for information on the LZ compression algorythm.
> It is the
> pre-cursor to LZW and is not protected, AFAIK. The W is the initial of
> the person
> whom modified LZ into LZW and his company patented it. I think the W
> stand for
> Welch. The L and Z are some strange names that I cannot spell, but
> phonetically
> they sound like "Lem-ph" and "Zip-fell" or something to that effect.
> Sorry it was over
> 10 years ago that I worked with this stuff.
>
> Dan
>
>Karl
>
>Quoting Dan Larson <dlarsonKILLspamCITILINK.COM>:
>> Oh, yah,,,, try looking for information on the LZ compression algorythm.
>> It is the
>> pre-cursor to LZW and is not protected, AFAIK. The W is the initial of
>> the person
>> whom modified LZ into LZW and his company patented it. I think the W
>> stand for
>> Welch. The L and Z are some strange names that I cannot spell, but
>> phonetically
>> they sound like "Lem-ph" and "Zip-fell" or something to that effect.
>> Sorry it was over
>> 10 years ago that I worked with this stuff.
>>
>> Dan
>
>--
>http://www.piclist.com hint: The PICList is archived three different
>ways. See http://www.piclist.com/#archives for details.
>
>
>
decadenet.com ~ Web: http://www.decadenet.com
