Hi David,
The short "guess" answer for your problem is that I imagine that doing a getColorModel() on one of your screen components will help you make this determination, but the fact that you have to check this screen depth concerns me for the following reasons:
Robot always returns a 24-bit image regardless of screen depth. If there is an issue with color depth, it is not in the image that we give you from that API.
It sounds like this GIF encoder package you found does some funny work under the covers to process the pixels and ends up using a system ColorModel when it doesn't need to. It doesn't have to have native code to have this dependency, it could make use of Component.getColorModel() and end up with such a dependency, though it is still pretty much unnecessary. In the new age (JDK 1.2 and later) of BufferedImage objects any reasonable encoder would work directly with the color depth that is given to it. You might want to look for another encoder.
I might also recommend using PNG instead of GIF for this reason. The GIF format is restricted to at most 256 colors and so all of your great snapshots of your rich 24-bit color depth screens will end up getting dithered when reduced to 256 colors for writing as a GIF file. PNG supports 24-bit images so no color reduction will be needed for your screen snapshots to write out an image.
JPEG also writes out full color images, but uses a "lossy" compression that doesn't work well for text, line art, or GUI images. PNG is a better choice because it uses non-lossy compression, though JPEG at a very low compression factor could look much better than a dithered GIF image.
Finally, we supply both PNG and JPEG encoders built into the JDK as of 1.4 in the javax.imageio package. No need to download an external package to write out images...
...jim
--On Thursday, October 21, 2004 2:50 PM -0400 "Rosenstrauch, David" <[EMAIL PROTECTED]> wrote:
Hi David,
you can use BufferedImage bi = ...; ColorModel cm = bi.getColorModel(); int bpp = cm.getPixelSize();
Thank you, Dmitri
Hmmm. That did work (thanks!), but it looks that's not actually what I'm looking for after all. Let me clarify my problem a little bit then.
One of our developers wrote some code to do a screen scrape: generate a BufferedImage using the java.awt.Robot. We then try to save that to a GIF using an encoder class we found. But we ran into a problem: the GIF encoding worked on some people's machines and failed on others. Turns out that the deciding factor was whether the user's PC is set to 16-bit color or to a higher setting. Writing the GIF would succeed on 16-bit boxes, but fail for 24- or 32-bit: we'd get an exception thrown from the encoder indicating that the image contained more than 255 colors (which I assume is a limit for the GIF format).
Now I'm able to successfully work around the problem whenever I get that exception by converting the image to 16 bit (by creating a new buffered image BufferedImage.TYPE_USHORT_565_RGB). But I'd like to make this more efficient. I don't want to have to get halfway through encoding the image before I get that "> 255 colors" exception and then have to go and re-do the encoding using the converted image. I'd much rather find a way to query up front as to whether the original image is not encodable as a GIF due to too many colors and, if so, then do the conversion and in this way I would only ever have to do the encoding once.
Although the getPixelSize() method you mentioned does show the difference between the pixel sizes of the original and the converted images (24 bit as opposed to 16), that's not a sufficient query to use for this purpose. On a machine with 16-bit color (where I'm able to encode the image fine without any exceptions thrown) getPixelSize() still reports the original image at 24 bits, even though it will encode to GIF just fine.
So I guess the problem is not just determining the pixel size, but rather how many colors are actually in use by the image. Anyone know of a technique I can use to do that?
Thanks,
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".
