home *** CD-ROM | disk | FTP | other *** search
/ ftp.wwiv.com / ftp.wwiv.com.zip / ftp.wwiv.com / pub / HATCH / WWIVNEWS.ZIP / 9210_1.NWS < prev    next >
Text File  |  1992-10-27  |  32KB  |  548 lines
  1.                 ┌┐┌┐┌┐┌┐┌┐┌┐┌────┐┌┐  ┌┐┌─┐ ┌┐┌────┐┌┐┌┐┌┐┌────┐
  2.   ╔═════════════││││││││││││└─┐┌─┘││  │││ └┐│││┌───┘│││││││┌───┘═════════════╗
  3.   ║  Volume 3   ││││││││││││  ││  └┼┐┌┼┘│  └┘││└───┐│││││││└───┐ October 25  ║
  4.   ║   Issue 6   ││││││││││││  ││   ││││ │┌┐  ││┌───┘││││││└───┐│    1992     ║
  5.   ╚═════════════│└┘└┘││└┘└┘│┌─┘└─┐ └┼┼┘ ││└┐ ││└───┐│└┘└┘│┌───┘│═════════════╝
  6.             │   └────┘└────┘└────┘  └┘  └┘ └─┘└────┘└────┘└────┘   │
  7.             │ Serving WWIV Sysops & Users Across All WWIV Networks │
  8.             └──────────────────────────────────────────────────────┘
  9.                            ┌─────────────────────┐
  10.                            │This Month's Features│
  11. ┌──────────────────────────┴─────────────────────┴───────────────────────────┐
  12. │ Random Factors.......................................Wayne Bell (1@1)      │
  13. │                                                                            │
  14. │ The History Of WWIVedit..............................The Emperor (1@6470)  │
  15. │                                                                            │
  16. │ TechnOTES............................................WWIVnews Staff        │
  17. │                                                                            │
  18. │ Squashing Those Gluttony .GIF's (Part 2).............Spackle (1@19995)     │
  19. │                                                                            │
  20. │ USERREC - The Next Generation........................Tolkien (1@3456)      │
  21. │                                                                            │
  22. │ Filo's Mod of the Month..............................Filo (1@5252)         │
  23. │                                                                            │
  24. │ Dateline: @#$*()#!...................................Omega Man (1@5282)    │
  25. └────────────────────────────────────────────────────────────────────────────┘
  26.  
  27. ───────────────┬─────────────────────────────────────────────┬───────────────
  28.                │               Random Factors                │
  29.                │   Creative Commentary by Wayne Bell (1@1)   │
  30.                └─────────────────────────────────────────────┘
  31.  
  32. Yet some more v4.22/net32 news:
  33.  
  34. v4.22/net32 will gate subs among networks. We have tried that, and it does 
  35. work. Also, the subs by name does work (even when gating subs-by-name). Either
  36. the host, or a subscriber can gate a sub. Anyone on any network can auto-reply
  37. to a gated post, and the E-mail will go back to the author of the post. Again,
  38. we have tried that, and it does work. ("We" being 1@1, 1@4, and 1@5252.)
  39.  
  40. net32 should go out to a more extended beta-test (SDS's mostly) in the next
  41. week or two. Hopefully, if all goes well, it should be released in about a 
  42. month. Oh, also, net32 has full support for file locking, so people using 
  43. multi-line BBS mods will no longer have any problems relating to the net 
  44. software. (But, no, I don't currently have any plans to make the BBS multi-
  45. line [yet].)
  46.  
  47. v4.22 now has (as stated above) post and E-Mail gating, and subs-by-name. Also,
  48. there is a new userrec format (1k per user), which hopefully incorporates all 
  49. the various userrec modifications, so everyone can have a "standard" userrec, 
  50. and authors of WWIV add-ons won't have to worry about having numerous different
  51. formats to support. The quickscan pointers are stored in a separate file 
  52. (user.qsc), and the max subs (and max dirs) can be set to anything from 32 to 
  53. 999. Be aware, though, that setting them to 999 from 32 requires 144k more of 
  54. memory.
  55.  
  56. I am currently working on extracting embedded strings out of the BBS, and 
  57. storing them in a data file. This is mostly to support multiple languages, but
  58. should also save a lot of memory (straight out of DGROUP, for those of you that
  59. have problems there). v4.22 probably won't have actual multi-language support,
  60. but it should be very close.
  61.  
  62. That will probably do it for v4.22. In programming at work (non-BBS stuff), 
  63. I've had bad experiences with the "put everything in the next version" idea,
  64. but then again I'm currently involved in the other extreme - trying to do 
  65. things in itty-bitty pieces (and that isn't a very good idea either). v4.22
  66. will be out sometime probably first quarter next year (Jan-Mar). There will be
  67. a v4.23 after that. For those of you who want to know, things I'm considering 
  68. for a v4.23 are: full multi-language support; integrating a QWK reader into 
  69. the BBS; putting some large global data structures into EMS/XMS; and maybe 
  70. support for other network types (Fido, Vnet). No, I don't >PROMISE< any of 
  71. those (except multi-language support), but those are what I am considering.
  72.  
  73. (I hope PKZip 2.0 comes out before v4.22. Or at least before v4.23.)
  74.  
  75. I'd also like to take a second to remind people a bit about C programming 
  76. nomenclature. C functions are called "functions". A "void" is a valid data 
  77. type, like "int" or "real" or "long". In Pascal, each block of code is either 
  78. a function (meaning it returns a value), or a procedure (meaning that it 
  79. doesn't return a value). Therefore, in Pascal, you start these routines out 
  80. with "procedure this;" or "function that;" 
  81.  
  82. In C, however, every function returns a value. Thus, if the function returns an
  83. int, it is "int func()". If you don't care what value it returns, then you 
  84. declare the return value to be of type "void", meaning "I don't care what this
  85. returns". So if you see "void nl()", that stands for starting FUNCTION "nl" 
  86. with a return type of "void".
  87.  
  88. Finally, an important reminder regarding HS/Link command lines. If you're using
  89. HS/Link, you should go into INIT and edit the command lines so that they look 
  90. as shown below:
  91.      
  92.           Description              : HS/Link
  93.           Xfer OK code             : 0
  94.           Require MNP/LAPM         : N
  95.           Receive command line:
  96.           HSLINK -P%2 -E%4 -U%3
  97.           Send command line:
  98.           HSLINK -P%2 -E%4 -NU %3
  99.           Receive batch command line:
  100.           HSLINK -P%2 -E%4 -U%3
  101.           Send batch command line:
  102.           HSLINK -P%2 -E%4 -NU @%3
  103.           Bi-directional transfer command line:
  104.           HSLINK -P%2 -E%4 -@ @%3
  105.           
  106. BE VERY SURE the -NU option is present as shown on the "Send" and "Send batch"
  107. command lines! 
  108.  
  109. (Of course, it is not necessary to specify ALL command lines - you can only 
  110. specify the batch command lines if you do not wish HS/Link used for single file
  111. transfers.)
  112.      
  113. This option is used on SEND command lines when uploads are not expected or
  114. desired. It MUST be used on the HS/Link command lines in INIT for "Send" and
  115. "Send batch" to ensure unwanted files cannot be uploaded.
  116.  
  117. ───────────────┬─────────────────────────────────────────────┬───────────────
  118.                │           The History Of WWIVedit           │
  119.                │          Guest Creative Commentary          │
  120.                │           by The Emperor (1@6470)           │
  121.                └─────────────────────────────────────────────┘
  122.  
  123. Back in February of 1991, I was frustrated. I had, at this point, been running
  124. a WWIV board for 6 months, and in this time, I had always longed for a good 
  125. editor. At the time, I didn't have the funds to call long distance to download
  126. any files. 
  127.  
  128. Later that month, I got hold of the source code for some obscure editor from 
  129. another BBS here in Athens. I warped the code enough to get it to run under 
  130. WWIV, and I finally had a full editor on my system. This was all fine and 
  131. dandy until I tried to add color to it. That proved to be a dismal failure, 
  132. and so I set out to build a better editor. In early March, I built an editor 
  133. from the ground up. It never did work very well, but I considered it my first 
  134. go at writing a real full screen editor. 
  135.  
  136. One night in late March, when I knew I should have been working on a project 
  137. for one of my classes, I sat down and began in earnest on what would eventually
  138. become WWIVEdit 1.0. Eight hours later, I had a working prototype of it. It had
  139. one major advantage over anything I had written thus far. It handled colors 
  140. elegantly. 
  141.  
  142. In my design of WWIVEdit, the look and feel of it was highly influenced by
  143. ProEdit by H. S. Smith for PCBoard. I liked the idea of having the title and 
  144. destination on the screen. This was probably one of the hardest things to code.
  145. While at first the problem may appear easy, it is actually quite difficult. As
  146. it stands, WWIV provides no interface for a Full Screen editor to get 
  147. information as to what it is being used for. In fact, there isn't even a 
  148. guarantee that a FSED can get information as to the current user on line. 
  149.  
  150. In my initial version of WWIVEdit, the destination detection algorithm "read 
  151. the screen" to see if it could figure out where a message was going. This 
  152. worked fine, except it wasn't always obvious where a message was going from 
  153. what was on the screen. This is still a problem today, though versions 2.2 and 
  154. up provide an alternate way to get the needed information. (Note:in WWIV 4.21a,
  155. this will be standard). 
  156.  
  157. In about May of 1991, I had the editor to the point where I actually believed
  158. it was worth giving to other people, so I contacted The Duelist (1@18258 
  159. WWIVLink) to help me with some testing. The Duelist was the person who 
  160. introduced me to WWIV my freshman year of college. I nagged him for a few 
  161. weeks to try my editor, and when I finally sent him a copy, he installed 
  162. it and had it up and running in a matter of minutes. Thus was born WWIVEdit 
  163. 1.0. Only one other copy of version 1.0 was distributed, and for the life of
  164. me, I can't remember who got it. . 
  165.  
  166. Over the next several weeks, The Duelist sent me a constant stream of E-Mail
  167. on how to improve my creation. Thus were born versions 1.1 through 1.4. 
  168. Version 1.4 and 1.6 were the first versions that were ever distributed 
  169. publicly. I got some response, but there really didn't seem to be much 
  170. interest in them. 
  171.  
  172. It was about this time that I joined WWIVLink, and a month later, WWIVNet.
  173. In that gap of time, WWIVEdit 2.0 was born. Version 2.0 contained some very
  174. significant advances. The internals were reworked, providing cleaner, but
  175. not perfect, formatting. Version 2.0 also was different in one very significant
  176. way; a fact which I attribute much of its success to: I included the source 
  177. code with the editor, with no strings attached. I continue this policy today 
  178. with only one slight modification; the source code, due to its large size 
  179. isn't included in the distribution file, however is available separately. 
  180.  
  181. In August of 91, one of my users said "Hey, why don't you add a spell
  182. checker to the editor?"At the time, I laughed at him and said "Yeah. Right.
  183. "But over the next several weeks, I got a few more requests. some from my
  184. users, some from people on the networks. So I began to look for a file that
  185. contained enough words to make a reasonable dictionary. Filo eventually
  186. pointed me to a list of about 6000 words, so I got it, changed it into a
  187. form I could use, and had a working dictionary a few weeks later. With that
  188. feature added, I released version 2.2.
  189.  
  190. Over the next several months, I got a steady stream of suggestions on what
  191. should be added to the next version, and in December, I had enough changes
  192. to warrant a Beta version of 2.3. It went to all of the people who had
  193. registered WWIVEdit up till that point, as well as a few of my favorite 
  194. beta testers. The beta version was pretty complete and free of bugs, but
  195. I didn't feel that it was ready for public distribution. Then, over the
  196. next 3 months, I was very busy with my school work, so I did very little
  197. in the way of improvements. 
  198.  
  199. Finally, during Spring Break of 1992, I got enough time to sit down and
  200. work. And in early April, I had another beta version ready. This one only
  201. had a few bugs, so I fixed them, and a few weeks later release version 2.3.
  202. Just before release though, I added what I thought was a relatively simple
  203. change, however, it generated a lot of apparently unrelated bugs. Since
  204. then, I haven't released a full version, but a bug fix has been available
  205. on my system for a few months. 
  206.  
  207. By the time this makes it to press, WWIVEdit 2.4 will probably have been 
  208. released. A number of features will be added, many of them related to the
  209. upcoming release of WWIV 4. 21a. In particular, WWIVEdit 2.4 will have support
  210. for a quoter that has been installed in WWIV 4. 21a, support for the "Disable
  211. Tag" feature in WWIV's //BOARDEDIT, support for BBS's other than WWIV (waffle,
  212. Telegard, etc), and a few other bug fixes and enhancements. 
  213.  
  214. After this next release, I have nothing of significance to add to WWIVEdit.
  215. I may rework a lot of the internals to make more efficient use of memory,
  216. and I may add support for a few more BBS's, but I have no ideas left on what 
  217. to add. I have always welcomed suggestions on how WWIVEdit can be improved, 
  218. and continue to do so. 
  219.  
  220. So, if you have any suggest, comments (both positive and negative), please
  221. feel free to Mail me at any of the following addresses: 
  222.  
  223. 1@6470 Net 
  224. 1@16470 Link 
  225. acaldwel@oucsace. cs. ohiou. edu 
  226. acaldwel@bigbird. cs. ohiou. edu 
  227. CALDWELL@duce. cs. ohiou. edu 
  228.  
  229. I would like to take a few lines to thank everyone who have sent me comments, 
  230. suggestions, bug reports, and all: Lance Halle, Trader Jack, The Duelist, 
  231. Jim Wire, Aahz, Trojan, Filo, and Wayne Bell. 
  232.  
  233. ───────────────┬─────────────────────────────────────────────┬───────────────
  234.                │                 TechnOTES                   │
  235.                │        Compiled by the WWIVnews Staff       │
  236.                └─────────────────────────────────────────────┘
  237.  
  238. ...While the industry as a whole is trying to decide whether to support
  239. the PCMCIA standard (the so-called "Credit Card Hard Drives", AKA "Flash
  240. Memory") for low-power portable mass storage, Hewlett-Packard has decided to 
  241. tie an alternatively less expensive carrot on the end of the stick by 
  242. developing the smallest commercial hard drive yet released on the open market.
  243.  
  244. ...Dubbed the "Kittyhawk" by HP, the drive has a platter size of 1.3 inches, 
  245. and contains two platters capable of 14MB of storage each. Although the 
  246. Kittyhawk can easily fit inside of a matchbox, it does so at the cost of one 
  247. side of platter storage; the top platter is too close to the case to allow for
  248. a R/W head to move freely. Still, the small size allows the drive to run
  249. at less than 3v, which is becoming a requirement for use in portables that
  250. promise longer continuous use on battery power.
  251.  
  252. ...With something that small and compact, one would probably expect the
  253. Kittyhawk to be rather fragile. According to HP, the drive is far from
  254. gossamer, and can take over 100 G's of shock force before incurring any
  255. real internal damage. This helps to negate most of the remaining arguments 
  256. that PCMCIA advocates have had against using mechanical hard drives for 
  257. portable storage instead of shockproof Flash Memory cards. In fact, the drive's
  258. size will be PCMCIA Type III compatible, thus allowing for manufacturers to
  259. produce both versions for a relatively small difference in cost.
  260.  
  261. ...It should come as no surprise then that HP's target market for the Kittyhawk
  262. is the next generation of palmtops and hand-held pen computers. This new breed
  263. of PC, which HP refers to as a "mobile information appliance", is reportedly 
  264. the foundation for a revamped line of HP palmtops, including an expanded 
  265. version of the popular HP95LX. Already NEC and Apple have expressed interest 
  266. in using removable Kittyhawks in future palmtop development as opposed to the
  267. PCMCIA cards that are expected to be touted as the next "standard" within the 
  268. next couple of years.
  269.  
  270. ...GSI of Irvine, CA has released a new floppy controller that promises to
  271. allow for a "seamless installation and operation" of extra-high-density
  272. 3.5" drives in any system without the hassle of BIOS upgrading or juggling
  273. of software drivers. The Model 11 controller has it's own onboard BIOS 
  274. aliasing manager, which eliminates BIOS incompatibilities and allows 
  275. installation as a secondary controller without conflict with the existing
  276. floppy controller.
  277.  
  278. ...The Model 11 supports up to four extra-high-density drives, and comes as 
  279. part of a "Super Floppy Upgrade Kit", which also includes a TEAC 2.88MB Floppy
  280. Drive, one Toshiba 4MB 3.5" diskette, and connecting ribbon cables. MSRP
  281. for the kit is $325, but street prices are expected to drop below the $300
  282. mark by the end of the year.
  283.  
  284. ...Looking towards the future a bit, IBM has announced that researchers
  285. at the Watson Center have produced transistors that are just under 1/75,000
  286. of the width of a human hair. Using an experimental form of electron-beam
  287. nanolithography fabrication, the transistors produced are just under 0.1
  288. micron in size, and may eventually pave the way for 4GB DRAMs. Don't hold
  289. your breath for 'em, though - the current method of processing the transistors
  290. only allows for a production run of about 35 individual chips per hour. For
  291. actual market purposes, the process would have to produce that many *wafers*
  292. per hour, which will probably delay the release of such chips on the market
  293. until the latter half of this decade at the earliest.
  294.  
  295. ...Texas Instruments is shipping a new 4Mb Video RAM chip that the company 
  296. hopes will become the "new standard" for VRAM by the end of 1993. The new
  297. chip is designed to replace the existing 1Mb VRAM standard, and is expected
  298. to allow graphics board manufacturers the resources to produce inexpensive
  299. 24-bit video adapters using much of the same existing design elements in
  300. most popular SVGA cards. With the ability to fit 4 megs of VRAM in the space
  301. of one with very little modding to the original 1Mb circuitry for about the
  302. same cost, boards like the high-end Targa series and the recently-released 
  303. Video Blaster from Creative Labs, may soon find themselves outdated quicker 
  304. than their respective manufacturers expected.
  305.  
  306. ...Speaking of Creative Labs, how many of you have wanted a Sound Blaster to
  307. enhance that copy of Wing Commander or Wolfenstein 3-D, but didn't really want
  308. all the frills of the MIDI accessory kit? If one has no real interest in music,
  309. or actually has no musical talent, then why should you have to fork over the
  310. dough for the MIDI accessories?
  311.  
  312. ...Ok, so lack of musical talent didn't stop Nirvana from smelling like 
  313. something other than Teen Spirit. Still, Creative Labs must have heard these 
  314. wishes from a lot of potential (read: broke and untalented) customers, and 
  315. have released the Sound Blaster Pro Basic kit.
  316.  
  317. ...The Pro Basic kit contains a Sound Blaster Pro board with all the non-
  318. MIDI specific frills, including voice sampling, text-to-speech capabilities,
  319. FM synthesized 20-voice output capacity, and basic control of audio CD's for
  320. multimedia use. The board also will be interfaceable with CL's new Video
  321. Blaster board for additional multimedia presentation production.
  322.  
  323. ...While the MSRP for this package is $229 direct from CL, street prices have
  324. been as low as $169. The expected side effect has been to reduce the price of
  325. the original Sound Blaster to as low as $119 on the street. At prices like
  326. these, expect another round of "Sound Blaster Chat Mods" to hit the Modnet
  327. shortly after Christmas.
  328.  
  329. ───────────────┬─────────────────────────────────────────────┬───────────────
  330.                │  Squashing Those Gluttony .GIF's (Part 2)   │
  331.                │             By Spackle (1@19955)            │
  332.                └─────────────────────────────────────────────┘
  333.  
  334. This article is the second in a three-part series of articles discussing the
  335. various GIF (Graphics Interchange Format) picture file compression methods,
  336. their pros and cons, and a sample test with sample GIF files. The complete
  337. article (12K archived) is available for download at The Rubicon in Raleigh,
  338. North Carolina at 919-676-0738 under the filename of GIFCOMPR.LZH. Sysops
  339. are auto-validated first call. This would make an excellent G-File, and is
  340. good download information as well.
  341.  
  342. ─────────────────────────────────────────────────────────────────────────────
  343.  
  344. There is one last GIF compression method we have not looked at. Let's take
  345. a very in-depth look into JPEG...
  346.  
  347. JPEG Compression:
  348. ─────────────────
  349.  
  350. First, a few definitions (taken from the JPG2GIF.DOC file/slightly modified):
  351.  
  352. - A CONTINUOUS TONE IMAGE is one where there aren't any sharp edges between 
  353. objects in the image. Instead, there are lots of intermediate colors around the
  354. edges of objects. Images like this are created when you scan a photograph or
  355. use a video digitizer with a video camera. Another property of continuous tone
  356. images is that there aren't any large areas which are only one color; rather,
  357. there are many subtle different shades of color.
  358.  
  359. - A DRAWN IMAGE is exactly that, an image drawn using a paint program. Drawn 
  360. images look like they are out of comic books; they have sharp edges and large
  361. areas which are one solid color.
  362.  
  363. - JPEG compression is an image compression technique which compresses 
  364. continuous tone images. You can JPEG-compress drawn images, but the results 
  365. aren't exactly pleasing (most drawn and JPEG'd files grow by a LARGE amount!)
  366.  
  367. - GIF is a compression technique which works on both continuous tone or drawn
  368. images. GIF compression works much better on drawn images, but most of the GIF
  369. images in the world are continuous tone images.
  370.  
  371. Now that we have those out of the way, let's explain what JPEG is, what it 
  372. does, where it came from, etc...
  373.  
  374. The best quality JPEG images result when you start with 24-bit, undithered
  375. images. Unfortunately, GIF does not support 24-bit images; and most of the 
  376. 8-bit GIF images are dithered. In short, there are VERY few 24-bit images 
  377. floating around in the PC arena. The reason for this is that to work with them
  378. in the first place, you need to have a Targa video board or an XGA-compatible 
  379. PS/2. Both are relatively expensive for the end user.
  380.  
  381. So, if you are using a scanner or digitizer to produce images, you can get 
  382. better compression ratios--and better quality images--if you generate 24-bit
  383. Targa or TIFF files and then convert them to JPEG files. You can't do this
  384. with GIF2JPG, however. (Author's Note: A separate program by the same company
  385. [Handmade Software], called Image Alchemy, will perform this task for you.)
  386.  
  387. GIF2JPG performs basically the same task as GIFLITE--filtering out non-vital
  388. information--but uses a standard algorithm, as defined by the JPEG committee
  389. (see the end of this article for the JPEG address).
  390.  
  391. Unlike GIFLITE, however, GIF2JPG allows you to define a "quality factor," which
  392. determines the amount of compression, the resulting image quality, and the 
  393. amount of image degradation. A higher quality factor will preserve more of the
  394. image quality, while a lower quality factor will compress the file more by 
  395. removing more of the image information. While this may seem powerful, it is 
  396. also tedious and dangerous. Every GIF is different, and using a set quality 
  397. factor on each one will cause all but a few GIFs to turn out looking extremely
  398. poor. For this reason, it is necessary to test-compress each GIF at least twice
  399. to find a happy medium between compression and image loss. At 10 seconds (my 
  400. average) for every 10Kb being compressed (using the default factor of 55), if
  401. I compressed all 80 megs here at The Rubicon, it would take me at least 21 
  402. HOURS!
  403.  
  404. JPEG files can be un-JPEG'd back into GIF files, and JPEG compression is almost
  405. never (emphasis: NEVER) faster than GIFLITE compression, but it must also be 
  406. taken into account that JPEG compression is NOT a lossless compression method!
  407. If you compress a file using JPEG and then turn around and uncompress it, the 
  408. original and the uncompressed files WILL NOT BE THE SAME. In fact, there will 
  409. be a significant amount of degradation between the two files.
  410.  
  411. Let's do a compression comparison on the same files we used with GIFLITE. We'll
  412. use basically the same chart, with a few exceptions. We will need three 
  413. separate file size listings - the original GIF, the compressed GIF, as well as
  414. the GIF after being uncompressed again. These will be listed as #1, #2, and #3,
  415. respectively. We will also run four separate tests instead of three. The first 
  416. will be run using a quality factor of 20, the second using 40, the third with 
  417. the default factor of 55, and the fourth will be run using a quality factor of
  418. 75. In addition, the time to convert back to .GIF from .JPG will also be 
  419. included, listed as "UnCompres" (compression time will be listed as 
  420. "Compress").
  421.  
  422.   ┌─────────┬───────────────┬───────────────┬──────────────┬──────────────┐
  423.   │GIF File │  3BABES.GIF   │ CALVIN2.GIF   │ CLAUDIA.GIF  │ WATERFAL.GIF │
  424.   │Resolut. │ (640x480x256) │ (320x200x16)  │ (607x774x16) │ (576x360x4)  │
  425.   ├─────────┼───────────────┼───────────────┼──────────────┼──────────────┤
  426.   │20% Qual.│#1   260.61 Kb │#1   8.19 Kb   │#1  107.52 Kb │#1   22.14 Kb │
  427.   │         │#2    39.06 Kb │#2   8.19 Kb   │#2   68.89 Kb │#2   22.14 Kb │
  428.   │         │#3   262.58 Kb │#3   8.19 Kb   │#3  108.43 Kb │#3   22.14 Kb │
  429.   │ Redux   │85.1% reduction│0.0% reduction │36% reduction │0.0% reduction│
  430.   │Compress │Time: 4:14.85  │Time: 0:24.89  │Time: 3:20.58 │Time: 1:42.22 │
  431.   │Uncompres│Time: 9:48.23  │Time: 0:02.29  │Time: 6:55.76 │Time: 0:02.35 │
  432.   │ Loss?   │Considerable   │None detected  │Lots - spots  │Size distorted│
  433.   ├─────────┼───────────────┼───────────────┼──────────────┼──────────────┤
  434.   │40% Qual │#1   260.61 Kb │#1   8.19 Kb   │#1  107.52 Kb │#1   22.14 Kb │
  435.   │         │#2    61.21 Kb │#2   8.19 Kb   │#2   96.44 Kb │#2   22.14 Kb │
  436.   │         │#3   255.98 Kb │#3   8.19 Kb   │#3  113.72 Kb │#3   22.14 Kb │
  437.   │ Redux   │77.2% reduction│0.0% reduction │11% reduction │0.0% reduction│
  438.   │Compress │Time: 4:19.14  │Time: 0:25.10  │Time: 3:27.67 │Time: 1:36.51 │
  439.   │UnCompres│Time: 9:51.66  │Time: 0:02.14  │Time: 6:57.16 │Time: 0:02.36 │
  440.   │ Loss?   │Significant    │None detected  │Darker/grainy │Size distorted│
  441.   ├─────────┼───────────────┼───────────────┼──────────────┼──────────────┤
  442.   │55% Qual │#1   260.61 Kb │#1   8.19 Kb   │#1  107.52 Kb │#1   22.14 Kb │
  443.   │(default)│#2    74.97 Kb │#2   8.19 Kb   │#2  107.52 Kb │#2   22.14 Kb │
  444.   │         │#3   257.84 Kb │#3   8.19 Kb   │#3  107.52 Kb │#3   22.14 Kb │
  445.   │ Redux   │ 72% reduction │0.0% reduction │0.0% reduction│0.0% reduction│
  446.   │Compress │Time: 4:24.35  │Time: 0:25.21  │Time: 3:33.50 │Time: 1:36.01 │
  447.   │UnCompres│Time: 9:59.79  │Time: 0:02.26  │Time: 0:02.75 │Time: 0:02.20 │
  448.   │ Loss?   │VERY poor qual.│None/No Compr.!│None/No Compr!│Size distorted│
  449.   ├─────────┼───────────────┼───────────────┼──────────────┼──────────────┤
  450.   │75% Qual │#1   260.61 Kb │#1   8.19 Kb   │#1  107.52 Kb │#1   22.14 Kb │
  451.   │         │#2    92.08 Kb │#2   8.19 Kb   │#2  107.52 Kb │#2   22.14 Kb │
  452.   │         │#3   262.33 Kb │#3   8.19 Kb   │#3  107.52 Kb │#3   22.14 Kb │
  453.   │ Redux   │ 65% reduction │0.0% reduction │0.0% reduction│0.0% reduction│
  454.   │Compress │Time:  4:29.64 │Time: 0:25.33  │Time: 3:39.42 │Time: 1:36.28 │
  455.   │UnCompres│Time: 10:08.79 │Time: 0:02.20  │Time: 0:02.69 │Time: 0:02.19 │
  456.   │ Loss?   │SEE NOTE BELOW │None/No Compr.!│None/No Compr!│Size distorted│
  457.   └─────────┴───────────────┴───────────────┴──────────────┴──────────────┘
  458.  
  459. Now that we've attained our results, let's examine them in more detail. We'll 
  460. go down the list by filename and quality factor (hereby known as "QF").
  461.  
  462. 3BABES.GIF
  463. ──────────
  464.  
  465.    20 QF - Took about 4 minutes to compress from 260K down to 39K. A VERY
  466.            impressive space gain indeed, but we lost a VERY considerable
  467.            amount of image integrity. The image was discernible enough,
  468.            but I would have been very dissatisfied had I downloaded it
  469.            somewhere. It took more than twice as long to convert back to
  470.            the "original" GIF, which ended up 2K bigger than the original.
  471.            Go figure.
  472.  
  473.    40 QF - Another 4 minutes to compress, with a 200K space gain. However,
  474.            contrary to what the GIF2JPG documentation says, this image was
  475.            MORE degraded than the 20 QF one, when it certainly should not
  476.            have been. Ten minutes to get the "original" back, 5K short.
  477.  
  478.    55 QF - Pretty much the same as 40 QF - a 190K gain this time. Time for
  479.            compression is increasing as the QF goes up... (For some reason
  480.            that strikes me as odd - if you're NOT doing much to the file,
  481.            it should go faster, right?)  Picture quality is better than
  482.            before, but still shows splotches and small portions of severe
  483.            degradation.
  484.  
  485.    75 QF - Less space gain, more time to compress/uncompress. Image was NOT
  486.            fully viewable. After running the test several times on this
  487.            file with the same results (GIF had an error halfway through it),
  488.            I gave up. This is yet another bug in GIF2JPG or the accompanying
  489.            JPG2GIF.
  490.  
  491. CALVIN2.GIF
  492. ───────────
  493.  
  494.    ALL --- NO compression was ever done on this file. This is a hand-drawn
  495.            GIF, and just as the GIF2JPG docs state, hand-drawn images gain
  496.            very little from JPEG compression. A complete waste of time with
  497.            this file. 
  498.  
  499. CLAUDIA.GIF
  500. ───────────
  501.  
  502.    20 QF - Three minutes compression gains about 40K. Uncompression gives
  503.            us a file 1K bigger than the original and takes twice as long.
  504.  
  505.    40 QF - Only a 10K compression this time, with a 10-second increase in
  506.            compression. Uncompression is at least twice as slow, and this
  507.            time we get a file 6K bigger than the original.
  508.  
  509.    55 QF - File would not compress under this QF. No gain or loss. Just
  510.            wasting more time...
  511.  
  512.    75 QF - Same with this QF (and higher - I tested 80 and 90 QF to see).
  513.  
  514. WATERFAL.GIF
  515. ────────────
  516.  
  517.    ALL --- Another waste of time. However, nothing in the docs makes mention
  518.            of this type of file (interlaced), or the fact that GIF2JPG simply
  519.            will not compress them at all (even at 5 QF!)  I consider that a
  520.            serious flaw. No space gain or loss, only a waste of CPU time.
  521.  
  522. Note also that it takes FOREVER to convert from a .JPG to a .GIF file - on
  523. *any* machine. It took almost 10 minutes to un-JPEG the 3BABES.GIF image, and
  524. almost 20 for the group of four!  And that was for EACH TEST RUN!
  525.  
  526. Compounding that problem is the SERIOUS FACT that GIFs may be compressed,
  527. uncompressed, compressed, transferred, uncompressed, and compressed again
  528. an UNLIMITED number of times. You may download a GIF that has been through
  529. the compression/decompression cycle tens of times, with no way of actually
  530. KNOWING it!
  531.  
  532. And each time, it lost some image information. Not to mention that image loss 
  533. is a subjective item. Major loss to some is minor loss to others -- you may 
  534. think 25% quality loss is ok, but Joe Uploader may think that 80% loss is 
  535. acceptable... so you may be downloading a file that has lost 85% or more of
  536. its original information!  Do this more than a few times, and the picture may
  537. well be completely useless.
  538.  
  539. There are other items against JPEG compression. For one, JPEG is and always was
  540. a 24-bit image compression technique. It originated in video recording and 
  541. editing studios as a way to store information in less space with minimal 
  542. quality loss. It was NEVER intended to be used on 8-bit machines with 8-bit
  543. images. ALL GIF images are 8-bit. Some may have been converted from 24-bit
  544. TARGA images, but they end up as 8-bit images.
  545.  
  546. [To be concluded in next month's WWIVnews]
  547.  
  548.