home *** CD-ROM | disk | FTP | other *** search
/ 17 Bit Software 3: The Continuation / 17-Bit_The_Continuation_Disc.iso / files / nz29a.dms / nz29a.adf / FIGsupp4 / FIG.doc < prev    next >
Text File  |  1993-12-03  |  6KB  |  149 lines
  1.                              Fig Documentation 
  2.  
  3. Program: Fig.
  4.  
  5. Author:
  6.     John Bickers (JJB TEMPLAR),
  7.     214 Rata St,
  8.     Naenae.
  9.  
  10. Sources:
  11.     The following documents were used in creating this program:
  12.  
  13.     1.  gifstd.txt: Incomplete Compuserve decription of GIF87a standard.
  14.     2.  "A Technique for High Performance Data Compression"
  15.                 Terry A Welch, IEEE Computer, vol 17 no 6 (June 1984)
  16.  
  17. Purpose:
  18.     To convert a Compuserve GIF file to IFF format, on the suggestion of
  19.     Tony Wills, who also supplied a description of the GIF format, GIF
  20.     files, and various GIF programs.
  21.  
  22. Usage:
  23.     The conversion process is as follows:
  24.         *   Decode GIF file into wrk file.
  25.         *   If deinterlace necessary then convert wrk file into
  26.             deinterlaced wrkD file, delete wrk file, rename wrkD file as
  27.             wrk file.
  28.         *   Convert wrk file into IFF file, delete wrk file.
  29.  
  30.     The following notes also apply:
  31.         1.  The maximum dimensions for the GIF picture are 1024 x 1024 x 8.
  32.             Thus a work file space of a little more than 1Meg is required
  33.             for images this large.
  34.  
  35.             The GIF data is just reformatted into IFF format, so no data is
  36.             lost. However, many such pictures are not viewable on the Amiga
  37.             with the standard tool ("display", by C.Scheppner). In order to
  38.             see the image to some extent, use "mash" to convert a 6 to 8
  39.             plane picture into 5 planes. The final IFF file is viewable by
  40.             most programs (if there is sufficient CHIP RAM to contain the
  41.             pic). In this respect, another supplementary program "tdis" may
  42.             be useful.
  43.  
  44.             The reason work files are used at all is that most people will
  45.             not have enough RAM to accomodate a RAM based version of fig on
  46.             large pictures. And work files provide a useful input format
  47.             for supplementary programs like "mash".
  48.  
  49.         2.  Only the first image in a GIF file is converted. If the image
  50.             has a local color map, hopefully fig treats it OK, but I
  51.             haven't a suitable GIF file to test it with.
  52.  
  53.         3.  Absolute worst case stack requirement is about 48K. For most
  54.             pictures, 10000 is sufficient. For very big pictures, 20000 is
  55.             usually sufficient. If in doubt, make your stack 50000. This
  56.             stack increase is required because one of the functions used
  57.             may recurse to a max depth of almost 4096, with 4 bytes return
  58.             address plus 4 bytes parameter plus 4 bytes local per call.
  59.             If the program runs out of stack, it will just exit. Thus files
  60.             may not be closed (and so be tied up).
  61.  
  62.         4.  The default wrk file directory is the current directory,
  63.             regardless of the GIF filename's path. The default IFF file
  64.             output is also to the current directory.
  65.  
  66.         5.  Some pictures do not contain all the data they should. These
  67.             will be converted with a warning, and the wrk file will be
  68.             padded out to a suitable size with zeros.
  69.  
  70.         6.  If the work file ends up with a depth of 6, fig will output
  71.             a CAMG chunk into the ILBM file, saying that the picture's
  72.             ViewMode is EXTRA_HALFBRITE. Use the -h option to indicate HAM.
  73.  
  74. Options:
  75.     d[str]
  76.         When the ILBM has been written the program described by [str] is
  77.         run with it as an argument. If no [str] is specified, the default
  78.         string of "display" is used. This is an ILBM viewer (by
  79.         C.Scheppner, CATS).
  80.  
  81.     l
  82.         Leave work work files behind.
  83.  
  84.     L
  85.         Only create work file. Do not convert to ILBM.
  86.  
  87.     o{str}
  88.         Use the filename {str} as the name of the output ILBM.
  89.  
  90.     O
  91.         Fig will usually choke on a GIF file if the signature is not equal
  92.         to "GIF87a". This option ignores that. It is up to you to be sure
  93.         that a differently signed standard is the same as GIF87a.
  94.  
  95.     v
  96.         Display information as it progresses through the conversion. It
  97.         does not intrude into the decoding/deinterlacing/IFF writing loops.
  98.  
  99.     w{str}
  100.         This will preface wrk files with the string {str}. For example:
  101.                 CLI 1> fig -wRAM: pic.GIF
  102.         will create its wrk file(s) in RAM:
  103.  
  104.     W
  105.         Indicates input filename is already a wrk file.
  106.  
  107. Wrk file format:
  108.     The format is:  +----------------+
  109.                     | My Descriptor  |
  110.                     +----------------+
  111.                     |     colors     |
  112.                     +----------------+
  113.                     |   scanline 1   |
  114.                     +----------------+
  115.                     |     .....      |
  116.                     +----------------+
  117.                     |   scanline n   |   n = GIF picture height
  118.                     +----------------+
  119.                     | decode overrun |
  120.                     +----------------+
  121.     Where the components are:
  122.         1)  My Descriptor:-
  123.                 struct MyDes {
  124.                     UWORD   w;
  125.                     UWORD   h;
  126.                     UWORD   d;} MyDes;
  127.         2)  colors:
  128.                 1<<MyDes.d 3-byte values, representing RGB values. If the
  129.             GIF file did not have color information, these are all 000.
  130.         3)  scanline:
  131.                 MyDes.w bytes, where each byte represents the value of a
  132.             pixel, left to right. It is one byte per pixel, regardless of
  133.             the actual depth of the image. These values are indexes into
  134.             the color table above.
  135.                 There are MyDes.h of these scanlines, from 1 to MyDes.h
  136.         4)  decode overrun:
  137.                 There may be a few extra bytes of rubbish on the end,
  138.             leftovers from the decoding process.
  139.  
  140. Distribution:
  141.     This program is freely redistributable and usable, provided it is
  142.     accompanied by this documentation file.
  143.  
  144. Complaints/Suggestions/Questions/Aquiring source:
  145.     Contact:    John Bickers,
  146.                 214 Rata St,
  147.                 Naenae.
  148.     Or:     jbickers%templar@actrix.co.nz
  149.