dwatola@NEXTASY2.EECS.WSU.EDU (David Watola) (06/05/91)
theoretically, the same grayscale dps code should produce the same result on a color nextstation as a monochrome nextstation, right? i don't typically get to use a color station, but i just ran across a little problem that prevented me from giving a demo on a color machine. i have a custom view class that draws one of a set of NXImages cached as NXEPSImageReps. The drawing routine for this custom view only does one thing-- it does a [theNXImage drawRepresentation:theNXEPSImageRep inRect:&theBounds] which draws a properly scaled version of that image in the view. TFM says that drawRepresentation:inRect: fills in the view with the background color, then draws the image. the problem is that this background color is white on a monochrome system, and black (same as the pen color, unfortunately) on a color system. why? i never explictly set any background colors, and the default color is NX_COLORCLEAR (i.e. transparent). so why does transparent mean white on one system and black on the other? just wondering... doesn't matter too much. dave watola dwatola@yoda.eecs.wsu.edu
eps@toaster.SFSU.EDU (Eric P. Scott) (06/05/91)
In article <9106050533.AA20158@nextasy2.eecs.wsu.edu> dwatola@NEXTASY2.EECS.WSU.EDU (David Watola) writes: >the problem is that this background color is white on a monochrome system, >and black (same as the pen color, unfortunately) on a color system. why? Your image has an alpha channel and you're not compositing it properly. -=EPS=-
izumi@mindseye.berkeley.edu (Izumi Ohzawa) (06/05/91)
In article <1669@toaster.SFSU.EDU> eps@cs.SFSU.EDU (Eric P. Scott) writes: >In article <9106050533.AA20158@nextasy2.eecs.wsu.edu> > dwatola@NEXTASY2.EECS.WSU.EDU (David Watola) writes: >>the problem is that this background color is white on a monochrome system, >>and black (same as the pen color, unfortunately) on a color system. why? > >Your image has an alpha channel and you're not compositing it properly. > In last weeks demo of RenderMan for NeXT at a BaNG DeveloperSIG, RenderMan was run on NeXTdimension and Monochrome NeXTstation side-by-side. It exhibited the same problem. Now, RenderMan is by Pixar, and Pixar is where the alpha channel was invented. So, it is one of the following: [1] NeXT goofed. [2] Pixar goofed. [3] It's a feature of NeXT alpha channel. My guess is [3]. Izumi Ohzawa [ 大澤五住 ] USMail: University of California, 360 Minor Hall, Berkeley, CA 94720 Telephone: (415) 642-6440 Fax: (415) 642-3323 Internet: izumi@violet.berkeley.edu NeXTmail: izumi@pinoko.berkeley.edu
aozer@next.com (Ali Ozer) (06/06/91)
In article <1991Jun5.091018.21988@agate.berkeley.edu> Izumi Ohzawa writes: >[1] NeXT goofed. >[2] Pixar goofed. >[3] It's a feature of NeXT alpha channel. >My guess is [3]. The bottom line with black alpha vs white alpha is: Do not show alpha on the screen; what you get is system dependent. I tend to think of drawing alpha into a window as cutting a hole in that window, and what you see is the inside of the back of your monitor. (Of course some might argue that this should cause whatever is under this window (for instance, other windows, or the Workspace background) to show through... Well, yeah, that's a neat idea, but NeXTstep does not do non-rectangular windows.) So when do you use alpha? When creating images which will be layered on top of each other, for instance. You might either read a TIFF with transparency, or create an NXImage, clear it to transparent and draw some stuff in it. Then these images would be layered on top of some background using operators such as SOVER, which causes the alpha bits of the layered image to determine the color of the pixels that show up on the screen without actually putting the alpha on the screen. Going back to the original message: David Watola writes: >I have a custom view class that draws one of a set of NXImages cached as >NXEPSImageReps. The drawing routine for this custom view only does one >thing-- it does a > > [theNXImage drawRepresentation:theNXEPSImageRep inRect:&theBounds] > >which draws a properly scaled version of that image in the view. TFM >says that drawRepresentation:inRect: fills in the view with the background >color, then draws the image. Here's what the documentation says about drawRepresentation:inRect: : The NXImage uses this method to cache its representations and to print them. By overriding it in a subclass, you can change how representations appear in the cache, and thus how they'll appear when composited. For example, you could scale or rotate the coordinate system, then send a message to super to perform this version of the method. This method is here only for subclassers; it should not be used by other objects. It is the method an NXImage uses to cache one of its representations in its very own internal caches. The reason you end up getting alpha on the screen is because NXImage clears the cache to transparent (the default background color) before drawing the EPS file in it; thus, in your case, because you are drawing in your view, the alpha goes directly to the view. The correct ways to draw EPS reps include: 1. If you don't want to cache it, then simply create an instance of NXEPSImageRep and use draw or drawIn: to draw it: theEPSImageRep = [[NXEPSImageRep alloc] initFromFile:"BugsBunny.eps"]; ... // later, in drawSelf:: : [theEPSImageRep drawIn:&bounds]; 2. If you want to cache the EPS (which might be a nice idea if you'll draw it many times, or the view is destined to be in a ScrollView), then create an NXImage from the EPS file and use composite:toPoint: to draw it: theEPSImage = [[NXImage alloc] initFromFile:"BugsBunny.eps"]; ... // later, in drawSelf:: : PSsetgray (NX_WHITE); // These two lines might not be NXRectFill (&bounds); // necessary or might be different... [theEPSImage composite:NX_SOVER toPoint:&bounds.origin]; Ali, Ali_Ozer@NeXT.com