Is it possible that text antialiasing is turned on? (It might be on by default) If so, when you paint black text over the image you will wind up with many more colors (shades of gray) at the edges of the text. That would easily bump up the number of colors to greater than 255.
Seth On Wed, 16 Feb 2005 20:17:04 -0000, Rosenstrauch, David <[EMAIL PROTECTED]> wrote: > Hi Jim. Thanks for the response. > > > > Hi David, > > > > Where are you getting the IndexColorModel for your TYPE_BYTE_INDEXED > > image? If you use: > > > > new BufferedImage(w, h, TYPE_BYTE_INDEXED); > > > > then you get the default palette with a set of colors that may not > > match the original GIF image's color palette. As a result, trying > > to do any kind of manipulation with the image will result in color > > approximations. > > That is what I was initially doing. > > > > There is another constructor where you can specify your own palette > > in a custom IndexColorModel: > > > > new BufferedImage(w, h, TYPE_BYTE_INDEXED, icm); > > > > If you can retrieve the IndexColorModel from the original GIF > > then you might have better luck constructing a matching BYTE_INDEXED > > image using this constructor. This is probably easier done if you > > use the Image I/O framework since it returns a BufferedImage which > > will let you get the ColorModel directly. If you use any of the > > various "getImage(file)" or "createImage(file)" methods on Toolkit > > and Component then you will get back a somewhat "opaque" file which > > doesn't let you query its ColorModel very easily. > > Yes, that occurred to me yesterday too, and I tried to switch it over to use > the method you described, but still seemed to have the problem. As I > indicated yesterday, I render a white background, the original image, and some > overlaid black text onto a new BufferedImage, and then shuffle that new > BufferedImage off to the GifEncoder. If I try to create that buffered image > using TYPE_USHORT_565_RGB I get the "too many colors" error, and if I try it > with TYPE_BYTE_INDEXED then I get a grainy image. Somehow even with your > suggested changes I'm exceeding the color limit, but I'm not sure how. > > Hmmm - one possibility comes to mind, but it's a remote one: I think that the > original image might be using transparency instead of white. So perhaps the > original is already using 255 colors, and the addition of the white color > (and/or the black text color) is pushing it over the edge? Like I said, > though, seems like a pretty remote possibility. > > > > That answer explains why your previous technique might have gone > > wrong, but it also points out another solution that is potentially > > much easier. Use Image I/O to load the GIF and you will get back > > a BufferedImage. You should then be able to render directly into > > that BufferedImage without having to make a copy. > > Hmmm. That's an interesting idea. I'll have to give that some thought. > > > > If you want to create many different annoted versions > > of the image then you might get better perfomance by creating copies > > to modify rather than reloading and re-decoding the image every > > time, but you will need to take the issues I raised above into > > account when doing that... > > > > ...jim > > Yes, I'd have to do it that way, since I'm re-using the image over and over > and so can't be messing up the original. I'll have to see if this is > feasible. > > So far our solution has been to add PNG capability in addition to GIF. The > GIF output won't be as good as the PNG, but since I believe that some people > require it I have to support it. Kludgey state of affairs, though, so it'd be > good if I can find a way to address this. > > Thanks very much for the suggestions. I'll let you know how it goes. > > DR > > ============================================================================== > This message is for the sole use of the intended recipient. If you received > this message in error please delete it and notify us. If this message was > misdirected, CSFB does not waive any confidentiality or privilege. CSFB > retains and monitors electronic communications sent through its network. > Instructions transmitted over this system are not binding on CSFB until they > are confirmed by us. Message transmission is not guaranteed to be secure. > ============================================================================== > > =========================================================================== > To unsubscribe, send email to [EMAIL PROTECTED] and include in the body > of the message "signoff JAVA2D-INTEREST". For general help, send email to > [EMAIL PROTECTED] and include in the body of the message "help". > =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff JAVA2D-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
