Ahh, but when they introduce their new DirectPlay format, and start piping the music straight to your brain, what are you gonna do then?
Then you get in front of a microphone, hit the record button on your digital recording device, and begin "singing" what you are "hearing", in real-time:
it's only a matter of a year or two before we can start doing megabit streams, and when that starts, we'll be able to get pretty damn close to TV quality signals.
"Megabit streams"? I can only presume that you've never seen a Video CD. VCDs are a very popular movie distribution (read: piracy) format in Asia and some other parts of the world. They use exactly the same bitrate as audio CDs (~1.4 megabits/sec); this allows them to fit approximately 74 minutes of video on a standard CD. Unfortunately, the quality is not even as good as VHS SP, let alone broadcast-quality NTSC.
Maybe when we get into streaming multi-megabit/sec streams, things will start looking up.
That seems pretty stupid, considering they already have the unique CD-Keys for copy-protection.
The unique CD key is required only for Battle.Net play, not single-player or even multi-player play via TCP/IP.
Quite a few people (myself included) buy games like Diablo primarily for the single-player gameplay. Quite a few people pirate games like Diablo for the same reason, and they would not need a legitimate CD key to play single-player; a generated key (or a simple crack) would do just as well.
Anyway, what Kenwood seems to be doing here is our good old friend "interpolation".
I would guess that it's actually closer in concept to the "detail textures" feature that some of the 3D game engines (e.g. Unreal Tournament) are employing nowadays.
What you get is a lot of apparent detail, which looks "good" because it effectively masks extreme pixelation (as well as the blurring caused by filtering); however, it has virtually no resemblance to the "real" detail that would have existed had the textures been created/sampled at higher resolution in the first place.
"C sharp" is a musical term; it denotes a musical note that is one semitone higher than C. The musical sharp symbol actually looks quite different from the "#" pound (a.k.a. octothorp) symbol. A musician would never confuse the two.
The problem is that there is neither a proper sharp symbol on most keyboards nor a proper sharp symbol in most commonly-used character sets. As a workaround, the somewhat similar-looking octothorp is used instead.
However, I think you'll agree that "C sharp" sounds a little bit nicer than "C octothorp" (or "C pound", or "C hash"). So we make a compromise and say "C sharp", but type "C#".
I was at the local Electronics Boutique a few weeks ago, and I noticed that a new game (sorry, I forget the title) on the shelves, and it was packaged in a simple shrinkwrapped DVD-style plastic "keep case".
It looked a little strange to me at first, but after a minute I began to appreciate the practicality of this kind of packaging. Not only does it allow for more titles to fit on a store shelf, it's also convenient for the buyer. No more unwieldy oversized cardboard boxes to keep lying around somewhere (or recycle, or simply throw away, depending on the buyer). Not to mention that the keep case is a great storage container that already fits nicely in most "multimedia" or A/V storage racks.
The software industry should definitely agree to standardize on keep case packaging. I for one would be only too happy to see the end of those ridiculous trapezoidal-shaped embossed custom-printed holographic-design boxes (with velcro-fastened flip-tops!) that game companies use in a futile "arms race" to grab the buyer's attention.
Misguided art direction; NPR and the future
on
Review: 'Titan A.E.'
·
· Score: 1
I haven't actually seen the movie yet, but one of the things that turned me off when I saw the trailer was the glaring incongruity between the character art and the computer-rendered backgrounds.
Like many other animators before them, the folks at Bluth's studios appear to have fallen victim to the blind pursuit of the so-called holy grail of CGI: photorealistic rendering.
Because computer-generated imagery is still very much in its infancy, many people mistakenly assume that the ultimate goal is to be able to generate images that look absolutely true-to-life. Yes, that can be one goal of CGI, but that should definitely not be the only goal.
Artists in traditional media have long eschewed realism in favor of stylized renditions of reality, usually to better emphasize certain features or emotions better than realism would allow. If photorealism were the ultimate goal of visual art, then hand painting would have simply become obsolete when photography was invented.
Fortunately, some people are busy doing research on techniques and algorithms that can be used to coax non-photorealistic images out of a computer renderer. This newly emerging field is called non-photorealistic rendering (NPR), and it has already been used very successfully in commercial efforts, most notably the television series Futurama (which uses a specific NPR technique called cell shading). I for one was extremely impressed the first time I saw those great smoothly-animated (but still cartoony-looking) 3D ships flying through space in the very first episode of Futurama.
Fortunately, the future of NPR looks very promising. Adventure Gamer has a short but informative article on the state of NPR in adventure games. The site also has a preview of an upcoming game called Runaway, which makes extensive use of NPR for character art, and looks absolutely stunning. Download the runaway trailer, and prepare to be flabbergasted by what you see. (Yes, it really is 3D rendered!)
It's too bad it didn't occur to Bluth that attempted photorealism in the background art would look just plain silly next to hand-animated characters. I guess they were just pushing for the "Wow!" factor; the average Joe Sixpack is more impressed by flashy freedee 'puter graphics than he is by the seamless and immersive environments than NPR can afford.
Millions of Windows users tired of IRQ conflicts... can now install Mac OS X on their existing computer, keeping their data and their applications. Millions do.
And millions experience the same IRQ conflicts all over again.
IRQ conflicts are a hardware problem, not a software problem ("PnP" notwithstanding). Changing the OS does not automagically make hardware conflicts disappear. IRQ and hardware resource management is a very difficult and complicated job on the endlessly varied PC platform; throwing a brand new OS at a years-old problem is not very likely going to improve things at all.
You sound just like the condescending adults that I couldn't stand when I was a kid.
Many adults treat all kids as if they were stupid. The fact is that just as there are smart adults and stupid adults, there are smart kids and there are stupid kids.
Also, under some operating systems (such as Windows), many applications require a swapfile, because the swapfile can be (and is) used for other purposes, such as memory-mapped file access (for easy sharing of data among applications).
Hey, I wanna buy me some of that NT technology. Better go withdraw some money from a nearby ATM machine -- and I'd better not forget to shield the LCD display, so no one can read my PIN number over my shoulder!
Humans can do voice recognition with impressive accuracy (close to 100% when there are no accent issues). I find very easy to imagine that at some foreseeable point in the future, computers will have enough computing power to do the same.
I may be wrong on this, but I also have a feeling that reliable and usable computer voice control will come before reliable and usable mental control.
I have to say, this is one of the most brilliant ideas I've ever seen on Slashdot.
In the case of Windows, the OS already has a few global keyboard accelerators, such as ALT+F4 to close the current window. (Interestingly, ancient versions of windows actually reserved much of the ALT+Fx series for window manager shortcuts [restore, minimize, maximize], but for some reason these were all gone by Windows 2.x.)
All that needs to be done is to once again increase the stock list of global accelerators to include such commonly-used functions as New, Open, Print, Copy, Cut, Paste, Undo, Redo, Find, Find Next, Select All, and Options.
Each of these functions would then be assigned a default keyboard accelerator by the OS (user-customizeable, though, via the Control Panel). Each function would also be assigned a hard-coded event code that applications merely need to trap in order to be able to make use of the accelerator. Note that the concept of the hard-coded event code is nothing new in Windows; for example, IDOK and IDCANCEL are hard-coded and universally recognized dialog box event codes, and are mapped to the ENTER and ESC keys, respectively.
Application developers would also be encouraged to submit their own extensions to a central registry maintained by the OS developer (in this case Microsoft). Then, for example, if I were writing a Web browser, and wanted to add an "Add to Favorites" menu option, I would first search the official registry (say, on the Web) to see if anyone else had already come up with the same "Add to Favorites" idea for their own app. If so, I would simply look up the existing registered event code and trap that in my application. Otherwise, I would submit my new function idea (along with a detailed description of what it does, as well as the contexts in which it should be used), and then receive a brand new event code that I would then be able to trap in my own application.
Then , when the user installs my application, my installation program checks the locally stored accelerator database to see if all of the required accelerators are already there. Then, for each accelerator that does not already exist, create an entry on the local computer. Once that entry exists on the local computer, the user can at any time go to the Control Panel and assign his own desired key combination to the new function.
The beautiful thing about this is that it doesn't even have to be restricted to keyboard commands! Since the application is oblivious to the nature of actual physical event that triggered the event code, the OS could later be enhanced to accept different kinds of input to trigger the same shortcuts -- such as IR remote controls, voice control, or someday even thought control!
Imagine being able to use the exact same key combinations (or the same remote control buttons, or the same voice commands) to control every media application you have (Winamp, Windows Media Player, Quicktime, RealPlayer). Wonderful.
You appear to have misunderstood the original post.
"Kill the mouse" is not by any means anti-GUI, or even pro-CLI. The original poster had nothing against GUIs; he was merely expressing a wish for a better means of control.
You mistakenly assumed that his aversion to mice automatically translated into an aversion to GUIs. Not true.
You further assumed that this imagined aversion to GUIs automatically translated into a strong affinity to CLIs. Not true either. There are many potential alternatives to both GUIs and CLIs, such as voice-controlled or thought-controlled computers with no visible display required (think Star Trek).
I think you may be getting GEOS and GeoWorks Ensemble confused. GEOS was a GUI-based OS that was available on the Commodore 64/128 and Apple ][ series. (It may have been available on other platforms, but I have first-hand experience with it on a C64 and an Apple ][e.)
GeoWorks Ensemble came later, and was a PC-based loose adaptation of GEOS. You're approximately right about the timing relative to Windows, and you're absolutely right about the astonishingly good performance on very low-end hardware.
GeoWorks Ensemble actually still lives today. It was sold a few years ago to a company called NewDeal Inc., and has been renamed NewDeal Office.
I gave NewDeal Office a spin some time last year, and it still looks and feels very much like the original GeoWorks Ensemble. The improvements are mostly incremental -- nothing revolutionary. The UI is increasingly Windows-like, even including something that looks almost identical to the Windows Start menu.
NewDeal Office is a solid product for people and institutions that have old hardware that isn't up to snuff for the latest OSes and applications. The product is pretty much marketed as a "suite" that happens to have it's own built-in OS, which is appropriate, given the dearth of third-party applications. (That dearth, BTW, is what killed any chance it might have had as a mainstream OS in the first place.)
You said "bmp", not "bitmap". You explicitly referred to it as a "format", as in "bmp and several other formats".
"Bitmap" is not a format; it's a generic term loosely meaning the same thing as "computer image". BMP, on the other hand, is a format (it's one of many different formats used to store bitmaps); and no, it does not utilize LZW compression.
[GIF is] almost as old and outdated as Microsoft BMP Bitmaps.
News flash: The GIF format is older than the BMP format. The GIF specification was originally drafted in 1987, and the current GIF specification was drafted in 1989.
The BMP format, on the other hand, debuted with Microsoft Windows 3.0 in 1990. (Previous versions of Windows had the MSP "Microsoft Paint" format. I still have some old.MSP files sitting on a moldy old 5.25" floppy disk somewhere. Ahh, memories.)
While BMP "technology" (simple raw or RLE only) is unquestionably far more outdated than that used in GIF, the BMP format itself is newer.
For the record, Microsoft.BMP files have never utilized LZW compression, and almost certainly never will. The only compression method they support is run-length encoding, in which case the files are usually named with an.RLE extension.
Actually, it's even worse. The 35-byte file that kevin805 is talking about is actually a one-bit palettized GIF.
A single-pixel eight-bit GIF file comes to 799 bytes (!). That's because GIF does not attempt to compress the palette, and an eight-bit (256-entry) palette of 24-bit values comes to 768 bytes.
In any case, extremely tiny images like this are worse than useless for comparision purposes, since they represent a pathological case for GIF (due to the palette overhead).
Both the posting and the article itself refer to a so-called "GIF patent". Of course, we all know that there is no such thing. Unisys' patent is for LZW compression.
Sure, LZW is used in GIFs, but that doesn't warrant its being called a "GIF patent". LZW is used in a lot of other things, including TIFF images, but there's absolutely nothing about it that intrinsically makes it an image compression scheme, let alone a dedicated GIF compression algorithm.
The GIF image format was originally developed in the 1980s by Compuserve for use in its online service. IIRC, Compuserve was not aware at the time that LZW was protected by patent; if it had, then it certainly would have used some other compression technique. In any case, if anyone "owns" GIF, it would have to be Compuserve, not Unisys. (I'm pretty sure you can't patent a file format in the US, although you could always obtain copyright protection on the file specification text itself.)
Anyway, it's interesting to note that for a long time, Unisys was equally clueless about this matter. LZW technology was actually not developed by Unisys; it was developed by another company that was subsequently acquired by Unisys. GIF flourished for years on BBSes and then the Internet before Unisys even became aware that it was utilizing LZW.
So please, do your part to fight sloppy disinformation, and don't refer to the LZW patent as the "GIF patent". That's like referring to the MP3 format as the "illegal music piracy" format.
Slashdot Mirror
Ahh, but when they introduce their new DirectPlay format, and start piping the music straight to your brain, what are you gonna do then?
Then you get in front of a microphone, hit the record button on your digital recording device, and begin "singing" what you are "hearing", in real-time:
"Nananana, tananana, chika-chika, boom, snick, tananananana, snick, snick, boom..."
Voilá! Instant digital copy.
--
it's only a matter of a year or two before we can start doing megabit streams, and when that starts, we'll be able to get pretty damn close to TV quality signals.
"Megabit streams"? I can only presume that you've never seen a Video CD. VCDs are a very popular movie distribution (read: piracy) format in Asia and some other parts of the world. They use exactly the same bitrate as audio CDs (~1.4 megabits/sec); this allows them to fit approximately 74 minutes of video on a standard CD. Unfortunately, the quality is not even as good as VHS SP, let alone broadcast-quality NTSC.
Maybe when we get into streaming multi-megabit/sec streams, things will start looking up.
That seems pretty stupid, considering they already have the unique CD-Keys for copy-protection.
The unique CD key is required only for Battle.Net play, not single-player or even multi-player play via TCP/IP.
Quite a few people (myself included) buy games like Diablo primarily for the single-player gameplay. Quite a few people pirate games like Diablo for the same reason, and they would not need a legitimate CD key to play single-player; a generated key (or a simple crack) would do just as well.
Anyway, what Kenwood seems to be doing here is our good old friend "interpolation".
I would guess that it's actually closer in concept to the "detail textures" feature that some of the 3D game engines (e.g. Unreal Tournament) are employing nowadays.
What you get is a lot of apparent detail, which looks "good" because it effectively masks extreme pixelation (as well as the blurring caused by filtering); however, it has virtually no resemblance to the "real" detail that would have existed had the textures been created/sampled at higher resolution in the first place.
You have a valid point there.
"C sharp" is a musical term; it denotes a musical note that is one semitone higher than C. The musical sharp symbol actually looks quite different from the "#" pound (a.k.a. octothorp) symbol. A musician would never confuse the two.
The problem is that there is neither a proper sharp symbol on most keyboards nor a proper sharp symbol in most commonly-used character sets. As a workaround, the somewhat similar-looking octothorp is used instead.
However, I think you'll agree that "C sharp" sounds a little bit nicer than "C octothorp" (or "C pound", or "C hash"). So we make a compromise and say "C sharp", but type "C#".
I was at the local Electronics Boutique a few weeks ago, and I noticed that a new game (sorry, I forget the title) on the shelves, and it was packaged in a simple shrinkwrapped DVD-style plastic "keep case".
It looked a little strange to me at first, but after a minute I began to appreciate the practicality of this kind of packaging. Not only does it allow for more titles to fit on a store shelf, it's also convenient for the buyer. No more unwieldy oversized cardboard boxes to keep lying around somewhere (or recycle, or simply throw away, depending on the buyer). Not to mention that the keep case is a great storage container that already fits nicely in most "multimedia" or A/V storage racks.
The software industry should definitely agree to standardize on keep case packaging. I for one would be only too happy to see the end of those ridiculous trapezoidal-shaped embossed custom-printed holographic-design boxes (with velcro-fastened flip-tops!) that game companies use in a futile "arms race" to grab the buyer's attention.
I haven't actually seen the movie yet, but one of the things that turned me off when I saw the trailer was the glaring incongruity between the character art and the computer-rendered backgrounds.
Like many other animators before them, the folks at Bluth's studios appear to have fallen victim to the blind pursuit of the so-called holy grail of CGI: photorealistic rendering.
Because computer-generated imagery is still very much in its infancy, many people mistakenly assume that the ultimate goal is to be able to generate images that look absolutely true-to-life. Yes, that can be one goal of CGI, but that should definitely not be the only goal.
Artists in traditional media have long eschewed realism in favor of stylized renditions of reality, usually to better emphasize certain features or emotions better than realism would allow. If photorealism were the ultimate goal of visual art, then hand painting would have simply become obsolete when photography was invented.
Fortunately, some people are busy doing research on techniques and algorithms that can be used to coax non-photorealistic images out of a computer renderer. This newly emerging field is called non-photorealistic rendering (NPR), and it has already been used very successfully in commercial efforts, most notably the television series Futurama (which uses a specific NPR technique called cell shading). I for one was extremely impressed the first time I saw those great smoothly-animated (but still cartoony-looking) 3D ships flying through space in the very first episode of Futurama.
Fortunately, the future of NPR looks very promising. Adventure Gamer has a short but informative article on the state of NPR in adventure games. The site also has a preview of an upcoming game called Runaway, which makes extensive use of NPR for character art, and looks absolutely stunning. Download the runaway trailer, and prepare to be flabbergasted by what you see. (Yes, it really is 3D rendered!)
It's too bad it didn't occur to Bluth that attempted photorealism in the background art would look just plain silly next to hand-animated characters. I guess they were just pushing for the "Wow!" factor; the average Joe Sixpack is more impressed by flashy freedee 'puter graphics than he is by the seamless and immersive environments than NPR can afford.
Millions of Windows users tired of IRQ conflicts... can now install Mac OS X on their existing computer, keeping their data and their applications. Millions do.
And millions experience the same IRQ conflicts all over again.
IRQ conflicts are a hardware problem, not a software problem ("PnP" notwithstanding). Changing the OS does not automagically make hardware conflicts disappear. IRQ and hardware resource management is a very difficult and complicated job on the endlessly varied PC platform; throwing a brand new OS at a years-old problem is not very likely going to improve things at all.
Buffalo '66, another movie released in 1998, did it too. I wonder who was really first. Does anybody know?
Here's what I would suggest:
Microprose.
You sound just like the condescending adults that I couldn't stand when I was a kid.
Many adults treat all kids as if they were stupid. The fact is that just as there are smart adults and stupid adults, there are smart kids and there are stupid kids.
Last time I checked, RAM was hardware.
Also, under some operating systems (such as Windows), many applications require a swapfile, because the swapfile can be (and is) used for other purposes, such as memory-mapped file access (for easy sharing of data among applications).
Hey, I wanna buy me some of that NT technology. Better go withdraw some money from a nearby ATM machine -- and I'd better not forget to shield the LCD display, so no one can read my PIN number over my shoulder!
Never is a long, long time.
Humans can do voice recognition with impressive accuracy (close to 100% when there are no accent issues). I find very easy to imagine that at some foreseeable point in the future, computers will have enough computing power to do the same.
I may be wrong on this, but I also have a feeling that reliable and usable computer voice control will come before reliable and usable mental control.
I have to say, this is one of the most brilliant ideas I've ever seen on Slashdot.
In the case of Windows, the OS already has a few global keyboard accelerators, such as ALT+F4 to close the current window. (Interestingly, ancient versions of windows actually reserved much of the ALT+Fx series for window manager shortcuts [restore, minimize, maximize], but for some reason these were all gone by Windows 2.x.)
All that needs to be done is to once again increase the stock list of global accelerators to include such commonly-used functions as New, Open, Print, Copy, Cut, Paste, Undo, Redo, Find, Find Next, Select All, and Options.
Each of these functions would then be assigned a default keyboard accelerator by the OS (user-customizeable, though, via the Control Panel). Each function would also be assigned a hard-coded event code that applications merely need to trap in order to be able to make use of the accelerator. Note that the concept of the hard-coded event code is nothing new in Windows; for example, IDOK and IDCANCEL are hard-coded and universally recognized dialog box event codes, and are mapped to the ENTER and ESC keys, respectively.
Application developers would also be encouraged to submit their own extensions to a central registry maintained by the OS developer (in this case Microsoft). Then, for example, if I were writing a Web browser, and wanted to add an "Add to Favorites" menu option, I would first search the official registry (say, on the Web) to see if anyone else had already come up with the same "Add to Favorites" idea for their own app. If so, I would simply look up the existing registered event code and trap that in my application. Otherwise, I would submit my new function idea (along with a detailed description of what it does, as well as the contexts in which it should be used), and then receive a brand new event code that I would then be able to trap in my own application.
Then , when the user installs my application, my installation program checks the locally stored accelerator database to see if all of the required accelerators are already there. Then, for each accelerator that does not already exist, create an entry on the local computer. Once that entry exists on the local computer, the user can at any time go to the Control Panel and assign his own desired key combination to the new function.
The beautiful thing about this is that it doesn't even have to be restricted to keyboard commands! Since the application is oblivious to the nature of actual physical event that triggered the event code, the OS could later be enhanced to accept different kinds of input to trigger the same shortcuts -- such as IR remote controls, voice control, or someday even thought control!
Imagine being able to use the exact same key combinations (or the same remote control buttons, or the same voice commands) to control every media application you have (Winamp, Windows Media Player, Quicktime, RealPlayer). Wonderful.
You appear to have misunderstood the original post.
"Kill the mouse" is not by any means anti-GUI, or even pro-CLI. The original poster had nothing against GUIs; he was merely expressing a wish for a better means of control.
You mistakenly assumed that his aversion to mice automatically translated into an aversion to GUIs. Not true.
You further assumed that this imagined aversion to GUIs automatically translated into a strong affinity to CLIs. Not true either. There are many potential alternatives to both GUIs and CLIs, such as voice-controlled or thought-controlled computers with no visible display required (think Star Trek).
I think you may be getting GEOS and GeoWorks Ensemble confused. GEOS was a GUI-based OS that was available on the Commodore 64/128 and Apple ][ series. (It may have been available on other platforms, but I have first-hand experience with it on a C64 and an Apple ][e.)
GeoWorks Ensemble came later, and was a PC-based loose adaptation of GEOS. You're approximately right about the timing relative to Windows, and you're absolutely right about the astonishingly good performance on very low-end hardware.
GeoWorks Ensemble actually still lives today. It was sold a few years ago to a company called NewDeal Inc., and has been renamed NewDeal Office.
I gave NewDeal Office a spin some time last year, and it still looks and feels very much like the original GeoWorks Ensemble. The improvements are mostly incremental -- nothing revolutionary. The UI is increasingly Windows-like, even including something that looks almost identical to the Windows Start menu.
NewDeal Office is a solid product for people and institutions that have old hardware that isn't up to snuff for the latest OSes and applications. The product is pretty much marketed as a "suite" that happens to have it's own built-in OS, which is appropriate, given the dearth of third-party applications. (That dearth, BTW, is what killed any chance it might have had as a mainstream OS in the first place.)
Books can't hyperlink!
Ever hear of Choose Your Own Adventure books?
by bitmap I mean any raw bitmapped images
You said "bmp", not "bitmap". You explicitly referred to it as a "format", as in "bmp and several other formats".
"Bitmap" is not a format; it's a generic term loosely meaning the same thing as "computer image". BMP, on the other hand, is a format (it's one of many different formats used to store bitmaps); and no, it does not utilize LZW compression.
BMP != bitmap
[GIF is] almost as old and outdated as Microsoft BMP Bitmaps.
News flash: The GIF format is older than the BMP format. The GIF specification was originally drafted in 1987, and the current GIF specification was drafted in 1989.
The BMP format, on the other hand, debuted with Microsoft Windows 3.0 in 1990. (Previous versions of Windows had the MSP "Microsoft Paint" format. I still have some old .MSP files sitting on a moldy old 5.25" floppy disk somewhere. Ahh, memories.)
While BMP "technology" (simple raw or RLE only) is unquestionably far more outdated than that used in GIF, the BMP format itself is newer.
For the record, Microsoft .BMP files have never utilized LZW compression, and almost certainly never will. The only compression method they support is run-length encoding, in which case the files are usually named with an .RLE extension.
Actually, it's even worse. The 35-byte file that kevin805 is talking about is actually a one-bit palettized GIF.
A single-pixel eight-bit GIF file comes to 799 bytes (!). That's because GIF does not attempt to compress the palette, and an eight-bit (256-entry) palette of 24-bit values comes to 768 bytes.
In any case, extremely tiny images like this are worse than useless for comparision purposes, since they represent a pathological case for GIF (due to the palette overhead).
Both the posting and the article itself refer to a so-called "GIF patent". Of course, we all know that there is no such thing. Unisys' patent is for LZW compression.
Sure, LZW is used in GIFs, but that doesn't warrant its being called a "GIF patent". LZW is used in a lot of other things, including TIFF images, but there's absolutely nothing about it that intrinsically makes it an image compression scheme, let alone a dedicated GIF compression algorithm.
The GIF image format was originally developed in the 1980s by Compuserve for use in its online service. IIRC, Compuserve was not aware at the time that LZW was protected by patent; if it had, then it certainly would have used some other compression technique. In any case, if anyone "owns" GIF, it would have to be Compuserve, not Unisys. (I'm pretty sure you can't patent a file format in the US, although you could always obtain copyright protection on the file specification text itself.)
Anyway, it's interesting to note that for a long time, Unisys was equally clueless about this matter. LZW technology was actually not developed by Unisys; it was developed by another company that was subsequently acquired by Unisys. GIF flourished for years on BBSes and then the Internet before Unisys even became aware that it was utilizing LZW.
So please, do your part to fight sloppy disinformation, and don't refer to the LZW patent as the "GIF patent". That's like referring to the MP3 format as the "illegal music piracy" format.