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.
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.
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. You will have to load it all over again if you do this more than once to a given GIF image. 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
--On 02/14/05 09:23:47 PM +0000 Rosenstrauch, David wrote:
I have a strange situation happening. Perhaps someone can help me make head or tails of it?
I'm loading up a GIF image (i.e., 8-bit/256 color), then creating an offscreen BufferedImage (initially with TYPE_INT_ARGB, but I've tried others as I'll explain later). I then proceed to paint a white background onto it, paint the GIF onto it, paint some black text over it, and trying to write it out again as a GIF, using a GIF encoder utility. The GIF encoder, however is throwing an exception re: > 256 colors.
I'm able to avoid this problem by creating an image of TYPE_BYTE_INDEXED, but the quality of the image suffers as a result (it looks "grainy", for lack of a better word).
I realize that what's happening is that there's a 32-bit image being produced, and that it's rendering with > 256 colors, and so that's why I'm having this problem. But I can't understand why it's rendering with > 256 colors. As the initial image was a GIF, it was only using an 8-bit set of colors, and the only other colors I'm using are black and white, both of which I believe are already being used elsewhere in the image. So I can't see how I'd be using more colors than the original image.
Anyone have any idea what might be happening here and how to work around it? I'll use the grainy output image if I have to, but I'd prefer not to if I can avoid it.
(BTW, I do know about PNG, JPEG, etc., but unfortunately I'm stuck with GIF format for reasons outside of my control.)
TIA,
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".
