home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / sys / apple2 / 17894 < prev    next >
Encoding:
Internet Message Format  |  1992-07-25  |  2.4 KB
  1. Path: sparky!uunet!charon.amdahl.com!amdahl!fadden
  2. From: fadden@uts.amdahl.com (Andy McFadden)
  3. Newsgroups: comp.sys.apple2
  4. Subject: Re: Jpeg for the GS
  5. Message-ID: <f3l303y743mr00@amdahl.uts.amdahl.com>
  6. Date: 24 Jul 92 20:32:14 GMT
  7. References: <1992Jul21.155143.28113@sdf.lonestar.org> <bill.711807511@braille.uwo.ca>
  8. Distribution: World
  9. Organization: Amdahl Corporation, Sunnyvale CA
  10. Lines: 43
  11.  
  12. In article <bill.711807511@braille.uwo.ca> bill@braille.uwo.ca (Bill Carss) writes:
  13. >
  14. >This is one of the many areas about which I know very little.  According to
  15. >several friends of mine who are system level programmers JPeg is a flawed
  16. >system.  After packing and unpacking GIFs or whatever you begin to loose some
  17. >of the picture quality.  I would be willing to bet that the same could be 
  18. >said for any version of the process.
  19.  
  20. What a strange thing to say.
  21.  
  22. The JPEG scheme is, by definition, a "lossy" compression scheme.  (You don't
  23. pack GIFs with it; it's similar in function to GIF.)  Why would anyone want a
  24. scheme which degrades picture quality?  Because you can squash pictures down
  25. to 10 or 20% of their original size.
  26.  
  27. It's intended for "real world" scanned-in images, which are usually so grainy
  28. that you can't see any loss in quality.  Unless you require super-resolution
  29. and high quality (certainly not needed for alt.binaries.pictures.*), it's a
  30. good way to go, because the amount of storage required and the time to transmit
  31. images is dramatically reduced.
  32.  
  33. I think you had the right idea, but "flawed" is certainly the wrong word.
  34. Don't forget that ACE (Audio Compression & Expansion, available as a toolset
  35. on the //gs) is also a lossy scheme.
  36.  
  37. As far as a JPEG viewer goes, there isn't one.  Decoding JPEG is much more
  38. time consuming than decoding GIF; it requires a lot of multiplies and divides,
  39. which the '816 isn't particularly adept at.  An assembly version of the JPEG
  40. decoder would be reasonably fast, but the format is more complicated than GIF
  41. and so nobody has stepped forward to tackle it (instead we get 20 different
  42. GIF decoders...)
  43.  
  44. The JPEG decoder available on tybalt (as a //gs shell EXE only) will convert
  45. JPEG to GIF, which will allow you to view them with existing software.  Having
  46. an actual JPEG viewer would just remove the intermediate step (though it might
  47. provide a few more decoding options...).
  48.  
  49. >Bill Carss
  50. >bill@braille.uwo.ca
  51.  
  52. -- 
  53. fadden@uts.amdahl.com (Andy McFadden)
  54. [ Above opinions are mine, Amdahl has nothing to do with them, etc, etc. ]
  55.