home *** CD-ROM | disk | FTP | other *** search
/ The Datafile PD-CD 5 / DATAFILE_PDCD5.iso / utilities / o / optpal / Doc_OP next >
Encoding:
Text File  |  1997-03-14  |  7.9 KB  |  177 lines
  1. OPTIMUM PALETTES
  2. ================
  3.  
  4.  
  5.  
  6. This is a commandline utility which reads in 32bpp sprites, finds a more or less
  7. optimal palette (1/2/4/8 bpp) and writes a dithered sprite with that palette as
  8. output file. To find the (near) optimal palette an iterative error-gradient method
  9. is employed -- there are probably better ways but the output thus created is very
  10. good so there's little motivation to change this, even though it's rather slow.
  11.  
  12. Usage:
  13. ------
  14.  
  15. op [-b# -i# -m# -v# -p<file> -f -g -G -c -C] <infile> <outfile>
  16.  
  17. where # are numbers (there may or may not be spaces between the switches and their
  18. numbers). The switches and their meaning are:
  19.  
  20. -b#    BPP of the output sprite. Legal values are 1,2,4 and 8.
  21. -i#    Maximum number of iterations, default 32.
  22. -m#    Match palettes with recursion depth # (see below)
  23. -v#    Verbose mode (0-3), determines how much output text should be written.
  24.     0: none; 1: only main stages; 2: each iteration (default);
  25.     3: palette matching stages.
  26. -p<f>    Write palette to file <f>. This output file will be a standard palette
  27.     file that should be usable on any machine. 256 colour palette file are only
  28.     usable on RiscPCs. For older machines use the program "setpal" also included
  29.     in this distribution.
  30. -f    Use hardware floating point instructions. This is recommended if your
  31.     machine has hardware FP. Otherwise you're better off not using this
  32.     switch which will make op use its own floating point code.
  33. -g    Make the output a greyscale image.
  34. -G    Make lightest and darkest greyscales (black/white) fixpoints, i.e. these
  35.     colours will remain unchanged during the iteration.
  36. -c    Like -G but additionally make the purest spectral colours fixpoints. For
  37.     instance for red this is the colour where red/(green+blue) is maximal. Sadly
  38.     this usually results in very dark colours which is pretty useless...
  39. -C    Like -G but additionally make brightest spectral colours fixpoints. This
  40.     means the largest quantity of each of the three spectral colours used in the
  41.     source sprite. This is usually a lot better than -c.
  42.  
  43.  
  44. First up op will sort the source sprite to get the number of individual colours.
  45. This is usually pretty quick (a couple of seconds) but may in extreme cases take
  46. up several minutes :-(.
  47.  
  48. op will iterate until the palette doesn't change anymore or the maximum number of
  49. iterations has been reached. The number output each iteration is the sum of the
  50. weighted, squared errors which is usally very large (around 1e10); it won't go
  51. anywhere near zero unless you have fewer individual colours than palette entries
  52. in which case there will be no iteration in the first place. Typically the error
  53. will go down to 1/100th to 1/1000th its original value. The currently best
  54. palette has a `*' in front of the error.
  55. Don't be discouraged when the computation starts diverging after a couple of
  56. iterations, that's perfectly normal. Convergence is pretty rare with sprites
  57. with >= 4bpp. This is also the reason why I'm talking of "more or less" optimal
  58. palettes since a gradient method can only find local minima - all you can do is
  59. hope it's a global one as well... (and usually it's pretty damn close).
  60. The time taken for each iteration is mostly dependent upon the number of individual
  61. colours, not the sprite's size as such. This may take quite long - after all in
  62. the worst case each colour has to be verified with each palette entry to determine
  63. the best match. op uses a pretty smart system to be able to terminate the lookup as
  64. soon as possible but especially towards the beginning this will not always be
  65. possible.
  66. So in conclusion: it takes a lot of time, but the output is really good.
  67.  
  68.  
  69. Dithering:
  70. ----------
  71.  
  72. Hmm... not much to say here. I use a dithering method that propagates two error
  73. values. The reason the dithering takes longer than ChangeFSI's is that you're
  74. comparing ChangeFSI dithering to the default palette which it knows quite a bit
  75. about to op dithering to an utterly arbitrary palette which will naturally take
  76. up more time. To verify this set the current palette using the -p file and tell
  77. ChangeFSI to output to current mode - you'll be amazed how much longer it'll take...
  78.  
  79.  
  80. Fixpoints:
  81. ----------
  82.  
  83. There's one problem here: the most extreme colours (be it brightness or colour
  84. saturation) will be "drawn" towards the middle by the iteration, i.e. the image
  85. will be mellowed-out a little (this effect is hardly noticable with 8bpp but
  86. the stronger the fewer bpp). A typical effect is white becoming somewhat yellow.
  87. To remedy that you can declare some colours fixpoints. The -G switch will make
  88. the lightest and darkest greyscale fixpoints (usually white and black), -c and
  89. -C try the same for the three spectral colours. If you're using one of the later
  90. I'd go for -C since -c usually results in very dark colours.
  91. The effect of declaring fixpoints is preserving small areas of extreme colours
  92. - say a small spot of bright red - at the cost of a higher error. Neither switch
  93. has much effect in 256 colour modes. With 16 colours all of them can make a
  94. difference but using -c/-C fixes 5 colours out of 16 which will make the
  95. approximation pretty bad so I'd only use -G in that case. In 1 or 2 bpp modes
  96. only -G is possible in the first place and even that is not a good idea, if you
  97. ask me...
  98.  
  99.  
  100. Palette Matching:
  101. -----------------
  102.  
  103. If you only want to find the (more or less) best palette you needn't worry about
  104. this. Palette Matching is a purely cosmetic aspect re. viewing the output sprites
  105. with the current palette forced to their palettes. This attempts to permute the
  106. palette found in such a way that it best fits the default palette for that mode.
  107. And since permutation means exponential complexity we're in trouble.
  108. The palette matching used by op is a recursive procedure with a maximum recursion
  109. depth of (n - 1) where n = number of colours in palette. Explaining how it works is
  110. pretty complicated, all you need to know is that the smaller the value you pass
  111. to -m the faster the matching will be done and the worse the match will be. If
  112. you intend to view the sprites in the desktop with the current palette forced to
  113. theirs I recommend at least -m1 although this will take some time in 256 colour
  114. modes. In 16 or less colour modes you can usually go for the full depth without
  115. ludicrous delays but -m1 is definitely the maximum I'd use for 256 colour sprites.
  116. The lowest value possible at all is -m0 which actually does more harm than good in
  117. 256 colour modes.
  118.  
  119. The output you get in this stage if you specified -v3 is closely linked to the
  120. way the algorithm works. Basically each line means one colour matched. It's all
  121. a bit complicated...
  122.  
  123.  
  124.  
  125. The setpal utility:
  126. -------------------
  127.  
  128. This sets the current palette to the one output into a file by op. Use:
  129.  
  130. setpal <palname>
  131.  
  132. where <palname> is the name of the palette file. Since setpal registers as a WIMP
  133. task to be able to force a redraw you can't start it from a task window. You can't
  134. run it from single tasking either since the WIMP isn't active then. So you either
  135. have to write the command in an obey file or call it via the TaskManager (-> NewTask).
  136.  
  137. Make sure that the current mode has the same number of colours as specified in the
  138. palette file. For 256 colour palettes: use this only if your hardware allows free
  139. programming of all 256 palette entries (RiscPC, older machines with graphic cards).
  140.  
  141. The easiest way to view the output sprites with their palette is to get the latest
  142. version of !Deep4All (0.12) which can do this without any hassle and doesn't even
  143. need the palette file.
  144.  
  145.  
  146.  
  147. What, no WIMP frontend?
  148. -----------------------
  149.  
  150. No.
  151.  
  152. Anyone can write one if (s)he so pleases. I didn't make it a WIMP program for a couple
  153. of reasons:
  154.  
  155. 1) I have more important things to do
  156. 2) I like running stuff in task windows that don't lock up the computer
  157. 3) As an owner of an old A5000 it's imperative to me that something like this runs
  158.    with !Virtual.
  159.  
  160.  
  161.  
  162.  
  163.  
  164. LEGAL ISSUES and CONTACT:
  165. =========================
  166.  
  167. This program is Videoware. For what this means and how to contact me read the file
  168. VIDEOWARE.
  169.  
  170.  
  171. Hopefully this proves useful to some people,
  172.  
  173.  
  174.  
  175.  
  176. Andreas Dehmel, March 97
  177.