home *** CD-ROM | disk | FTP | other *** search
/ ftp.cse.unsw.edu.au / 2014.06.ftp.cse.unsw.edu.au.tar / ftp.cse.unsw.edu.au / pub / doc / standards / GIFextensions < prev   
Encoding:
Internet Message Format  |  1992-10-18  |  10.2 KB

  1. Path: usage.csd.unsw.oz.au!metro!munnari.oz.au!uunet!wuarchive!usc!elroy.jpl.nasa.gov!ames!sgi!shinobu!odin!surfside.sgi.com!jindak
  2. From: jindak@surfside.sgi.com (Chris Schoeneman)
  3. Newsgroups: comp.graphics
  4. Subject: GIF extensions
  5. Message-ID: <11081@odin.corp.sgi.com>
  6. Date: 29 Jul 90 01:09:44 GMT
  7. Sender: news@odin.corp.sgi.com
  8. Reply-To: jindak@surfside.sgi.com (Chris Schoeneman)
  9. Organization: Silicon Graphics, Inc., Mountain View, CA
  10. Lines: 199
  11.  
  12.  
  13. In article <OTTO.90Jul27095755@tukki.jyu.fi> otto@tukki.jyu.fi (Otto J.
  14. Makela) proposes a new thread of discussion:  upgrading the GIF
  15. standard.  In the last couple of weeks, there have been several postings
  16. about this topic.  I wanted to add my $0.02.  Otto's suggestions are
  17. indented below.  Sorry about the size.
  18.  
  19.     The current (and only) GIF standard is GIF87a.  It was designed
  20. with extensibility and the hardware of the time in mind.  As a result
  21. the standard is:  1) easy to enhance, and 2) inadequate for today's
  22. hardware and user.  And now a brief lesson on the GIF standard.
  23.     Enhancements are added as '!' extension blocks.  Each block has an
  24. 8 bit function code;  if a reader doesn't know a particular function,
  25. it should skip over the block.  ALL GIF readers should accept '!' blocks
  26. and skip over them if necessary.
  27.     Tom Lane has pointed out that some GIF readers don't skip over
  28. unrecognized '!' blocks, but crash instead.  Therefore, these readers
  29. do not conform to the GIF standard.  Future versions of these readers
  30. should at least accept '!' blocks if not make use of them, otherwise
  31. these readers will become obsolete due to wider use of '!' blocks.
  32.     GIF87a allows multiple images per file and one logical screen.  The
  33. screen and each image may have its own color map (of up to 256 colors).
  34. Images fit onto the logical screen and may use the screens color map.
  35.  
  36. > better compression - some asymmetric 2D compressions squeeze the picture
  37. > real nice and are reasonably fast when decompressing; compression takes
  38. > more time, of course
  39.  
  40.     The GIF standard uses LZW compression which achieves good compression
  41. over a wide range of images.  It's also fast and easy to implement.  I
  42. don't know anything about 'asymmetric 2D' compression schemes and would
  43. like to hear more.  But adding it to GIF87a would probably double the
  44. size of an encoder or decoder.  And replacing LZW would make all current
  45. images unusable (unless translated).  So IMHO GIF should say with LZW.
  46.  
  47. > pixel shape information - on the PC with a VGA you can get about five
  48. > different pixel ratios, and on just any machine with different graphics
  49. > modes you end up with different shaped pixels in different modes; the
  50. > current standard does not support any pixel information
  51.  
  52.     This is true.  Aspect ratio information is, of course, very
  53. important.  I posted a proposal for a '!' extension to solve this
  54. problem two weeks ago.  The important bit was:
  55.  
  56. >   7 6 5 4 3 2 1 0   Byte #
  57. >  +---------------+
  58. >  |0 0 1 0 0 0 0 1|    1        '!' - GIF extension block introducer
  59. >  +---------------+
  60. >  |0 1 0 1 0 0 1 0|    2        'R' - For 'aspect Ratio'
  61. >  +---------------+
  62. >  |0 0 0 0 0 0 1 0|    3         2  - Two bytes in block
  63. >  +---------------+
  64. >  |  pixel width  |    4            - First part of ratio (numerator)
  65. >  +---------------+
  66. >  | pixel height  |    5            - Second part of ratio (denominator)
  67. >  +---------------+
  68. >  |0 0 0 0 0 0 0 0|    6         0  - extension block end code
  69. >  +---------------+
  70. >Let byte four equal 'x' and byte five equal 'y'  Then x:y is the _pixel_
  71. >aspect ratio.  'x' and 'y' should be relatively prime (ie they should
  72. >have no common divisor except one), but they don't have to be.
  73.  
  74. This proposal received a favorable response.  Allen Braunsdorf noted
  75. that this extension should apply to the logical screen, not individual
  76. images (for simplicity).  This makes a lot of sense, so:
  77.   All aspect ratio extension blocks after the first one or after any
  78.   image descriptors are ignored.
  79.  
  80. > more colors per image - now that VGAs are common, we've hit the end of the
  81. > standard; also for example the Amiga is able to show 4096 colors (albeit
  82. > restrictedly)
  83.  
  84.     Another important point.  While most VGA's today only allow 256 at
  85. once, this will change.  However, CompuServe, in an effort to save a
  86. few bits, only allows 3 bits to describe the number of bits per pixel,
  87. for a maximum of eight;  this means 256 colors tops.  GIF87a does use
  88. 24 bits to define these colors, though.  The 3 bit fields can't be
  89. widened within the GIF87a standard, though they could be overridden.
  90.     24 bit images won't be compressed much at all if all 24 bits are
  91. stored together since scanned images have a lot of noise.  In 8 bits
  92. noise isn't so bad, patterns usually form.  With 24 bits, noise is
  93. terrible;  figure on virtually no compression for a scanned image.
  94.     The solution, of course, is to separate the channels.  That is,
  95. store all the reds, then the greens, then the blues.  Now we have
  96. three 8 bit images.  This naturally presents a solution to the 8 bit
  97. color problem.  Since GIF87a allows multiple images per file, we can
  98. store a 24 bit image as three 8 bit images and some information on
  99. how to combine the images.
  100.  
  101.    7 6 5 4 3 2 1 0   Byte #
  102.   +---------------+
  103.   |0 0 1 0 0 0 0 1|    1        '!' - GIF extension block introducer
  104.   +---------------+
  105.   |0 1 0 1 0 0 1 1|    2        'S' - For 'Stencil'
  106.   +---------------+
  107.   |0 0 0 0 0 0 1 0|    3         3  - Three bytes in block
  108.   +---------------+
  109.   |  red stencil  |    4            - 24 bits of bit mask. Bitwise
  110.   +---------------+
  111.   | green stencil |    5            - AND the logical screen's color
  112.   +---------------+
  113.   |  blue stencil |    5            - with the mask before drawing.
  114.   +---------------+
  115.   |0 0 0 0 0 0 0 0|    7         0  - extension block end code
  116.   +---------------+
  117.  
  118. There should be no more than one of these before an image descriptor
  119. block (image data).  In any case, all but the first are ignored, and
  120. this block only affects the next image.  Every pixel in the area of
  121. the logical screen under the next image should be bitwise AND'ed with
  122. the 24 bit stencil mask.  Then image data should be bitwise OR'ed with
  123. the screen's data.
  124.     Now we can store a 24 bit image as three 8 bit images.  The first
  125. image (the red channel) would be preceeded by the '!' stencil
  126. extension:  0,83,3,0,0,0,0.  The screen pixels under the image are
  127. cleared to all zeros since we bitwise AND with 0.  The colors of the
  128. image are (r,g,b): (0,0,0),(1,0,0),(2,0,0),(3,0,0), ... ,(254,0,0),
  129. (255,0,0), i.e. all possible 8 bit red intensities.  Each pixel is OR'ed
  130. with the screen pixel (which has a zero).  When the decoder has
  131. finished drawing this image, all the red components of the image have
  132. been drawn.
  133.     The next image (green) is preceded by: 0,83,3,255,0,0,0.  The colors
  134. are all the greens.  The red channel of the screen pixels are unchanged,
  135. the green and blue channels are cleared.  After drawing the image, we
  136. have the red and green channels visible.
  137.     The final image (blue) is preceeded by: 0,83,3,255,255,0,0.  The
  138. image is drawn as above, resulting in the final 24 bit color image.
  139.  
  140. NOTE:  This extension isn't restricted to this scenario.
  141.   * From 1-8 bits can be added at once.
  142.   * Images with any number of bit planes (up to 24) can be drawn
  143.   * Bit planes can be drawn in any order
  144.  
  145.     We could make an image with 4 red planes, 5 green planes, and 3
  146. blue planes.  This could be stored as:
  147.   * 16 color red image, 32 color green image, 8 color blue image
  148.   * 16 color red image, 256 color green-cyan-blue image.
  149.   * 12 2 color images.
  150. The stencils and colors need only be set correctly.
  151.  
  152.     IMHO this extension gives a maximum of flexibility with a minimum
  153. of extra information and additions to GIF.
  154.  
  155. > define better color coding - for some reason, GIFs made on a Macintosh
  156. > tend to come out a lot darker on a PC (this could be a problem with the
  157. > Mac software, but I suspect that it's something more esoteric like the
  158. > color characteristics of a Mac display/display card vs. a PC VGA)
  159.  
  160.     This is probably due to the gamma's of the monitors.  Every montior
  161. has non-linearities in intensity.  If this isn't corrected for, images
  162. come out dark and contrasty.  Each GIF screen should have information
  163. about the gamma values it's calibrated to.
  164.  
  165.    7 6 5 4 3 2 1 0   Byte #
  166.   +---------------+
  167.   |0 0 1 0 0 0 0 1|    1        '!' - GIF extension block introducer
  168.   +---------------+
  169.   |0 1 0 0 0 1 1 1|    2        'G' - For 'Gamma calibration'
  170.   +---------------+
  171.   |0 0 0 0 0 0 1 0|    3         3  - Three bytes in block
  172.   +---------------+
  173.   |   red gamma   |    4            - Gamma values for each color.
  174.   +---------------+
  175.   |  green gamma  |    5            - Images are calibrated for display
  176.   +---------------+
  177.   |   blue gamma  |    5            - on a montior with these gammas.
  178.   +---------------+
  179.   |0 0 0 0 0 0 0 0|    7         0  - extension block end code
  180.   +---------------+
  181.  
  182. The gamma values are in fixed point, unsigned format:
  183.   +---------------+  Two integral bits, 6 fractional bits.
  184.   |7 6|5         0|  The actual floating point gamma is found
  185.   +---------------+  by dividing by 64.0
  186. The range is 0.0 - 3.984375, with a resolution of 0.015625.
  187. Since most montiors are in the range 1 - 4, this should be okay.
  188. Images can then be adjusted for different gamma values for display
  189. on any monitor.  The decoder must, or course, know the monitor's
  190. gamma values.  If only one is known, use it for all three colors.
  191.  
  192.     Only the first '!' gamma block should be used, all others are
  193. ignored.  Furthermore, the '!' gamma block should come before any
  194. image descriptor blocks.  If the field is absent, the decoder should
  195. assume 1.0 for all three colors.  This is probably wrong, and the
  196. decoder may want to indicate this.
  197.     Future images should be calibrated to a gamma of 1.0 for all
  198. colors.  The extension should be included so the decoder knows for
  199. sure that the gammas are all 1.0.  If absent the decoder may assume
  200. unity, but it may also assume that this assumption is wrong.
  201.  
  202. I've taken up enough bandwidth (overall I'd say I added my $2 :-).
  203. Anybody have any comments?  About the proposals, I mean, not the
  204. length.
  205.  
  206. -Chris Schoeneman
  207.            Chris Schoeneman | I was neat, clean, shaved and sober,
  208.     jindak@surfside.esd.sgi.com | and I didn't care who knew it.
  209.      Silicon Graphics, Inc. |        -Raymond Chandler
  210.           Mountain View, CA |         (The Big Sleep)
  211.