myoung@joker.sgi.com (Mark Young) (07/23/90)
I'm working on a class project that does simple color halftoning, and I want to be able to set up the color table and then write color index values to the pixels on the screen. I looked over the color stuff in volume five and it wasn't obvious how you would go about doing this...everything seemed to want RGB colors which would then get mapped for you. is this easier than it looks? can someone give me an RTFM reference to volume V that explains this... thanks. ...myoung
gerhard@cs.arizona.edu (Gerhard Mehldau) (07/24/90)
In article <10754@odin.corp.sgi.com>, myoung@joker.sgi.com (Mark Young) writes: > > I'm working on a class project that does simple color halftoning, and I > want to be able to set up the color table and then write color index values > to the pixels on the screen. > > I looked over the color stuff in volume five and it wasn't obvious how > you would go about doing this...everything seemed to want RGB colors which > would then get mapped for you. > > is this easier than it looks? can someone give me an RTFM reference to > volume V that explains this... > > thanks. > > ...myoung I have struggled through this, too - IM V and the 32-Bit QuickDraw documentation really isn't very clear on this topic (Apple, are you listening?). First, you need to create a color table - either within your program, or as a resource which you can read in from your resource file. You then convert the color table to a palette (with all entries allocated as pmTolerant+pmExplicit), and associate the palette with the window(s) in question. You can then create an offscreen pixmap, set the individual pixels to whatever index you want, and do a CopyBits() to put them on-screen. The code for the color table/palette stuff should look like this (note that this code requires 32-Bit QuickDraw to be installed): CTabHandle gTable; PaletteHandle gPalette; gTable = GetCTable(kColorTable); /* read in from resource file */ gPalette = NewPalette((*gTable)->ctSize+1,gTable,pmTolerant+pmExplicit,0); SetPalette((WindowPtr)(-1),gPalette,TRUE); /* make default palette */ Good luck! - Gerhard -- -> Gerhard Mehldau Dept. of Computer Science internet: gerhard@cs.arizona.edu University of Arizona uucp: {cmcl2,noao,uunet}!arizona!gerhard Tucson, AZ 85721, U.S.A. at&t: +1 (602) 621-4632
lsr@Apple.COM (Larry Rosenstein) (07/24/90)
In article <23410@megaron.cs.arizona.edu> gerhard@cs.arizona.edu (Gerhard Mehldau) writes: > >I have struggled through this, too - IM V and the >32-Bit QuickDraw documentation really isn't very >clear on this topic (Apple, are you listening?). If you can get a copy, the first issue of _develop_ magazine had 3 articles about 32-bit Color QuickDraw, the Palette Manager, and offscreen worlds. >can read in from your resource file. You then >convert the color table to a palette (with all You can create the palette directly (without the intermediate color table). There's also a resource format you can use. -- Larry Rosenstein, Object Specialist Apple Computer, Inc. 20525 Mariani Ave, MS 46-B Cupertino, CA 95014 AppleLink:Rosenstein1 domain:lsr@Apple.COM UUCP:{sun,voder,nsc,decwrl}!apple!lsr
gerhard@cs.arizona.edu (Gerhard Mehldau) (07/24/90)
In article <9342@goofy.Apple.COM>, lsr@Apple.COM (Larry Rosenstein) writes: > If you can get a copy, the first issue of _develop_ magazine had 3 articles > about 32-bit Color QuickDraw, the Palette Manager, and offscreen worlds. Me, a poor student? :-) But I'll try to get my hands on one... > >can read in from your resource file. You then > >convert the color table to a palette (with all > > You can create the palette directly (without the intermediate color table). > There's also a resource format you can use. True, but you still need the color table later on, when you want to create an offscreen world... - Gerhard -- -> Gerhard Mehldau Dept. of Computer Science internet: gerhard@cs.arizona.edu University of Arizona uucp: {cmcl2,noao,uunet}!arizona!gerhard Tucson, AZ 85721, U.S.A. at&t: +1 (602) 621-4632
johnston@adhawk.Eng.Sun.COM (Scott Johnston) (07/24/90)
In article <23410@megaron.cs.arizona.edu> gerhard@cs.arizona.edu (Gerhard Mehldau) writes: >In article <10754@odin.corp.sgi.com>, myoung@joker.sgi.com (Mark Young) writes: >> >> I'm working on a class project that does simple color halftoning, and I >> want to be able to set up the color table and then write color index values >> to the pixels on the screen. >> >> [stuff deleted...} >> >> ...myoung > >I have struggled through this, too - IM V and the >32-Bit QuickDraw documentation really isn't very >clear on this topic (Apple, are you listening?). > > [stuff deleted...] > >The code for the color table/palette stuff should >look like this (note that this code requires 32-Bit >QuickDraw to be installed): > >CTabHandle gTable; >PaletteHandle gPalette; >gTable = GetCTable(kColorTable); /* read in from resource file */ >gPalette = NewPalette((*gTable)->ctSize+1,gTable,pmTolerant+pmExplicit,0); >SetPalette((WindowPtr)(-1),gPalette,TRUE); /* make default palette */ > >Good luck! > >- Gerhard I have been flailing miserably with this, too, so correct me if I am wrong. Isn't the color table created with the above set of commands still dependent upon the underlying device CLUT? And this device CLUT has not changed? So, the way I understand it, the Color Manager will attempt to find the closest RGB matches between this newly created CLUT and the device CLUT. What if you wanted to do 256-tone Gray Scale? Wouldn't you need to go in and modify the device's CLUT directly in order to get this wide range of grays? Just worth mentioning: modifying the device CLUT gets ugly. All the cached fonts, etc become invalidated, and I have had a difficult time trying to bring to machine back to the state it was in before I messed with the CLUT. Maybe there's a lesson here...:^) Thanks in advance for any advice and/or help. sj johnston@portia.stanford.edu johnston@adhawk.sun.com ----------------------------
gerhard@cs.arizona.edu (Gerhard Mehldau) (07/25/90)
In article <139442@sun.Eng.Sun.COM>, johnston@adhawk.Eng.Sun.COM (Scott Johnston) writes: > >The code for the color table/palette stuff should > >look like this (note that this code requires 32-Bit > >QuickDraw to be installed): > >CTabHandle gTable; > >PaletteHandle gPalette; > >gTable = GetCTable(kColorTable); /* read in from resource file */ > >gPalette = NewPalette((*gTable)->ctSize+1,gTable,pmTolerant+pmExplicit,0); > >SetPalette((WindowPtr)(-1),gPalette,TRUE); /* make default palette */ > I have been flailing miserably with this, too, so correct me if > I am wrong. Isn't the color table created with the above set of > commands still dependent upon the underlying device CLUT? And > this device CLUT has not changed? So, the way I understand it, > the Color Manager will attempt to find the closest RGB matches > between this newly created CLUT and the device CLUT. No, it doesn't. If you set the tolerance to 'pmTolerant+pmExplicit', the palette manager will do all the ugly work of modifying the CLUT for you - and, even better, will switch back to the old CLUT when your application quits. And you do get the exact colors you want in exactly the locations you requested them. > What if you wanted to do 256-tone Gray Scale? Wouldn't you need > to go in and modify the device's CLUT directly in order to get > this wide range of grays? Again, no. I've been using the above code to create a palette with a 128-level grayscale, and 128 colors (for an image processing application), and it works just fine... > Just worth mentioning: modifying the device CLUT gets ugly. It certainly does. I should know - this was also one of my earlier attempts at solving the problem (before 32-Bit QuickDraw was released). > sj - Gerhard -- -> Gerhard Mehldau Dept. of Computer Science internet: gerhard@cs.arizona.edu University of Arizona uucp: {cmcl2,noao,uunet}!arizona!gerhard Tucson, AZ 85721, U.S.A. at&t: +1 (602) 621-4632