home *** CD-ROM | disk | FTP | other *** search
/ Amiga ISO Collection / AmigaUtilCD2.iso / Programming / Assembler / dse-src3.dms / in.adf / Source / Ham / hamshadow1.txt / text0000.txt < prev   
Encoding:
Text File  |  1993-01-06  |  2.5 KB  |  61 lines
  1. In article <1121@leah.Albany.Edu>, rsb584@leah.Albany.Edu (Raymond S Brand) writes:
  2. > In article <2855@sugar.uu.net>, peter@sugar.uu.net (Peter da Silva) writes:
  3. > > And thirdly, they never seem to try propogating the HAM error backwards,
  4. > > even though this might produce better results...
  5.  
  6. > This is easy to say, and sometimes easy to see, but it isn't easy to do for
  7. > the general case.
  8.  
  9. Handling HAM at all isn't that easy to do for the general case... but people
  10. still do it.
  11.  
  12. > If erradicating this defect is that important to you, devise and
  13. > publish an algorithm/code that when given an X by Y image D bits deep, will
  14. > output an X by Y HAM image and color table such that the "HAM shadows" are
  15. > minimized for the image.
  16.  
  17. Well, the outline is conceptually easy. If you're handling HAM at all you have
  18. some sort of function that will tell you the distance between seperate colors
  19. so I'm going to take that as a given.
  20.  
  21. The simplest algorithm would be to alternate the error propogation on a
  22. scanline basis, the way nroff does to prevent rivers of whitespace in one
  23. or the other margin. A better algorithm would be:
  24.  
  25. Pass 1:
  26.     Initialise all tracked colors and counts to 0.
  27.     Scan:
  28.         When dist(color(this pixel), color(next pixel)) > thresh
  29.             If it's within thresh of a tracked color, inc
  30.                 its count, go on.
  31.             Else add it to the tracked color list.
  32.     Allocate top 16 tracked colors as true colors.
  33.     
  34. This is already more than most existing programs do, because they all seem to
  35. allocate true colors on the fly while generating the image, or let you
  36. do it manually. This of course assumes you HAVE a deeper bitmap to work
  37. from. As an experiment you could also try allocate the top 8 as true colors
  38. and then allocate the next 8 from the remaining colors unless a HAM change
  39. will put it within thresh...
  40.  
  41. Pass 2:
  42.     Scan:
  43.         When dist(color(this pixel), color(next pixel)) > thresh
  44.             If a single HAM change can make it within
  45.                 thresh, do it
  46.             Else If it's within thresh of a true color, assign
  47.                 that color.
  48.             Else if a single HAM change from LAST pixel will
  49.                 put THIS pixel within thresh of NEXT
  50.                 pixel, do it.
  51.             Repeat for double HAM change, if intermediate
  52.                 HAM color is within thresh.
  53.             Repeat for triple HAM change, if intermediate
  54.                 HAM color is within thresh.
  55.             Else If a true color is within a HAM change of new
  56.                 color, use that as the new color.
  57.             Else fall back on existing algorithm.
  58. -- 
  59.         Peter da Silva  `-_-'  peter@sugar.uu.net
  60.          Have you hugged  U  your wolf today?
  61.