home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / sys / mac / programm / 18056 < prev    next >
Encoding:
Internet Message Format  |  1992-11-06  |  5.1 KB

  1. Path: sparky!uunet!gumby!wupost!waikato.ac.nz!ldo
  2. From: ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University)
  3. Newsgroups: comp.sys.mac.programmer
  4. Subject: Re: QuickTime and Fast Dithering
  5. Message-ID: <1992Nov6.151855.12011@waikato.ac.nz>
  6. Date: 6 Nov 92 15:18:54 +1300
  7. References: <40577@sdcc12.ucsd.edu>
  8. Followup-To: comp.sys.mac.programmer
  9. Organization: University of Waikato, Hamilton, New Zealand
  10. Lines: 87
  11.  
  12. In article <40577@sdcc12.ucsd.edu>, sakelley@euclid.ucsd.edu (Scott Kelley) writes:
  13.  
  14. > I'm doing a project in MacroMind Director that also uses QuickTime.
  15. > Since Director's built in support for QuickTime isn't sufficient for our
  16. > needs, I've beed writing XObjects (Director's version of XCMD's) to play
  17. > back movies and still images. We want to store stills and video clips at
  18. > 24-bit color and then have them "dither down nicely" for display on
  19. > 8-bit systems.
  20. >
  21. > Here's the problem I'm having: by default, QuickTime is displaying
  22. > everything using it's "fast dither" algorithm. This is fine for video
  23. > clips, but for still images (JPEG), we'd like to do a little better.
  24. > According to the QT 1.0 developer's guide, page 3-20:
  25. >
  26. >    "Apple decompressors use fast dithering when copying from image band
  27. >    buffers to 8-bit destinations. If the accuracy for decompression is
  28. >    above normal, then the decompressors use true error diffusion rather
  29. >    than fast dithering."
  30. >
  31. > Does this imply that QT will ALWAYS use fast dithering to an 8-bit
  32. > destination, or is it possible to bump up the "accuracy" setting for
  33. > playback to get better results? If so, how can I set this accuracy
  34. > setting? This setting is NOT the "temporal/spatial quality" setting;
  35. > I've tried setting those high and low and I always get the fast dither.
  36. > I have found a couple of functions in the movie toolbox (like
  37. > SetMediaQuality) and in the image compression manager
  38. > (SetDSequenceAccuracy) that seemed to imply (I hope) that I could
  39. > specify that I wanted high quality just before I started playback, and
  40. > that I would get what I want. But I haven't been able to sort out the
  41. > details well enough to actually try it yet.
  42.  
  43. Hi, Scott!
  44.  
  45. Now, you need to keep a number of different concepts straight here:
  46.  
  47. * The spatial/temporal quality settings govern the amount of *compression*
  48.   you get; as you rightly observed, they don't control whether the decompressors
  49.   use fast dithering on playback or not.
  50. * The media quality setting (as set by SetMediaQuality) is nothing more than
  51.   an informational hint to the Movie Toolbox; it allows you to have alternative
  52.   versions of tracks that contain the same information at different quality
  53.   levels (e g a video track optimized for 4-bit displays versus another one
  54.   optimized for 8-bit displays), and have the Movie Toolbox automatically pick
  55.   the right one based on your system configuration.
  56. * You're getting very warm with your comment about SetDSequenceAccuracy.
  57.   When you decompress an image, you can specify an "accuracy" setting, which
  58.   specifies how much effort the decompressor should put into the job. You
  59.   can specify a range of numeric values, but all that really happens in
  60.   practice is that, if you specify a value of "normal", then you will get
  61.   fast dithering (if appropriate), whereas if you specify a value greater than
  62.   this, the image will be drawn using standard QuickDraw drawing modes,
  63.   including normal QuickDraw dithering if appropriate.
  64.  
  65. Unfortunately, the playback decompression sequence is buried in the depths of
  66. the workings of the video media handler, and I know of no calls to let you get
  67. access to it.
  68.  
  69. > I should also probably point out that right now I'm working with JPEG
  70. > images stored as single-frame movies. This is because Director's native
  71. > support for QuickTime only recognizes MooV files, so to get it to load a
  72. > JPEG image, I have to store it as a movie. I could store the JPEG images
  73. > as compressed PICT images and then use Director's "link to file" option
  74. > for PICT's, but that doesn't work for us because it stores absolute
  75. > pathname links. Eventually we will move to using all our own XObjects to
  76. > talk to QuickTime, and, if necessary, I can write a separate XObject
  77. > for stills.
  78.  
  79. I'd say you're really better off abandoning the single-frame movie approach,
  80. and storing your stills as (JPEG-compressed) PICTs. And if Director is too
  81. inflexible with its links to files, then to hell with it--write that stills
  82. XObject!
  83.  
  84. One of my current projects is a simple interactive tour, with lots of still
  85. images stored as JPEG-compressed PICT files. I'm doing it in HyperCard, with
  86. a whole lot of custom XCMDs and XFCNs. I'm actually storing aliases to the
  87. individual picture files, which gives you a bit more flexibility in how you
  88. arrange things.
  89.  
  90. I think Director is a marvellous tool for creating animations, but I personally
  91. prefer to put together final presentations in HyperCard. It's sort of like
  92. plasticine: some may see it as a kids' toy, but I can mould it into any shape
  93. I want!
  94.  
  95. Lawrence D'Oliveiro                       fone: +64-7-856-2889
  96. Computer Services Dept                     fax: +64-7-838-4066
  97. University of Waikato            electric mail: ldo@waikato.ac.nz
  98. Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+13:00
  99.