home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / sys / next / programm / 7126 < prev    next >
Encoding:
Text File  |  1992-11-10  |  3.6 KB  |  86 lines
  1. Newsgroups: comp.sys.next.programmer
  2. Path: sparky!uunet!ornl!utkcs2!darwin.sura.net!zaphod.mps.ohio-state.edu!usc!venice!gumby.dsd.trw.com!deneva!news
  3. From: kieffer@spf.trw.com (Robert Kieffer)
  4. Subject: Re: Changing alpha only?
  5. Message-ID: <2AFFE819.29D6@deneva.sdd.trw.com>
  6. Sender: news@deneva.sdd.trw.com
  7. Organization: TRW Inc., Redondo Beach, CA
  8. References: <1992Nov10.053919.19601@ohsu.edu>
  9. Date: Tue, 10 Nov 92 16:49:28 GMT
  10. Lines: 74
  11.  
  12. In article <1992Nov10.053919.19601@ohsu.edu> filibert@vista (Daniel  
  13. Filiberti) writes:
  14. > Hi Everybody!
  15. > 
  16. > Another quirky problem.  I need to mask an area of an image
  17. > by changing the alpha value within the area to 1 (for
  18. > example) and everything outside the area to (0).  The
  19. > catch is that I need to retain the original RGB data within
  20. > the whole image (not just the masked area! otherwise
  21. > clipping would work!).  I have a path to clip to, easy
  22. > enough, but how can I draw only to the alpha channel?  Or,
  23. > how do I use some strange combination of compositing
  24. > functions to do this?  The images are RGB tiffs, no alpha,
  25. > so compositing defaults to an opaque alpha (1, I
  26. > think)... 
  27. > 
  28. > In simpler terms, I need all of the image data, and the
  29. > alpha channel to mask a region of interest within
  30. > it...easy, right?  Any takers? 
  31. > 
  32. > Daniel Filiberti 
  33.  
  34. Well Daniel, I'm afraid you're out o' luck.
  35.  
  36. What you were probably looking for is the DIN ("destination in") composite  
  37. operation.  The output is the destination data, masked by the source alpha  
  38. value.  However, you're going to run into problems I expect.  Read on...
  39.  
  40. I ran into a problem trying to do some related work a few months back  
  41. (i.e. change alpha w/out affecting the RGB values). So, I started  
  42. exploring...
  43.  
  44. It turns out that NeXT kind of outsmarts themselves here.  In their (TIFF)  
  45. representation of image data, they do a pre-multiplication of the RGB  
  46. channels by the alpha channel to help speed up the compositing operations.   
  47. This comes from the fact that the SOVER operation, for instance, is  
  48. mathematically represented as:
  49.  
  50.     RGB' = a * RGB1 + (1-a) * RGB2
  51.  
  52.     RGB' = new value for red, green, or blue channel
  53.     RGB1 = overlay(source) RGB value
  54.     RGB2 = "underlay" (destination) RGB value
  55.     a = alpha value of overlay image
  56.     (all values range 0 -> 1)
  57.  
  58. What Next does is store the RGB values already multiplied by the  
  59. corresponding alpha (i.e. the "a*RGB1" component of the above equation).   
  60. Now then, keeping in mind that the values used in the 8-bit TIFF images  
  61. represent "virtual" values of 0 -> 1, any RGB value that is larger then  
  62. the alpha value is invalid. So, if you use the composite operation I  
  63. described above to make a region of your image totally transparent (set  
  64. the alpha to 0) all corresponding color information also gets set to zero  
  65. and is subsequently lost! :^(  Returning the alpha to 1 (255 in 8-bit)  
  66. just multiplies the, now zero, color information by one and you get zero,  
  67. a black image.
  68.  
  69. The upshot of this is that if you want to retain the RGB information,  
  70. you're better off keeping a raw version of the data around, and tweaking  
  71. with the alpha values separately... then, when you want to display it, do  
  72. the multiplication by alpha and create a [disposable] NXBitmapImageRep for  
  73. it.
  74.  
  75. Sorry, this got kind of long winded.  I hope it makes sense.
  76.  
  77. I vaguely recall confirming all of this with Ali Ozer, the NeXT graphics  
  78. guru, at the time I was hashing it out so I'm pretty sure it's correct.   
  79. It shouldn't be hard to write your own routine to check this out if you  
  80. want, though.
  81.  
  82. Anyway, let me know if you have questions.
  83.  
  84. Robert Kieffer
  85. kieffer@spf.trw.com
  86.